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? Regards, Enric > Regards, > Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot