Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Guenter Roeck]

Hi,

my 'sabrelite' and 'imx25-pdk' qemu boot tests are failing in linux-next.

Bisect for the sabrelite failure points to commit 'ARM: dts: imx: Remove skeleton.dtsi'.

Bisect log is attached. Complete test logs are at
http://kerneltests.org/builders/qemu-arm-next/builds/571/steps/qemubuildcommand/logs/stdio

Boot log for imx25-pdk:

qemu-system-arm: findnode_nofail Couldn't find node /chosen: FDT_ERR_NOTFOUND

Boot log for sabrelite:

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.9.0-rc5-next-20161116 (groeck@jupiter.roeck-us.net) (gcc version 4.9.2 (GCC) ) #1 SMP Tue Nov 15 22:34:35 PST 2016
[    0.000000] CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] OF: fdt:Machine model: Freescale i.MX6 DualLite SABRE Lite Board
[    0.000000] earlycon: ec_imx21 at MMIO 0x021e8000 (options '')
[    0.000000] bootconsole [ec_imx21] enabled
[    0.000000] INITRD: 0x14000000+0x00501600 is not a memory region - disabling initrd
[    0.000000] cma: Failed to reserve 64 MiB
[    0.000000] Memory policy: Data cache writeback

[ stuck here until aborted ]

Build is imx_v6_v7_defconfig and multi_v7_defconfig with imx6dl-sabrelite.dtb,
and imx_v4_v5_defconfig with imx25-pdk.dtb.

Any idea what might be wrong ?

Thanks,
Guenter

-------
# bad: [56c0dbc6eced261af328afd3335d62234bc56513] Add linux-next specific files for 20161116
# good: [a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6] Linux 4.9-rc5
git bisect start 'HEAD' 'v4.9-rc5'
# bad: [56abc46730bb1c5ffd960c71ae089cb713e85e47] Merge remote-tracking branch 'drm/drm-next'
git bisect bad 56abc46730bb1c5ffd960c71ae089cb713e85e47
# bad: [c0d79c892333b32ddae50bbadd885413b51f7252] Merge remote-tracking branch 'dlm/next'
git bisect bad c0d79c892333b32ddae50bbadd885413b51f7252
# bad: [4763d380325df1d74bf3891b00fd318d4a44feee] Merge remote-tracking branch 'renesas/next'
git bisect bad 4763d380325df1d74bf3891b00fd318d4a44feee
# good: [19be51760fbe79fc5926c455546971bd1412b9cf] Merge remote-tracking branch 'pinctrl/for-next'
git bisect good 19be51760fbe79fc5926c455546971bd1412b9cf
# bad: [c07b71c4ddd300095d39b74da58f0e70b7931f1d] Merge remote-tracking branch 'mvebu/for-next'
git bisect bad c07b71c4ddd300095d39b74da58f0e70b7931f1d
# bad: [242a001e48b78f190d18242132cab73527ca06a4] Merge branch 'zte/dt64' into for-next
git bisect bad 242a001e48b78f190d18242132cab73527ca06a4
# bad: [c201369d4aa5f05b8a37d6d1eeabf248c7086454] ARM: dts: imx6ull: add imx6ull support
git bisect bad c201369d4aa5f05b8a37d6d1eeabf248c7086454
# good: [9daee307694027eac4b10baa9cd3f2070f7459ba] ARM: dts: imx6q: Add Engicam i.CoreM6 DualLite/Solo initial support
git bisect good 9daee307694027eac4b10baa9cd3f2070f7459ba
# good: [67cb5d52ea2c3ae35d637ab79a46cd452d1c7d41] ARM: dts: imx6sx-sdb: update TX D_CAL for USBPHY
git bisect good 67cb5d52ea2c3ae35d637ab79a46cd452d1c7d41
# good: [c4479f6f57a0821aae4f6ab6a91a23625d6b35a0] ARM: dts: add new compatible string for i.MX6QP mmdc
git bisect good c4479f6f57a0821aae4f6ab6a91a23625d6b35a0
# bad: [7f107887d1995c819389f292828097cac4ec4396] ARM: dts: imx: Remove skeleton.dtsi
git bisect bad 7f107887d1995c819389f292828097cac4ec4396
# good: [425dd2773ed07d1ba21d4ada0f9a9abc85b75151] ARM: dts: imx6q-utilite-pro: i2c1 is muxed
git bisect good 425dd2773ed07d1ba21d4ada0f9a9abc85b75151
# first bad commit: [7f107887d1995c819389f292828097cac4ec4396] ARM: dts: imx: Remove skeleton.dtsi

Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Guenter Roeck]

Hi,

my 'sabrelite' and 'imx25-pdk' qemu boot tests are failing in linux-next.

Bisect for the sabrelite failure points to commit 'ARM: dts: imx: Remove skeleton.dtsi'.

Bisect log is attached. Complete test logs are at
http://kerneltests.org/builders/qemu-arm-next/builds/571/steps/qemubuildcommand/logs/stdio

Boot log for imx25-pdk:

qemu-system-arm: findnode_nofail Couldn't find node /chosen: FDT_ERR_NOTFOUND

Boot log for sabrelite:

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.9.0-rc5-next-20161116 (groeck at jupiter.roeck-us.net) (gcc version 4.9.2 (GCC) ) #1 SMP Tue Nov 15 22:34:35 PST 2016
[    0.000000] CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] OF: fdt:Machine model: Freescale i.MX6 DualLite SABRE Lite Board
[    0.000000] earlycon: ec_imx21 at MMIO 0x021e8000 (options '')
[    0.000000] bootconsole [ec_imx21] enabled
[    0.000000] INITRD: 0x14000000+0x00501600 is not a memory region - disabling initrd
[    0.000000] cma: Failed to reserve 64 MiB
[    0.000000] Memory policy: Data cache writeback

[ stuck here until aborted ]

Build is imx_v6_v7_defconfig and multi_v7_defconfig with imx6dl-sabrelite.dtb,
and imx_v4_v5_defconfig with imx25-pdk.dtb.

Any idea what might be wrong ?

Thanks,
Guenter

-------
# bad: [56c0dbc6eced261af328afd3335d62234bc56513] Add linux-next specific files for 20161116
# good: [a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6] Linux 4.9-rc5
git bisect start 'HEAD' 'v4.9-rc5'
# bad: [56abc46730bb1c5ffd960c71ae089cb713e85e47] Merge remote-tracking branch 'drm/drm-next'
git bisect bad 56abc46730bb1c5ffd960c71ae089cb713e85e47
# bad: [c0d79c892333b32ddae50bbadd885413b51f7252] Merge remote-tracking branch 'dlm/next'
git bisect bad c0d79c892333b32ddae50bbadd885413b51f7252
# bad: [4763d380325df1d74bf3891b00fd318d4a44feee] Merge remote-tracking branch 'renesas/next'
git bisect bad 4763d380325df1d74bf3891b00fd318d4a44feee
# good: [19be51760fbe79fc5926c455546971bd1412b9cf] Merge remote-tracking branch 'pinctrl/for-next'
git bisect good 19be51760fbe79fc5926c455546971bd1412b9cf
# bad: [c07b71c4ddd300095d39b74da58f0e70b7931f1d] Merge remote-tracking branch 'mvebu/for-next'
git bisect bad c07b71c4ddd300095d39b74da58f0e70b7931f1d
# bad: [242a001e48b78f190d18242132cab73527ca06a4] Merge branch 'zte/dt64' into for-next
git bisect bad 242a001e48b78f190d18242132cab73527ca06a4
# bad: [c201369d4aa5f05b8a37d6d1eeabf248c7086454] ARM: dts: imx6ull: add imx6ull support
git bisect bad c201369d4aa5f05b8a37d6d1eeabf248c7086454
# good: [9daee307694027eac4b10baa9cd3f2070f7459ba] ARM: dts: imx6q: Add Engicam i.CoreM6 DualLite/Solo initial support
git bisect good 9daee307694027eac4b10baa9cd3f2070f7459ba
# good: [67cb5d52ea2c3ae35d637ab79a46cd452d1c7d41] ARM: dts: imx6sx-sdb: update TX D_CAL for USBPHY
git bisect good 67cb5d52ea2c3ae35d637ab79a46cd452d1c7d41
# good: [c4479f6f57a0821aae4f6ab6a91a23625d6b35a0] ARM: dts: add new compatible string for i.MX6QP mmdc
git bisect good c4479f6f57a0821aae4f6ab6a91a23625d6b35a0
# bad: [7f107887d1995c819389f292828097cac4ec4396] ARM: dts: imx: Remove skeleton.dtsi
git bisect bad 7f107887d1995c819389f292828097cac4ec4396
# good: [425dd2773ed07d1ba21d4ada0f9a9abc85b75151] ARM: dts: imx6q-utilite-pro: i2c1 is muxed
git bisect good 425dd2773ed07d1ba21d4ada0f9a9abc85b75151
# first bad commit: [7f107887d1995c819389f292828097cac4ec4396] ARM: dts: imx: Remove skeleton.dtsi

Re: Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Fabio Estevam]

Hi Guenter,

On Wed, Nov 16, 2016 at 3:45 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> Hi,
>
> my 'sabrelite' and 'imx25-pdk' qemu boot tests are failing in linux-next.
>
> Bisect for the sabrelite failure points to commit 'ARM: dts: imx: Remove
> skeleton.dtsi'.

Interesting. I am not able to reproduce the boot failure and also do
not see it reported at kernelci.org:

https://kernelci.org/soc/imx/job/next/kernel/next-20161115/

nor at Olof's autobooter:
http://arm-soc.lixom.net/bootlogs/next/next-20161116/wandboard-arm-multi_v7_defconfig.html

Not sure why the boot fails with qemu. I will try to install qemu here
and take a look.

Regards,

Fabio Estevam

Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Fabio Estevam]

Hi Guenter,

On Wed, Nov 16, 2016 at 3:45 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> Hi,
>
> my 'sabrelite' and 'imx25-pdk' qemu boot tests are failing in linux-next.
>
> Bisect for the sabrelite failure points to commit 'ARM: dts: imx: Remove
> skeleton.dtsi'.

Interesting. I am not able to reproduce the boot failure and also do
not see it reported at kernelci.org:

https://kernelci.org/soc/imx/job/next/kernel/next-20161115/

nor at Olof's autobooter:
http://arm-soc.lixom.net/bootlogs/next/next-20161116/wandboard-arm-multi_v7_defconfig.html

Not sure why the boot fails with qemu. I will try to install qemu here
and take a look.

Regards,

Fabio Estevam

Re: Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Mark Rutland]

On Wed, Nov 16, 2016 at 09:45:35AM -0800, Guenter Roeck wrote:
> Hi,

Hi,

> my 'sabrelite' and 'imx25-pdk' qemu boot tests are failing in linux-next.
> 
> Bisect for the sabrelite failure points to commit 'ARM: dts: imx: Remove skeleton.dtsi'.
> 
> Bisect log is attached. Complete test logs are at
> http://kerneltests.org/builders/qemu-arm-next/builds/571/steps/qemubuildcommand/logs/stdio
> 
> Boot log for imx25-pdk:
> 
> qemu-system-arm: findnode_nofail Couldn't find node /chosen: FDT_ERR_NOTFOUND

So this implies we no longer have a /chosen node. We should add one to
the relevant dts{i,} files, with stdout-path and so on.

> Boot log for sabrelite:
> 
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 4.9.0-rc5-next-20161116 (groeck@jupiter.roeck-us.net) (gcc version 4.9.2 (GCC) ) #1 SMP Tue Nov 15 22:34:35 PST 2016
> [    0.000000] CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> [    0.000000] OF: fdt:Machine model: Freescale i.MX6 DualLite SABRE Lite Board
> [    0.000000] earlycon: ec_imx21 at MMIO 0x021e8000 (options '')
> [    0.000000] bootconsole [ec_imx21] enabled
> [    0.000000] INITRD: 0x14000000+0x00501600 is not a memory region - disabling initrd
> [    0.000000] cma: Failed to reserve 64 MiB
> [    0.000000] Memory policy: Data cache writeback
> 
> [ stuck here until aborted ]

The last message was from build_mem_types_table(), called from
paging_init(). We'll head on to unflatten_device_tree() shortly
afterwards.

I wonder if the DTB is corrupted somehow in this case. Maybe the initrd
and cma failures is due to unparseable memory nodes.

Could you try with memblock=debug to see if memory looks as expected?

Thanks,
Mark.

Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Mark Rutland]

On Wed, Nov 16, 2016 at 09:45:35AM -0800, Guenter Roeck wrote:
> Hi,

Hi,

> my 'sabrelite' and 'imx25-pdk' qemu boot tests are failing in linux-next.
> 
> Bisect for the sabrelite failure points to commit 'ARM: dts: imx: Remove skeleton.dtsi'.
> 
> Bisect log is attached. Complete test logs are at
> http://kerneltests.org/builders/qemu-arm-next/builds/571/steps/qemubuildcommand/logs/stdio
> 
> Boot log for imx25-pdk:
> 
> qemu-system-arm: findnode_nofail Couldn't find node /chosen: FDT_ERR_NOTFOUND

So this implies we no longer have a /chosen node. We should add one to
the relevant dts{i,} files, with stdout-path and so on.

> Boot log for sabrelite:
> 
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 4.9.0-rc5-next-20161116 (groeck at jupiter.roeck-us.net) (gcc version 4.9.2 (GCC) ) #1 SMP Tue Nov 15 22:34:35 PST 2016
> [    0.000000] CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> [    0.000000] OF: fdt:Machine model: Freescale i.MX6 DualLite SABRE Lite Board
> [    0.000000] earlycon: ec_imx21 at MMIO 0x021e8000 (options '')
> [    0.000000] bootconsole [ec_imx21] enabled
> [    0.000000] INITRD: 0x14000000+0x00501600 is not a memory region - disabling initrd
> [    0.000000] cma: Failed to reserve 64 MiB
> [    0.000000] Memory policy: Data cache writeback
> 
> [ stuck here until aborted ]

The last message was from build_mem_types_table(), called from
paging_init(). We'll head on to unflatten_device_tree() shortly
afterwards.

I wonder if the DTB is corrupted somehow in this case. Maybe the initrd
and cma failures is due to unparseable memory nodes.

Could you try with memblock=debug to see if memory looks as expected?

Thanks,
Mark.

Re: Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Guenter Roeck]

On Wed, Nov 16, 2016 at 06:46:50PM +0000, Mark Rutland wrote:
> On Wed, Nov 16, 2016 at 09:45:35AM -0800, Guenter Roeck wrote:
> > Hi,
> 
> Hi,
> 
> > my 'sabrelite' and 'imx25-pdk' qemu boot tests are failing in linux-next.
> > 
> > Bisect for the sabrelite failure points to commit 'ARM: dts: imx: Remove skeleton.dtsi'.
> > 
> > Bisect log is attached. Complete test logs are at
> > http://kerneltests.org/builders/qemu-arm-next/builds/571/steps/qemubuildcommand/logs/stdio
> > 
> > Boot log for imx25-pdk:
> > 
> > qemu-system-arm: findnode_nofail Couldn't find node /chosen: FDT_ERR_NOTFOUND
> 
> So this implies we no longer have a /chosen node. We should add one to
> the relevant dts{i,} files, with stdout-path and so on.
> 
> > Boot log for sabrelite:
> > 
> > [    0.000000] Booting Linux on physical CPU 0x0
> > [    0.000000] Linux version 4.9.0-rc5-next-20161116 (groeck@jupiter.roeck-us.net) (gcc version 4.9.2 (GCC) ) #1 SMP Tue Nov 15 22:34:35 PST 2016
> > [    0.000000] CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d
> > [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> > [    0.000000] OF: fdt:Machine model: Freescale i.MX6 DualLite SABRE Lite Board
> > [    0.000000] earlycon: ec_imx21 at MMIO 0x021e8000 (options '')
> > [    0.000000] bootconsole [ec_imx21] enabled
> > [    0.000000] INITRD: 0x14000000+0x00501600 is not a memory region - disabling initrd
> > [    0.000000] cma: Failed to reserve 64 MiB
> > [    0.000000] Memory policy: Data cache writeback
> > 
> > [ stuck here until aborted ]
> 
> The last message was from build_mem_types_table(), called from
> paging_init(). We'll head on to unflatten_device_tree() shortly
> afterwards.
> 
> I wonder if the DTB is corrupted somehow in this case. Maybe the initrd
> and cma failures is due to unparseable memory nodes.
> 
This appears to be quite messed up. There should be an initrd.
Here is the log with memblock=debug.

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.9.0-rc5-next-20161116 (groeck@server.roeck-us.net) (gcc version 4.9.2 (GCC) ) #1 SMP Wed Nov 16 13:05:32 PST 2016
[    0.000000] CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] OF: fdt:Machine model: Freescale i.MX6 DualLite SABRE Lite Board
[    0.000000] earlycon: ec_imx21 at MMIO 0x021e8000 (options '')
[    0.000000] bootconsole [ec_imx21] enabled
[    0.000000] memblock_reserve: [0x00000010100000-0x00000011680737] flags 0x0 arm_memblock_init+0x28/0x190
[    0.000000] INITRD: 0x14000000+0x00501600 is not a memory region - disabling initrd
[    0.000000] memblock_reserve: [0x00000010004000-0x00000010007fff] flags 0x0 arm_mm_memblock_reserve+0x1c/0x24
[    0.000000] memblock_reserve: [0x00000014502000-0x0000001451885b] flags 0x0 early_init_dt_reserve_memory_arch+0x20/0x24
[    0.000000] cma: Failed to reserve 64 MiB
[    0.000000] MEMBLOCK configuration:
[    0.000000]  memory size = 0x0 reserved size = 0x159af94
[    0.000000]  memory.cnt  = 0x1
[    0.000000]  memory[0x0]	[0x00000000000000-0xffffffffffffffff], 0x0 bytes flags: 0x0
[    0.000000]  reserved.cnt  = 0x3
[    0.000000]  reserved[0x0]	[0x00000010004000-0x00000010007fff], 0x4000 bytes flags: 0x0
[    0.000000]  reserved[0x1]	[0x00000010100000-0x00000011680737], 0x1580738 bytes flags: 0x0
[    0.000000]  reserved[0x2]	[0x00000014502000-0x0000001451885b], 0x1685c bytes flags: 0x0
[    0.000000] Memory policy: Data cache writeback

Memory size is obviously a bit on the high side.

Here is the log after reverting the 'offenting' patch:

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.9.0-rc5-next-20161116-00001-g3e6c6cb5519b (groeck@server.roeck-us.net) (gcc version 4.9.2 (GCC) ) #1 SMP Wed Nov 16 13:14:07 PST 2016
[    0.000000] CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] OF: fdt:Machine model: Freescale i.MX6 DualLite SABRE Lite Board
[    0.000000] earlycon: ec_imx21 at MMIO 0x021e8000 (options '')
[    0.000000] bootconsole [ec_imx21] enabled
[    0.000000] memblock_reserve: [0x00000010100000-0x00000011680737] flags 0x0 arm_memblock_init+0x28/0x190
[    0.000000] memblock_reserve: [0x00000014000000-0x000000145015ff] flags 0x0 arm_memblock_init+0x108/0x190
[    0.000000] memblock_reserve: [0x00000010004000-0x00000010007fff] flags 0x0 arm_mm_memblock_reserve+0x1c/0x24
[    0.000000] memblock_reserve: [0x00000014502000-0x00000014518883] flags 0x0 early_init_dt_reserve_memory_arch+0x20/0x24
[    0.000000] cma: Failed to reserve 64 MiB
[    0.000000] MEMBLOCK configuration:
[    0.000000]  memory size = 0x8000000 reserved size = 0x1a9c5bc
[    0.000000]  memory.cnt  = 0x1
[    0.000000]  memory[0x0]	[0x00000010000000-0x00000017ffffff], 0x8000000 bytes flags: 0x0
[    0.000000]  reserved.cnt  = 0x4
[    0.000000]  reserved[0x0]	[0x00000010004000-0x00000010007fff], 0x4000 bytes flags: 0x0
[    0.000000]  reserved[0x1]	[0x00000010100000-0x00000011680737], 0x1580738 bytes flags: 0x0
[    0.000000]  reserved[0x2]	[0x00000014000000-0x000000145015ff], 0x501600 bytes flags: 0x0
[    0.000000]  reserved[0x3]	[0x00000014502000-0x00000014518883], 0x16884 bytes flags: 0x0

Turns out cma allocation fails because the qemu default memory size for
sabrelite is 128MB, which isn't enough, or not enough anymore. That doesn't
seem to matter, though, as the boot succeeds without it (but only if I _don't_
set memblock=debug on the command line) 

Anyway, I guess the problem is that the "official" dtb files no longer provide
the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
expect that they are provided. Is that correct ?

Thanks,
Guenter

Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Guenter Roeck]

On Wed, Nov 16, 2016 at 06:46:50PM +0000, Mark Rutland wrote:
> On Wed, Nov 16, 2016 at 09:45:35AM -0800, Guenter Roeck wrote:
> > Hi,
> 
> Hi,
> 
> > my 'sabrelite' and 'imx25-pdk' qemu boot tests are failing in linux-next.
> > 
> > Bisect for the sabrelite failure points to commit 'ARM: dts: imx: Remove skeleton.dtsi'.
> > 
> > Bisect log is attached. Complete test logs are at
> > http://kerneltests.org/builders/qemu-arm-next/builds/571/steps/qemubuildcommand/logs/stdio
> > 
> > Boot log for imx25-pdk:
> > 
> > qemu-system-arm: findnode_nofail Couldn't find node /chosen: FDT_ERR_NOTFOUND
> 
> So this implies we no longer have a /chosen node. We should add one to
> the relevant dts{i,} files, with stdout-path and so on.
> 
> > Boot log for sabrelite:
> > 
> > [    0.000000] Booting Linux on physical CPU 0x0
> > [    0.000000] Linux version 4.9.0-rc5-next-20161116 (groeck at jupiter.roeck-us.net) (gcc version 4.9.2 (GCC) ) #1 SMP Tue Nov 15 22:34:35 PST 2016
> > [    0.000000] CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d
> > [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> > [    0.000000] OF: fdt:Machine model: Freescale i.MX6 DualLite SABRE Lite Board
> > [    0.000000] earlycon: ec_imx21 at MMIO 0x021e8000 (options '')
> > [    0.000000] bootconsole [ec_imx21] enabled
> > [    0.000000] INITRD: 0x14000000+0x00501600 is not a memory region - disabling initrd
> > [    0.000000] cma: Failed to reserve 64 MiB
> > [    0.000000] Memory policy: Data cache writeback
> > 
> > [ stuck here until aborted ]
> 
> The last message was from build_mem_types_table(), called from
> paging_init(). We'll head on to unflatten_device_tree() shortly
> afterwards.
> 
> I wonder if the DTB is corrupted somehow in this case. Maybe the initrd
> and cma failures is due to unparseable memory nodes.
> 
This appears to be quite messed up. There should be an initrd.
Here is the log with memblock=debug.

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.9.0-rc5-next-20161116 (groeck at server.roeck-us.net) (gcc version 4.9.2 (GCC) ) #1 SMP Wed Nov 16 13:05:32 PST 2016
[    0.000000] CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] OF: fdt:Machine model: Freescale i.MX6 DualLite SABRE Lite Board
[    0.000000] earlycon: ec_imx21 at MMIO 0x021e8000 (options '')
[    0.000000] bootconsole [ec_imx21] enabled
[    0.000000] memblock_reserve: [0x00000010100000-0x00000011680737] flags 0x0 arm_memblock_init+0x28/0x190
[    0.000000] INITRD: 0x14000000+0x00501600 is not a memory region - disabling initrd
[    0.000000] memblock_reserve: [0x00000010004000-0x00000010007fff] flags 0x0 arm_mm_memblock_reserve+0x1c/0x24
[    0.000000] memblock_reserve: [0x00000014502000-0x0000001451885b] flags 0x0 early_init_dt_reserve_memory_arch+0x20/0x24
[    0.000000] cma: Failed to reserve 64 MiB
[    0.000000] MEMBLOCK configuration:
[    0.000000]  memory size = 0x0 reserved size = 0x159af94
[    0.000000]  memory.cnt  = 0x1
[    0.000000]  memory[0x0]	[0x00000000000000-0xffffffffffffffff], 0x0 bytes flags: 0x0
[    0.000000]  reserved.cnt  = 0x3
[    0.000000]  reserved[0x0]	[0x00000010004000-0x00000010007fff], 0x4000 bytes flags: 0x0
[    0.000000]  reserved[0x1]	[0x00000010100000-0x00000011680737], 0x1580738 bytes flags: 0x0
[    0.000000]  reserved[0x2]	[0x00000014502000-0x0000001451885b], 0x1685c bytes flags: 0x0
[    0.000000] Memory policy: Data cache writeback

Memory size is obviously a bit on the high side.

Here is the log after reverting the 'offenting' patch:

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.9.0-rc5-next-20161116-00001-g3e6c6cb5519b (groeck at server.roeck-us.net) (gcc version 4.9.2 (GCC) ) #1 SMP Wed Nov 16 13:14:07 PST 2016
[    0.000000] CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] OF: fdt:Machine model: Freescale i.MX6 DualLite SABRE Lite Board
[    0.000000] earlycon: ec_imx21 at MMIO 0x021e8000 (options '')
[    0.000000] bootconsole [ec_imx21] enabled
[    0.000000] memblock_reserve: [0x00000010100000-0x00000011680737] flags 0x0 arm_memblock_init+0x28/0x190
[    0.000000] memblock_reserve: [0x00000014000000-0x000000145015ff] flags 0x0 arm_memblock_init+0x108/0x190
[    0.000000] memblock_reserve: [0x00000010004000-0x00000010007fff] flags 0x0 arm_mm_memblock_reserve+0x1c/0x24
[    0.000000] memblock_reserve: [0x00000014502000-0x00000014518883] flags 0x0 early_init_dt_reserve_memory_arch+0x20/0x24
[    0.000000] cma: Failed to reserve 64 MiB
[    0.000000] MEMBLOCK configuration:
[    0.000000]  memory size = 0x8000000 reserved size = 0x1a9c5bc
[    0.000000]  memory.cnt  = 0x1
[    0.000000]  memory[0x0]	[0x00000010000000-0x00000017ffffff], 0x8000000 bytes flags: 0x0
[    0.000000]  reserved.cnt  = 0x4
[    0.000000]  reserved[0x0]	[0x00000010004000-0x00000010007fff], 0x4000 bytes flags: 0x0
[    0.000000]  reserved[0x1]	[0x00000010100000-0x00000011680737], 0x1580738 bytes flags: 0x0
[    0.000000]  reserved[0x2]	[0x00000014000000-0x000000145015ff], 0x501600 bytes flags: 0x0
[    0.000000]  reserved[0x3]	[0x00000014502000-0x00000014518883], 0x16884 bytes flags: 0x0

Turns out cma allocation fails because the qemu default memory size for
sabrelite is 128MB, which isn't enough, or not enough anymore. That doesn't
seem to matter, though, as the boot succeeds without it (but only if I _don't_
set memblock=debug on the command line) 

Anyway, I guess the problem is that the "official" dtb files no longer provide
the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
expect that they are provided. Is that correct ?

Thanks,
Guenter

Re: Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Fabio Estevam]

Hi Guenter,

On Wed, Nov 16, 2016 at 8:10 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>
> Anyway, I guess the problem is that the "official" dtb files no longer provide
> the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
> expect that they are provided. Is that correct ?

imx6qdl-sabrelite.dtsi provides chosen and memory nodes.

Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Fabio Estevam]

Hi Guenter,

On Wed, Nov 16, 2016 at 8:10 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>
> Anyway, I guess the problem is that the "official" dtb files no longer provide
> the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
> expect that they are provided. Is that correct ?

imx6qdl-sabrelite.dtsi provides chosen and memory nodes.

Re: Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Guenter Roeck]

On Wed, Nov 16, 2016 at 08:27:09PM -0200, Fabio Estevam wrote:
> Hi Guenter,
> 
> On Wed, Nov 16, 2016 at 8:10 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > Anyway, I guess the problem is that the "official" dtb files no longer provide
> > the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
> > expect that they are provided. Is that correct ?
> 
> imx6qdl-sabrelite.dtsi provides chosen and memory nodes.

Yes, but not the 'device_type' property, which the kernel seems to expect.
The qemu patch below fixes the problem for sabrelite, I just don't know
if that is really the way to go. You tell me; I'll be happy to submit
the necessary patch(es) into qemu.

The same is true for 'chosen'. Right now qemu expects this node to exist.
It does exist for sabrelite, but apparently not for imx25-pdk.

Guenter

---
diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index 1b913a4..080d1e5 100644
--- a/hw/arm/boot.c
+++ b/hw/arm/boot.c
@@ -486,6 +486,12 @@ static int load_dtb(hwaddr addr, const struct arm_boot_info *binfo,
             g_free(nodename);
         }
     } else {
+        Error *err = NULL;
+
+        if (!qemu_fdt_getprop(fdt, "/memory", "device_type", NULL, &err)) {
+            qemu_fdt_setprop_string(fdt, "/memory", "device_type", "memory");
+        }
+
         rc = qemu_fdt_setprop_sized_cells(fdt, "/memory", "reg",
                                           acells, binfo->loader_start,
                                           scells, binfo->ram_size);

Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Guenter Roeck]

On Wed, Nov 16, 2016 at 08:27:09PM -0200, Fabio Estevam wrote:
> Hi Guenter,
> 
> On Wed, Nov 16, 2016 at 8:10 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > Anyway, I guess the problem is that the "official" dtb files no longer provide
> > the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
> > expect that they are provided. Is that correct ?
> 
> imx6qdl-sabrelite.dtsi provides chosen and memory nodes.

Yes, but not the 'device_type' property, which the kernel seems to expect.
The qemu patch below fixes the problem for sabrelite, I just don't know
if that is really the way to go. You tell me; I'll be happy to submit
the necessary patch(es) into qemu.

The same is true for 'chosen'. Right now qemu expects this node to exist.
It does exist for sabrelite, but apparently not for imx25-pdk.

Guenter

---
diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index 1b913a4..080d1e5 100644
--- a/hw/arm/boot.c
+++ b/hw/arm/boot.c
@@ -486,6 +486,12 @@ static int load_dtb(hwaddr addr, const struct arm_boot_info *binfo,
             g_free(nodename);
         }
     } else {
+        Error *err = NULL;
+
+        if (!qemu_fdt_getprop(fdt, "/memory", "device_type", NULL, &err)) {
+            qemu_fdt_setprop_string(fdt, "/memory", "device_type", "memory");
+        }
+
         rc = qemu_fdt_setprop_sized_cells(fdt, "/memory", "reg",
                                           acells, binfo->loader_start,
                                           scells, binfo->ram_size);

Re: Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Fabio Estevam]

On Wed, Nov 16, 2016 at 8:40 PM, Guenter Roeck <linux@roeck-us.net> wrote:

> Yes, but not the 'device_type' property, which the kernel seems to expect.
> The qemu patch below fixes the problem for sabrelite, I just don't know
> if that is really the way to go. You tell me; I'll be happy to submit
> the necessary patch(es) into qemu.

I can send the patch adding device_type for the i.MX dts files, but in
the meantime, it would be nice if you could send your proposal patch
to qemu as it will make qemu to work closer to the real hardware.

Thanks

> The same is true for 'chosen'. Right now qemu expects this node to exist.
> It does exist for sabrelite, but apparently not for imx25-pdk.

We can fix this too in the dts.

Thanks

Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Fabio Estevam]

On Wed, Nov 16, 2016 at 8:40 PM, Guenter Roeck <linux@roeck-us.net> wrote:

> Yes, but not the 'device_type' property, which the kernel seems to expect.
> The qemu patch below fixes the problem for sabrelite, I just don't know
> if that is really the way to go. You tell me; I'll be happy to submit
> the necessary patch(es) into qemu.

I can send the patch adding device_type for the i.MX dts files, but in
the meantime, it would be nice if you could send your proposal patch
to qemu as it will make qemu to work closer to the real hardware.

Thanks

> The same is true for 'chosen'. Right now qemu expects this node to exist.
> It does exist for sabrelite, but apparently not for imx25-pdk.

We can fix this too in the dts.

Thanks

Re: Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Mark Rutland]

On Wed, Nov 16, 2016 at 02:40:24PM -0800, Guenter Roeck wrote:
> On Wed, Nov 16, 2016 at 08:27:09PM -0200, Fabio Estevam wrote:
> > Hi Guenter,
> > 
> > On Wed, Nov 16, 2016 at 8:10 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > Anyway, I guess the problem is that the "official" dtb files no longer provide
> > > the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
> > > expect that they are provided. Is that correct ?
> > 
> > imx6qdl-sabrelite.dtsi provides chosen and memory nodes.
> 
> Yes, but not the 'device_type' property, which the kernel seems to expect.

Memory nodes require this property per ePAPR and the devicetree.org
spec, so the bug is that we didn't add those when removing the
skeleton.dtsi include.

> The qemu patch below fixes the problem for sabrelite, I just don't know
> if that is really the way to go. You tell me; I'll be happy to submit
> the necessary patch(es) into qemu.

As above, I don't think the below patch is necessary. The dt should have
this property to begin with.

> The same is true for 'chosen'. Right now qemu expects this node to exist.
> It does exist for sabrelite, but apparently not for imx25-pdk.

Having QEMU create a /chosen node if one does not exist already sounds
sensible to me.

Thanks,
Mark.

> Guenter
> 
> ---
> diff --git a/hw/arm/boot.c b/hw/arm/boot.c
> index 1b913a4..080d1e5 100644
> --- a/hw/arm/boot.c
> +++ b/hw/arm/boot.c
> @@ -486,6 +486,12 @@ static int load_dtb(hwaddr addr, const struct arm_boot_info *binfo,
>              g_free(nodename);
>          }
>      } else {
> +        Error *err = NULL;
> +
> +        if (!qemu_fdt_getprop(fdt, "/memory", "device_type", NULL, &err)) {
> +            qemu_fdt_setprop_string(fdt, "/memory", "device_type", "memory");
> +        }
> +
>          rc = qemu_fdt_setprop_sized_cells(fdt, "/memory", "reg",
>                                            acells, binfo->loader_start,
>                                            scells, binfo->ram_size);

Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Mark Rutland]

On Wed, Nov 16, 2016 at 02:40:24PM -0800, Guenter Roeck wrote:
> On Wed, Nov 16, 2016 at 08:27:09PM -0200, Fabio Estevam wrote:
> > Hi Guenter,
> > 
> > On Wed, Nov 16, 2016 at 8:10 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > Anyway, I guess the problem is that the "official" dtb files no longer provide
> > > the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
> > > expect that they are provided. Is that correct ?
> > 
> > imx6qdl-sabrelite.dtsi provides chosen and memory nodes.
> 
> Yes, but not the 'device_type' property, which the kernel seems to expect.

Memory nodes require this property per ePAPR and the devicetree.org
spec, so the bug is that we didn't add those when removing the
skeleton.dtsi include.

> The qemu patch below fixes the problem for sabrelite, I just don't know
> if that is really the way to go. You tell me; I'll be happy to submit
> the necessary patch(es) into qemu.

As above, I don't think the below patch is necessary. The dt should have
this property to begin with.

> The same is true for 'chosen'. Right now qemu expects this node to exist.
> It does exist for sabrelite, but apparently not for imx25-pdk.

Having QEMU create a /chosen node if one does not exist already sounds
sensible to me.

Thanks,
Mark.

> Guenter
> 
> ---
> diff --git a/hw/arm/boot.c b/hw/arm/boot.c
> index 1b913a4..080d1e5 100644
> --- a/hw/arm/boot.c
> +++ b/hw/arm/boot.c
> @@ -486,6 +486,12 @@ static int load_dtb(hwaddr addr, const struct arm_boot_info *binfo,
>              g_free(nodename);
>          }
>      } else {
> +        Error *err = NULL;
> +
> +        if (!qemu_fdt_getprop(fdt, "/memory", "device_type", NULL, &err)) {
> +            qemu_fdt_setprop_string(fdt, "/memory", "device_type", "memory");
> +        }
> +
>          rc = qemu_fdt_setprop_sized_cells(fdt, "/memory", "reg",
>                                            acells, binfo->loader_start,
>                                            scells, binfo->ram_size);

Re: Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Guenter Roeck]

On 11/17/2016 02:55 AM, Mark Rutland wrote:
> On Wed, Nov 16, 2016 at 02:40:24PM -0800, Guenter Roeck wrote:
>> On Wed, Nov 16, 2016 at 08:27:09PM -0200, Fabio Estevam wrote:
>>> Hi Guenter,
>>>
>>> On Wed, Nov 16, 2016 at 8:10 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>
>>>> Anyway, I guess the problem is that the "official" dtb files no longer provide
>>>> the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
>>>> expect that they are provided. Is that correct ?
>>>
>>> imx6qdl-sabrelite.dtsi provides chosen and memory nodes.
>>
>> Yes, but not the 'device_type' property, which the kernel seems to expect.
>
> Memory nodes require this property per ePAPR and the devicetree.org
> spec, so the bug is that we didn't add those when removing the
> skeleton.dtsi include.
>

The downside from qemu perspective is that the real hardware seems
to add the property unconditionally, or the boot failure would have
been seen there as well.

I submitted https://patchwork.ozlabs.org/patch/695951/; we'll see how it goes.

Guenter

>> The qemu patch below fixes the problem for sabrelite, I just don't know
>> if that is really the way to go. You tell me; I'll be happy to submit
>> the necessary patch(es) into qemu.
>
> As above, I don't think the below patch is necessary. The dt should have
> this property to begin with.
>
>> The same is true for 'chosen'. Right now qemu expects this node to exist.
>> It does exist for sabrelite, but apparently not for imx25-pdk.
>
> Having QEMU create a /chosen node if one does not exist already sounds
> sensible to me.
>
> Thanks,
> Mark.
>
>> Guenter
>>
>> ---
>> diff --git a/hw/arm/boot.c b/hw/arm/boot.c
>> index 1b913a4..080d1e5 100644
>> --- a/hw/arm/boot.c
>> +++ b/hw/arm/boot.c
>> @@ -486,6 +486,12 @@ static int load_dtb(hwaddr addr, const struct arm_boot_info *binfo,
>>              g_free(nodename);
>>          }
>>      } else {
>> +        Error *err = NULL;
>> +
>> +        if (!qemu_fdt_getprop(fdt, "/memory", "device_type", NULL, &err)) {
>> +            qemu_fdt_setprop_string(fdt, "/memory", "device_type", "memory");
>> +        }
>> +
>>          rc = qemu_fdt_setprop_sized_cells(fdt, "/memory", "reg",
>>                                            acells, binfo->loader_start,
>>                                            scells, binfo->ram_size);
>

Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Guenter Roeck]

On 11/17/2016 02:55 AM, Mark Rutland wrote:
> On Wed, Nov 16, 2016 at 02:40:24PM -0800, Guenter Roeck wrote:
>> On Wed, Nov 16, 2016 at 08:27:09PM -0200, Fabio Estevam wrote:
>>> Hi Guenter,
>>>
>>> On Wed, Nov 16, 2016 at 8:10 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>
>>>> Anyway, I guess the problem is that the "official" dtb files no longer provide
>>>> the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
>>>> expect that they are provided. Is that correct ?
>>>
>>> imx6qdl-sabrelite.dtsi provides chosen and memory nodes.
>>
>> Yes, but not the 'device_type' property, which the kernel seems to expect.
>
> Memory nodes require this property per ePAPR and the devicetree.org
> spec, so the bug is that we didn't add those when removing the
> skeleton.dtsi include.
>

The downside from qemu perspective is that the real hardware seems
to add the property unconditionally, or the boot failure would have
been seen there as well.

I submitted https://patchwork.ozlabs.org/patch/695951/; we'll see how it goes.

Guenter

>> The qemu patch below fixes the problem for sabrelite, I just don't know
>> if that is really the way to go. You tell me; I'll be happy to submit
>> the necessary patch(es) into qemu.
>
> As above, I don't think the below patch is necessary. The dt should have
> this property to begin with.
>
>> The same is true for 'chosen'. Right now qemu expects this node to exist.
>> It does exist for sabrelite, but apparently not for imx25-pdk.
>
> Having QEMU create a /chosen node if one does not exist already sounds
> sensible to me.
>
> Thanks,
> Mark.
>
>> Guenter
>>
>> ---
>> diff --git a/hw/arm/boot.c b/hw/arm/boot.c
>> index 1b913a4..080d1e5 100644
>> --- a/hw/arm/boot.c
>> +++ b/hw/arm/boot.c
>> @@ -486,6 +486,12 @@ static int load_dtb(hwaddr addr, const struct arm_boot_info *binfo,
>>              g_free(nodename);
>>          }
>>      } else {
>> +        Error *err = NULL;
>> +
>> +        if (!qemu_fdt_getprop(fdt, "/memory", "device_type", NULL, &err)) {
>> +            qemu_fdt_setprop_string(fdt, "/memory", "device_type", "memory");
>> +        }
>> +
>>          rc = qemu_fdt_setprop_sized_cells(fdt, "/memory", "reg",
>>                                            acells, binfo->loader_start,
>>                                            scells, binfo->ram_size);
>

Re: Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Mark Rutland]

On Thu, Nov 17, 2016 at 06:44:55AM -0800, Guenter Roeck wrote:
> On 11/17/2016 02:55 AM, Mark Rutland wrote:
> >On Wed, Nov 16, 2016 at 02:40:24PM -0800, Guenter Roeck wrote:
> >>On Wed, Nov 16, 2016 at 08:27:09PM -0200, Fabio Estevam wrote:
> >>>Hi Guenter,
> >>>
> >>>On Wed, Nov 16, 2016 at 8:10 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> >>>>
> >>>>Anyway, I guess the problem is that the "official" dtb files no longer provide
> >>>>the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
> >>>>expect that they are provided. Is that correct ?
> >>>
> >>>imx6qdl-sabrelite.dtsi provides chosen and memory nodes.
> >>
> >>Yes, but not the 'device_type' property, which the kernel seems to expect.
> >
> >Memory nodes require this property per ePAPR and the devicetree.org
> >spec, so the bug is that we didn't add those when removing the
> >skeleton.dtsi include.
> 
> The downside from qemu perspective is that the real hardware seems
> to add the property unconditionally, or the boot failure would have
> been seen there as well.
> 
> I submitted https://patchwork.ozlabs.org/patch/695951/; we'll see how it goes.

