[PATCH v6 15/22] drivers: use dev_read_addr_index_ptr when cast to pointer
Simon Glass
sjg at chromium.org
Sat Mar 11 20:17:57 CET 2023
Hi Johan,
On Fri, 10 Mar 2023 at 17:37, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Johan,
>
> On Mon, 6 Mar 2023 at 12:32, Johan Jonker <jbx6244 at 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 at 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 at 400000 {
> > reg = <0x0 0x00400000 0x0 0x00200000>;
> > label = "boot-blk-0";
> > };
> >
> > partition at 600000 {
> > reg = <0x0 0x00600000 0x0 0x00200000>;
> > label = "boot-blk-1";
> > };
> >
> > partition at 800000 {
> > reg = <0x0 0x00800000 0x0 0x00200000>;
> > label = "boot-blk-2";
> > };
> >
> > partition at a00000 {
> > reg = <0x0 0x00a00000 0x0 0x00200000>;
> > label = "boot-blk-3";
> > };
> >
> > partition at c00000 {
> > reg = <0x0 0x00c00000 0x0 0x00200000>;
> > label = "boot-blk-4";
> > };
> >
> > partition at 1000000 {
> > reg = <0x0 0x01000000 0x1 0xfd000000>;
> > label = "rootfs";
> > };
> >
> > partition at 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
More information about the U-Boot
mailing list