Hi Felix, Thank you for the response. My responses inline below.
On Thu, Apr 11, 2013 at 9:49 AM, Felix Fietkau <n...@openwrt.org> wrote: > On 2013-04-11 6:10 AM, Ben West wrote: > > Hi All, > > > > I just successfully flashed trunk r36255 onto an AR2315-based > > Engenius/Senao EOC-1650, and an Engenius EOC-2611P, albeit with the > > following patches and modifications: > > > > target/linux/atheros/config-3.8 (disable gpiolib related options that > > interfere with SPI flash chip select) > How does it interfere with the flash chip reset? Which GPIO pin is > causing issues? > I do not know (yet) which GPIO the Engenius devices use for chip select, or if indeed that is the root problem. The schematics for these boards are not available, nor the pinout of Atheros SoC BGA (at least from my searching). My presumption of Engenius using non-standard GPIO for chip select comes from this statement from Jonathan Bither made on this listserv, which itself repeats a comment by nbd in changeset 16765. https://lists.openwrt.org/piperm9whicail/openwrt-devel/2012-November/017469.html https://dev.openwrt.org/changeset/16765 The statements about chip select could be incorrect, but the patch disabling CONFIG_LEDS_GPIO does work-around the boot problem. Given the symptoms described above in ticket # 11969, where might you recommend I start looking? > > > target/linux/atheros/base-files/etc/uci-defaults/01_leds (comment out > > ucidef commands for LEDs) > > https://dev.openwrt.org/ticket/11969 > > > > target/linux/atheros/patches-3.8/100-board.patch (change from GPIO 5 to > > GPIO 0 for soft reboot) > > https://dev.openwrt.org/ticket/6202 > > > > Finally, kmod-leds-gpio must /not/ be enabled in .config before building. > Why? > > I do agree, on reflection, that whether the kmods-leds-gpio package is enabled or not likely becomes moot after disabling CONFIG_LEDS_GPIO in the target kernel config. I had not yet had the chance to specifically try rebuilding the image with CONFIG_LEDS_GPIO disabled but kmod-leds-gpio enabled. > > Also, a /subset/ of these modifications (disabled CONFIG_LEDS_GPIO in > > target/atheros/config-3.8) was required for trunk to boot on an Open > > Mesh OM1P, too. Otherwise, it failed with squashfs errors, similar to > > those described in issue #11969 above. * > > > > These modifications do address the symptoms, but they neglect the > > underlying issue that certain atheros-based boards, like the Engenius > > devices, appear to use different GPIO assignments for soft reset and > > chip select. > Before you attempt to address the root causes, please do some more > research on what the *exact* root causes are, especially the ones that > you worked around by disabling GPIO/LED access. > Information about the AR231x-generation Engenius products seems scant, and so I posted to this list in case other list members could be help with such research. The tickets and changeset cited above contain the most current information about this older Engenius platform that I've been able to find thus far. > > > I can submit patches containing these modifications, but they would be > > specific to these boards and presumably rejected on those grounds. > > Likewise, these mods also completely disable any soft control of LEDs. > Correct, such patches would not be accepted. > > > Previous discussion on this topic indicated the preferred approach is to > > migrate the atheros platform to board-specific target profiles, like how > > was done with ar71xx. > > > > What is the best way to begin here? Is there information available on > > how board-specific target profiles are defined? > Board specific target profiles are not a suitable way to deal with this > problem. With platforms like ar71xx, the same build works on all common > devices (through kernel command line patching). > ar71xx is not a good example on where a platform rework should go, the > use of Device Tree is preferred, and it has been implemented in the > ramips and lantiq platforms. If you want to do a proper rework of the > target, those are good examples to look at. > Thank you very much for the pointer to Device Tree in the ramips and lantiq platforms. That helps greatly. > > - Felix > -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
