Geoff Levand <ge...@infradead.org> writes: > Hi Michael, > > On 5/14/20 7:02 PM, Michael Ellerman wrote: >> Geoff Levand <ge...@infradead.org> writes: > ... >>> + # The ps3's flash loader has a size limit of 16 MiB for the >>> uncompressed >>> + # image. If a compressed image that exceeded this limit is written to >>> + # flash the loader will decompress that image until the 16 MiB limit is >>> + # reached, then enter the system reset vector of the partially >>> decompressed >>> + # image. No warning is issued. >>> + rm -f "$odir"/{otheros,otheros-too-big}.bld >>> + size=$(${CROSS}nm --no-sort --radix=d "$ofile" | egrep ' _end$' | cut >>> -d' ' -f1) >>> + bld="otheros.bld" >>> + if [ $size -gt $((0x1000000)) ]; then >>> + bld="otheros-too-big.bld" >>> + echo " INFO: Uncompressed kernel is too large to program into PS3 >>> flash memory;" \ >> >> This now appears on all my ppc64_defconfig builds, which I don't really >> like. > > No, neither do I. I didn't think of that case. > >> That does highlight the fact that ppc64_defconfig including >> CONFIG_PPC_PS3 is not really helpful for people actually wanting to run >> the kernel on a PS3. > > No, this is just for the bootloader image (.bld) that can be > programed into flash memory. This is what is used to create, > for example, a petitboot bootloader image. > > Normal usage is for the bootloader in flash to load a vmlinux > image from disk or network, in which case running a ppc64_defconfig > image would be fine.
Ah yep, that rings a bell. >> So I wonder if we should drop CONFIG_PPC_PS3 from ppc64_defconfig, in >> which case I'd be happy to keep the INFO message because it should only >> appear on ps3 specific builds. > > I'd like to keep CONFIG_PPC_PS3 set in ppc64_defconfig. I feel it > useful to get some build testing of the PS3 platform code. > >> The other option would be to drop the message, or only print it when >> we're doing a verbose build. > > Building a boatloader image to program into flash memory is > something only very advanced users would be doing. I don't > think they would need this message. They would see the file > name and understand the situation. I'll post a v3 patch that > removes the message. Great, thanks. cheers