| Message ID | 51CAEB33.5010101@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 Rini <trini@ti.com> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: Paul Walmsley [mailto:paul@pwsan.com] > Sent: Monday, July 01, 2013 7:46 AM > To: Vutla, Lokesh > Cc: Nayak, Rajendra; Hiremath, Vaibhav; Kevin Hilman; Rini, Tom; linux- > omap@vger.kernel.org; Balbi, Felipe; linux-arm- > kernel@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/01/2013 11:29 PM, Hiremath, Vaibhav wrote: > >> -----Original Message----- >> From: Paul Walmsley [mailto:paul@pwsan.com] >> Sent: Monday, July 01, 2013 7:46 AM >> To: Vutla, Lokesh >> Cc: Nayak, Rajendra; Hiremath, Vaibhav; Kevin Hilman; Rini, Tom; linux- >> omap@vger.kernel.org; Balbi, Felipe; linux-arm- >> kernel@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.
On Tue, 2 Jul 2013, Nishanth Menon wrote: > On 07/01/2013 11:29 PM, Hiremath, Vaibhav wrote: > > > > > -----Original Message----- > > > From: Paul Walmsley [mailto:paul@pwsan.com] > > > Sent: Monday, July 01, 2013 7:46 AM > > > To: Vutla, Lokesh > > > Cc: Nayak, Rajendra; Hiremath, Vaibhav; Kevin Hilman; Rini, Tom; linux- > > > omap@vger.kernel.org; Balbi, Felipe; linux-arm- > > > kernel@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: linux-2.6/arch/arm/Makefile =================================================================== --- linux-2.6.orig/arch/arm/Makefile 2013-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/Makefile 2013-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 $@ @: