[adding Stefan as the maintainer of drivers/mtd/cfi_*]
On 09/01/2020 14:11, Robin Randhawa wrote:
Hi Matthias.
On Thu, 2020-01-09 at 12:12 +0100, Matthias Brugger wrote:
[...]
Can you pinpoint me to where I can find the DTS used by U-boot.
As per my understanding the DTB for this virtual platform is generated by qemu and handed to u-boot.
I dumped the DTB to the host filesystem using GDB and 'dump mem' then dtc'd it to get the DTS.
Site note, I think you can do that in U-Boot like this: fdt addr <address-of-your-dtb> fdt print
Ok, what I found so far: in hw/arm/virt.c virt_flash_fdt() it creates the reg property like this [0]: qemu_fdt_setprop_sized_cells(vms->fdt, nodename, "reg", 2, flashbase, 2, flashsize, 2, flashbase + flashsize, 2, flashsize);
Which creates the flash node we see in the dts you shared: reg = <0x0 0x0 0x0 0x4000000 0x0 0x4000000 0x0 0x4000000>;
Which is: Bank1: Flashbase 0x0 0x0 Flashsize 0x0 0x4000000 Bank2: Flashbase 0x0 0x4000000 Flashsize 0x0 0x4000000
The property expects size-cells to be two, but U-Boot will use one cell if no size-cells are defined in the device node (which is not the case) and therefor will see
Bank1: Flashbase 0x0 0x0 Flashsize 0x4000000 Bank2: Flashbase 0x4000000 0x0 Flashsize 0x4000000
Which maches with the flinfo you mentioned.
Now the question is if this is a problem of U-Boots implementation of cfi_flash, which expects size-cells to be present in the flash node as it otherwise assumes one [1]. Or if this is a problem of qemu which creates a device tree specifying the size-cells only in the parent node.
Unfortunately the device tree specification as I understand it, is not clear [2] on this.
Peter, Stefan any thoughts?
Regards, Matthias
[0] https://git.qemu.org/?p=qemu.git;a=blob;f=hw/arm/virt.c;h=39ab5f47e0bdc33b9b... [1] https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/mtd/cfi_flash.c#L24... [2] https://github.com/devicetree-org/devicetree-specification/blob/master/sourc...
I tried to run that myself but wasn't able to see any output. Which U-Boot config do you use? rpi_3_defconfig?
I hit this problem for the qemu_arm64 u-boot platform target for which I used qemu_arm64_defconfig [1].
Let me know if you need more info.
Cheers, Robin