Hi Enric, On 30 January 2015 at 01:10, Enric Balletbo Serra <eballe...@gmail.com> wrote: > Hi Simon, > > 2015-01-30 2:24 GMT+01:00 Simon Glass <s...@chromium.org>: >> Hi Enric, >> >> On 26 January 2015 at 10:55, Enric Balletbo Serra <eballe...@gmail.com> >> wrote: >>> I just tried boot with my OMAP3 based board (IGEPv2) and I found that >>> is broken in current mainline and v2015.01. The boot process stops at >>> >>> reading u-boot.img >>> >>> Did someone, with another OMAP3 board, have the same problem? >>> >>> I bisected the problem and looks that was introduced in following commit. >>> >>> commit b3f4ca1135edd66d14254089bbeb8077c6d0bb72 >>> dm: omap3: Move to driver model for GPIO and serial >>> >>> Reverting the patch boots again. Any clue? >> >> It looks like someone else had this problem: >> >> http://patchwork.ozlabs.org/patch/433866/ >> > > This patch is made by me, I sent this patch :) > > But the patch only replaces the use of show_boot_progress for the > STATUS_LED API, Which is better for that purpose. But the root problem > is not solved. > > Looks like the problem is the gpio_request call inside the function > show_boot_progress. If I'm not wrong the gpio_request implementation > is different when device model is used, and for some reason doing a > gpio_request inside the show_boot_progress function hangs. If I remove > the gpio_request from show_boot_progress it boots as expected. What's > the difference between gpio_request implementation when using DM or > not? Maybe it's a malloc problem?
Well gpio_request() is probably a no-op in the non-driver-model case. We should call gpio_request() once, in the board init, ideally before any calls to show_boot_progress(), since otherwise GPIO operations will fail. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
