Hi Johan,

On Fri, 10 Mar 2023 at 17:37, Simon Glass sjg@chromium.org wrote:

Hi Johan,

On Mon, 6 Mar 2023 at 12:32, Johan Jonker jbx6244@gmail.com wrote:

...

On 3/6/23 19:20, Simon Glass wrote:

...

Hi Johan,

On Thu, 2 Mar 2023 at 17:15, Johan Jonker jbx6244@gmail.com wrote:

...

The fdt_addr_t and phys_addr_t size have been decoupled. A 32bit CPU can expect 64-bit data from the device tree parser, so use

Why is that? It seems quite inefficient.

1:

Because the device tree does describes more then just only the internal io/mem range. When a NAND chip is connected it must be able to describe partitions far beyond that 32bit range. This change only changes the PARSE capacity defined by fdt_addr_t and fdt_size_t and not the phys_addr_t and phys_size_t. Most drivers make a little mess when taking a DT reg value and then trying to make it fit in a structure of multiple registers with various offsets. Fixing all of that is beyond my capacity/this serie and more a MAINTAINER task.

https://elixir.bootlin.com/u-boot/latest/source/drivers/mtd/mtdpart.c#L933

struct mtd_partition { const char *name; /* identifier string */ uint64_t size; /* partition size */ uint64_t offset; /* offset within the master MTD space */ uint32_t mask_flags; /* master MTD flags to mask out for this partition */ struct nand_ecclayout *ecclayout; /* out of band layout for this partition (NAND only) */ };

int add_mtd_partitions_of(struct mtd_info *master) struct mtd_partition part = { 0 }; fdt_addr_t offset; fdt_size_t size;

[..] part.offset = offset; part.size = size;

While the mtd_partition structure is ready with uint64_t size all the parse functions that export this reg value were typedef to a 32bit value.

=== Given mk808 rk3066a with NAND:

[ 38.750789] nand: Hynix H27UCG8T2ATR-BC 64G 3.3V 8-bit [ 38.756650] nand: 8192 MiB, MLC, erase size: 2048 KiB, page size: 8192, OOB size: 640

=== BEFORE:

List of MTD devices:

• nand0
  • type: MLC NAND flash
  • block size: 0x200000 bytes
  • min I/O: 0x2000 bytes
  • OOB size: 640 bytes
  • OOB available: 4294967290 bytes
  • ECC strength: 40 bits
  • ECC step size: 1024 bytes
  • bitflip threshold: 30 bits
  • 0x000000000000-0x000200000000 : "nand0" - 0x000000400000-0x000000600000 : "boot-blk-0" - 0x000000600000-0x000000800000 : "boot-blk-1" - 0x000000800000-0x000000a00000 : "boot-blk-2" - 0x000000a00000-0x000000c00000 : "boot-blk-3" - 0x000000c00000-0x000000e00000 : "boot-blk-4" - 0x000001000000-0x0000fe000000 : "rootfs" - 0x0000fe000000-0x000100000000 : "bbt"

# This output is corrupted.

=== AFTER:

List of MTD devices:

• nand0
  • type: MLC NAND flash
  • block size: 0x200000 bytes
  • min I/O: 0x2000 bytes
  • OOB size: 640 bytes
  • OOB available: 4294967290 bytes
  • ECC strength: 40 bits
  • ECC step size: 1024 bytes
  • bitflip threshold: 30 bits
  • 0x000000000000-0x000200000000 : "nand0" - 0x000000400000-0x000000600000 : "boot-blk-0" - 0x000000600000-0x000000800000 : "boot-blk-1" - 0x000000800000-0x000000a00000 : "boot-blk-2" - 0x000000a00000-0x000000c00000 : "boot-blk-3" - 0x000000c00000-0x000000e00000 : "boot-blk-4" - 0x000001000000-0x0001fe000000 : "rootfs" - 0x0001fe000000-0x000200000000 : "bbt"

=== Example: partitions { compatible = "fixed-partitions"; #address-cells = <2>; #size-cells = <2>;

                    partition@400000 {
                            reg = <0x0 0x00400000 0x0 0x00200000>;
                            label = "boot-blk-0";
                    };

                    partition@600000 {
                            reg = <0x0 0x00600000 0x0 0x00200000>;
                            label = "boot-blk-1";
                    };

                    partition@800000 {
                            reg = <0x0 0x00800000 0x0 0x00200000>;
                            label = "boot-blk-2";
                    };

                    partition@a00000 {
                            reg = <0x0 0x00a00000 0x0 0x00200000>;
                            label = "boot-blk-3";
                    };

                    partition@c00000 {
                            reg = <0x0 0x00c00000 0x0 0x00200000>;
                            label = "boot-blk-4";
                    };

                    partition@1000000 {
                            reg = <0x0 0x01000000 0x1 0xfd000000>;
                            label = "rootfs";
                    };

                    partition@1fe000000 {
                            reg = <0x1 0xfe000000 0x0 0x02000000>;
                            label = "bbt";
                    };
            };

===

2: As a side effect Rockchip rk3288 with 32bit reg should be able to parse 64bit size device tree synced from Linux. (No need to maintain simply copy and paste) How ever popmetal-rk3288 and phycore-rk3288 must be changed to use TPL/SPL to fit in size again. (Could someone finally make some progress in making these boards future proof?

OK I think I understand. I had thought that fdt_addr_t was changing to 64-bits on 32-bit boards, but I misunderstood. I checked your series and it is still 32-bit.

...

And could Simon Glass make/help with rk3288 video/mipi/lvds/hdmi Uboot drivers for work with Linux nodes?) (This seems to work only on Google boards that nobody has, but it blocks all progress for the rest)

Yes I can, but unfortunately my lab is broken due to a servod update. I need to spend some time to get it running again and likely can't even start that for another 5 weeks.

If you'd like to do some patches I can test it then. Otherwise when I get the lab going I can take a look.

Actually I was able to hack it into life so can test bob and jerry if you'd like to send some patches. I had a bit of a look at it and it seems that rk3288 is wildly different from upstream Linux at present.

Regards, Simon