[Battlemesh] Ligowave DLB devices hardware
ufo at rund.freifunk.net
Thu Nov 19 16:50:12 CET 2015
Who else has such a device, with original-firmware on it?
I was smashing our one-and-only device, so we are not able to test it
with openwrt any more :-(
On 19.10.2015 17:13, Daniel Golle wrote:
> 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.
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
More information about the Battlemesh