Nathan Chancellor <natechancel...@gmail.com> writes: > On Thu, Jun 18, 2020 at 10:48:21AM +1000, Michael Ellerman wrote: >> Nick Desaulniers <ndesaulni...@google.com> writes: >> > On Wed, Jun 17, 2020 at 3:20 AM Michael Ellerman <m...@ellerman.id.au> >> > wrote: >> >> Michael Ellerman <m...@ellerman.id.au> writes: >> >> > Michal Simek <michal.si...@xilinx.com> writes: >> >> <snip> >> >> >> >> >> Or if bamboo requires uImage to be built by default you can do it via >> >> >> Kconfig. >> >> >> >> >> >> diff --git a/arch/powerpc/platforms/44x/Kconfig >> >> >> b/arch/powerpc/platforms/44x/Kconfig >> >> >> index 39e93d23fb38..300864d7b8c9 100644 >> >> >> --- a/arch/powerpc/platforms/44x/Kconfig >> >> >> +++ b/arch/powerpc/platforms/44x/Kconfig >> >> >> @@ -13,6 +13,7 @@ config BAMBOO >> >> >> select PPC44x_SIMPLE >> >> >> select 440EP >> >> >> select FORCE_PCI >> >> >> + select DEFAULT_UIMAGE >> >> >> help >> >> >> This option enables support for the IBM PPC440EP evaluation >> >> >> board. >> >> > >> >> > Who knows what the actual bamboo board used. But I'd be happy to take a >> >> > SOB'ed patch to do the above, because these days the qemu emulation is >> >> > much more likely to be used than the actual board. >> >> >> >> I just went to see why my CI boot of 44x didn't catch this, and it's >> >> because I don't use the uImage, I just boot the vmlinux directly: >> >> >> >> $ qemu-system-ppc -M bamboo -m 128m -display none -kernel >> >> build~/vmlinux -append "console=ttyS0" -display none -nodefaults -serial >> >> mon:stdio >> >> Linux version 5.8.0-rc1-00118-g69119673bd50 (michael@alpine1-p1) (gcc >> >> (Ubuntu 9.3.0-10ubuntu2) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #4 >> >> Wed Jun 17 20:19:22 AEST 2020 >> >> Using PowerPC 44x Platform machine description >> >> ioremap() called early from find_legacy_serial_ports+0x690/0x770. Use >> >> early_ioremap() instead >> >> printk: bootconsole [udbg0] enabled >> >> >> >> >> >> So that's probably the simplest solution? >> > >> > If the uImage or zImage self decompresses, I would prefer to test that as >> > well. >> >> The uImage is decompressed by qemu AIUI. >> >> >> That means previously arch/powerpc/boot/zImage was just a hardlink to >> >> the uImage: >> > >> > It sounds like we can just boot the zImage, or is that no longer >> > created with the uImage? >> >> The zImage won't boot on bamboo. >> >> Because of the vagaries of the arch/powerpc/boot/Makefile the zImage >> ends up pointing to treeImage.ebony, which is for a different board. >> >> The zImage link is made to the first item in $(image-y): >> >> $(obj)/zImage: $(addprefix $(obj)/, $(image-y)) >> $(Q)rm -f $@; ln $< $@ >> ^ >> first preqrequisite >> >> Which for this defconfig happens to be: >> >> image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony >> >> If you turned off CONFIG_EBONY then the zImage will be a link to >> treeImage.bamboo, but qemu can't boot that either. >> >> It's kind of nuts that the zImage points to some arbitrary image >> depending on what's configured and the order of things in the Makefile. >> But I'm not sure how we make it less nuts without risking breaking >> people's existing setups. > > Hi Michael, > > For what it's worth, this is squared this away in terms of our CI by > just building and booting the uImage directly, rather than implicitly > using the zImage: > > https://github.com/ClangBuiltLinux/continuous-integration/pull/282 > https://github.com/ClangBuiltLinux/boot-utils/pull/22
Great. > We were only using the zImage because that is what Joel Stanley intially > set us up with when PowerPC 32-bit was added to our CI: > > https://github.com/ClangBuiltLinux/continuous-integration/pull/100 Ah, so Joel owes us all beers then ;) > Admittedly, we really do not have many PowerPC experts in our > organization so we are supporting it on a "best effort" basis, which > often involves using whatever knowledge is floating around or can be > gained from interactions such as this :) so thank you for that! No worries. I definitely don't expect you folks to invest much effort in powerpc, especially the old 32-bit stuff, so always happy to help debug things, and really appreciate the testing you do. cheers