| Message ID | 20220419163810.2118169-1-arnd@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | ARM: PXA multiplatform support | expand |
On Tue, Apr 19, 2022 at 6:37 PM Arnd Bergmann <arnd@kernel.org> wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > This revisits a series I sent a few years ago: > > https://lore.kernel.org/lkml/20191018154052.1276506-1-arnd@arndb.de/ > > All the other ARMv5 conversions are under way now, with > OMAP1 being the only one still not in linux-next yet, > and PXA completing the set. > > Most of the patches are unchanged from before, furtunately > the PXA code is fairly stable. I addressed Robert's comments, > pulled in two patches from Dmitry, and added the last a the > final four patches to finish off the multiplatform conversion. > > I hope someone is left to test these on PXA: if this works, > I'd like to merge it for 5.19. A git tree with these is available > for testing at > > https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/log/?h=pxa-multiplatform-5.18 I have updated the branch based on the feedback I got, and done a preliminary merge into the for-next branch, so this work should show up in linux-next. I expect to rebase this particular branch before the merge window, to add further Acks or fix regressions in place. (I don't do this for the other branches). Let me know if there are any show-stoppers or patches that need more work. I realize that this is a lot to review and that there is limited reviewer bandwidth as most of the original developers have moved on from PXA a long time ago. Arnd
On Tue, Apr 19, 2022 at 06:37:22PM +0200, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > This revisits a series I sent a few years ago: > > https://lore.kernel.org/lkml/20191018154052.1276506-1-arnd@arndb.de/ > > All the other ARMv5 conversions are under way now, with > OMAP1 being the only one still not in linux-next yet, > and PXA completing the set. > > Most of the patches are unchanged from before, furtunately > the PXA code is fairly stable. I addressed Robert's comments, > pulled in two patches from Dmitry, and added the last a the > final four patches to finish off the multiplatform conversion. > > I hope someone is left to test these on PXA: if this works, > I'd like to merge it for 5.19. A git tree with these is avaialable > for testing at > > https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/log/?h=pxa-multiplatform-5.18 > Unfortunately that crashes for me when trying to boot from ide. Bisect points to the last patch of the series. Guenter --- [ 1.403715] 8<--- cut here --- [ 1.403848] Unable to handle kernel paging request at virtual address feeb000e [ 1.404097] [feeb000e] *pgd=00000000 [ 1.404400] Internal error: Oops: 805 [#1] PREEMPT ARM [ 1.404648] Modules linked in: [ 1.404890] CPU: 0 PID: 22 Comm: pccardd Not tainted 5.18.0-rc3-next-20220422 #1 [ 1.405159] Hardware name: SHARP Borzoi [ 1.405319] PC is at pcmcia_init_one+0xf8/0x27c [ 1.405476] LR is at devres_add+0x40/0x6c [ 1.405611] pc : [<c04bdea0>] lr : [<c044d808>] psr: a0000113 [ 1.405846] sp : c48a5d00 ip : c15f4220 fp : 60000113 [ 1.406026] r10: 00000000 r9 : c48b000e r8 : c48b0000 [ 1.406195] r7 : feeb0000 r6 : feeb000e r5 : c15ec090 r4 : c15ec020 [ 1.406395] r3 : 00000002 r2 : 00000000 r1 : c15f4200 r0 : feeb000e [ 1.406615] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 1.406847] Control: 00007977 Table: a0004000 DAC: 00000071 [ 1.407042] Register r0 information: 0-page vmalloc region starting at 0xfee00000 allocated at pci_reserve_io+0x0/0x38 [ 1.407453] Register r1 information: slab [ 1.407721] Register r2 information: NULL pointer [ 1.407885] Register r3 information: non-paged memory [ 1.408047] Register r4 information: slab [ 1.408179] Register r5 information: slab [ 1.408310] Register r6 information: 0-page vmalloc region starting at 0xfee00000 allocated at pci_reserve_io+0x0/0x38 [ 1.408622] Register r7 information: 0-page vmalloc region starting at 0xfee00000 allocated at pci_reserve_io+0x0/0x38 [ 1.408941] Register r8 information: 0-page vmalloc region starting at 0xc48b0000 allocated at soc_pcmcia_add_one+0xf0/0x370 [ 1.409291] Register r9 information: 0-page vmalloc region starting at 0xc48b0000 allocated at soc_pcmcia_add_one+0xf0/0x370 [ 1.409617] Register r10 information: NULL pointer [ 1.409768] Register r11 information: non-paged memory [ 1.409924] Register r12 information: slab [ 1.410066] Process pccardd (pid: 22, stack limit = 0x(ptrval)) [ 1.410268] Stack: (0xc48a5d00 to 0xc48a6000) [ 1.410448] 5d00: c15ebb78 00000000 0000001a 00000110 00000000 c0ad702c ff00051a c15ec090 [ 1.410694] 5d20: c0b713ec c0b713ec c12f6048 c0b644fc 00000000 00000000 60000113 c053f6bc [ 1.410938] 5d40: c16b3bf0 c15efa88 c09d4e48 00000001 00000007 00000200 0000000f 00000000 [ 1.411174] 5d60: 00000000 00000000 c0b71300 c0ad702c c0b644fc 00000000 c15ec090 c0b713ec [ 1.411410] 5d80: c0b9f980 c04491a8 c15ec090 00000000 60000113 c15ec090 c0b713ec c15ec090 [ 1.411644] 5da0: 00000003 c0449530 c078a988 c0399c90 ffffff08 c0be4d7c c0b713ec c15ec090 [ 1.411882] 5dc0: 00000003 c0b644fc 00000000 00000000 60000113 c04496e0 00000001 c0b713ec [ 1.412117] 5de0: c48a5e2c c15ec090 c0b644fc c0449aa0 00000000 c48a5e2c c04499fc c0be4d50 [ 1.412352] 5e00: c0b644fc c044702c 00000000 c12f407c c16b3bd4 c0ad702c c15ec090 00000001 [ 1.412587] 5e20: c15ec0d4 c0449030 c15ec090 c15ec090 00000001 c0ad702c c15ec090 c15ec090 [ 1.412827] 5e40: c0b77a9c c0448044 c15ec090 00000000 c12f5030 c04458bc 00000001 c009c720 [ 1.413065] 5e60: c15ec090 c04590e4 c15ec090 00000002 c12f6048 c12f6150 c15ec088 c0ad702c [ 1.413307] 5e80: c15ec090 c15ec020 c12f6150 c12f6048 c12f6150 c15ec088 c15ec090 c12f6160 [ 1.413551] 5ea0: 60000113 c0540820 00000000 c12f6048 c12f6150 ffffffe4 c12f6178 c12f6900 [ 1.413804] 5ec0: c0bb6828 c05409e8 00000000 00000011 c12f6048 00000000 c12f6150 c0ba35c8 [ 1.414050] 5ee0: c12f6178 c12f6900 c0bb6828 c074c3a8 c48a5f04 c0ad702c c48a5f10 c074c44c [ 1.414294] 5f00: c098de10 c09acdc0 c12f4fa0 c48a5f1c 000031d0 c0ad702c c12f6048 c12f6048 [ 1.414538] 5f20: 00000000 c12f6150 c0ba35c8 c0540af8 c12f6048 00000000 c12f6150 c053dcd4 [ 1.414791] 5f40: c12f6048 00000000 00000080 c12f6144 c12f6900 c053e704 00000000 c12f6178 [ 1.415037] 5f60: 000030d0 c0ad702c c12f6900 c12f4fe0 c12f21a0 c053e36c c12f6048 c12f6900 [ 1.415282] 5f80: c4809cc0 00000000 00000000 c004d67c c12f4fe0 c004d5a0 00000000 00000000 [ 1.415531] 5fa0: 00000000 00000000 00000000 c0008368 00000000 00000000 00000000 00000000 [ 1.415780] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1.416025] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 1.416643] pcmcia_init_one from pcmcia_device_probe+0xe4/0x2a0 [ 1.416882] pcmcia_device_probe from really_probe+0xc8/0x3b4 [ 1.417070] really_probe from __driver_probe_device+0x9c/0x214 [ 1.417255] __driver_probe_device from driver_probe_device+0x38/0xe0 [ 1.417454] driver_probe_device from __device_attach_driver+0xa4/0x11c [ 1.417657] __device_attach_driver from bus_for_each_drv+0x88/0xd8 [ 1.417864] bus_for_each_drv from __device_attach+0xf4/0x194 [ 1.418047] __device_attach from bus_probe_device+0x8c/0x94 [ 1.418224] bus_probe_device from device_add+0x3d0/0x894 [ 1.418395] device_add from pcmcia_device_add+0x2ec/0x3e0 [ 1.418568] pcmcia_device_add from pcmcia_card_add+0xd4/0x1a0 [ 1.418756] pcmcia_card_add from pcmcia_bus_add+0x44/0x4c [ 1.418930] pcmcia_bus_add from socket_insert+0x12c/0x150 [ 1.419103] socket_insert from pccardd+0x398/0x44c [ 1.419257] pccardd from kthread+0xdc/0x114 [ 1.419400] kthread from ret_from_fork+0x14/0x2c [ 1.419569] Exception stack(0xc48a5fb0 to 0xc48a5ff8) [ 1.419735] 5fa0: 00000000 00000000 00000000 00000000 [ 1.419979] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1.420222] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 1.420501] Code: 13570000 e1a06000 0a000043 e3a03002 (e5c03000) [ 1.420874] ---[ end trace 0000000000000000 ]--- --- # bad: [7643a9ca9f8e08f71e15f89dd74863635e981e03] ARM: pxa: convert to multiplatform # good: [3123109284176b1532874591f7c81f3837bbdc17] Linux 5.18-rc1 git bisect start 'HEAD' 'v5.18-rc1' # good: [9b03d7f95bd4d97101ecb8ea1e822103b81fdb2d] ARM: pxa: mainstone-wm97xx: use gpio lookup table git bisect good 9b03d7f95bd4d97101ecb8ea1e822103b81fdb2d # good: [764063eee7620ea9abb940068a7ad0e7f9efa1b6] cpufreq: pxa3: move clk register access to clk driver git bisect good 764063eee7620ea9abb940068a7ad0e7f9efa1b6 # good: [5153474f0a4388b7ddb59add4be73bfb42b2007f] ARM: mmp: remove tavorevb board support git bisect good 5153474f0a4388b7ddb59add4be73bfb42b2007f # good: [2746f7c78b428c8b01b691a29a972c08101ae343] ARM: PXA: fix multi-cpu build of xsc3 git bisect good 2746f7c78b428c8b01b691a29a972c08101ae343 # good: [73d5106e9489464eac84362705e93bcf3b376123] ARM: pxa: remove support for MTD_XIP git bisect good 73d5106e9489464eac84362705e93bcf3b376123 # first bad commit: [7643a9ca9f8e08f71e15f89dd74863635e981e03] ARM: pxa: convert to multiplatform
On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck <linux@roeck-us.net> wrote: > > On Tue, Apr 19, 2022 at 06:37:22PM +0200, Arnd Bergmann wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > > > This revisits a series I sent a few years ago: > > > > https://lore.kernel.org/lkml/20191018154052.1276506-1-arnd@arndb.de/ > > > > All the other ARMv5 conversions are under way now, with > > OMAP1 being the only one still not in linux-next yet, > > and PXA completing the set. > > > > Most of the patches are unchanged from before, furtunately > > the PXA code is fairly stable. I addressed Robert's comments, > > pulled in two patches from Dmitry, and added the last a the > > final four patches to finish off the multiplatform conversion. > > > > I hope someone is left to test these on PXA: if this works, > > I'd like to merge it for 5.19. A git tree with these is avaialable > > for testing at > > > > https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/log/?h=pxa-multiplatform-5.18 > > > > Unfortunately that crashes for me when trying to boot from ide. > Bisect points to the last patch of the series. Thanks a lot for testing and the perfect bug report! > [ 1.403715] 8<--- cut here --- > [ 1.403848] Unable to handle kernel paging request at virtual address feeb000e > [ 1.404097] [feeb000e] *pgd=00000000 Ok, this is the PCI I/O space area, which starts at 0xfee00000, clearly the way I/O space gets mapped changed here. I don't yet see what happened, but it should be straightforward to find from here. > [ 1.416643] pcmcia_init_one from pcmcia_device_probe+0xe4/0x2a0 > [ 1.416882] pcmcia_device_probe from really_probe+0xc8/0x3b4 > [ 1.417070] really_probe from __driver_probe_device+0x9c/0x214 > [ 1.417255] __driver_probe_device from driver_probe_device+0x38/0xe0 > [ 1.417454] driver_probe_device from __device_attach_driver+0xa4/0x11c > [ 1.417657] __device_attach_driver from bus_for_each_drv+0x88/0xd8 > [ 1.417864] bus_for_each_drv from __device_attach+0xf4/0x194 > [ 1.418047] __device_attach from bus_probe_device+0x8c/0x94 > [ 1.418224] bus_probe_device from device_add+0x3d0/0x894 > [ 1.418395] device_add from pcmcia_device_add+0x2ec/0x3e0 > [ 1.418568] pcmcia_device_add from pcmcia_card_add+0xd4/0x1a0 > [ 1.418756] pcmcia_card_add from pcmcia_bus_add+0x44/0x4c > [ 1.418930] pcmcia_bus_add from socket_insert+0x12c/0x150 > [ 1.419103] socket_insert from pccardd+0x398/0x44c > [ 1.419257] pccardd from kthread+0xdc/0x114 > [ 1.419400] kthread from ret_from_fork+0x14/0x2c > [ 1.419569] Exception stack(0xc48a5fb0 to 0xc48a5ff8) > [ 1.419735] 5fa0: 00000000 00000000 00000000 00000000 > [ 1.419979] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > [ 1.420222] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 > [ 1.420501] Code: 13570000 e1a06000 0a000043 e3a03002 (e5c03000) > [ 1.420874] ---[ end trace 0000000000000000 ]--- > > --- > # bad: [7643a9ca9f8e08f71e15f89dd74863635e981e03] ARM: pxa: convert to multiplatform > # good: [3123109284176b1532874591f7c81f3837bbdc17] Linux 5.18-rc1 > git bisect start 'HEAD' 'v5.18-rc1' > # good: [9b03d7f95bd4d97101ecb8ea1e822103b81fdb2d] ARM: pxa: mainstone-wm97xx: use gpio lookup table > git bisect good 9b03d7f95bd4d97101ecb8ea1e822103b81fdb2d > # good: [764063eee7620ea9abb940068a7ad0e7f9efa1b6] cpufreq: pxa3: move clk register access to clk driver > git bisect good 764063eee7620ea9abb940068a7ad0e7f9efa1b6 > # good: [5153474f0a4388b7ddb59add4be73bfb42b2007f] ARM: mmp: remove tavorevb board support > git bisect good 5153474f0a4388b7ddb59add4be73bfb42b2007f > # good: [2746f7c78b428c8b01b691a29a972c08101ae343] ARM: PXA: fix multi-cpu build of xsc3 > git bisect good 2746f7c78b428c8b01b691a29a972c08101ae343 > # good: [73d5106e9489464eac84362705e93bcf3b376123] ARM: pxa: remove support for MTD_XIP > git bisect good 73d5106e9489464eac84362705e93bcf3b376123 > # first bad commit: [7643a9ca9f8e08f71e15f89dd74863635e981e03] ARM: pxa: convert to multiplatform I'll back out this patch for now while investigating further. Which machine did you hit this on? Is this on hardware or in qemu? Arnd
On 4/22/22 12:16, Arnd Bergmann wrote: > On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck <linux@roeck-us.net> wrote: >> >> On Tue, Apr 19, 2022 at 06:37:22PM +0200, Arnd Bergmann wrote: >>> From: Arnd Bergmann <arnd@arndb.de> >>> >>> This revisits a series I sent a few years ago: >>> >>> https://lore.kernel.org/lkml/20191018154052.1276506-1-arnd@arndb.de/ >>> >>> All the other ARMv5 conversions are under way now, with >>> OMAP1 being the only one still not in linux-next yet, >>> and PXA completing the set. >>> >>> Most of the patches are unchanged from before, furtunately >>> the PXA code is fairly stable. I addressed Robert's comments, >>> pulled in two patches from Dmitry, and added the last a the >>> final four patches to finish off the multiplatform conversion. >>> >>> I hope someone is left to test these on PXA: if this works, >>> I'd like to merge it for 5.19. A git tree with these is avaialable >>> for testing at >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/log/?h=pxa-multiplatform-5.18 >>> >> >> Unfortunately that crashes for me when trying to boot from ide. >> Bisect points to the last patch of the series. > > Thanks a lot for testing and the perfect bug report! > >> [ 1.403715] 8<--- cut here --- >> [ 1.403848] Unable to handle kernel paging request at virtual address feeb000e >> [ 1.404097] [feeb000e] *pgd=00000000 > > Ok, this is the PCI I/O space area, which starts at 0xfee00000, > clearly the way I/O space > gets mapped changed here. I don't yet see what happened, but it should > be straightforward > to find from here. > >> [ 1.416643] pcmcia_init_one from pcmcia_device_probe+0xe4/0x2a0 >> [ 1.416882] pcmcia_device_probe from really_probe+0xc8/0x3b4 >> [ 1.417070] really_probe from __driver_probe_device+0x9c/0x214 >> [ 1.417255] __driver_probe_device from driver_probe_device+0x38/0xe0 >> [ 1.417454] driver_probe_device from __device_attach_driver+0xa4/0x11c >> [ 1.417657] __device_attach_driver from bus_for_each_drv+0x88/0xd8 >> [ 1.417864] bus_for_each_drv from __device_attach+0xf4/0x194 >> [ 1.418047] __device_attach from bus_probe_device+0x8c/0x94 >> [ 1.418224] bus_probe_device from device_add+0x3d0/0x894 >> [ 1.418395] device_add from pcmcia_device_add+0x2ec/0x3e0 >> [ 1.418568] pcmcia_device_add from pcmcia_card_add+0xd4/0x1a0 >> [ 1.418756] pcmcia_card_add from pcmcia_bus_add+0x44/0x4c >> [ 1.418930] pcmcia_bus_add from socket_insert+0x12c/0x150 >> [ 1.419103] socket_insert from pccardd+0x398/0x44c >> [ 1.419257] pccardd from kthread+0xdc/0x114 >> [ 1.419400] kthread from ret_from_fork+0x14/0x2c >> [ 1.419569] Exception stack(0xc48a5fb0 to 0xc48a5ff8) >> [ 1.419735] 5fa0: 00000000 00000000 00000000 00000000 >> [ 1.419979] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 >> [ 1.420222] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 >> [ 1.420501] Code: 13570000 e1a06000 0a000043 e3a03002 (e5c03000) >> [ 1.420874] ---[ end trace 0000000000000000 ]--- >> >> --- >> # bad: [7643a9ca9f8e08f71e15f89dd74863635e981e03] ARM: pxa: convert to multiplatform >> # good: [3123109284176b1532874591f7c81f3837bbdc17] Linux 5.18-rc1 >> git bisect start 'HEAD' 'v5.18-rc1' >> # good: [9b03d7f95bd4d97101ecb8ea1e822103b81fdb2d] ARM: pxa: mainstone-wm97xx: use gpio lookup table >> git bisect good 9b03d7f95bd4d97101ecb8ea1e822103b81fdb2d >> # good: [764063eee7620ea9abb940068a7ad0e7f9efa1b6] cpufreq: pxa3: move clk register access to clk driver >> git bisect good 764063eee7620ea9abb940068a7ad0e7f9efa1b6 >> # good: [5153474f0a4388b7ddb59add4be73bfb42b2007f] ARM: mmp: remove tavorevb board support >> git bisect good 5153474f0a4388b7ddb59add4be73bfb42b2007f >> # good: [2746f7c78b428c8b01b691a29a972c08101ae343] ARM: PXA: fix multi-cpu build of xsc3 >> git bisect good 2746f7c78b428c8b01b691a29a972c08101ae343 >> # good: [73d5106e9489464eac84362705e93bcf3b376123] ARM: pxa: remove support for MTD_XIP >> git bisect good 73d5106e9489464eac84362705e93bcf3b376123 >> # first bad commit: [7643a9ca9f8e08f71e15f89dd74863635e981e03] ARM: pxa: convert to multiplatform > > I'll back out this patch for now while investigating further. > > Which machine did you hit this on? Is this on hardware or in qemu? > qemu, as always. borzoi, spitz, terrier, tosa, z2, and sx1 fail. Also, I just noticed that the failure is not always the same. z2 fails to boot from initrd, and sx1 fails to boot completely. I'll do another round of bisects. Guenter > Arnd
On Fri, Apr 22, 2022 at 10:55 PM Guenter Roeck <linux@roeck-us.net> wrote: > On 4/22/22 12:16, Arnd Bergmann wrote: > > On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck <linux@roeck-us.net> wrote: > > > > Which machine did you hit this on? Is this on hardware or in qemu? > > > qemu, as always. borzoi, spitz, terrier, tosa, z2, and sx1 fail. > Also, I just noticed that the failure is not always the same. > z2 fails to boot from initrd, and sx1 fails to boot completely. That's a lot of machines failing, I hope at least we got the same bugs more than once here. For the I/O space, I found now that PXA was not using the standard virtual I/O address yet, but instead used a NULL-based offset. I'm not entirely happy with this patch, but this is an outline of what I think we need to fix that: https://pastebin.com/3nVgQsEw This one is probably incomplete, at least it breaks sa1100 for now, and it adds a bogus CONFIG_PCI dependency. I'm also not sure in what way the last patch in the series triggers it, rather than the one that removed mach/io.h. I had sx1 booting in qemu at least, with the omap1 multiplatform series only. If you have a custom config for this one, make sure you get the right DEBUG_LL address. > I'll do another round of bisects. Thanks! Arnd
On Sat, Apr 23, 2022 at 12:04:31AM +0200, Arnd Bergmann wrote: > On Fri, Apr 22, 2022 at 10:55 PM Guenter Roeck <linux@roeck-us.net> wrote: > > On 4/22/22 12:16, Arnd Bergmann wrote: > > > On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck <linux@roeck-us.net> wrote: > > > > > > Which machine did you hit this on? Is this on hardware or in qemu? > > > > > qemu, as always. borzoi, spitz, terrier, tosa, z2, and sx1 fail. > > Also, I just noticed that the failure is not always the same. > > z2 fails to boot from initrd, and sx1 fails to boot completely. > > That's a lot of machines failing, I hope at least we got the same bugs more > than once here. > > For the I/O space, I found now that PXA was not using the standard > virtual I/O address yet, but instead used a NULL-based offset. > > I'm not entirely happy with this patch, but this is an outline of what > I think we need to fix that: https://pastebin.com/3nVgQsEw > This one is probably incomplete, at least it breaks sa1100 for now, > and it adds a bogus CONFIG_PCI dependency. I'm also not sure > in what way the last patch in the series triggers it, rather than the > one that removed mach/io.h. > > I had sx1 booting in qemu at least, with the omap1 multiplatform series only. > If you have a custom config for this one, make sure you get the right > DEBUG_LL address. > > > I'll do another round of bisects. > So ... z2 bisect points to the same patch, but the error is different. As mentioned, it does not recognize the initrd. Oddly enough, booting from initrd works for the other platforms. The sx1 boot failure seems to be unrelated to your patch series. It boots fine if built from the tip of your branch, but fails to boot in -next. That will require a bisect from -next. Guenter
On Sat, Apr 23, 2022 at 12:04:31AM +0200, Arnd Bergmann wrote: > On Fri, Apr 22, 2022 at 10:55 PM Guenter Roeck <linux@roeck-us.net> wrote: > > On 4/22/22 12:16, Arnd Bergmann wrote: > > > On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck <linux@roeck-us.net> wrote: > > > > > > Which machine did you hit this on? Is this on hardware or in qemu? > > > > > qemu, as always. borzoi, spitz, terrier, tosa, z2, and sx1 fail. > > Also, I just noticed that the failure is not always the same. > > z2 fails to boot from initrd, and sx1 fails to boot completely. > > That's a lot of machines failing, I hope at least we got the same bugs more > than once here. > > For the I/O space, I found now that PXA was not using the standard > virtual I/O address yet, but instead used a NULL-based offset. > > I'm not entirely happy with this patch, but this is an outline of what > I think we need to fix that: https://pastebin.com/3nVgQsEw > This one is probably incomplete, at least it breaks sa1100 for now, > and it adds a bogus CONFIG_PCI dependency. I'm also not sure > in what way the last patch in the series triggers it, rather than the > one that removed mach/io.h. > > I had sx1 booting in qemu at least, with the omap1 multiplatform series only. > If you have a custom config for this one, make sure you get the right > DEBUG_LL address. > > > I'll do another round of bisects. > Here is the bisect for the sx1 boot failure. Guenter --- # bad: [e7d6987e09a328d4a949701db40ef63fbb970670] Add linux-next specific files for 20220422 # good: [b2d229d4ddb17db541098b83524d901257e93845] Linux 5.18-rc3 git bisect start 'HEAD' 'v5.18-rc3' # bad: [479506a21bd2df998017a00f4fe0ea893039d9d0] Merge branch 'drm-next' of git://git.freedesktop.org/git/drm/drm.git git bisect bad 479506a21bd2df998017a00f4fe0ea893039d9d0 # bad: [84fdc506ff63f3f8eb7feaac87821c39bf1dbdfd] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux.git git bisect bad 84fdc506ff63f3f8eb7feaac87821c39bf1dbdfd # bad: [0318e72d28be01b99056a7e66572423682eae2bb] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git git bisect bad 0318e72d28be01b99056a7e66572423682eae2bb # good: [813d98e2e26d3f418d925263a82d72d1454b326e] Merge branch 'zstd-linus' of https://github.com/terrelln/linux.git git bisect good 813d98e2e26d3f418d925263a82d72d1454b326e # bad: [5e87f91cfe6e938eccb88a992687e2ac52eec2a7] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git git bisect bad 5e87f91cfe6e938eccb88a992687e2ac52eec2a7 # bad: [ac4b03d5ad6b887558eb94943f0f2834661dee45] Merge branch 'pxa-multiplatform-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc into arm/multiplatform-late git bisect bad ac4b03d5ad6b887558eb94943f0f2834661dee45 # good: [6eab9bfd712f63c0977f2d38a45f321816030707] Merge branch 'omap1/multiplatform-prep' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc into arm/multiplatform git bisect good 6eab9bfd712f63c0977f2d38a45f321816030707 # good: [ac571609a9fab9b94bbd8e634ba20e2ab672e32d] input: touchscreen: mainstone: sync with zylonite driver git bisect good ac571609a9fab9b94bbd8e634ba20e2ab672e32d # good: [77b9aeb6e3cd4de6b320d3a9be5d692594159f9e] ARM: pxa: remove unused mach/bitfield.h git bisect good 77b9aeb6e3cd4de6b320d3a9be5d692594159f9e # good: [7643a9ca9f8e08f71e15f89dd74863635e981e03] ARM: pxa: convert to multiplatform git bisect good 7643a9ca9f8e08f71e15f89dd74863635e981e03 # good: [bdfb692acfa98c3e8135ab44bc8366636443590a] [MERGED] ASoC: ti: osk5912: Make it CCF clk API compatible git bisect good bdfb692acfa98c3e8135ab44bc8366636443590a # bad: [b59e8a5fd321fe44bdabd38908b4f899f933cf0f] [TO BE REBASED] ARM: omap1: enable multiplatform git bisect bad b59e8a5fd321fe44bdabd38908b4f899f933cf0f # good: [4c4467ac74299b14b8cf74406722af8090aa7766] [TO BE REBASED] ARM: OMAP1: clock: Convert to CCF git bisect good 4c4467ac74299b14b8cf74406722af8090aa7766 # first bad commit: [b59e8a5fd321fe44bdabd38908b4f899f933cf0f] [TO BE REBASED] ARM: omap1: enable multiplatform
On Sat, Apr 23, 2022 at 1:41 AM Guenter Roeck <linux@roeck-us.net> wrote: > > On Sat, Apr 23, 2022 at 12:04:31AM +0200, Arnd Bergmann wrote: > > On Fri, Apr 22, 2022 at 10:55 PM Guenter Roeck <linux@roeck-us.net> wrote: > > > On 4/22/22 12:16, Arnd Bergmann wrote: > > > > On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck <linux@roeck-us.net> wrote: > > > > > > > > Which machine did you hit this on? Is this on hardware or in qemu? > > > > > > > qemu, as always. borzoi, spitz, terrier, tosa, z2, and sx1 fail. > > > Also, I just noticed that the failure is not always the same. > > > z2 fails to boot from initrd, and sx1 fails to boot completely. > > > > That's a lot of machines failing, I hope at least we got the same bugs more > > than once here. > > > > For the I/O space, I found now that PXA was not using the standard > > virtual I/O address yet, but instead used a NULL-based offset. > > > > I'm not entirely happy with this patch, but this is an outline of what > > I think we need to fix that: https://pastebin.com/3nVgQsEw > > This one is probably incomplete, at least it breaks sa1100 for now, > > and it adds a bogus CONFIG_PCI dependency. I'm also not sure > > in what way the last patch in the series triggers it, rather than the > > one that removed mach/io.h. > > > > I had sx1 booting in qemu at least, with the omap1 multiplatform series only. > > If you have a custom config for this one, make sure you get the right > > DEBUG_LL address. > > > > > I'll do another round of bisects. > > > > Here is the bisect for the sx1 boot failure. Odd, I can't reproduce this at all. Do you get any console output at all for this? Is this the plain omap1_defconfig, or something else? One thing I keep having to apply myself is this snippet: diff --git a/arch/arm/mm/proc-arm925.S b/arch/arm/mm/proc-arm925.S index 0bfad62ea858..87c695703580 100644 --- a/arch/arm/mm/proc-arm925.S +++ b/arch/arm/mm/proc-arm925.S @@ -441,7 +441,6 @@ __arm925_setup: #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH mov r0, #4 @ disable write-back on caches explicitly - mcr p15, 7, r0, c15, c0, 0 #endif adr r5, arm925_crval I don't remember what the story is behind this, but I can't actually manage to boot omap1_defconfig on qemu with the instruction intact. Arnd
On 4/23/22 12:55, Arnd Bergmann wrote: > On Sat, Apr 23, 2022 at 1:41 AM Guenter Roeck <linux@roeck-us.net> wrote: >> >> On Sat, Apr 23, 2022 at 12:04:31AM +0200, Arnd Bergmann wrote: >>> On Fri, Apr 22, 2022 at 10:55 PM Guenter Roeck <linux@roeck-us.net> wrote: >>>> On 4/22/22 12:16, Arnd Bergmann wrote: >>>>> On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck <linux@roeck-us.net> wrote: >>>>> >>>>> Which machine did you hit this on? Is this on hardware or in qemu? >>>>> >>>> qemu, as always. borzoi, spitz, terrier, tosa, z2, and sx1 fail. >>>> Also, I just noticed that the failure is not always the same. >>>> z2 fails to boot from initrd, and sx1 fails to boot completely. >>> >>> That's a lot of machines failing, I hope at least we got the same bugs more >>> than once here. >>> >>> For the I/O space, I found now that PXA was not using the standard >>> virtual I/O address yet, but instead used a NULL-based offset. >>> >>> I'm not entirely happy with this patch, but this is an outline of what >>> I think we need to fix that: https://pastebin.com/3nVgQsEw >>> This one is probably incomplete, at least it breaks sa1100 for now, >>> and it adds a bogus CONFIG_PCI dependency. I'm also not sure >>> in what way the last patch in the series triggers it, rather than the >>> one that removed mach/io.h. >>> >>> I had sx1 booting in qemu at least, with the omap1 multiplatform series only. >>> If you have a custom config for this one, make sure you get the right >>> DEBUG_LL address. >>> >>>> I'll do another round of bisects. >>> >> >> Here is the bisect for the sx1 boot failure. > > Odd, I can't reproduce this at all. Do you get any console output at > all for this? > > Is this the plain omap1_defconfig, or something else? > No, it is my own sx1 specific configuration. https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/qemu_sx1_defconfig I don't recall where I got it from but ... > One thing I keep having to apply myself is this snippet: > > diff --git a/arch/arm/mm/proc-arm925.S b/arch/arm/mm/proc-arm925.S > index 0bfad62ea858..87c695703580 100644 > --- a/arch/arm/mm/proc-arm925.S > +++ b/arch/arm/mm/proc-arm925.S > @@ -441,7 +441,6 @@ __arm925_setup: > > #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH > mov r0, #4 @ disable write-back > on caches explicitly > - mcr p15, 7, r0, c15, c0, 0 > #endif it does not have CONFIG_CPU_DCACHE_WRITETHROUGH enabled. Guenter > > adr r5, arm925_crval > > I don't remember what the story is behind this, but I can't actually manage > to boot omap1_defconfig on qemu with the instruction intact. > > Arnd
On Sun, Apr 24, 2022 at 4:09 AM Guenter Roeck <linux@roeck-us.net> wrote: > On 4/23/22 12:55, Arnd Bergmann wrote: > > On Sat, Apr 23, 2022 at 1:41 AM Guenter Roeck <linux@roeck-us.net> wrote: > >> On Sat, Apr 23, 2022 at 12:04:31AM +0200, Arnd Bergmann wrote: > > > > Odd, I can't reproduce this at all. Do you get any console output at > > all for this? > > > > Is this the plain omap1_defconfig, or something else? > > > > No, it is my own sx1 specific configuration. > > https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/qemu_sx1_defconfig > > I don't recall where I got it from but ... Ok, that explains it, thanks! I fixed all the defconfig files that come with the kernel, but for your own ones you have to add # CONFIG_ARCH_MULTI_V7 is not set into the defconfig file, otherwise the multiplatform target defaults to an ARMv7 instead of ARMv5 build. For an OMAP15xx as in the SX1, you also need to enable CONFIG_ARCH_MULTI_V4T. This is slightly unfortunate, but I don't see any way to avoid it, and the modified defconfig will still work fine with older kernel trees. > > One thing I keep having to apply myself is this snippet: > > > > diff --git a/arch/arm/mm/proc-arm925.S b/arch/arm/mm/proc-arm925.S > > index 0bfad62ea858..87c695703580 100644 > > --- a/arch/arm/mm/proc-arm925.S > > +++ b/arch/arm/mm/proc-arm925.S > > @@ -441,7 +441,6 @@ __arm925_setup: > > > > #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH > > mov r0, #4 @ disable write-back > > on caches explicitly > > - mcr p15, 7, r0, c15, c0, 0 > > #endif > > it does not have CONFIG_CPU_DCACHE_WRITETHROUGH enabled. Maybe it was disabled explicitly for the sx1_defconfig because of this bug. I would think that this is required for actual sx1 hardware because the option is default-enabled for ARM925T, and that CPU core is exclusively used in OMAP15xx. Arnd
On 4/24/22 01:52, Arnd Bergmann wrote: > On Sun, Apr 24, 2022 at 4:09 AM Guenter Roeck <linux@roeck-us.net> wrote: >> On 4/23/22 12:55, Arnd Bergmann wrote: >>> On Sat, Apr 23, 2022 at 1:41 AM Guenter Roeck <linux@roeck-us.net> wrote: >>>> On Sat, Apr 23, 2022 at 12:04:31AM +0200, Arnd Bergmann wrote: >>> >>> Odd, I can't reproduce this at all. Do you get any console output at >>> all for this? >>> >>> Is this the plain omap1_defconfig, or something else? >>> >> >> No, it is my own sx1 specific configuration. >> >> https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/qemu_sx1_defconfig >> >> I don't recall where I got it from but ... > > Ok, that explains it, thanks! > > I fixed all the defconfig files that come with the kernel, but for your own > ones you have to add > > # CONFIG_ARCH_MULTI_V7 is not set > > into the defconfig file, otherwise the multiplatform target defaults to > an ARMv7 instead of ARMv5 build. For an OMAP15xx as in the SX1, > you also need to enable CONFIG_ARCH_MULTI_V4T. > > This is slightly unfortunate, but I don't see any way to avoid it, and the > modified defconfig will still work fine with older kernel trees. > Yes, that works. I changed it in my configuration. >>> One thing I keep having to apply myself is this snippet: >>> >>> diff --git a/arch/arm/mm/proc-arm925.S b/arch/arm/mm/proc-arm925.S >>> index 0bfad62ea858..87c695703580 100644 >>> --- a/arch/arm/mm/proc-arm925.S >>> +++ b/arch/arm/mm/proc-arm925.S >>> @@ -441,7 +441,6 @@ __arm925_setup: >>> >>> #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH >>> mov r0, #4 @ disable write-back >>> on caches explicitly >>> - mcr p15, 7, r0, c15, c0, 0 >>> #endif >> >> it does not have CONFIG_CPU_DCACHE_WRITETHROUGH enabled. > > Maybe it was disabled explicitly for the sx1_defconfig because of this > bug. I would think that this is required for actual sx1 hardware because the > option is default-enabled for ARM925T, and that CPU core is exclusively > used in OMAP15xx. > That looks like a bug in qemu. ARM925T instruction support is limited to V4T instructions. qemu doesn't have explicit 5T support. It is either V4T or V5. Guenter
On Sun, Apr 24, 2022 at 5:28 PM Guenter Roeck <linux@roeck-us.net> wrote: > On 4/24/22 01:52, Arnd Bergmann wrote: > > On Sun, Apr 24, 2022 at 4:09 AM Guenter Roeck <linux@roeck-us.net> wrote: > > into the defconfig file, otherwise the multiplatform target defaults to > > an ARMv7 instead of ARMv5 build. For an OMAP15xx as in the SX1, > > you also need to enable CONFIG_ARCH_MULTI_V4T. > > > > This is slightly unfortunate, but I don't see any way to avoid it, and the > > modified defconfig will still work fine with older kernel trees. > > > > Yes, that works. I changed it in my configuration. Ok, great!. I managed to boot the z2 machine with PCMCIA support and it gets around the issue with my patch, correctly detecting the CF card. > >>> One thing I keep having to apply myself is this snippet: > >>> > >>> diff --git a/arch/arm/mm/proc-arm925.S b/arch/arm/mm/proc-arm925.S > >>> index 0bfad62ea858..87c695703580 100644 > >>> --- a/arch/arm/mm/proc-arm925.S > >>> +++ b/arch/arm/mm/proc-arm925.S > >>> @@ -441,7 +441,6 @@ __arm925_setup: > >>> > >>> #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH > >>> mov r0, #4 @ disable write-back > >>> on caches explicitly > >>> - mcr p15, 7, r0, c15, c0, 0 > >>> #endif > >> > >> it does not have CONFIG_CPU_DCACHE_WRITETHROUGH enabled. > > > > Maybe it was disabled explicitly for the sx1_defconfig because of this > > bug. I would think that this is required for actual sx1 hardware because the > > option is default-enabled for ARM925T, and that CPU core is exclusively > > used in OMAP15xx. > > > > That looks like a bug in qemu. ARM925T instruction support is limited to V4T > instructions. qemu doesn't have explicit 5T support. It is either V4T > or V5. I'm not entirely sure what instructions the CPU supports, but Linux treats it as ARMv4T as well, and qemu supports some of the 925t specific instructions as "ti925t" in target/arm/cpu_tcg.c, it just seems it's missing some others. Arnd
On Sun, Apr 24, 2022 at 8:48 PM Arnd Bergmann <arnd@kernel.org> wrote: > On Sun, Apr 24, 2022 at 5:28 PM Guenter Roeck <linux@roeck-us.net> wrote: > > On 4/24/22 01:52, Arnd Bergmann wrote: > > > On Sun, Apr 24, 2022 at 4:09 AM Guenter Roeck <linux@roeck-us.net> wrote: > > > into the defconfig file, otherwise the multiplatform target defaults to > > > an ARMv7 instead of ARMv5 build. For an OMAP15xx as in the SX1, > > > you also need to enable CONFIG_ARCH_MULTI_V4T. > > > > > > This is slightly unfortunate, but I don't see any way to avoid it, and the > > > modified defconfig will still work fine with older kernel trees. > > > > > > > Yes, that works. I changed it in my configuration. > > Ok, great!. I managed to boot the z2 machine with PCMCIA support > and it gets around the issue with my patch, correctly detecting the > CF card. Hi Guenter, I have now sent out a fix that I'm happy with, and applied it to the pxa-multiplatform-5.18 branch of the soc tree as well as the combined arm/multiplatform tree. I have not merged this new version into the for-next branch since I would like to see if there are any other regressions first. Can you run your boot tests on the arm/multiplatform branch and let me know if that fixes everything you found? If that takes a lot of manual steps on your side, I'd just wait for the build bots and merge it after all there are no new compile-time issues. Arnd
On 4/28/22 06:44, Arnd Bergmann wrote: > On Sun, Apr 24, 2022 at 8:48 PM Arnd Bergmann <arnd@kernel.org> wrote: >> On Sun, Apr 24, 2022 at 5:28 PM Guenter Roeck <linux@roeck-us.net> wrote: >>> On 4/24/22 01:52, Arnd Bergmann wrote: >>>> On Sun, Apr 24, 2022 at 4:09 AM Guenter Roeck <linux@roeck-us.net> wrote: >>>> into the defconfig file, otherwise the multiplatform target defaults to >>>> an ARMv7 instead of ARMv5 build. For an OMAP15xx as in the SX1, >>>> you also need to enable CONFIG_ARCH_MULTI_V4T. >>>> >>>> This is slightly unfortunate, but I don't see any way to avoid it, and the >>>> modified defconfig will still work fine with older kernel trees. >>>> >>> >>> Yes, that works. I changed it in my configuration. >> >> Ok, great!. I managed to boot the z2 machine with PCMCIA support >> and it gets around the issue with my patch, correctly detecting the >> CF card. > > Hi Guenter, > > I have now sent out a fix that I'm happy with, and applied it to the > pxa-multiplatform-5.18 branch of the soc tree as well as the > combined arm/multiplatform tree. > > I have not merged this new version into the for-next branch > since I would like to see if there are any other regressions first. > > Can you run your boot tests on the arm/multiplatform branch > and let me know if that fixes everything you found? If that > takes a lot of manual steps on your side, I'd just wait for the > build bots and merge it after all there are no new compile-time > issues. > -next is pretty badly broken right now due to a series of less than perfect mm patches, so testing there won't do any good. I'll see if I can dig up the multiplatform branch and push it into my 'testing' branch. Guenter
On 4/28/22 06:44, Arnd Bergmann wrote: > On Sun, Apr 24, 2022 at 8:48 PM Arnd Bergmann <arnd@kernel.org> wrote: >> On Sun, Apr 24, 2022 at 5:28 PM Guenter Roeck <linux@roeck-us.net> wrote: >>> On 4/24/22 01:52, Arnd Bergmann wrote: >>>> On Sun, Apr 24, 2022 at 4:09 AM Guenter Roeck <linux@roeck-us.net> wrote: >>>> into the defconfig file, otherwise the multiplatform target defaults to >>>> an ARMv7 instead of ARMv5 build. For an OMAP15xx as in the SX1, >>>> you also need to enable CONFIG_ARCH_MULTI_V4T. >>>> >>>> This is slightly unfortunate, but I don't see any way to avoid it, and the >>>> modified defconfig will still work fine with older kernel trees. >>>> >>> >>> Yes, that works. I changed it in my configuration. >> >> Ok, great!. I managed to boot the z2 machine with PCMCIA support >> and it gets around the issue with my patch, correctly detecting the >> CF card. > > Hi Guenter, > > I have now sent out a fix that I'm happy with, and applied it to the > pxa-multiplatform-5.18 branch of the soc tree as well as the > combined arm/multiplatform tree. > > I have not merged this new version into the for-next branch > since I would like to see if there are any other regressions first. > > Can you run your boot tests on the arm/multiplatform branch > and let me know if that fixes everything you found? If that > takes a lot of manual steps on your side, I'd just wait for the > build bots and merge it after all there are no new compile-time > issues. > I tried the pxa-multiplatform-5.18 branch. Its failures match those in v5.18-rc1. Should I try soc/arm/multiplatform as well ? Guenter
On 4/29/22 10:48, Guenter Roeck wrote: > On 4/28/22 06:44, Arnd Bergmann wrote: >> On Sun, Apr 24, 2022 at 8:48 PM Arnd Bergmann <arnd@kernel.org> wrote: >>> On Sun, Apr 24, 2022 at 5:28 PM Guenter Roeck <linux@roeck-us.net> wrote: >>>> On 4/24/22 01:52, Arnd Bergmann wrote: >>>>> On Sun, Apr 24, 2022 at 4:09 AM Guenter Roeck <linux@roeck-us.net> wrote: >>>>> into the defconfig file, otherwise the multiplatform target defaults to >>>>> an ARMv7 instead of ARMv5 build. For an OMAP15xx as in the SX1, >>>>> you also need to enable CONFIG_ARCH_MULTI_V4T. >>>>> >>>>> This is slightly unfortunate, but I don't see any way to avoid it, and the >>>>> modified defconfig will still work fine with older kernel trees. >>>>> >>>> >>>> Yes, that works. I changed it in my configuration. >>> >>> Ok, great!. I managed to boot the z2 machine with PCMCIA support >>> and it gets around the issue with my patch, correctly detecting the >>> CF card. >> >> Hi Guenter, >> >> I have now sent out a fix that I'm happy with, and applied it to the >> pxa-multiplatform-5.18 branch of the soc tree as well as the >> combined arm/multiplatform tree. >> >> I have not merged this new version into the for-next branch >> since I would like to see if there are any other regressions first. >> >> Can you run your boot tests on the arm/multiplatform branch >> and let me know if that fixes everything you found? If that >> takes a lot of manual steps on your side, I'd just wait for the >> build bots and merge it after all there are no new compile-time >> issues. >> > > I tried the pxa-multiplatform-5.18 branch. Its failures match > those in v5.18-rc1. > Uuh, wait, the build wasn't complete. There are still some failures. I'll report later. Guenter
On Fri, Apr 29, 2022 at 10:23 PM Guenter Roeck <linux@roeck-us.net> wrote: > On 4/29/22 10:48, Guenter Roeck wrote: > > > > I tried the pxa-multiplatform-5.18 branch. Its failures match > > those in v5.18-rc1. > > > > Uuh, wait, the build wasn't complete. There are still some > failures. I'll report later. Sorry about the breakage, I got a few more reports about minor build errors and warnings, the newly uploaded branches should address all of the ones I got reports for. Arnd
On 4/29/22 14:46, Arnd Bergmann wrote: > On Fri, Apr 29, 2022 at 10:23 PM Guenter Roeck <linux@roeck-us.net> wrote: >> On 4/29/22 10:48, Guenter Roeck wrote: >>> >>> I tried the pxa-multiplatform-5.18 branch. Its failures match >>> those in v5.18-rc1. >>> >> >> Uuh, wait, the build wasn't complete. There are still some >> failures. I'll report later. > > Sorry about the breakage, I got a few more reports about minor build errors > and warnings, the newly uploaded branches should address all of the ones > I got reports for. > Unless I am missing something the failures are the same as before. See https://kerneltests.org/builders/qemu-arm-testing/builds/74/steps/qemubuildcommand/logs/stdio This is with v5.18-rc1-49-ge8ab9a9a2745 which is the tip of soc/pxa-multiplatform-5.18. Should I check a different branch ? Thanks, Guenter
On Sat, Apr 30, 2022 at 1:09 AM Guenter Roeck <linux@roeck-us.net> wrote: > On 4/29/22 14:46, Arnd Bergmann wrote: > > On Fri, Apr 29, 2022 at 10:23 PM Guenter Roeck <linux@roeck-us.net> wrote: > >> On 4/29/22 10:48, Guenter Roeck wrote: > >>> > >>> I tried the pxa-multiplatform-5.18 branch. Its failures match > >>> those in v5.18-rc1. > >>> > >> > >> Uuh, wait, the build wasn't complete. There are still some > >> failures. I'll report later. > > > > Sorry about the breakage, I got a few more reports about minor build errors > > and warnings, the newly uploaded branches should address all of the ones > > I got reports for. > > > > Unless I am missing something the failures are the same as before. See > https://kerneltests.org/builders/qemu-arm-testing/builds/74/steps/qemubuildcommand/logs/stdio > > This is with v5.18-rc1-49-ge8ab9a9a2745 which is the tip of > soc/pxa-multiplatform-5.18. > > Should I check a different branch ? I only addressed the pcmcia probe failure that you reported for the final pxa patch, which previously caused a NULL pointer reference here: [ 1.405319] PC is at pcmcia_init_one+0xf8/0x27c [ 1.405476] LR is at devres_add+0x40/0x6c [ 1.405611] pc : [<c04bdea0>] lr : [<c044d808>] psr: a0000113 [ 1.405846] sp : c48a5d00 ip : c15f4220 fp : 60000113 [ 1.406026] r10: 00000000 r9 : c48b000e r8 : c48b0000 [ 1.406195] r7 : feeb0000 r6 : feeb000e r5 : c15ec090 r4 : c15ec020 [ 1.406395] r3 : 00000002 r2 : 00000000 r1 : c15f4200 r0 : feeb000e This now seems to work: [ 1.435846] pcmcia_socket pcmcia_socket1: pccard: PCMCIA card inserted into slot 1 [ 1.456350] pcmcia_socket pcmcia_socket0: pccard: PCMCIA card inserted into slot 0 [ 1.457489] pcmcia 0.0: pcmcia: registering new device pcmcia0.0 (IRQ: 217) [ 1.460275] pata_pcmcia: probe of 0.0 failed with error -12 So it sounds like there are additional bugs that I have to look at. I probably won't be able to do that in time for the merge window. The logs contain a number of warnings, but I have no idea which ones of those are preexisting issue. I had a look at [ 0.689982] pxa-dma pxa-dma.0: error -ENXIO: IRQ index 1 not found and concluded that it must have done this for a long time. In my own qemu instance, I see a crash from iWMMXt, but that works fine on your machine. OTOH, your failed instances all look like they either time out or failed to find a rootfs. I tried passing an MMC device as root, and that works here. Arnd
On 4/30/22 01:04, Arnd Bergmann wrote: > On Sat, Apr 30, 2022 at 1:09 AM Guenter Roeck <linux@roeck-us.net> wrote: >> On 4/29/22 14:46, Arnd Bergmann wrote: >>> On Fri, Apr 29, 2022 at 10:23 PM Guenter Roeck <linux@roeck-us.net> wrote: >>>> On 4/29/22 10:48, Guenter Roeck wrote: >>>>> >>>>> I tried the pxa-multiplatform-5.18 branch. Its failures match >>>>> those in v5.18-rc1. >>>>> >>>> >>>> Uuh, wait, the build wasn't complete. There are still some >>>> failures. I'll report later. >>> >>> Sorry about the breakage, I got a few more reports about minor build errors >>> and warnings, the newly uploaded branches should address all of the ones >>> I got reports for. >>> >> >> Unless I am missing something the failures are the same as before. See >> https://kerneltests.org/builders/qemu-arm-testing/builds/74/steps/qemubuildcommand/logs/stdio >> >> This is with v5.18-rc1-49-ge8ab9a9a2745 which is the tip of >> soc/pxa-multiplatform-5.18. >> >> Should I check a different branch ? > > I only addressed the pcmcia probe failure that you reported for the > final pxa patch, which > previously caused a NULL pointer reference here: > > [ 1.405319] PC is at pcmcia_init_one+0xf8/0x27c > [ 1.405476] LR is at devres_add+0x40/0x6c > [ 1.405611] pc : [<c04bdea0>] lr : [<c044d808>] psr: a0000113 > [ 1.405846] sp : c48a5d00 ip : c15f4220 fp : 60000113 > [ 1.406026] r10: 00000000 r9 : c48b000e r8 : c48b0000 > [ 1.406195] r7 : feeb0000 r6 : feeb000e r5 : c15ec090 r4 : c15ec020 > [ 1.406395] r3 : 00000002 r2 : 00000000 r1 : c15f4200 r0 : feeb000e > > This now seems to work: > > [ 1.435846] pcmcia_socket pcmcia_socket1: pccard: PCMCIA card > inserted into slot 1 > [ 1.456350] pcmcia_socket pcmcia_socket0: pccard: PCMCIA card > inserted into slot 0 > [ 1.457489] pcmcia 0.0: pcmcia: registering new device pcmcia0.0 (IRQ: 217) > [ 1.460275] pata_pcmcia: probe of 0.0 failed with error -12 > > So it sounds like there are additional bugs that I have to look at. I > probably won't > be able to do that in time for the merge window. The logs contain a number of > warnings, but I have no idea which ones of those are preexisting issue. I had > a look at > > [ 0.689982] pxa-dma pxa-dma.0: error -ENXIO: IRQ index 1 not found > Yes, those messages are indeed old. > and concluded that it must have done this for a long time. In my own qemu > instance, I see a crash from iWMMXt, but that works fine on your machine. > OTOH, your failed instances all look like they either time out or > failed to find a > rootfs. I tried passing an MMC device as root, and that works here. > Booting from mmc works for me as well. Booting from pcmcia worked before, so I assume that there must be some regression. Guenter
On Sat, Apr 30, 2022 at 2:41 PM Guenter Roeck <linux@roeck-us.net> wrote: > On 4/30/22 01:04, Arnd Bergmann wrote: > > and concluded that it must have done this for a long time. In my own qemu > > instance, I see a crash from iWMMXt, but that works fine on your machine. > > OTOH, your failed instances all look like they either time out or > > failed to find a > > rootfs. I tried passing an MMC device as root, and that works here. > > > > Booting from mmc works for me as well. Booting from pcmcia worked before, > so I assume that there must be some regression. Ok, got it, and managed to reproduce the hang now. My "ARM: pxa/sa1100: move I/O space to PCI_IOBASE" patch managed to get it to the point of detecting the pcmcia device instead of crashing, so I assumed it was enough when it clearly was not. Before that patch, it still works, afterwards it hangs with "pata_pcmcia: probe of 0.0 failed with error -12" as mentioned above. I'll have another look. Arnd
On Sat, Apr 30, 2022 at 3:32 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Sat, Apr 30, 2022 at 2:41 PM Guenter Roeck <linux@roeck-us.net> wrote: > > On 4/30/22 01:04, Arnd Bergmann wrote: > > > and concluded that it must have done this for a long time. In my own qemu > > > instance, I see a crash from iWMMXt, but that works fine on your machine. > > > OTOH, your failed instances all look like they either time out or > > > failed to find a > > > rootfs. I tried passing an MMC device as root, and that works here. > > > > > > > Booting from mmc works for me as well. Booting from pcmcia worked before, > > so I assume that there must be some regression. > > Ok, got it, and managed to reproduce the hang now. My "ARM: pxa/sa1100: move > I/O space to PCI_IOBASE" patch managed to get it to the point of detecting > the pcmcia device instead of crashing, so I assumed it was enough when it > clearly was not. Before that patch, it still works, afterwards it hangs with > "pata_pcmcia: probe of 0.0 failed with error -12" as mentioned above. I'll > have another look. Got it: as the PCMCIA bus on this machine is the only thing with an I/O space, I assigned it port number range 0-0x1000, with an io_offset of 0, but this was apparently unexpected and triggered this sanity check: static int static_find_io(struct pcmcia_socket *s, unsigned int attr, unsigned int *base, unsigned int num, unsigned int align, struct resource **parent) { if (!s->io_offset) return -EINVAL; ... return 0; } I moved the devices around now, giving zeus/viper I/O space an offset of zero, and moving PCMCIA to offset 0x10000 and 0x11000 for the two slots, which now works because the io_offset is nonzero. I've regenerated the branches again, and confirmed the for-next branch still boots from pcmcia. Arnd
On 4/30/22 07:23, Arnd Bergmann wrote: > On Sat, Apr 30, 2022 at 3:32 PM Arnd Bergmann <arnd@arndb.de> wrote: >> >> On Sat, Apr 30, 2022 at 2:41 PM Guenter Roeck <linux@roeck-us.net> wrote: >>> On 4/30/22 01:04, Arnd Bergmann wrote: >>>> and concluded that it must have done this for a long time. In my own qemu >>>> instance, I see a crash from iWMMXt, but that works fine on your machine. >>>> OTOH, your failed instances all look like they either time out or >>>> failed to find a >>>> rootfs. I tried passing an MMC device as root, and that works here. >>>> >>> >>> Booting from mmc works for me as well. Booting from pcmcia worked before, >>> so I assume that there must be some regression. >> >> Ok, got it, and managed to reproduce the hang now. My "ARM: pxa/sa1100: move >> I/O space to PCI_IOBASE" patch managed to get it to the point of detecting >> the pcmcia device instead of crashing, so I assumed it was enough when it >> clearly was not. Before that patch, it still works, afterwards it hangs with >> "pata_pcmcia: probe of 0.0 failed with error -12" as mentioned above. I'll >> have another look. > > Got it: as the PCMCIA bus on this machine is the only thing with an I/O space, > I assigned it port number range 0-0x1000, with an io_offset of 0, but this > was apparently unexpected and triggered this sanity check: > > static int static_find_io(struct pcmcia_socket *s, unsigned int attr, > unsigned int *base, unsigned int num, > unsigned int align, struct resource **parent) > { > if (!s->io_offset) > return -EINVAL; > ... > return 0; > } > > I moved the devices around now, giving zeus/viper I/O space an offset of > zero, and moving PCMCIA to offset 0x10000 and 0x11000 for the two slots, > which now works because the io_offset is nonzero. I've regenerated the > branches again, and confirmed the for-next branch still boots from pcmcia. > With v5.18-rc1-49-gcb813018b5c1, I still get: [ 0.797668] RAMDISK: Couldn't find valid RAM disk image starting at 0. [ 0.805262] /dev/root: Can't open blockdev [ 0.805487] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6 [ 0.805674] Please append a correct "root=" boot option; here are the available partitions: when trying to boot z2 from initrd. The other problems are gone. Guenter
On Mon, May 2, 2022 at 6:26 PM Guenter Roeck <linux@roeck-us.net> wrote: > > With v5.18-rc1-49-gcb813018b5c1, I still get: > > [ 0.797668] RAMDISK: Couldn't find valid RAM disk image starting at 0. > [ 0.805262] /dev/root: Can't open blockdev > [ 0.805487] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6 > [ 0.805674] Please append a correct "root=" boot option; here are the available partitions: > > when trying to boot z2 from initrd. > > The other problems are gone. Ok, progress! What is your qemu command line? I see that z2 has no pcmcia device, so I tried booting from MMC, but this already fails with 5.18-rc1 without any of my patches, giving me [ 0.697481] Creating 3 MTD partitions on "physmap-flash": [ 0.698161] 0x000000000000-0x000000040000 : "U-Boot Bootloader" [ 0.702815] 0x000000040000-0x000000060000 : "U-Boot Environment" [ 0.706541] 0x000000060000-0x000000800000 : "Flash" [ 0.718066] pxa2xx-mci pxa2xx-mci.0: incomplete constraints, dummy supplies not allowed [ 0.718501] pxa2xx-mci pxa2xx-mci.0: incomplete constraints, dummy supplies not allowed Do you have MMC or some other rootfs working without my patch series? Arnd
On 5/2/22 12:21, Arnd Bergmann wrote: > On Mon, May 2, 2022 at 6:26 PM Guenter Roeck <linux@roeck-us.net> wrote: >> >> With v5.18-rc1-49-gcb813018b5c1, I still get: >> >> [ 0.797668] RAMDISK: Couldn't find valid RAM disk image starting at 0. >> [ 0.805262] /dev/root: Can't open blockdev >> [ 0.805487] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6 >> [ 0.805674] Please append a correct "root=" boot option; here are the available partitions: >> >> when trying to boot z2 from initrd. >> >> The other problems are gone. > > Ok, progress! > > What is your qemu command line? I see that z2 has no pcmcia device, so > I tried booting > from MMC, but this already fails with 5.18-rc1 without any of my > patches, giving me > > [ 0.697481] Creating 3 MTD partitions on "physmap-flash": > [ 0.698161] 0x000000000000-0x000000040000 : "U-Boot Bootloader" > [ 0.702815] 0x000000040000-0x000000060000 : "U-Boot Environment" > [ 0.706541] 0x000000060000-0x000000800000 : "Flash" > [ 0.718066] pxa2xx-mci pxa2xx-mci.0: incomplete constraints, dummy > supplies not allowed > [ 0.718501] pxa2xx-mci pxa2xx-mci.0: incomplete constraints, dummy > supplies not allowed > To boot from initrd: qemu-system-arm -M z2 -kernel \ arch/arm/boot/zImage -no-reboot -initrd \ rootfs-armv5.cpio --append \ "panic=-1 slub_debug=FZPUA rdinit=/sbin/init console=ttyS0" -nographic \ -monitor null -serial stdio where rootfs-armv5.cpio is from my repository at github.com. https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/rootfs-armv5.cpio.gz > Do you have MMC or some other rootfs working without my patch series? > I can boot z2 from mmc and flash, but I have a number of configuration flags enabled on top of pxa_defconfig. That also works with your latest patch series. See https://kerneltests.org/builders/qemu-arm-testing/builds/75/steps/qemubuildcommand/logs/stdio # Always enable ... enable_config "${defconfig}" CONFIG_DEVTMPFS CONFIG_DEVTMPFS_MOUNT CONFIG_BLK_DEV_INITRD # Options needed to be built into the kernel for device support # on pxa devices # MTD, squashfs enable_config_cond "${defconfig}" CONFIG_MTD_BLOCK CONFIG_MTD_PXA2XX CONFIG_SQUASHFS # MMC enable_config_cond "${defconfig}" CONFIG_MMC_BLOCK CONFIG_MMC_PXA # PCMCIA enable_config_cond "${defconfig}" CONFIG_ATA CONFIG_BLK_DEV_SD CONFIG_PCCARD enable_config_cond "${defconfig}" CONFIG_PCMCIA CONFIG_PATA_PCMCIA CONFIG_PCMCIA_PXA2XX # USB enable_config_cond "${defconfig}" CONFIG_USB CONFIG_USB_STORAGE CONFIG_USB_OHCI_HCD CONFIG_USB_OHCI_HCD_PXA27X Hope this helps, Guenter
On Mon, May 2, 2022 at 10:35 PM Guenter Roeck <linux@roeck-us.net> wrote: > On 5/2/22 12:21, Arnd Bergmann wrote: > > > > To boot from initrd: > > qemu-system-arm -M z2 -kernel \ > arch/arm/boot/zImage -no-reboot -initrd \ > rootfs-armv5.cpio --append \ > "panic=-1 slub_debug=FZPUA rdinit=/sbin/init console=ttyS0" -nographic \ > -monitor null -serial stdio > > where rootfs-armv5.cpio is from my repository at github.com. > > https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/rootfs-armv5.cpio.gz > Ok, that works here with any configuration, I don't see a regression. Could this be a problem with the size increase? The machine only has 32MB of RAM, so it's possible that the multiplatform-enabled kernel with DT support etc pushes it over the edge, especially with an initramfs. My configuration is clearly a bit different from yours, so I tried giving it a larger initramfs file, which randomly crashes elsewhere for me: [ 0.648659] pxa2xx-uart.0: ttyS0 at MMIO 0x40100000 (irq = 38, base_baud = 928571) is a UART1 [ 0.697984] kworker/u2:0 invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 [ 0.698278] CPU: 0 PID: 7 Comm: kworker/u2:0 Not tainted 5.18.0-rc1-00109-gee927ad51300-dirty #52 [ 0.698382] Hardware name: Zipit Z2 [ 0.698520] Workqueue: events_unbound async_run_entry_fn [ 0.699063] unwind_backtrace from show_stack+0x18/0x1c [ 0.699148] show_stack from dump_header+0x68/0x254 [ 0.699186] dump_header from out_of_memory+0x474/0x4f0 [ 0.699208] out_of_memory from __alloc_pages+0xa0c/0xb84 [ 0.699227] __alloc_pages from shmem_getpage_gfp.constprop.0+0x270/0x9e0 [ 0.699247] shmem_getpage_gfp.constprop.0 from generic_perform_write+0xd8/0x210 [ 0.699268] generic_perform_write from __generic_file_write_iter+0x130/0x198 [ 0.699286] __generic_file_write_iter from generic_file_write_iter+0x64/0xd0 [ 0.699302] generic_file_write_iter from __kernel_write+0x114/0x2b0 [ 0.699321] __kernel_write from kernel_write+0x68/0x194 [ 0.699337] kernel_write from xwrite+0x3c/0x78 [ 0.699363] xwrite from do_copy+0xc0/0x11c [ 0.699381] do_copy from write_buffer+0x2c/0x44 [ 0.699397] write_buffer from flush_buffer+0x3c/0xa0 [ 0.699413] flush_buffer from __gunzip+0x2a4/0x364 [ 0.699434] __gunzip from gunzip+0x2c/0x34 [ 0.699449] gunzip from unpack_to_rootfs+0x19c/0x304 [ 0.699465] unpack_to_rootfs from do_populate_rootfs+0x6c/0x1dc [ 0.699483] do_populate_rootfs from async_run_entry_fn+0x44/0x1a0 [ 0.699502] async_run_entry_fn from process_one_work+0x1e8/0x544 [ 0.699520] process_one_work from worker_thread+0x34/0x578 [ 0.699579] worker_thread from kthread+0xdc/0x114 [ 0.699599] kthread from ret_from_fork+0x14/0x2c [ 0.699651] Exception stack(0xc2821fb0 to 0xc2821ff8) [ 0.699711] 1fa0: 00000000 00000000 00000000 00000000 [ 0.699731] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 0.699744] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 0.699801] Mem-Info: [ 0.699889] active_anon:90 inactive_anon:674 isolated_anon:0 [ 0.699889] active_file:0 inactive_file:0 isolated_file:0 [ 0.699889] unevictable:0 dirty:0 writeback:0 [ 0.699889] slab_reclaimable:0 slab_unreclaimable:1691 [ 0.699889] mapped:0 shmem:771 pagetables:0 bounce:0 [ 0.699889] kernel_misc_reclaimable:0 [ 0.699889] free:207 free_pcp:37 free_cma:0 [ 0.699986] Node 0 active_anon:360kB inactive_anon:2696kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:3084kB writeback_tmp:0kB kernel_stack:192kB pagetables:0kB all_unreclaimable? yes [ 0.700116] Normal free:828kB boost:1024kB min:1464kB low:1572kB high:1680kB reserved_highatomic:0KB active_anon:360kB inactive_anon:2696kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:32768kB managed:12232kB mlocked:0kB bounce:0kB free_pcp:148kB local_pcp:148kB free_cma:0kB [ 0.700177] lowmem_reserve[]: 0 0 [ 0.700247] Normal: 3*4kB (UM) 2*8kB (UM) 2*16kB (M) 0*32kB 0*64kB 0*128kB 1*256kB (M) 1*512kB (M) 0*1024kB = 828kB Arnd
On 5/2/22 14:03, Arnd Bergmann wrote: > On Mon, May 2, 2022 at 10:35 PM Guenter Roeck <linux@roeck-us.net> wrote: >> On 5/2/22 12:21, Arnd Bergmann wrote: >>> >> >> To boot from initrd: >> >> qemu-system-arm -M z2 -kernel \ >> arch/arm/boot/zImage -no-reboot -initrd \ >> rootfs-armv5.cpio --append \ >> "panic=-1 slub_debug=FZPUA rdinit=/sbin/init console=ttyS0" -nographic \ >> -monitor null -serial stdio >> >> where rootfs-armv5.cpio is from my repository at github.com. >> >> https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/rootfs-armv5.cpio.gz >> > > Ok, that works here with any configuration, I don't see a regression. > Could this be a problem with the size increase? The machine only has > 32MB of RAM, so it's possible that the multiplatform-enabled kernel > with DT support etc pushes it over the edge, especially with an initramfs. > qemu puts initrd in the middle of available memory. With the image size being ~1MB larger than with v5.18-rc, this is too much, and the kernel overwrites part of initrd. This causes it to be corrupted. It looks like that would have happened eventually, your patch series just made it happen now. The kernel is just getting too large to run on such small systems. I worked around the problem in my version of qemu by loading initrd at the end of the (small) RAM. With that, I no longer see the boot failure. Guenter
On Tue, May 3, 2022 at 4:55 AM Guenter Roeck <linux@roeck-us.net> wrote: > On 5/2/22 14:03, Arnd Bergmann wrote: > > On Mon, May 2, 2022 at 10:35 PM Guenter Roeck <linux@roeck-us.net> wrote: > >> On 5/2/22 12:21, Arnd Bergmann wrote: > > qemu puts initrd in the middle of available memory. With the image size > being ~1MB larger than with v5.18-rc, this is too much, and the kernel > overwrites part of initrd. This causes it to be corrupted. > > It looks like that would have happened eventually, your patch series just > made it happen now. The kernel is just getting too large to run on such small > systems. I worked around the problem in my version of qemu by loading initrd > at the end of the (small) RAM. With that, I no longer see the boot failure. Ok, thanks for confirming. If it's just the image size that changed, then I think we can live with it. Having the kernel image grow by 1MB seems excessive though, I'd like to understand better where that increase comes from. Starting out from pxa_defconfig, I see a 40KB increase from the final patch that moves to multiplatform support, which I think is fine. If you have a z2 specific config, that would probably not enable CONFIG_OF, which is always turned on for multiplatform, but again that only adds around 250KB in my builds (using gcc-11). This is more than I'd like it to be, but still much less than 1MB. Arnd
On 5/3/22 00:17, Arnd Bergmann wrote: > On Tue, May 3, 2022 at 4:55 AM Guenter Roeck <linux@roeck-us.net> wrote: >> On 5/2/22 14:03, Arnd Bergmann wrote: >>> On Mon, May 2, 2022 at 10:35 PM Guenter Roeck <linux@roeck-us.net> wrote: >>>> On 5/2/22 12:21, Arnd Bergmann wrote: >> >> qemu puts initrd in the middle of available memory. With the image size >> being ~1MB larger than with v5.18-rc, this is too much, and the kernel >> overwrites part of initrd. This causes it to be corrupted. >> >> It looks like that would have happened eventually, your patch series just >> made it happen now. The kernel is just getting too large to run on such small >> systems. I worked around the problem in my version of qemu by loading initrd >> at the end of the (small) RAM. With that, I no longer see the boot failure. > > Ok, thanks for confirming. If it's just the image size that changed, > then I think > we can live with it. Having the kernel image grow by 1MB seems excessive > though, I'd like to understand better where that increase comes from. > > Starting out from pxa_defconfig, I see a 40KB increase from the final patch > that moves to multiplatform support, which I think is fine. > > If you have a z2 specific config, that would probably not enable CONFIG_OF, > which is always turned on for multiplatform, but again that only adds around > 250KB in my builds (using gcc-11). This is more than I'd like it to be, but > still much less than 1MB. > Maybe it is a bit less; I only compared the size of "Image". Either case, it is enough to cause the problem. I am not sure if it is worth the time trying to track this down further. Guenter
On Tue, May 3, 2022 at 4:04 PM Guenter Roeck <linux@roeck-us.net> wrote: > On 5/3/22 00:17, Arnd Bergmann wrote: > > > If you have a z2 specific config, that would probably not enable CONFIG_OF, > > which is always turned on for multiplatform, but again that only adds around > > 250KB in my builds (using gcc-11). This is more than I'd like it to be, but > > still much less than 1MB. > > > > Maybe it is a bit less; I only compared the size of "Image". Either case, > it is enough to cause the problem. I am not sure if it is worth the time > trying to track this down further. Sure, I'm not worried about the boot regression any more, as that is definitely explained by the size growth. The only question is whether the patches make the kernel grow more than it should. The 40+250KB I measured seem within my expectations, so unless you have specific data showing much more, I think we're good. Thanks for all the help! Arnd
From: Arnd Bergmann <arnd@arndb.de> This revisits a series I sent a few years ago: https://lore.kernel.org/lkml/20191018154052.1276506-1-arnd@arndb.de/ All the other ARMv5 conversions are under way now, with OMAP1 being the only one still not in linux-next yet, and PXA completing the set. Most of the patches are unchanged from before, furtunately the PXA code is fairly stable. I addressed Robert's comments, pulled in two patches from Dmitry, and added the last a the final four patches to finish off the multiplatform conversion. I hope someone is left to test these on PXA: if this works, I'd like to merge it for 5.19. A git tree with these is avaialable for testing at https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/log/?h=pxa-multiplatform-5.18 Arnd Arnd Bergmann (46): ARM: pxa: split mach/generic.h ARM: pxa: make mainstone.h private ARM: pxa: make mach/regs-uart.h private ARM: pxa: remove mach/dma.h ARM: pxa: split up mach/hardware.h ARM: pxa: stop using mach/bitfield.h ARM: pxa: move mach/sound.h to linux/platform_data/ ARM: pxa: move regs-lcd.h into driver watchdog: sa1100: use platform device registration ARM: pxa: pxa2xx-ac97-lib: use IRQ resource ARM: pxa: move pcmcia board data into mach-pxa ARM: pxa: make addr-map.h header local ARM: pxa: use pdev resource for palmld mmio ARM: pxa: maybe fix gpio lookup tables ARM: pxa: tosa: use gpio descriptor for audio ARM: pxa: poodle: use platform data for poodle asoc driver ARM: pxa: corgi: use gpio descriptors for audio ARM: pxa: hx4700: use gpio descriptors for audio ARM: pxa: lubbock: pass udc irqs as resource ARM: pxa: spitz: use gpio descriptors for audio ARM: pxa: eseries: use gpio lookup for audio ARM: pxa: z2: use gpio lookup for audio device ARM: pxa: magician: use platform driver for audio ARM: pxa: mainstone-wm97xx: use gpio lookup table ARM: pxa: zylonite: use gpio lookup instead mfp header input: touchscreen: mainstone: fix pxa2xx+pxa3xx configuration input: touchscreen: mainstone: sync with zylonite driver Input: touchscreen: use wrapper for pxa2xx ac97 registers ASoC: pxa: use pdev resource for FIFO regs ASoC: pxa: ac97: use normal MMIO accessors ASoC: pxa: i2s: use normal MMIO accessors ARM: pxa: pcmcia: move smemc configuration back to arch ARM: pxa: remove get_clk_frequency_khz() cpufreq: pxa3: move clk register access to clk driver ARM: pxa: move smemc register access from clk to platform ARM: pxa: move clk register definitions to driver power: tosa: simplify probe function ARM: pxa: tosa: use gpio lookup for battery ARM: pxa: remove unused mach/bitfield.h ARM: mmp: remove tavorevb board support ARM: mmp: rename pxa_register_device ARM: pxa: move plat-pxa to drivers/soc/ ARM: PXA: fix multi-cpu build of xsc3 ARM: pxa: move mach/*.h to mach-pxa/ ARM: pxa: remove support for MTD_XIP ARM: pxa: convert to multiplatform Dmitry Torokhov (2): Input: wm97xx - switch to using threaded IRQ Input: wm97xx - get rid of irq_enable method in wm97xx_mach_ops arch/arm/Kconfig | 22 -- arch/arm/Makefile | 1 - arch/arm/common/locomo.c | 1 - arch/arm/common/sa1111.c | 5 +- arch/arm/include/asm/hardware/sa1111.h | 2 - arch/arm/mach-mmp/Kconfig | 10 +- arch/arm/mach-mmp/Makefile | 1 - arch/arm/mach-mmp/devices.c | 2 +- arch/arm/mach-mmp/devices.h | 10 +- arch/arm/mach-mmp/mfp.h | 2 +- arch/arm/mach-mmp/mmp2.h | 48 ++--- arch/arm/mach-mmp/pxa168.h | 60 +++--- arch/arm/mach-mmp/pxa910.h | 38 ++-- arch/arm/mach-mmp/tavorevb.c | 113 ----------- arch/arm/mach-mmp/ttc_dkb.c | 6 +- arch/arm/mach-pxa/Kconfig | 14 ++ arch/arm/mach-pxa/Makefile | 18 +- arch/arm/mach-pxa/Makefile.boot | 3 - .../mach-pxa/{include/mach => }/addr-map.h | 0 arch/arm/mach-pxa/am300epd.c | 2 +- .../arm/mach-pxa/balloon3-pcmcia.c | 4 +- arch/arm/mach-pxa/balloon3.c | 4 +- .../mach-pxa/{include/mach => }/balloon3.h | 0 arch/arm/mach-pxa/cm-x300.c | 12 +- arch/arm/mach-pxa/colibri-evalboard.c | 1 - .../arm/mach-pxa/colibri-pcmcia.c | 2 +- arch/arm/mach-pxa/colibri-pxa270-income.c | 1 - arch/arm/mach-pxa/colibri-pxa270.c | 2 +- arch/arm/mach-pxa/colibri-pxa300.c | 3 +- arch/arm/mach-pxa/colibri-pxa320.c | 2 +- arch/arm/mach-pxa/colibri-pxa3xx.c | 3 +- arch/arm/mach-pxa/colibri.h | 2 +- arch/arm/mach-pxa/corgi.c | 23 ++- arch/arm/mach-pxa/{include/mach => }/corgi.h | 0 arch/arm/mach-pxa/corgi_pm.c | 5 +- arch/arm/mach-pxa/csb726.c | 5 +- arch/arm/mach-pxa/csb726.h | 2 +- arch/arm/mach-pxa/devices.c | 17 +- .../arm/mach-pxa/e740-pcmcia.c | 4 +- .../{include/mach => }/eseries-gpio.h | 0 arch/arm/mach-pxa/eseries.c | 36 +++- arch/arm/mach-pxa/ezx.c | 1 - arch/arm/mach-pxa/generic.c | 62 ++++-- arch/arm/mach-pxa/generic.h | 9 - arch/arm/mach-pxa/gumstix.c | 1 - arch/arm/mach-pxa/gumstix.h | 2 +- arch/arm/mach-pxa/h5000.c | 2 +- .../arm/mach-pxa/hx4700-pcmcia.c | 4 +- arch/arm/mach-pxa/hx4700.c | 18 +- arch/arm/mach-pxa/{include/mach => }/hx4700.h | 0 arch/arm/mach-pxa/idp.c | 2 - arch/arm/mach-pxa/idp.h | 2 +- arch/arm/mach-pxa/include/mach/bitfield.h | 114 ----------- arch/arm/mach-pxa/include/mach/dma.h | 17 -- arch/arm/mach-pxa/include/mach/generic.h | 1 - arch/arm/mach-pxa/include/mach/mtd-xip.h | 36 ---- arch/arm/mach-pxa/include/mach/uncompress.h | 70 ------- arch/arm/mach-pxa/irq.c | 5 +- arch/arm/mach-pxa/{include/mach => }/irqs.h | 0 arch/arm/mach-pxa/littleton.c | 1 - arch/arm/mach-pxa/lpd270.c | 6 +- arch/arm/mach-pxa/lubbock.c | 17 +- .../arm/mach-pxa/{include/mach => }/lubbock.h | 4 +- arch/arm/mach-pxa/magician.c | 56 +++++- .../mach-pxa/{include/mach => }/magician.h | 2 +- arch/arm/mach-pxa/mainstone.c | 17 +- .../mach-pxa/{include/mach => }/mainstone.h | 4 +- arch/arm/mach-pxa/mfp-pxa2xx.c | 3 +- arch/arm/mach-pxa/mfp-pxa2xx.h | 2 +- arch/arm/mach-pxa/mfp-pxa3xx.c | 3 +- arch/arm/mach-pxa/mfp-pxa3xx.h | 2 +- arch/arm/mach-pxa/{include/mach => }/mfp.h | 2 +- arch/arm/mach-pxa/mioa701.c | 4 +- arch/arm/mach-pxa/mxm8x10.c | 8 +- arch/arm/mach-pxa/palm27x.c | 2 +- .../arm/mach-pxa/palmld-pcmcia.c | 5 +- arch/arm/mach-pxa/palmld.c | 23 ++- arch/arm/mach-pxa/{include/mach => }/palmld.h | 0 arch/arm/mach-pxa/palmt5.c | 11 +- arch/arm/mach-pxa/palmt5.h | 2 +- .../arm/mach-pxa/palmtc-pcmcia.c | 4 +- arch/arm/mach-pxa/palmtc.c | 4 +- arch/arm/mach-pxa/{include/mach => }/palmtc.h | 0 arch/arm/mach-pxa/palmte2.c | 2 +- arch/arm/mach-pxa/palmtreo.c | 4 +- .../arm/mach-pxa/palmtx-pcmcia.c | 4 +- arch/arm/mach-pxa/palmtx.c | 13 +- arch/arm/mach-pxa/{include/mach => }/palmtx.h | 0 arch/arm/mach-pxa/palmz72.c | 2 +- arch/arm/mach-pxa/pcm027.h | 2 +- arch/arm/mach-pxa/pcm990-baseboard.c | 2 +- arch/arm/mach-pxa/pcm990_baseboard.h | 2 +- arch/arm/mach-pxa/poodle.c | 31 ++- arch/arm/mach-pxa/{include/mach => }/poodle.h | 2 - arch/arm/mach-pxa/pxa-dt.c | 2 +- arch/arm/mach-pxa/pxa-regs.h | 52 +++++ arch/arm/mach-pxa/pxa25x.c | 12 +- arch/arm/mach-pxa/pxa25x.h | 6 +- arch/arm/mach-pxa/pxa27x-udc.h | 2 + arch/arm/mach-pxa/pxa27x.c | 12 +- arch/arm/mach-pxa/pxa27x.h | 6 +- .../mach-pxa/{include/mach => }/pxa2xx-regs.h | 47 +---- arch/arm/mach-pxa/pxa2xx.c | 30 ++- arch/arm/mach-pxa/pxa300.c | 1 + arch/arm/mach-pxa/pxa320.c | 1 + .../mach-pxa/{include/mach => }/pxa3xx-regs.h | 71 +------ arch/arm/mach-pxa/pxa3xx-ulpi.c | 2 +- arch/arm/mach-pxa/pxa3xx.c | 19 +- arch/arm/mach-pxa/pxa3xx.h | 6 +- arch/arm/mach-pxa/pxa930.c | 1 + .../mach-pxa/{include/mach => }/regs-ost.h | 4 +- arch/arm/mach-pxa/regs-rtc.h | 2 +- arch/arm/mach-pxa/regs-u2d.h | 2 - .../mach-pxa/{include/mach => }/regs-uart.h | 2 + arch/arm/mach-pxa/reset.c | 9 +- arch/arm/mach-pxa/{include/mach => }/reset.h | 2 +- arch/arm/mach-pxa/sharpsl_pm.c | 2 +- arch/arm/mach-pxa/sleep.S | 9 +- arch/arm/mach-pxa/smemc.c | 13 +- arch/arm/mach-pxa/{include/mach => }/smemc.h | 0 arch/arm/mach-pxa/spitz.c | 37 +++- arch/arm/mach-pxa/{include/mach => }/spitz.h | 0 arch/arm/mach-pxa/spitz_pm.c | 3 +- arch/arm/mach-pxa/standby.S | 3 +- arch/arm/mach-pxa/tosa.c | 47 ++++- arch/arm/mach-pxa/{include/mach => }/tosa.h | 0 .../arm/mach-pxa/trizeps4-pcmcia.c | 6 +- arch/arm/mach-pxa/trizeps4.c | 6 +- .../mach-pxa/{include/mach => }/trizeps4.h | 1 + .../arm/mach-pxa/viper-pcmcia.c | 6 +- .../arm/mach-pxa/viper-pcmcia.h | 0 arch/arm/mach-pxa/viper.c | 8 +- .../arm/mach-pxa/vpac270-pcmcia.c | 4 +- arch/arm/mach-pxa/vpac270.c | 4 +- .../arm/mach-pxa/{include/mach => }/vpac270.h | 0 arch/arm/mach-pxa/xcep.c | 4 +- arch/arm/mach-pxa/z2.c | 13 +- arch/arm/mach-pxa/{include/mach => }/z2.h | 0 arch/arm/mach-pxa/zeus.c | 8 +- arch/arm/mach-pxa/zylonite.c | 34 +++- arch/arm/mach-pxa/zylonite.h | 2 + arch/arm/mach-pxa/zylonite_pxa300.c | 1 + arch/arm/mach-pxa/zylonite_pxa320.c | 1 + arch/arm/mach-sa1100/generic.c | 6 +- arch/arm/mach-sa1100/include/mach/reset.h | 1 - arch/arm/mm/copypage-xsc3.c | 2 + arch/mips/alchemy/devboards/db1300.c | 9 - drivers/ata/pata_palmld.c | 3 +- drivers/clk/pxa/clk-pxa.c | 8 +- drivers/clk/pxa/clk-pxa.h | 9 +- drivers/clk/pxa/clk-pxa25x.c | 46 ++--- drivers/clk/pxa/clk-pxa27x.c | 68 +++---- drivers/clk/pxa/clk-pxa2xx.h | 58 ++++++ drivers/clk/pxa/clk-pxa3xx.c | 139 +++++++++++-- drivers/cpufreq/pxa2xx-cpufreq.c | 6 +- drivers/cpufreq/pxa3xx-cpufreq.c | 65 +++--- drivers/input/mouse/pxa930_trkball.c | 1 - drivers/input/touchscreen/Kconfig | 2 + drivers/input/touchscreen/mainstone-wm97xx.c | 130 ++++++------ drivers/input/touchscreen/wm97xx-core.c | 42 +--- drivers/input/touchscreen/zylonite-wm97xx.c | 43 ++-- drivers/leds/leds-locomo.c | 1 - drivers/mmc/host/pxamci.c | 2 +- drivers/mtd/maps/pxa2xx-flash.c | 2 - drivers/pcmcia/Makefile | 13 -- drivers/pcmcia/pxa2xx_base.c | 48 ++--- drivers/pcmcia/pxa2xx_sharpsl.c | 3 +- drivers/pcmcia/sa1111_generic.c | 1 - drivers/pcmcia/sa1111_lubbock.c | 1 - drivers/pcmcia/soc_common.c | 2 - drivers/pcmcia/soc_common.h | 120 +---------- drivers/power/supply/tosa_battery.c | 189 ++++++++++-------- drivers/rtc/rtc-pxa.c | 2 - drivers/soc/Kconfig | 1 + drivers/soc/Makefile | 1 + .../arm/plat-pxa => drivers/soc/pxa}/Kconfig | 5 +- .../arm/plat-pxa => drivers/soc/pxa}/Makefile | 4 - {arch/arm/plat-pxa => drivers/soc/pxa}/mfp.c | 2 +- {arch/arm/plat-pxa => drivers/soc/pxa}/ssp.c | 0 drivers/usb/gadget/udc/pxa25x_udc.c | 37 ++-- drivers/usb/gadget/udc/pxa25x_udc.h | 7 +- drivers/usb/host/ohci-pxa27x.c | 3 +- .../video/fbdev/pxa3xx-regs.h | 24 +-- drivers/video/fbdev/pxafb.c | 4 +- drivers/watchdog/sa1100_wdt.c | 88 +++++--- include/linux/clk/pxa.h | 16 ++ include/linux/platform_data/asoc-poodle.h | 16 ++ .../linux/platform_data/asoc-pxa.h | 4 +- include/linux/platform_data/video-pxafb.h | 22 +- .../hardware.h => include/linux/soc/pxa/cpu.h | 61 +----- .../plat => include/linux/soc/pxa}/mfp.h | 6 +- include/linux/soc/pxa/smemc.h | 13 ++ include/linux/wm97xx.h | 4 - include/pcmcia/soc_common.h | 125 ++++++++++++ include/sound/pxa2xx-lib.h | 4 + sound/arm/pxa2xx-ac97-lib.c | 145 +++++++++----- .../arm/pxa2xx-ac97-regs.h | 42 ++-- sound/arm/pxa2xx-ac97.c | 3 +- sound/soc/pxa/corgi.c | 43 ++-- sound/soc/pxa/e740_wm9705.c | 37 ++-- sound/soc/pxa/e750_wm9705.c | 33 ++- sound/soc/pxa/e800_wm9712.c | 33 ++- sound/soc/pxa/em-x270.c | 2 +- sound/soc/pxa/hx4700.c | 34 ++-- sound/soc/pxa/magician.c | 141 ++++--------- sound/soc/pxa/mioa701_wm9713.c | 2 +- sound/soc/pxa/palm27x.c | 2 +- sound/soc/pxa/poodle.c | 51 ++--- sound/soc/pxa/pxa2xx-ac97.c | 24 ++- sound/soc/pxa/pxa2xx-i2s.c | 112 ++++++----- sound/soc/pxa/spitz.c | 58 +++--- sound/soc/pxa/tosa.c | 18 +- sound/soc/pxa/z2.c | 8 +- 213 files changed, 1902 insertions(+), 1936 deletions(-) delete mode 100644 arch/arm/mach-mmp/tavorevb.c delete mode 100644 arch/arm/mach-pxa/Makefile.boot rename arch/arm/mach-pxa/{include/mach => }/addr-map.h (100%) rename drivers/pcmcia/pxa2xx_balloon3.c => arch/arm/mach-pxa/balloon3-pcmcia.c (98%) rename arch/arm/mach-pxa/{include/mach => }/balloon3.h (100%) rename drivers/pcmcia/pxa2xx_colibri.c => arch/arm/mach-pxa/colibri-pcmcia.c (99%) rename arch/arm/mach-pxa/{include/mach => }/corgi.h (100%) rename drivers/pcmcia/pxa2xx_e740.c => arch/arm/mach-pxa/e740-pcmcia.c (98%) rename arch/arm/mach-pxa/{include/mach => }/eseries-gpio.h (100%) rename drivers/pcmcia/pxa2xx_hx4700.c => arch/arm/mach-pxa/hx4700-pcmcia.c (98%) rename arch/arm/mach-pxa/{include/mach => }/hx4700.h (100%) delete mode 100644 arch/arm/mach-pxa/include/mach/bitfield.h delete mode 100644 arch/arm/mach-pxa/include/mach/dma.h delete mode 100644 arch/arm/mach-pxa/include/mach/generic.h delete mode 100644 arch/arm/mach-pxa/include/mach/mtd-xip.h delete mode 100644 arch/arm/mach-pxa/include/mach/uncompress.h rename arch/arm/mach-pxa/{include/mach => }/irqs.h (100%) rename arch/arm/mach-pxa/{include/mach => }/lubbock.h (95%) rename arch/arm/mach-pxa/{include/mach => }/magician.h (99%) rename arch/arm/mach-pxa/{include/mach => }/mainstone.h (98%) rename arch/arm/mach-pxa/{include/mach => }/mfp.h (91%) rename drivers/pcmcia/pxa2xx_palmld.c => arch/arm/mach-pxa/palmld-pcmcia.c (98%) rename arch/arm/mach-pxa/{include/mach => }/palmld.h (100%) rename drivers/pcmcia/pxa2xx_palmtc.c => arch/arm/mach-pxa/palmtc-pcmcia.c (98%) rename arch/arm/mach-pxa/{include/mach => }/palmtc.h (100%) rename drivers/pcmcia/pxa2xx_palmtx.c => arch/arm/mach-pxa/palmtx-pcmcia.c (98%) rename arch/arm/mach-pxa/{include/mach => }/palmtx.h (100%) rename arch/arm/mach-pxa/{include/mach => }/poodle.h (98%) create mode 100644 arch/arm/mach-pxa/pxa-regs.h rename arch/arm/mach-pxa/{include/mach => }/pxa2xx-regs.h (76%) rename arch/arm/mach-pxa/{include/mach => }/pxa3xx-regs.h (61%) rename arch/arm/mach-pxa/{include/mach => }/regs-ost.h (94%) rename arch/arm/mach-pxa/{include/mach => }/regs-uart.h (99%) rename arch/arm/mach-pxa/{include/mach => }/reset.h (92%) rename arch/arm/mach-pxa/{include/mach => }/smemc.h (100%) rename arch/arm/mach-pxa/{include/mach => }/spitz.h (100%) rename arch/arm/mach-pxa/{include/mach => }/tosa.h (100%) rename drivers/pcmcia/pxa2xx_trizeps4.c => arch/arm/mach-pxa/trizeps4-pcmcia.c (98%) rename arch/arm/mach-pxa/{include/mach => }/trizeps4.h (99%) rename drivers/pcmcia/pxa2xx_viper.c => arch/arm/mach-pxa/viper-pcmcia.c (97%) rename include/linux/platform_data/pcmcia-pxa2xx_viper.h => arch/arm/mach-pxa/viper-pcmcia.h (100%) rename drivers/pcmcia/pxa2xx_vpac270.c => arch/arm/mach-pxa/vpac270-pcmcia.c (98%) rename arch/arm/mach-pxa/{include/mach => }/vpac270.h (100%) rename arch/arm/mach-pxa/{include/mach => }/z2.h (100%) create mode 100644 drivers/clk/pxa/clk-pxa2xx.h rename {arch/arm/plat-pxa => drivers/soc/pxa}/Kconfig (83%) rename {arch/arm/plat-pxa => drivers/soc/pxa}/Makefile (51%) rename {arch/arm/plat-pxa => drivers/soc/pxa}/mfp.c (99%) rename {arch/arm/plat-pxa => drivers/soc/pxa}/ssp.c (100%) rename arch/arm/mach-pxa/include/mach/regs-lcd.h => drivers/video/fbdev/pxa3xx-regs.h (90%) create mode 100644 include/linux/clk/pxa.h create mode 100644 include/linux/platform_data/asoc-poodle.h rename arch/arm/mach-pxa/include/mach/audio.h => include/linux/platform_data/asoc-pxa.h (93%) rename arch/arm/mach-pxa/include/mach/hardware.h => include/linux/soc/pxa/cpu.h (75%) rename {arch/arm/plat-pxa/include/plat => include/linux/soc/pxa}/mfp.h (98%) create mode 100644 include/linux/soc/pxa/smemc.h create mode 100644 include/pcmcia/soc_common.h rename arch/arm/mach-pxa/include/mach/regs-ac97.h => sound/arm/pxa2xx-ac97-regs.h (71%)