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

Reply via email to