On Sat, 11 Jul 2020 at 19:03, Arnd Bergmann <a...@arndb.de> wrote: > > On Sat, Jul 11, 2020 at 5:00 PM Ard Biesheuvel <a...@kernel.org> wrote: > > On Sat, 11 Jul 2020 at 15:30, Russell King - ARM Linux admin > > <li...@armlinux.org.uk> wrote: > > > > > > I doubt anyone is going to fix this; it's an XIP kernel, and it looks > > > like the .data and .rodata sections are correctly placed as per the > > > configuration, but for some reason the .text (and sections that follow) > > > are incorrectly placed in VMA space. The configuration file says that > > > the kernel should start at 0x00080000, and there's no way the .text > > > VMA should be starting at 0x3f0801a0. > > > > > > > Note that only one of those lines has the >> prefix, and so this > > config was broken even before this patch got applied. > > > > > Unless one of the XIP using folk can debug this, I doubt there will be > > > any movement on it. Especially as it's 5 months old... > > > > > > What do we do with bugs like this that people won't fix? Remove XIP > > > support from the kernel? > > > > > > > I fail to see the point of randconfig testing for xip kernels tbh, and > > i don't think it is fair to disable xip altogether if the configs that > > those people care about still build as expected. > > > > But it would indeed be nice if we could at least get rid of these > > pointless build reports. Is there any way we can avoid xip from being > > selected by randconfig? > > In my randconfig builds, I have a patch that makes CONFIG_XIP_KERNEL > and some other options depend on '!COMPILE_TEST', and I always enable > COMPILE_TEST for randconfig builds. I don't know whether that would > work for the kernel test robot as well. > >
Both changes sound like things we might simply upstream, no? Randconfig is only intended for compile testing anyway, and making xip depend on !COMPILE_TEST seems uncontroversial to me as well.