Sure, the firmare/bootlaoder you're using may add this automatically.

My worry is that adding this to a generic file in QEMU only serves to
mask this class of bug for other boards (i.e. they'll work fine in QEMU,
but not on real HW using whatever bootlaoder happens ot be there).

Thanks,
Mark.

Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Mark Rutland]

On Thu, Nov 17, 2016 at 06:44:55AM -0800, Guenter Roeck wrote:
> On 11/17/2016 02:55 AM, Mark Rutland wrote:
> >On Wed, Nov 16, 2016 at 02:40:24PM -0800, Guenter Roeck wrote:
> >>On Wed, Nov 16, 2016 at 08:27:09PM -0200, Fabio Estevam wrote:
> >>>Hi Guenter,
> >>>
> >>>On Wed, Nov 16, 2016 at 8:10 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> >>>>
> >>>>Anyway, I guess the problem is that the "official" dtb files no longer provide
> >>>>the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
> >>>>expect that they are provided. Is that correct ?
> >>>
> >>>imx6qdl-sabrelite.dtsi provides chosen and memory nodes.
> >>
> >>Yes, but not the 'device_type' property, which the kernel seems to expect.
> >
> >Memory nodes require this property per ePAPR and the devicetree.org
> >spec, so the bug is that we didn't add those when removing the
> >skeleton.dtsi include.
> 
> The downside from qemu perspective is that the real hardware seems
> to add the property unconditionally, or the boot failure would have
> been seen there as well.
> 
> I submitted https://patchwork.ozlabs.org/patch/695951/; we'll see how it goes.

Sure, the firmare/bootlaoder you're using may add this automatically.

My worry is that adding this to a generic file in QEMU only serves to
mask this class of bug for other boards (i.e. they'll work fine in QEMU,
but not on real HW using whatever bootlaoder happens ot be there).

Thanks,
Mark.

Re: Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Guenter Roeck]

On 11/17/2016 07:05 AM, Mark Rutland wrote:
> On Thu, Nov 17, 2016 at 06:44:55AM -0800, Guenter Roeck wrote:
>> On 11/17/2016 02:55 AM, Mark Rutland wrote:
>>> On Wed, Nov 16, 2016 at 02:40:24PM -0800, Guenter Roeck wrote:
>>>> On Wed, Nov 16, 2016 at 08:27:09PM -0200, Fabio Estevam wrote:
>>>>> Hi Guenter,
>>>>>
>>>>> On Wed, Nov 16, 2016 at 8:10 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>>
>>>>>> Anyway, I guess the problem is that the "official" dtb files no longer provide
>>>>>> the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
>>>>>> expect that they are provided. Is that correct ?
>>>>>
>>>>> imx6qdl-sabrelite.dtsi provides chosen and memory nodes.
>>>>
>>>> Yes, but not the 'device_type' property, which the kernel seems to expect.
>>>
>>> Memory nodes require this property per ePAPR and the devicetree.org
>>> spec, so the bug is that we didn't add those when removing the
>>> skeleton.dtsi include.
>>
>> The downside from qemu perspective is that the real hardware seems
>> to add the property unconditionally, or the boot failure would have
>> been seen there as well.
>>
>> I submitted https://patchwork.ozlabs.org/patch/695951/; we'll see how it goes.
>
> Sure, the firmare/bootlaoder you're using may add this automatically.
>
> My worry is that adding this to a generic file in QEMU only serves to
> mask this class of bug for other boards (i.e. they'll work fine in QEMU,
> but not on real HW using whatever bootlaoder happens ot be there).
>
Good point.

What would be the correct behavior for qemu ? Adding a chosen node if it does
not exist is one detail we already established. Also, I think a check if
/memory/device_type exists (and to bail out if it doesn't) would make sense.

What about the memory node ? Does it have to exist, or should it be added
(including the device_type property) if not ?

Thanks,
Guenter

Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Guenter Roeck]

On 11/17/2016 07:05 AM, Mark Rutland wrote:
> On Thu, Nov 17, 2016 at 06:44:55AM -0800, Guenter Roeck wrote:
>> On 11/17/2016 02:55 AM, Mark Rutland wrote:
>>> On Wed, Nov 16, 2016 at 02:40:24PM -0800, Guenter Roeck wrote:
>>>> On Wed, Nov 16, 2016 at 08:27:09PM -0200, Fabio Estevam wrote:
>>>>> Hi Guenter,
>>>>>
>>>>> On Wed, Nov 16, 2016 at 8:10 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>>
>>>>>> Anyway, I guess the problem is that the "official" dtb files no longer provide
>>>>>> the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
>>>>>> expect that they are provided. Is that correct ?
>>>>>
>>>>> imx6qdl-sabrelite.dtsi provides chosen and memory nodes.
>>>>
>>>> Yes, but not the 'device_type' property, which the kernel seems to expect.
>>>
>>> Memory nodes require this property per ePAPR and the devicetree.org
>>> spec, so the bug is that we didn't add those when removing the
>>> skeleton.dtsi include.
>>
>> The downside from qemu perspective is that the real hardware seems
>> to add the property unconditionally, or the boot failure would have
>> been seen there as well.
>>
>> I submitted https://patchwork.ozlabs.org/patch/695951/; we'll see how it goes.
>
> Sure, the firmare/bootlaoder you're using may add this automatically.
>
> My worry is that adding this to a generic file in QEMU only serves to
> mask this class of bug for other boards (i.e. they'll work fine in QEMU,
> but not on real HW using whatever bootlaoder happens ot be there).
>
Good point.

What would be the correct behavior for qemu ? Adding a chosen node if it does
not exist is one detail we already established. Also, I think a check if
/memory/device_type exists (and to bail out if it doesn't) would make sense.

What about the memory node ? Does it have to exist, or should it be added
(including the device_type property) if not ?

Thanks,
Guenter

Re: Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Mark Rutland]

On Thu, Nov 17, 2016 at 08:17:00AM -0800, Guenter Roeck wrote:
> On 11/17/2016 07:05 AM, Mark Rutland wrote:
> >On Thu, Nov 17, 2016 at 06:44:55AM -0800, Guenter Roeck wrote:
> >>On 11/17/2016 02:55 AM, Mark Rutland wrote:
> >>>Memory nodes require this property per ePAPR and the devicetree.org
> >>>spec, so the bug is that we didn't add those when removing the
> >>>skeleton.dtsi include.
> >>
> >>The downside from qemu perspective is that the real hardware seems
> >>to add the property unconditionally, or the boot failure would have
> >>been seen there as well.
> >>
> >>I submitted https://patchwork.ozlabs.org/patch/695951/; we'll see how it goes.
> >
> >Sure, the firmare/bootlaoder you're using may add this automatically.
> >
> >My worry is that adding this to a generic file in QEMU only serves to
> >mask this class of bug for other boards (i.e. they'll work fine in QEMU,
> >but not on real HW using whatever bootlaoder happens ot be there).
> >
> Good point.
> 
> What would be the correct behavior for qemu ? Adding a chosen node if it does
> not exist is one detail we already established. Also, I think a check if
> /memory/device_type exists (and to bail out if it doesn't) would make sense.

We'd also need to check for /memory@<n> nodes, as they can validly have
unit-addresses (and many do).

Generally, the "correct" way to find them is to iterate over all ndoes
with device_type = "memory", so one could do that and give up if none
are found, ignoring the naming entirely.

> What about the memory node ? Does it have to exist, or should it be added
> (including the device_type property) if not ?

I'm not sure what QEMU does in this area. I suspect it may expect a node
in some cases, or may generate one in others.

There's no point generating one when we don't have the information to
hand, certainly.

Thanks,
Mark.

Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Mark Rutland]

