Re: OMAP baseline test results for v3.10-rc6
On 07/30/2013 03:23 PM, Paul Walmsley wrote: Do you know if anyone ever got serial cold-booting working well for, say, OMAP3 and OMAP4 chips? I had done configuration header based OMAP3 boot[1] once upon a time, but serial boot straight to kernel, we need a second that gives control there.. could be done, have'nt heard it done + I dont directly see a customer usage model for it ("ROI for investment of time") - so doubt any investment was done. CH was the closest I could get to avoiding bootloaders in it's entirety. but the level of interest fell off when there was no viable usage model for the same. [1] http://marc.info/?t=12723240113&r=1&w=2 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
Hi Tom, On Mon, 29 Jul 2013, Tom Rini wrote: > On 07/29/2013 04:29 AM, Paul Walmsley wrote: > > On Wed, 26 Jun 2013, Tom Rini wrote: > >> > >> Well, me? I'm all in favor of people using latest release of U-Boot for > >> their board and yelling and screaming (or just reporting bugs) when > >> things don't work. I'm biased of course. > > > > That's exactly how bootloader developers should be testing their changes. > > But most of the rest of us kernel folks don't want to deal with constantly > > replacing bootloaders, and then dealing with the inevitable bootloader > > regressions, when what we're really trying to test is the kernel... > > The kernel should be completely independent of the bootloader used. > > And thus the chicken and egg problems we have today. The kernel should > be independent, but unless someone is also testing more recent U-Boots > as well, we may or may not have more hidden clock problems. It doesn't have to be this way :-) IMHO the only thing that the bootloader should be responsible for is the minimum that's needed to get the kernel started. Setting up RAM, maybe a handful of critical system clocks, and that's basically it. In fact it would be great if there was a bootloader option where it would return the rest of the bits on the chip that it tweaked to power-on reset status. That would let you guys off the hook for everything that we don't set up correctly in the kernel. And it would allow the kernel folks to see where the problems really are. And then for customer-targeted images, that bootloader option could be kept off so management doesn't freak out. You might not believe this, but we went to great pain on the OMAP Linux kernel to reset as much as we could, as early as possible. This was partially so that if kernel device driver authors assumed that the bootloader would configure their device, it would show up as a bug that would need to be fixed. We were even resetting and reprogramming the SDRAM controller for a while. Unfortunately we weren't able to reset the clocks... > I don't suspect what I'm going to say now will have a lot of traction, > but I really think that much like user space, every once in a while (6 > months? year?) one ought to update their environment and make sure > things are still working too. > > You folks don't need to test ever rev of U-Boot (that's my job), but it > often feels like there's this cycle of "U-Boot sucks and can't do ... !" > "We've had that fixed / improved / changed for years now, upgrade?" "No, > can't / won't!". And... I've always wanted to switch most of the devices in my test platform over to serial-booted bootloaders and MLOs/X-loaders/SPLs. That way any bootloader could be booted during automated test. This is what's happening now on the BeagleBone-black here; that's really easy to cold-boot from serial due to the Xmodem download code implemented in the ROM, plus the lack of flash: http://www.pwsan.com/omap/testlogs/test_v3.11-rc3/20130728224046/boot/am335xbonelt/am335x-bone/ Do you know if anyone ever got serial cold-booting working well for, say, OMAP3 and OMAP4 chips? > For shipping consumer product, or however you want to call those kind of > devices, yes, appended dtb needs to work since the bootloader is locked, > and making that boot something else to boot the kernel is an exercise > for us oddballs :) But the boards which are designed as reference > platform, we can make your lives easier, if you let us help. If > something is a pain to do, give us feedback. OK I would love it if you would add a bootloader option "ASSUME_WORKING_KERNEL" that would reset every non-essential device on the board to power-on reset, and reset any non-essential clock register bits etc. to their POR values. Unlock the USB DPLL, etc. To start with, you'd need to leave that disabled for shipping customer images, but we could start testing with it and prevent patches from going upstream that implicitly rely on the bootloader settings. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
On 07/29/2013 04:29 AM, Paul Walmsley wrote: > Hi > > On Wed, 26 Jun 2013, Tom Rini wrote: > >> On 06/26/2013 01:19 PM, Paul Walmsley wrote: >>> On Tue, 25 Jun 2013, Tom Rini wrote: >>> On 06/25/2013 02:20 PM, Paul Walmsley wrote: > 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). >>> >>> Yeah, I've tried to keep the original bootloader that came on the first SD >>> card image that was used on that device. But am starting to think that >>> it's time to stop my bootloader independence jihad, since appended DTB >>> booting is so broken - have seen similar problems on SoCs from other >>> vendors as well :-( >> >> Well, me? I'm all in favor of people using latest release of U-Boot for >> their board and yelling and screaming (or just reporting bugs) when >> things don't work. I'm biased of course. > > That's exactly how bootloader developers should be testing their changes. > But most of the rest of us kernel folks don't want to deal with constantly > replacing bootloaders, and then dealing with the inevitable bootloader > regressions, when what we're really trying to test is the kernel... > The kernel should be completely independent of the bootloader used. And thus the chicken and egg problems we have today. The kernel should be independent, but unless someone is also testing more recent U-Boots as well, we may or may not have more hidden clock problems. Or if there is a bug in the bootloader for some particular use case, we don't find out until a new device ships out with broken code for that case, and now we're stuck for "forever". I don't suspect what I'm going to say now will have a lot of traction, but I really think that much like user space, every once in a while (6 months? year?) one ought to update their environment and make sure things are still working too. You folks don't need to test ever rev of U-Boot (that's my job), but it often feels like there's this cycle of "U-Boot sucks and can't do ... !" "We've had that fixed / improved / changed for years now, upgrade?" "No, can't / won't!". And... >> And assuming rmk answers the way I expect he will, like it or not, the >> version(s) we kit up and get in the box need to be factored into our >> test system setup so if folks don't want to avail themselves of >> improvements, they still get a functional system too. > > Yep seems like a good idea from a customer service point of view. Also > most OMAP devices out there probably have locked bootloaders, so replacing > the bootloader is often not an option. For shipping consumer product, or however you want to call those kind of devices, yes, appended dtb needs to work since the bootloader is locked, and making that boot something else to boot the kernel is an exercise for us oddballs :) But the boards which are designed as reference platform, we can make your lives easier, if you let us help. If something is a pain to do, give us feedback. -- Tom -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
Hi On Wed, 26 Jun 2013, Tom Rini wrote: > On 06/26/2013 01:19 PM, Paul Walmsley wrote: > > On Tue, 25 Jun 2013, Tom Rini wrote: > > > >> On 06/25/2013 02:20 PM, Paul Walmsley wrote: > >> > >>> 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). > > > > Yeah, I've tried to keep the original bootloader that came on the first SD > > card image that was used on that device. But am starting to think that > > it's time to stop my bootloader independence jihad, since appended DTB > > booting is so broken - have seen similar problems on SoCs from other > > vendors as well :-( > > Well, me? I'm all in favor of people using latest release of U-Boot for > their board and yelling and screaming (or just reporting bugs) when > things don't work. I'm biased of course. That's exactly how bootloader developers should be testing their changes. But most of the rest of us kernel folks don't want to deal with constantly replacing bootloaders, and then dealing with the inevitable bootloader regressions, when what we're really trying to test is the kernel... The kernel should be completely independent of the bootloader used. > And assuming rmk answers the way I expect he will, like it or not, the > version(s) we kit up and get in the box need to be factored into our > test system setup so if folks don't want to avail themselves of > improvements, they still get a functional system too. Yep seems like a good idea from a customer service point of view. Also most OMAP devices out there probably have locked bootloaders, so replacing the bootloader is often not an option. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
On Fri, 5 Jul 2013, Rajendra Nayak wrote: > Grant already made it clear when he posted that patch that neither that nor > anything similar would be taken up mainline because the appended dtb was only > meant for folks stuck with legacy bootloaders and have no way to upgrade. He's not the final arbiter of what goes into the mainline kernel :-) > Anyone who uses a bootloader capable of passing the dtb should *not* use > the appended dtb way. Look, either the kernel should support appended DTB booting, or it shouldn't. If it shouldn't, then that code should be ripped out of the kernel completely, and we tell people 'tough luck'. If it should, then it makes sense to help the millions of folks out there with locked bootloaders to build and boot new kernels. This half-support that's in the kernel now is not good. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
On 07/05/2013 01:48 AM, Rajendra Nayak wrote: > On Thursday 04 July 2013 11:42 PM, Paul Walmsley wrote: >> On Wed, 3 Jul 2013, Paul Walmsley wrote: >> >>> As far as Lokesh's patch goes: it doesn't make sense to me to remove a >>> file during 'make clean' that the build process doesn't create. So while >>> I understand the motivation for the patch, and don't mind if upstream >>> takes it, I personally wouldn't care to ack it. >> >> Incidentally, if there's any patch that would improve the current >> situation with appended DTBs by going upstream, it would be a patch like >> Grant's "HACK" patch to add appended DTB building into the kernel build >> system. Maybe folks can push to something similar to that one upstream? > > Grant already made it clear when he posted that patch that neither that nor > anything similar would be taken up mainline because the appended dtb was only > meant for folks stuck with legacy bootloaders and have no way to upgrade. > Anyone who uses a bootloader capable of passing the dtb should *not* use the > appended dtb way. The problem with that statement, and why I poked rmk the other week to confirm, and posted a patch to enable appended dtb support in the omap2plus_defconfig is that Grants statement conflicts with rmk's statement. Now, my personal preference, with my U-Boot guy hat on, would be to say that eval boards (those things that come with support and instructions on un-bricking them, and really have to have bootloader source available when applicable, or should be thrown back at the vendor, with extreme prejudice) ought to require passed dtbs even if that means upgrading bootloader. Shipping product boards, well, you make do, and that probably means passing a new bootloader to the locked bootloader to pass in a separate dtb is going to be left to the folks who think that is fun. Everyone else will be happy just booting mainline(ish) kernels with appended dtb. -- Tom -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
On Thursday 04 July 2013 11:42 PM, Paul Walmsley wrote: > On Wed, 3 Jul 2013, Paul Walmsley wrote: > >> As far as Lokesh's patch goes: it doesn't make sense to me to remove a >> file during 'make clean' that the build process doesn't create. So while >> I understand the motivation for the patch, and don't mind if upstream >> takes it, I personally wouldn't care to ack it. > > Incidentally, if there's any patch that would improve the current > situation with appended DTBs by going upstream, it would be a patch like > Grant's "HACK" patch to add appended DTB building into the kernel build > system. Maybe folks can push to something similar to that one upstream? Grant already made it clear when he posted that patch that neither that nor anything similar would be taken up mainline because the appended dtb was only meant for folks stuck with legacy bootloaders and have no way to upgrade. Anyone who uses a bootloader capable of passing the dtb should *not* use the appended dtb way. > > > - Paul > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
On Wed, 3 Jul 2013, Paul Walmsley wrote: > As far as Lokesh's patch goes: it doesn't make sense to me to remove a > file during 'make clean' that the build process doesn't create. So while > I understand the motivation for the patch, and don't mind if upstream > takes it, I personally wouldn't care to ack it. Incidentally, if there's any patch that would improve the current situation with appended DTBs by going upstream, it would be a patch like Grant's "HACK" patch to add appended DTB building into the kernel build system. Maybe folks can push to something similar to that one upstream? - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
On Tue, 2 Jul 2013, Nishanth Menon wrote: > On 07/01/2013 11:29 PM, Hiremath, Vaibhav wrote: > > > > > -Original Message- > > > From: Paul Walmsley [mailto:p...@pwsan.com] > > > Sent: Monday, July 01, 2013 7:46 AM > > > To: Vutla, Lokesh > > > Cc: Nayak, Rajendra; Hiremath, Vaibhav; Kevin Hilman; Rini, Tom; linux- > > > o...@vger.kernel.org; Balbi, Felipe; linux-arm- > > > ker...@lists.infradead.org > > > Subject: Re: OMAP baseline test results for v3.10-rc6 > > > > > > On Fri, 28 Jun 2013, Paul Walmsley wrote: > > > > > > > On Thu, 27 Jun 2013, Lokesh Vutla wrote: > > > > > > > > > Here is the catch.. > > > > > Your dtb is generated in arch/arm/boot/dts/ folder(before V3.8 dtb > > > was > > > > > generated in arch/arm/boot). > > > > > > > > Ugh... that's probably it :-( > to prevent this from happening again, Lokesh did post a patch: > https://patchwork.kernel.org/patch/2796921/ > > Will be good to ack it if we think it might prevent such scenarios in the > future. Thanks for the suggestion. Unfortunately it wouldn't have caught the problem, since, as I mentioned in the E-mail you quoted, I build from a fresh tree each time. So there was no previous DTB. This wasn't caught here because 'cat' was copying over the kernel to its standard output, even though it was returning an error, and I wasn't checking the 'cat' return value. This is obviously being remedied here. Also will modify the build scripts to output each command as it's being run. As far as Lokesh's patch goes: it doesn't make sense to me to remove a file during 'make clean' that the build process doesn't create. So while I understand the motivation for the patch, and don't mind if upstream takes it, I personally wouldn't care to ack it. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
On 07/01/2013 11:29 PM, Hiremath, Vaibhav wrote: -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, July 01, 2013 7:46 AM To: Vutla, Lokesh Cc: Nayak, Rajendra; Hiremath, Vaibhav; Kevin Hilman; Rini, Tom; linux- o...@vger.kernel.org; Balbi, Felipe; linux-arm- ker...@lists.infradead.org Subject: Re: OMAP baseline test results for v3.10-rc6 On Fri, 28 Jun 2013, Paul Walmsley wrote: On Thu, 27 Jun 2013, Lokesh Vutla wrote: Here is the catch.. Your dtb is generated in arch/arm/boot/dts/ folder(before V3.8 dtb was generated in arch/arm/boot). Ugh... that's probably it :-( to prevent this from happening again, Lokesh did post a patch: https://patchwork.kernel.org/patch/2796921/ Will be good to ack it if we think it might prevent such scenarios in the future. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.10-rc6
> -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Monday, July 01, 2013 7:46 AM > To: Vutla, Lokesh > Cc: Nayak, Rajendra; Hiremath, Vaibhav; Kevin Hilman; Rini, Tom; linux- > o...@vger.kernel.org; Balbi, Felipe; linux-arm- > ker...@lists.infradead.org > Subject: Re: OMAP baseline test results for v3.10-rc6 > > On Fri, 28 Jun 2013, Paul Walmsley wrote: > > > On Thu, 27 Jun 2013, Lokesh Vutla wrote: > > > > > Here is the catch.. > > > Your dtb is generated in arch/arm/boot/dts/ folder(before V3.8 dtb > was > > > generated in arch/arm/boot). > > > > Ugh... that's probably it :-( > > Indeed, this was at least one major problem. With this fixed, and with > CONFIG_MACH_OMAP_GENERIC=y in the v3.10-rc Kconfigs, the BeagleBone > white > boots here now with v3.10-rc7. Will test the previous releases going > back Surely it will boot. :) Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
On Fri, 28 Jun 2013, Paul Walmsley wrote: > On Thu, 27 Jun 2013, Lokesh Vutla wrote: > > > Here is the catch.. > > Your dtb is generated in arch/arm/boot/dts/ folder(before V3.8 dtb was > > generated in arch/arm/boot). > > Ugh... that's probably it :-( Indeed, this was at least one major problem. With this fixed, and with CONFIG_MACH_OMAP_GENERIC=y in the v3.10-rc Kconfigs, the BeagleBone white boots here now with v3.10-rc7. Will test the previous releases going back to v3.8 and will update the web-linked READMEs as appropriate. Thanks for the help and the fixes. Vaibhav and Rajendra, thanks also for looking into it. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
Hi Lokesh On Thu, 27 Jun 2013, Lokesh Vutla wrote: > On Wednesday 26 June 2013 10:56 PM, Paul Walmsley wrote: > > > > Here's how I do it: > > > > ARCH=arm CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} nice make > > -j$CORES zImage am335x-bone.dtb > > > > cat arch/arm/boot/zImage arch/arm/boot/am335x-bone.dtb > > > arch/arm/boot/zImage-dtb.am335x-bone > Here is the catch.. > Your dtb is generated in arch/arm/boot/dts/ folder(before V3.8 dtb was > generated in arch/arm/boot). Ugh... that's probably it :-( > You are using very old dtb file. Please delete all your dtb files in > arch/arm/boot/ folder and check once. The tree is freshly recreated for each build, so the most likely scenario is that there's no DTB file at all appended to the image. > Here is the patch from Grant Likely which does that. > https://patchwork.kernel.org/patch/1813321/ > Can you please give a try updating this ..:) Yeah will try that, probably either today or tomorrow. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
Hi Paul, On Wednesday 26 June 2013 10:56 PM, Paul Walmsley wrote: On Wed, 26 Jun 2013, Rajendra Nayak wrote: Apart from confirming if you are manually enabling these options, can you also give some details on how you append the dtb to the kernel image? Most of us use an out-of-tree patch from Grant to do this, which I have shared below [2] Even without the patch with the below commands [1] to append the dtb, it still works, so it would be good to know what steps you follow to append the dtb to the kernel image. Here's how I do it: ARCH=arm CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} nice make -j$CORES zImage am335x-bone.dtb cat arch/arm/boot/zImage arch/arm/boot/am335x-bone.dtb > arch/arm/boot/zImage-dtb.am335x-bone Here is the catch.. Your dtb is generated in arch/arm/boot/dts/ folder(before V3.8 dtb was generated in arch/arm/boot). You are using very old dtb file. Please delete all your dtb files in arch/arm/boot/ folder and check once. Here is the patch from Grant Likely which does that. https://patchwork.kernel.org/patch/1813321/ Can you please give a try updating this ..:) Thanks and regards, Lokesh scripts/mkuboot.sh -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux-' -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
Tom Rini writes: > On 06/26/2013 01:58 PM, Paul Walmsley wrote: >> On Wed, 26 Jun 2013, Tom Rini wrote: >> >>> OK, is there a reason to not be using omap2plus_defconfig? My pass/fail >>> here is based on that config and enabling, or not, dtb append. Seems >>> like it would be one less thing to maintain on your end and it would be >>> on TIs end (roughly speaking) to make sure our platforms that ought to >>> be working upstream have what they need enabled in the defconfig(s) in >>> question. >> >> That would be convenient for me, but part of the goal is to verify that a >> Kconfig that deselects all OMAPs other than AM33xx continues to work. >> >> So the build process for am33xx_only here goes something like: >> >> 1. Start with omap2plus_defconfig >> >> 2. Turn off support for everything other than AM33xx in the SoC target >> selection menus >> >> 3. Turn on the appended DTB and compat ATAGs options >> >> You might consider adding something like this to your pass/fail tests. > > Adding more and different build+boot tests is on the list. I guess you > could automate this with a fraagment of everything am33xx must have to > boot+root and alldefconfig for the rest? Since I recently discovered scripts/kconfig/merge_config.sh, I thought I'd share a very convenient way of automating the variations on a kconfig theme, just in case I'm not the last one to discover this useful tool. For example, I have the following in am335x_only.config: CONFIG_ARCH_OMAP2=n CONFIG_ARCH_OMAP3=n CONFIG_ARCH_OMAP4=n CONFIG_SOC_OMAP5=n CONFIG_SOC_AM33XX=y Then I run: scripts/kconfig/merge_config.sh arch/arm/configs/omap2plus_defconfig /path/to/am335x_only.config This gives me omap2plus_defconfig with overrides from my fragment. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
"Hiremath, Vaibhav" writes: >> -Original Message- >> From: linux-arm-kernel [mailto:linux-arm-kernel- >> boun...@lists.infradead.org] On Behalf Of Kevin Hilman >> Sent: Wednesday, June 26, 2013 1:28 AM >> To: Rini, Tom >> Cc: Paul Walmsley; linux-omap@vger.kernel.org; linux-arm- >> ker...@lists.infradead.org; Balbi, Felipe; Hiremath, Vaibhav >> Subject: Re: OMAP baseline test results for v3.10-rc6 >> >> Tom Rini 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 +, 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? >> > > What is missing here is, > > CONFIG_ARM_APPENDED_DTB = y > CONFIG_ARM_ATAG_DTB_COMPAT = y Yes, yes... I use these options since I use appended DT with mainline for *many* boards. Only the beaglebone stopped working. I just tested v3.10-rc7 and it's back to working again for me with appended DT. I did not spend anymore time to figure out exactly which versions worked or didn't work. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
On 06/26/2013 01:19 PM, Paul Walmsley wrote: > On Tue, 25 Jun 2013, Tom Rini wrote: > >> On 06/25/2013 02:20 PM, Paul Walmsley wrote: >> >>> 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). > > Yeah, I've tried to keep the original bootloader that came on the first SD > card image that was used on that device. But am starting to think that > it's time to stop my bootloader independence jihad, since appended DTB > booting is so broken - have seen similar problems on SoCs from other > vendors as well :-( Well, me? I'm all in favor of people using latest release of U-Boot for their board and yelling and screaming (or just reporting bugs) when things don't work. I'm biased of course. And assuming rmk answers the way I expect he will, like it or not, the version(s) we kit up and get in the box need to be factored into our test system setup so if folks don't want to avail themselves of improvements, they still get a functional system too. -- Tom -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
On 06/26/2013 01:58 PM, Paul Walmsley wrote: > On Wed, 26 Jun 2013, Tom Rini wrote: > >> OK, is there a reason to not be using omap2plus_defconfig? My pass/fail >> here is based on that config and enabling, or not, dtb append. Seems >> like it would be one less thing to maintain on your end and it would be >> on TIs end (roughly speaking) to make sure our platforms that ought to >> be working upstream have what they need enabled in the defconfig(s) in >> question. > > That would be convenient for me, but part of the goal is to verify that a > Kconfig that deselects all OMAPs other than AM33xx continues to work. > > So the build process for am33xx_only here goes something like: > > 1. Start with omap2plus_defconfig > > 2. Turn off support for everything other than AM33xx in the SoC target > selection menus > > 3. Turn on the appended DTB and compat ATAGs options > > You might consider adding something like this to your pass/fail tests. Adding more and different build+boot tests is on the list. I guess you could automate this with a fraagment of everything am33xx must have to boot+root and alldefconfig for the rest? -- Tom -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
On Wed, 26 Jun 2013, Tom Rini wrote: > OK, is there a reason to not be using omap2plus_defconfig? My pass/fail > here is based on that config and enabling, or not, dtb append. Seems > like it would be one less thing to maintain on your end and it would be > on TIs end (roughly speaking) to make sure our platforms that ought to > be working upstream have what they need enabled in the defconfig(s) in > question. That would be convenient for me, but part of the goal is to verify that a Kconfig that deselects all OMAPs other than AM33xx continues to work. So the build process for am33xx_only here goes something like: 1. Start with omap2plus_defconfig 2. Turn off support for everything other than AM33xx in the SoC target selection menus 3. Turn on the appended DTB and compat ATAGs options You might consider adding something like this to your pass/fail tests. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
On 06/26/2013 01:28 PM, Paul Walmsley wrote: > On Wed, 26 Jun 2013, Tom Rini wrote: > >> Yes, please confirm that they're being set. > > For the Kconfig that I use to boot the BeagleBone-white, which is called > "am33xx_only", yes, both of those are set. > > Here's the v3.8-rc1 version of this Kconfig as an example: > > http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/build/am33xx_only/am33xx_only OK, is there a reason to not be using omap2plus_defconfig? My pass/fail here is based on that config and enabling, or not, dtb append. Seems like it would be one less thing to maintain on your end and it would be on TIs end (roughly speaking) to make sure our platforms that ought to be working upstream have what they need enabled in the defconfig(s) in question. -- Tom -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.10-rc6
On Wed, 26 Jun 2013, Paul Walmsley wrote: > On Wed, 26 Jun 2013, Hiremath, Vaibhav wrote: > > > That’s not quite true, I remember going through your log in detail multiple > > Times. > > > > The issue is, for appended DTB you must enable 2 config options, > > > > CONFIG_ARM_APPENDED_DTB = y > > CONFIG_ARM_ATAG_DTB_COMPAT = y > > Maybe you should look again. Both of these options are set in the > am33xx_only Kconfig which is used here for the Beaglebone-White boot. (and I do appreciate the attention you brought to looking into this issue a few months ago) - Paul
Re: OMAP baseline test results for v3.10-rc6
Hi On Wed, 26 Jun 2013, Lokesh Vutla wrote: > I checked your am33xx-only build config for v3.10-rc6 here: > http://www.pwsan.com/omap/testlogs/test_v3.10-rc6/20130616211951/build/am33xx_only/am33xx_only > I can see that you are disabling config MACH_OMAP_GENERIC > "# CONFIG_MACH_OMAP_GENERIC is not set" > If this is not selected you cannot boot with dt. Hmm yeah, looks like there's some problem where that didn't get set for any of the am33xx_only Kconfigs after v3.8-rc7. Will fix that and give it a try on v3.10-rc6. But still that doesn't explain why none of the v3.8* kernels booted here. Care to take a quick look at the v3.8-rc1 Kconfig? http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/build/am33xx_only/am33xx_only - Paul $ find . -type f -name "am33xx_only" -exec fgrep -q CONFIG_MACH_OMAP_GENERIC=y '{}' ';' -print |fgrep test_v3. | sort -t. -k3,3 -n ./test_v3.7/20121211094536/build/am33xx_only/am33xx_only ./test_v3.7-rc1/20121017205513/build/am33xx_only/am33xx_only ./test_v3.7-rc2/20121020134755/build/am33xx_only/am33xx_only ./test_v3.7-rc3/20121028162003/build/am33xx_only/am33xx_only ./test_v3.7-rc4/20121104142910/build/am33xx_only/am33xx_only ./test_v3.7-rc5/2012081034/build/am33xx_only/am33xx_only ./test_v3.7-rc6/20121117093152/build/am33xx_only/am33xx_only ./test_v3.7-rc7/20121127152704/build/am33xx_only/am33xx_only ./test_v3.7-rc8/20121204220128/build/am33xx_only/am33xx_only ./test_v3.8/20130218214403/build/am33xx_only/am33xx_only ./test_v3.8-rc1/20121228031713/build/am33xx_only/am33xx_only ./test_v3.8-rc2/20130103093341/build/am33xx_only/am33xx_only ./test_v3.8-rc3/20130109222058/build/am33xx_only/am33xx_only ./test_v3.8-rc4/20130120122039/build/am33xx_only/am33xx_only ./test_v3.8-rc5/20130126003323/build/am33xx_only/am33xx_only ./test_v3.8-rc6/20130206155004/build/am33xx_only/am33xx_only ./test_v3.8-rc7/20130210080644/build/am33xx_only/am33xx_only -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
On Wed, 26 Jun 2013, Tom Rini wrote: > Yes, please confirm that they're being set. For the Kconfig that I use to boot the BeagleBone-white, which is called "am33xx_only", yes, both of those are set. Here's the v3.8-rc1 version of this Kconfig as an example: http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/build/am33xx_only/am33xx_only - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
On Wed, 26 Jun 2013, Rajendra Nayak wrote: > Apart from confirming if you are manually enabling these options, can you > also give some > details on how you append the dtb to the kernel image? > > Most of us use an out-of-tree patch from Grant to do this, which I have > shared below [2] > > Even without the patch with the below commands [1] to append the dtb, it > still works, so it > would be good to know what steps you follow to append the dtb to the kernel > image. Here's how I do it: ARCH=arm CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} nice make -j$CORES zImage am335x-bone.dtb cat arch/arm/boot/zImage arch/arm/boot/am335x-bone.dtb > arch/arm/boot/zImage-dtb.am335x-bone scripts/mkuboot.sh -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux-' -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
On Tue, 25 Jun 2013, Tom Rini wrote: > On 06/25/2013 02:20 PM, Paul Walmsley wrote: > > > 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). Yeah, I've tried to keep the original bootloader that came on the first SD card image that was used on that device. But am starting to think that it's time to stop my bootloader independence jihad, since appended DTB booting is so broken - have seen similar problems on SoCs from other vendors as well :-( > And yeah, I feel your pain about power cycling BeagleBone-White. The QA > folks here sent me one of the relay controllers they use, and I think > Felipe is partial to one from phidgets. Thanks yeah, I should have been more specific in my whining. Here I use a USB cable with VBUS sliced and then connected to an Ethernet-controlled DC relay. But there's a power delivery issue where, under some conditions, supplemental power has to be supplied through the DC jack also, requiring two separate contacts to be switched :-( - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.10-rc6
On Wed, 26 Jun 2013, Hiremath, Vaibhav wrote: > That’s not quite true, I remember going through your log in detail multiple > Times. > > The issue is, for appended DTB you must enable 2 config options, > > CONFIG_ARM_APPENDED_DTB = y > CONFIG_ARM_ATAG_DTB_COMPAT = y Maybe you should look again. Both of these options are set in the am33xx_only Kconfig which is used here for the Beaglebone-White boot. - Paul $ find . -type f -name "am33xx_only" -exec fgrep -q CONFIG_ARM_APPENDED_DTB=y '{}' ';' -print |fgrep test_v3. | sort -t. -k3,3 -n ./test_v3.7/20121211094536/build/am33xx_only/am33xx_only ./test_v3.7-rc1/20121017205513/build/am33xx_only/am33xx_only ./test_v3.7-rc2/20121020134755/build/am33xx_only/am33xx_only ./test_v3.7-rc3/20121028162003/build/am33xx_only/am33xx_only ./test_v3.7-rc4/20121104142910/build/am33xx_only/am33xx_only ./test_v3.7-rc5/2012081034/build/am33xx_only/am33xx_only ./test_v3.7-rc6/20121117093152/build/am33xx_only/am33xx_only ./test_v3.7-rc7/20121127152704/build/am33xx_only/am33xx_only ./test_v3.7-rc8/20121204220128/build/am33xx_only/am33xx_only ./test_v3.8/20130218214403/build/am33xx_only/am33xx_only ./test_v3.8-rc1/20121228031713/build/am33xx_only/am33xx_only ./test_v3.8-rc2/20130103093341/build/am33xx_only/am33xx_only ./test_v3.8-rc3/20130109222058/build/am33xx_only/am33xx_only ./test_v3.8-rc4/20130120122039/build/am33xx_only/am33xx_only ./test_v3.8-rc5/20130126003323/build/am33xx_only/am33xx_only ./test_v3.8-rc6/20130206155004/build/am33xx_only/am33xx_only ./test_v3.8-rc7/20130210080644/build/am33xx_only/am33xx_only ./test_v3.9/20130429104339/build/am33xx_only/am33xx_only ./test_v3.9-rc1/20130312100243/build/am33xx_only/am33xx_only ./test_v3.9-rc2/20130314094808/build/am33xx_only/am33xx_only ./test_v3.9-rc3/20130317194234/build/am33xx_only/am33xx_only ./test_v3.9-rc4/20130324120244/build/am33xx_only/am33xx_only ./test_v3.9-rc5/20130331205513/build/am33xx_only/am33xx_only ./test_v3.9-rc6/20130410123059/build/am33xx_only/am33xx_only ./test_v3.9-rc7/20130414220303/build/am33xx_only/am33xx_only ./test_v3.9-rc8/20130422154921/build/am33xx_only/am33xx_only ./test_v3.10-rc1/20130518212204/build/am33xx_only/am33xx_only ./test_v3.10-rc2/20130527225935/build/am33xx_only/am33xx_only ./test_v3.10-rc3/20130527220737/build/am33xx_only/am33xx_only ./test_v3.10-rc3/20130603032237/build/am33xx_only/am33xx_only ./test_v3.10-rc4/20130603034317/build/am33xx_only/am33xx_only ./test_v3.10-rc5/20130609031534/build/am33xx_only/am33xx_only ./test_v3.10-rc6/20130616211951/build/am33xx_only/am33xx_only $ find . -type f -name "am33xx_only" -exec fgrep -q CONFIG_ARM_ATAG_DTB_COMPAT=y '{}' ';' -print |fgrep test_v3. | sort -t. -k3,3 -n ./test_v3.7/20121211094536/build/am33xx_only/am33xx_only ./test_v3.7-rc1/20121017205513/build/am33xx_only/am33xx_only ./test_v3.7-rc2/20121020134755/build/am33xx_only/am33xx_only ./test_v3.7-rc3/20121028162003/build/am33xx_only/am33xx_only ./test_v3.7-rc4/20121104142910/build/am33xx_only/am33xx_only ./test_v3.7-rc5/2012081034/build/am33xx_only/am33xx_only ./test_v3.7-rc6/20121117093152/build/am33xx_only/am33xx_only ./test_v3.7-rc7/20121127152704/build/am33xx_only/am33xx_only ./test_v3.7-rc8/20121204220128/build/am33xx_only/am33xx_only ./test_v3.8/20130218214403/build/am33xx_only/am33xx_only ./test_v3.8-rc1/20121228031713/build/am33xx_only/am33xx_only ./test_v3.8-rc2/20130103093341/build/am33xx_only/am33xx_only ./test_v3.8-rc3/20130109222058/build/am33xx_only/am33xx_only ./test_v3.8-rc4/20130120122039/build/am33xx_only/am33xx_only ./test_v3.8-rc5/20130126003323/build/am33xx_only/am33xx_only ./test_v3.8-rc6/20130206155004/build/am33xx_only/am33xx_only ./test_v3.8-rc7/20130210080644/build/am33xx_only/am33xx_only ./test_v3.9/20130429104339/build/am33xx_only/am33xx_only ./test_v3.9-rc1/20130312100243/build/am33xx_only/am33xx_only ./test_v3.9-rc2/20130314094808/build/am33xx_only/am33xx_only ./test_v3.9-rc3/20130317194234/build/am33xx_only/am33xx_only ./test_v3.9-rc4/20130324120244/build/am33xx_only/am33xx_only ./test_v3.9-rc5/20130331205513/build/am33xx_only/am33xx_only ./test_v3.9-rc6/20130410123059/build/am33xx_only/am33xx_only ./test_v3.9-rc7/20130414220303/build/am33xx_only/am33xx_only ./test_v3.9-rc8/20130422154921/build/am33xx_only/am33xx_only ./test_v3.10-rc1/20130518212204/build/am33xx_only/am33xx_only ./test_v3.10-rc2/20130527225935/build/am33xx_only/am33xx_only ./test_v3.10-rc3/20130527220737/build/am33xx_only/am33xx_only ./test_v3.10-rc3/20130603032237/build/am33xx_only/am33xx_only ./test_v3.10-rc4/20130603034317/build/am33xx_only/am33xx_only ./test_v3.10-rc5/20130609031534/build/am33xx_only/am33xx_only ./test_v3.10-rc6/20130616211951/build/am33xx_only/am33xx_only
Re: OMAP baseline test results for v3.10-rc6
On 06/26/2013 09:22 AM, Rajendra Nayak wrote: >>> >>> 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? >>> >> >> What is missing here is, >> >> CONFIG_ARM_APPENDED_DTB = y >> CONFIG_ARM_ATAG_DTB_COMPAT = y >> >> >> And for the code which is required in case of appended DTB, please refer to >> the code >> "arch/arm/boot/compressed/head.S" >> >> >> Please __NOTE__ that these options are not enabled in default >> omap2plus_defconfig. > > Paul/Kevin, > > Apart from confirming if you are manually enabling these options, can you > also give some > details on how you append the dtb to the kernel image? Yes, please confirm that they're being set. I've managed to reproduce the failure, with them off, and enabling them brings things back to life. Pending rmk's reply in another part of the thread, I'll submit a patch to enable the above in omap2plus_defconfig. -- Tom -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
>> >> 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? >> > > What is missing here is, > > CONFIG_ARM_APPENDED_DTB = y > CONFIG_ARM_ATAG_DTB_COMPAT = y > > > And for the code which is required in case of appended DTB, please refer to > the code > "arch/arm/boot/compressed/head.S" > > > Please __NOTE__ that these options are not enabled in default > omap2plus_defconfig. Paul/Kevin, Apart from confirming if you are manually enabling these options, can you also give some details on how you append the dtb to the kernel image? Most of us use an out-of-tree patch from Grant to do this, which I have shared below [2] Even without the patch with the below commands [1] to append the dtb, it still works, so it would be good to know what steps you follow to append the dtb to the kernel image. regards, Rajendra [1] cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb > zImage mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Linux" -d zImage uImage [2] From: Grant Likely Date: Tue, 24 Apr 2012 16:19:29 +0530 Subject: Makefile: Build a uImage with dtb already appended Do not commit to mainline; this is a useful hack only for now. Signed-off-by: Grant Likely --- arch/arm/Makefile |2 ++ arch/arm/boot/Makefile |7 +++ 2 files changed, 9 insertions(+) Index: linux-2.6/arch/arm/Makefile === --- linux-2.6.orig/arch/arm/Makefile2013-04-24 12:25:22.547990009 +0530 +++ linux-2.6/arch/arm/Makefile 2013-04-26 14:30:57.143150733 +0530 @@ -295,6 +295,8 @@ %.dtb: scripts $(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) $(boot)/dts/$@ +uImage.%: uImage + $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@ dtbs: scripts $(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) dtbs Index: linux-2.6/arch/arm/boot/Makefile === --- linux-2.6.orig/arch/arm/boot/Makefile 2013-04-24 12:25:22.547990009 +0530 +++ linux-2.6/arch/arm/boot/Makefile2013-04-26 14:30:57.151150508 +0530 @@ -55,6 +55,9 @@ $(call if_changed,objcopy) @$(kecho) ' Kernel: $@ is ready' +$(obj)/zImage-dtb.%: $(obj)/dts/%.dtb $(obj)/zImage + cat $(obj)/zImage $< > $@ + endif ifneq ($(LOADADDR),) @@ -80,6 +83,10 @@ $(call if_changed,uimage) @$(kecho) ' Image $@ is ready' +$(obj)/uImage.%: $(obj)/zImage-dtb.% FORCE + $(call if_changed,uimage) + @echo ' Image $@ is ready' + $(obj)/bootp/bootp: $(obj)/zImage initrd FORCE $(Q)$(MAKE) $(build)=$(obj)/bootp $@ @: -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
On 06/26/2013 05:15 AM, Russell King - ARM Linux wrote: > On Tue, Jun 25, 2013 at 04:22:29PM -0400, Tom Rini wrote: >> On 06/25/2013 03:57 PM, Kevin Hilman wrote: >>> 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. >> >> Since we've narrowed down what the problem is, someone can bisect it >> now, yeah. >> >>> Can you guys update your tests to test appended DTB also? >> >> What is the official position on appending DTBs? > > If a platform goes from being able to boot without a DTB to requiring > a DTB, we must continue to support booting on that platform in some > manner otherwise it is a regression. > > And no, I don't term upgrading uboot as an acceptable regression fix. > So if appended DTB doesn't work, that needs fixing before the non-DTB > support for a platform is removed, otherwise we _will_ have a regression. am335x never had a board file in mainline, so it's always required a DTB. Now, I assume you're still saying that whatever software, except for the kernel of course, shipped on the SD card, has to be supported for forever by the kernel, right? -- Tom -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
Hi Paul, On Tuesday 25 June 2013 11:50 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 +, 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?) Anyway, for BeagleBone white, here's the last working test log, from 3.7: http://www.pwsan.com/omap/testlogs/test_v3.7/20121211094536/boot/am335xbone/am335xbone_log.txt The concatenated kernel and DTB, along with the Kconfig used to build, are here: http://www.pwsan.com/omap/testlogs/test_v3.7/20121211094536/build/am33xx_only/ The boot broke immediately afterwards with v3.8-rc1 and has never worked since: http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/boot/am335xbone/ You can find all of the archived testlogs here: http://www.pwsan.com/omap/testlogs/ You'll probably only be interested in the ones that start with "test_v3.". ... As for BeagleBone Black, here's the latest non-booting log: http://www.pwsan.com/omap/testlogs/test_v3.10-rc6/20130616211951/boot/am335xbonelt/am335x-bone/am335xbonelt_log.txt I checked your am33xx-only build config for v3.10-rc6 here: http://www.pwsan.com/omap/testlogs/test_v3.10-rc6/20130616211951/build/am33xx_only/am33xx_only I can see that you are disabling config MACH_OMAP_GENERIC "# CONFIG_MACH_OMAP_GENERIC is not set" If this is not selected you cannot boot with dt. I copied your config and selected "CONFIG_MACH_OMAP_GENERIC" then it boots fine. Thanks and regards, Lokesh This has never booted on mainline for me. The closest I got was with the ti-linux-3.8.y tree on Vaibhav's github account, which booted with the 'am335x-boneblack.dtb' built from the same tree. Mainline didn't boot with either the am335x-bone.dtb or Vaibhav's am335x-boneblack.dtb, but since it booted on 3.8.y with am335x-boneblack.dtb, I've kept that around for the mainline boot tests (as you can see from the logs). There's nothing exotic about the kernel used here, it's a pure omap2plus_defconfig zImage. The bootloader and DTB used are here (booted via serial from the boot ROM): http://www.pwsan.com/tmp/boneblack-20130625/ Please let me know if you need more binaries shared from the test runs! ... 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. Also, if you could share the entire thing, we will add your scripts to our nightly tests as to try and avoid future regressions. It would be great to have TI folks running those tests, or something similar to them! An early version of the test system has been shared with a handful of folks, but it needs to be cleaned up further before broader release. - Paul ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
On Tue, Jun 25, 2013 at 04:22:29PM -0400, Tom Rini wrote: > On 06/25/2013 03:57 PM, Kevin Hilman wrote: > > 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. > > Since we've narrowed down what the problem is, someone can bisect it > now, yeah. > > > Can you guys update your tests to test appended DTB also? > > What is the official position on appending DTBs? If a platform goes from being able to boot without a DTB to requiring a DTB, we must continue to support booting on that platform in some manner otherwise it is a regression. And no, I don't term upgrading uboot as an acceptable regression fix. So if appended DTB doesn't work, that needs fixing before the non-DTB support for a platform is removed, otherwise we _will_ have a regression. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.10-rc6
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Paul Walmsley > Sent: Tuesday, June 25, 2013 11:51 PM > To: Balbi, Felipe > Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > Rini, Tom; Hiremath, Vaibhav; khil...@ti.com > Subject: Re: OMAP baseline test results for v3.10-rc6 > > + Vaibhav and Kevin > > Hi, > > On Tue, 25 Jun 2013, Felipe Balbi wrote: > > > On Mon, Jun 17, 2013 at 05:23:17AM +, 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?) > That’s not quite true, I remember going through your log in detail multiple Times. The issue is, for appended DTB you must enable 2 config options, CONFIG_ARM_APPENDED_DTB = y CONFIG_ARM_ATAG_DTB_COMPAT = y OR If you don’t want to change/modify default config (omap2plus_defconfig), Use separate DTB and zImage, which is standard way of booting kernel. Same applies to BeagleBone Black. Infact same DTB and zImage boots up fine On both boards without any issues. Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.10-rc6
> -Original Message- > From: linux-arm-kernel [mailto:linux-arm-kernel- > boun...@lists.infradead.org] On Behalf Of Kevin Hilman > Sent: Wednesday, June 26, 2013 1:28 AM > To: Rini, Tom > Cc: Paul Walmsley; linux-omap@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; Balbi, Felipe; Hiremath, Vaibhav > Subject: Re: OMAP baseline test results for v3.10-rc6 > > Tom Rini 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 +, 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? > What is missing here is, CONFIG_ARM_APPENDED_DTB = y CONFIG_ARM_ATAG_DTB_COMPAT = y And for the code which is required in case of appended DTB, please refer to the code "arch/arm/boot/compressed/head.S" Please __NOTE__ that these options are not enabled in default omap2plus_defconfig. Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
Hi, On Tue, Jun 25, 2013 at 06:20:51PM +, Paul Walmsley wrote: > 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. oh yeah, you can use something like [1] for that [1] http://www.cleware-shop.de/epages/63698188.sf/en_US/?ObjectPath=/Shops/63698188/Products/01 -- balbi signature.asc Description: Digital signature
Re: OMAP baseline test results for v3.10-rc6
On 06/25/2013 03:57 PM, Kevin Hilman wrote: > Tom Rini 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 +, 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. Since we've narrowed down what the problem is, someone can bisect it now, yeah. > Can you guys update your tests to test appended DTB also? What is the official position on appending DTBs? -- Tom -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
Tom Rini 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 +, 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
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 +, 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. And yeah, I feel your pain about power cycling BeagleBone-White. The QA folks here sent me one of the relay controllers they use, and I think Felipe is partial to one from phidgets. >> Also, if you could share the entire thing, we will add your scripts to >> our nightly tests as to try and avoid future regressions. > > It would be great to have TI folks running those tests, or something > similar to them! An early version of the test system has been shared with > a handful of folks, but it needs to be cleaned up further before broader > release. We've got "something similar", at least wrt boot tests. But since we use separate kernel + DT, we hadn't seen this problem. -- Tom -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
+ Vaibhav and Kevin Hi, On Tue, 25 Jun 2013, Felipe Balbi wrote: > On Mon, Jun 17, 2013 at 05:23:17AM +, 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?) Anyway, for BeagleBone white, here's the last working test log, from 3.7: http://www.pwsan.com/omap/testlogs/test_v3.7/20121211094536/boot/am335xbone/am335xbone_log.txt The concatenated kernel and DTB, along with the Kconfig used to build, are here: http://www.pwsan.com/omap/testlogs/test_v3.7/20121211094536/build/am33xx_only/ The boot broke immediately afterwards with v3.8-rc1 and has never worked since: http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/boot/am335xbone/ You can find all of the archived testlogs here: http://www.pwsan.com/omap/testlogs/ You'll probably only be interested in the ones that start with "test_v3.". ... As for BeagleBone Black, here's the latest non-booting log: http://www.pwsan.com/omap/testlogs/test_v3.10-rc6/20130616211951/boot/am335xbonelt/am335x-bone/am335xbonelt_log.txt This has never booted on mainline for me. The closest I got was with the ti-linux-3.8.y tree on Vaibhav's github account, which booted with the 'am335x-boneblack.dtb' built from the same tree. Mainline didn't boot with either the am335x-bone.dtb or Vaibhav's am335x-boneblack.dtb, but since it booted on 3.8.y with am335x-boneblack.dtb, I've kept that around for the mainline boot tests (as you can see from the logs). There's nothing exotic about the kernel used here, it's a pure omap2plus_defconfig zImage. The bootloader and DTB used are here (booted via serial from the boot ROM): http://www.pwsan.com/tmp/boneblack-20130625/ Please let me know if you need more binaries shared from the test runs! ... 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. > Also, if you could share the entire thing, we will add your scripts to > our nightly tests as to try and avoid future regressions. It would be great to have TI folks running those tests, or something similar to them! An early version of the test system has been shared with a handful of folks, but it needs to be cleaned up further before broader release. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc6
Hi, On Mon, Jun 17, 2013 at 05:23:17AM +, 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 ? Also, if you could share the entire thing, we will add your scripts to our nightly tests as to try and avoid future regressions. -- balbi signature.asc Description: Digital signature
OMAP baseline test results for v3.10-rc6
Here are some basic OMAP test results for Linux v3.10-rc6. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.10-rc6/20130616211951/ Test summary Build: uImage: Pass (16/16): am33xx_only, n800_multi_omap2xxx, n800_only_a, omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only, omap2plus_defconfig, omap2plus_defconfig_2430sdp_only omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig, rmk_omap4430_sdp_oldconfig Build: zImage: Pass ( 1/ 1): omap2plus_defconfig Boot to userspace: FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt Pass ( 9/12): 2420n800, 2430sdp, 3517evm, 3530es3beagle, 3730beaglexm, 4430es2panda, 4460pandaes, 5912osk, cmt3517 PM: chip retention via suspend: FAIL ( 3/ 6): 2430sdp, 37xxevm, 4430es2panda Pass ( 3/ 6): 3530es3beagle, 3730beaglexm, 4460pandaes PM: chip retention via dynamic idle: FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes Pass ( 2/ 6): 3530es3beagle, 3730beaglexm PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes Pass ( 1/ 4): 3530es3beagle PM: chip off via dynamic idle: FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes Pass ( 1/ 4): 3530es3beagle Failing tests: fixed by posted patches -- * 37xx EVM: boot fails - as of v3.10-rc1 - Fixed by http://marc.info/?l=linux-arm-kernel&m=137112093431021&w=2 * 2430SDP, 3730 Beagle XM, 3530 Beagle, 3517EVM, CM-T3517: {dmic,mcpdm} lookup failure - Cause unknown - These IP blocks don't exist on OMAP3xxx/AM35xx chips - Fixed by http://marc.info/?l=linux-omap&m=137093955903130&w=2 Failing tests: needing investigation Boot tests: * 3517EVM & CM-T3517: boot hangs with NFS root - Likely some Kconfig, board file, and PM issues with EMAC - Longstanding bug - Not currently part of the automated test suite Boot warnings: * 2420N800, 2430sdp: failed to get counter_32k resource - "omap2_sync32k_clocksource_init: failed to get counter_32k resource" - Cause unknown * CM-T3517: L3 in-band error with IPSS during boot - Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2 - Longstanding issue; does not occur on the 3517EVM * 3730 Beagle XM, 3517EVM, CM-T3517: uart4_rx.uart4_rx mux failure - Cause unknown - May be related to the OMAP serial driver and/or DT mux data - http://marc.info/?l=linux-arm-kernel&m=137121357528854&w=2 PM tests: * 2430sdp: power domains not entering retention - Cause unknown * 3730 Beagle XM: does not serial wake from off-idle suspend when console UART doesn't clock-gate ("debug ignore_loglevel") - Cause unknown - Not yet part of the automated test suite - Re-tested at v3.7; still failing: http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt * 4430es2panda: pwrdm state mismatch on CAM, DSS * 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB per discussion with Tero Kristo - Likely dependent on the bootloader version - fails with 2012.07-00136-g755de79 - http://marc.info/?l=linux-arm-kernel&m=136432340618226&w=2 * 4430es2panda: MPU, ABE didn't enter target state - New for v3.10-rc * 4460pandaes: pwrdm state mismatch on DSS, ABE, IVAHD, TESLA * 4460pandaes: chip not entering retention in dynamic idle - Presumably 4430es2panda also fails this - Suspend-to-RAM enters full chip retention Other: * 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed - Unknown cause; could be due to the lack of hierarchical enable/disable in hwmod code - Jon Hunter and Santosh Shilimkar report this does not appear with the same X-loader/bootloader on his 4430ES2.3 Panda, so could be ES-level dependent Failing tests: reported by others - - RTC wakeup from suspend broken on 3730beaglexm - as of v3.10-rc1 - discussion here: http://marc.info/?l=linux-omap&m=136915841625434&w=2 vmlinux object size (delta in bytes from test_v3.10-rc5 (317ddd256b9c24b0d78fa8018f80f1e495481a10)): text data bsstotal kernel +673 +560 +729 am33xx_only +444 +80 +452 n800_multi_omap2xxx +412 +80 +420 n800_only_a +808 +320 +840 omap1_defconfig +776