[Battlemesh] Ligowave DLB devices hardware
daniel at makrotopia.org
Mon Oct 19 17:13:12 CEST 2015
On Mon, Oct 19, 2015 at 09:38:37AM +0200, Jernej Kos wrote:
> On 18. 10. 2015 20:54, Daniel Golle wrote:
> > How are you figuring out which firmware partition to use (and split
> > into kernel + rootfs + rootfs_data) on boot? imho the only way would
> > be reading the U-Boot environment, which would need to be implemented
> > in the kernel (or hard-coding for one of the two firmware 'banks')
> We are using the latter option, so the partition is hardcoded. I agree
> that proper autodetection from the bootloader would be much better.
> > As device-tree is the new way for firmware to pass-down stuff to the
> > kernel, supporting legacy pre-device-tree versions of U-Boot in
> > recent kernels will most likely be rejected upstream.
> If I understand correctly, this would require the bootloader to actually
> properly pass things to the kernel, so explicit support in the existing
Exactly. If you really want dual-boot, have the boot loader tell the
kernel which part of the flash to use in a clean way rather than have
the kernel figuring it out from the bootloader environment.
> > For U-Boot the rules a different, obviously, because it's under GPL.
> > Recent versions of U-Boot support device-tree and thus parsing the
> > u-boot-env inside the kernel would no longer be needed if the sources
> > of the stock bootloader were public.
> How would having the bootloader sources help? Would it be possible to
> support autodetection without modifying the bootloader that is already
> present on the devices?
No. But it would allow replacing the loader with something which is not
a GPL violation if redistributed by third parties (like OpenWrt.org).
However, I also prefer supporting the existing loader, simply because
it's much less effort and easier to achieve.
The whole ar71xx hardware platform is full of ugly support for hacks
by $boardvendor, so one more hopefully won't hurt too much....
> > Anyway, please share :)
> Your patch is much better as you added proper support for all the LEDs,
> I didn't have time to look into that. And you also based it on trunk,
> which has much cleaner device definition style, while we have it on BB.
> Anyway, for reference:
Thanks a lot, I'll have a closer look at it in the next days.
More information about the Battlemesh