On Thu, Nov 17, 2016 at 08:17:00AM -0800, Guenter Roeck wrote:
> On 11/17/2016 07:05 AM, Mark Rutland wrote:
> >On Thu, Nov 17, 2016 at 06:44:55AM -0800, Guenter Roeck wrote:
> >>On 11/17/2016 02:55 AM, Mark Rutland wrote:
> >>>Memory nodes require this property per ePAPR and the devicetree.org
> >>>spec, so the bug is that we didn't add those when removing the
> >>>skeleton.dtsi include.
> >>
> >>The downside from qemu perspective is that the real hardware seems
> >>to add the property unconditionally, or the boot failure would have
> >>been seen there as well.
> >>
> >>I submitted https://patchwork.ozlabs.org/patch/695951/; we'll see how it goes.
> >
> >Sure, the firmare/bootlaoder you're using may add this automatically.
> >
> >My worry is that adding this to a generic file in QEMU only serves to
> >mask this class of bug for other boards (i.e. they'll work fine in QEMU,
> >but not on real HW using whatever bootlaoder happens ot be there).
> >
> Good point.
> 
> What would be the correct behavior for qemu ? Adding a chosen node if it does
> not exist is one detail we already established. Also, I think a check if
> /memory/device_type exists (and to bail out if it doesn't) would make sense.

We'd also need to check for /memory@<n> nodes, as they can validly have
unit-addresses (and many do).

Generally, the "correct" way to find them is to iterate over all ndoes
with device_type = "memory", so one could do that and give up if none
are found, ignoring the naming entirely.

> What about the memory node ? Does it have to exist, or should it be added
> (including the device_type property) if not ?

I'm not sure what QEMU does in this area. I suspect it may expect a node
in some cases, or may generate one in others.

There's no point generating one when we don't have the information to
hand, certainly.

Thanks,
Mark.

Re: Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Guenter Roeck]

On 11/17/2016 08:39 AM, Mark Rutland wrote:
> On Thu, Nov 17, 2016 at 08:17:00AM -0800, Guenter Roeck wrote:
>> On 11/17/2016 07:05 AM, Mark Rutland wrote:
>>> On Thu, Nov 17, 2016 at 06:44:55AM -0800, Guenter Roeck wrote:
>>>> On 11/17/2016 02:55 AM, Mark Rutland wrote:
>>>>> Memory nodes require this property per ePAPR and the devicetree.org
>>>>> spec, so the bug is that we didn't add those when removing the
>>>>> skeleton.dtsi include.
>>>>
>>>> The downside from qemu perspective is that the real hardware seems
>>>> to add the property unconditionally, or the boot failure would have
>>>> been seen there as well.
>>>>
>>>> I submitted https://patchwork.ozlabs.org/patch/695951/; we'll see how it goes.
>>>
>>> Sure, the firmare/bootlaoder you're using may add this automatically.
>>>
>>> My worry is that adding this to a generic file in QEMU only serves to
>>> mask this class of bug for other boards (i.e. they'll work fine in QEMU,
>>> but not on real HW using whatever bootlaoder happens ot be there).
>>>
>> Good point.
>>
>> What would be the correct behavior for qemu ? Adding a chosen node if it does
>> not exist is one detail we already established. Also, I think a check if
>> /memory/device_type exists (and to bail out if it doesn't) would make sense.
>
> We'd also need to check for /memory@<n> nodes, as they can validly have
> unit-addresses (and many do).
>
> Generally, the "correct" way to find them is to iterate over all ndoes
> with device_type = "memory", so one could do that and give up if none
> are found, ignoring the naming entirely.
>
>> What about the memory node ? Does it have to exist, or should it be added
>> (including the device_type property) if not ?
>
> I'm not sure what QEMU does in this area. I suspect it may expect a node
> in some cases, or may generate one in others.
>
> There's no point generating one when we don't have the information to
> hand, certainly.
>
So far, for arm, qemu assumes that the /memory node exists, and it fills in
/memory/reg. This is done if a devicetree file is specified and numa is disabled.

Numa node handling is different; if NUMA is enabled, qemu removes an existing
/memory node and creates /memory@ nodes as configured. It does not expect
to see pre-existing /memory@ nodes.

Thanks,
Guenter

Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Guenter Roeck]

On 11/17/2016 08:39 AM, Mark Rutland wrote:
> On Thu, Nov 17, 2016 at 08:17:00AM -0800, Guenter Roeck wrote:
>> On 11/17/2016 07:05 AM, Mark Rutland wrote:
>>> On Thu, Nov 17, 2016 at 06:44:55AM -0800, Guenter Roeck wrote:
>>>> On 11/17/2016 02:55 AM, Mark Rutland wrote:
>>>>> Memory nodes require this property per ePAPR and the devicetree.org
>>>>> spec, so the bug is that we didn't add those when removing the
>>>>> skeleton.dtsi include.
>>>>
>>>> The downside from qemu perspective is that the real hardware seems
>>>> to add the property unconditionally, or the boot failure would have
>>>> been seen there as well.
>>>>
>>>> I submitted https://patchwork.ozlabs.org/patch/695951/; we'll see how it goes.
>>>
>>> Sure, the firmare/bootlaoder you're using may add this automatically.
>>>
>>> My worry is that adding this to a generic file in QEMU only serves to
>>> mask this class of bug for other boards (i.e. they'll work fine in QEMU,
>>> but not on real HW using whatever bootlaoder happens ot be there).
>>>
>> Good point.
>>
>> What would be the correct behavior for qemu ? Adding a chosen node if it does
>> not exist is one detail we already established. Also, I think a check if
>> /memory/device_type exists (and to bail out if it doesn't) would make sense.
>
> We'd also need to check for /memory@<n> nodes, as they can validly have
> unit-addresses (and many do).
>
> Generally, the "correct" way to find them is to iterate over all ndoes
> with device_type = "memory", so one could do that and give up if none
> are found, ignoring the naming entirely.
>
>> What about the memory node ? Does it have to exist, or should it be added
>> (including the device_type property) if not ?
>
> I'm not sure what QEMU does in this area. I suspect it may expect a node
> in some cases, or may generate one in others.
>
> There's no point generating one when we don't have the information to
> hand, certainly.
>
So far, for arm, qemu assumes that the /memory node exists, and it fills in
/memory/reg. This is done if a devicetree file is specified and numa is disabled.

Numa node handling is different; if NUMA is enabled, qemu removes an existing
/memory node and creates /memory@ nodes as configured. It does not expect
to see pre-existing /memory@ nodes.

Thanks,
Guenter