Hi Johan, On Fri, 10 Mar 2023 at 17:37, Simon Glass <s...@chromium.org> wrote: > > Hi Johan, > > On Mon, 6 Mar 2023 at 12:32, Johan Jonker <jbx6...@gmail.com> wrote: > > > > > > > > On 3/6/23 19:20, Simon Glass wrote: > > > Hi Johan, > > > > > > On Thu, 2 Mar 2023 at 17:15, Johan Jonker <jbx6...@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
