Hi Piotr, This is going to end up in a fairly steep learning proces for me, so it may take up a little more time; so when this small project may wait for your input so now and then, should not be a real problem. Still, solving this one might further a few other ones.
As, usually see replies/question/comments below. As a side-note: the vendor firmware deployed OpenWrt with the Atheros LSDK 9.2 closed-source driver for the AR9285 wifi chip. Could that explain why LEDE with the ath9k driver maxes txpower at 16 dBm while the stock firmware maxes out at 27 (or 26 ?) dBm ? Thanks for taking your time, Paul > Op 9 apr. 2017, om 22:06 heeft Piotr Dymacz <pep...@gmail.com> het volgende > geschreven: > > Hello Paul, > > Sorry for a late reply. > > On 06.04.2017 14:24, Paul Oranje wrote: >> Thanks for the info. >> The systematics for the generation of the build config from the makefiles is >> still quite obscure to me. A wiki lemma that puts some light in this would >> be welcome; once I do understand I may write one. > > That would be really kind. > >> See my questions/comments/replies in-line below. >> >> Ciao, >> Paul >> >> >>> Op 6 apr. 2017, om 09:51 heeft Piotr Dymacz <pep...@gmail.com> het volgende >>> geschreven: >>> >>> Hello Paul, >>> >>> On 05.04.2017 23:23, Paul Oranje wrote: >>>> Hello, >>>> >>>> I’m wondering how to make LEDE build automatically an initramfs image (for >>>> use with u-boot tftp recovery boot), when the ENH200EXT is selected as the >>>> target device. By setting "CONFIG_TARGET_ROOTFS_INITRAMFS=y" a working >>>> image is build that can be tftp-booted alright, but I would prefer that it >>>> is build automatically beside the sysupgrade image. >>>> >>>> The context would, as requested, be "target/linux/ar71xx/image/generic.mk". >>> >>> The "generic" subtarget doesn't have included "ramdisk" feature: >>> https://github.com/lede-project/source/blob/master/target/linux/ar71xx/generic/target.mk#L2 >>> >>> It's the one responsible for selecting the "TARGET_ROOTFS_INITRAMFS": >>> https://github.com/lede-project/source/blob/master/scripts/target-metadata.pl#L34 >> Does that mean that the initramfs can only be triggered by manually setting >> “CONFIG_TARGET_ROOTFS_INITRAMFS=y” ? > > AFAIK, yes. > >> That would mean that the LEDE build-bots would not generate initramfs images >> and people would need for the initial install to build such images >> themselves. Likely I’ve not understood well how it works and what follows >> hints how to do it. >> >>> https://github.com/lede-project/source/blob/master/config/Config-images.in#L11 >>> >>> On the other hand, "mikrotik" subtarget uses initramfs images as they are >>> required for initial LEDE flash: >>> https://github.com/lede-project/source/blob/master/target/linux/ar71xx/mikrotik/target.mk#L2 >> >> Adding "FEATURES += ramdisk” to the "Device/enh200ext” definition in >> "target/linux/ar71xx/image/generic.mk” does not work (tried it). > > "FEATURES" variable belongs to the target, not particular device and thus > cannot be changed/extended like this. Meanwhile I’ve spent some time browsing and inductively came to that very same conclusion. > >> Since the initramfs is only needed for some ar71xx target profiles, the >> FEATURES declaration should not be set in >> “target/linux/ar71xx/generic/target.mk”. If the FEATURE should be set in the >> context of a target.mk, then a new makefile >> "target/linux/ar71xx/engenius/target.mk" would be needed, or to what other >> makefile could/should "FEATURES += ramdisk” then be added ? > > A separate subtarget just for one device is a bad idea. AFAIK, the only way > to include initramfs by default would require extending "FEATURES" in > ar71xx/generic subtarget target.mk config, but… Fair enough. Does an added ramdisk feature result by default in building initramfs images for all profiles below the subtarget ? If so, would it be doable to undo that effect in the default Device/Profile/Build definition ? >>> Is the initramfs image required for initial LEDE image flash on your device >>> or is it just useful with recovery mode? >> The stock firmware cannot install a LEDE factory image, so the initramfs >> image is indeed needed for the initial install. > > I'm not sure if enabling initramfs images for a whole subtarget just because > of a single device makes sense at all. The preferred way is to have a working > "factory" image for this device or at least detailed how-to for installing > "sysupgrade" image inside vendor firmware, using some custom approach > (failsafe?). > > Can you explain what/where is exactly problem with upgrade from vendor > firmware to LEDE on your device? See below. > I have just extracted enh200ext-etsi-v1.5.1.0.bin (downloaded from [1]), and > I see that it's based on very old OpenWrt version (KAMIKAZE, r20146). mtd and > sysupgrade tools are there, also failsafe could be working. The sysupgrade command in incomplete (dependency on a missing component). But luckily mtd and fwenv tools work. It looks like the vendor (Senao/Engenius) has not really bothered to clean up all not used parts ... > > What's more, vendor upgrade script is just a regular shell script > (/etc/fwupgrade.sh) and doesn't look complicated. Thanks, a telnet into the booted ECB350 vendor failsafe did not offer that much info. The vendor’s firmware rootfs has now been unsquash-ed to be studied a little more. > With little bit more effort you should be able to find out (based on this > script code) how to prepare a working "factory" image. A try with a definition copied more or less from another Engenius device in legacy.mk $(eval $(call SingleProfile,Senao,64K,ENH200EXT,enh200ext,ENH200EXT,ttyS0,115200,$$(enh200ext_mtdlayout))) ended up with a sysupgrade and a factory image. So hopefully just another two tasks to go: port this recipe (definition) to generic.mk and test it. About porting the recipe to generic.mk: what would be needed for that ? About testing the factory image: Getting the stock firmware back in has posed a problem. I spoiled the vendor failsafe mtd (an uImage with a very minimal LUCI that just allows installing a stock firmware) and have so far not been able to find this specific mtd image on the Internet. I tried with the failsafe of another alike Engenius device (ECB350) and although it can be booted on the ENH200EXT from u-boot (bootm 0x9f670000) I did not succeed installing any stock firmware from it. That left me with trying to install a stock firmware manually with mtd ("mtd write openwrt-senao-enh200ext-root.squashfs rootfs" and “mtd write openwrt-senao-enh200ext-uImage-lzma.bin kernel"), but for some reason that did not work out well. But now with the vendors upgrade script at hand it should not be a problem anymore (think I forgot to fw_setenv the checksums …). > If there is a working failsafe in this device, you could also make use of it > and install LEDE with "mtd -r write…". I’ve not tried to enter the OpenWrt failsafe mode and cannot as long the device is not reverted back to the stock firmware. But that it would run the OpenWrt failsafe seems unlikely since it has purposed a separate mtd partition for that and that image is run by u-boot when the normal image (at 0x9f050000) cannot be loaded for some reason. > > [1] http://www.engeniusnetworks.com/product/product.php?c=14&s=34&p=92 > > -- > Cheers, > Piotr > >> >>> >>>> From what I have understood so far, the clause would be something like: >>>> >>>> define Device/enh200ext >>>> DEVICE_TITLE := Engenius ENH200EXT >>>> DEVICE_PACKAGES := rssileds >>>> BOARDNAME := ENH200EXT >>>> CONSOLE := ttyS0,115200 >>> >>> Side note: this is default under ar71xx target, drop this line in your next >>> patch please. >> OK, I’ll drop the CONSOLE line. >> >>> >>> Defaults: >>> https://github.com/lede-project/source/blob/master/target/linux/ar71xx/image/Makefile#L99 >>> >>> -- >>> Cheers, >>> Piotr >>> >>>> IMAGE_SIZE := 8192k >>>> IMAGES := initramfs.bin sysupgrade.bin >>>> MTDPARTS := >>>> spi0.0:256k(u-boot)ro,64k(u-boot-env),6272k(firmware),1536k(failsafe),64k(art)ro >>>> endef >>>> TARGET_DEVICES += enh200ext >>>> >>>> The sysupgrade image is build, but the initramfs image is not build. I >>>> suppose an IMAGE/initramfs declaration must be added, but I do not know >>>> what to declare or call. >>>> >>>> Some help would be appreciated, >>>> >>> >>> >>> _______________________________________________ >>> Lede-dev mailing list >>> Lede-dev@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/lede-dev >> > > > _______________________________________________ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
