Tom Rini <trini@xxxxxx> writes: > On 06/25/2013 02:20 PM, Paul Walmsley wrote: >> + Vaibhav and Kevin >> >> Hi, >> >> On Tue, 25 Jun 2013, Felipe Balbi wrote: >> >>> On Mon, Jun 17, 2013 at 05:23:17AM +0000, Paul Walmsley wrote: >>>> Boot to userspace: >>>> FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt >>> >>> Paul, we have at least 2 different folks who can't reproduce your bone >>> and bone black boot to userspace failures. I wonder how you're trying to >>> boot them. >>> >>> Care to share your test scripts ? >> >> Sure... the methodology is completely open and has been posted in the >> online logs since the first test cycle. (For some reason, almost no one >> clicks through the test directory trees that I post online. Is this a >> documentation issue? What can we do to make it easier for people to >> explore this?) > > Well, another link never hurts the search results :) > > [snip] >> Am certainly open to the idea that there's something wrong with the way >> that I'm booting either of these. But AFAIK no one's been able to >> identify exactly what it could be. I haven't had the time recently to >> spend hours going through the various permutations, given all the other >> breakage :-( BeagleBone-white has the additional complication that it is >> not easy to automate, due to the way that power is delivered to the board, >> so there is an extra dimension of difficulty there. > > Ah-ha, I reproduced your failure. If I make up a concat uImage + DTB, > rather than pass them separately, it fails to boot. If you switch to > mainline U-Boot (v2012.10 or later) you get support for separate image + > dtb (v2013.04 gives you bootz and zImage support). v2013.04 will also > work out of the box for BeagleBone-Black. Just to confirm, my problems with mainline were with appended DTB also. Separate DTB and zImage work fine (at least using u-boot v2013.04.) That being said, appended DTB should still work, so there's a bug hiding someplace that needs to be found fixed. Can you guys update your tests to test appended DTB also? Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
