From MTD to DTS NAND. Possible?

For Developers
1

I'm trying to understand if it's possible to build the DTS NAND by knowing the structure thrown by mtd in the bootloader and also I would like to learn about the U-Boot commands in case someone could help me out

First, lets say we have this structure

#: name                size            offset          mask_flags
 0: u-boot              0x00100000      0x00000000      0
 1: u-boot-env          0x00100000      0x00100000      0
 2: factory             0x001c0000      0x00200000      0
 3: firmware            0x02800000      0x003c0000      0
 4: firmware2           0x02800000      0x02bc0000      0
 5: other               0x02c40000      0x053c0000      0

Sizes are clear:

u-boot and u-boot-env 1024k
So u-boot starts from 0x00000000 and ends on 0x00100000
u-boot-env starts on 0x10000000 + 0x00100000 = 0x00200000
factory starts on 0x00200000 + 0x001c0000 (1782k) = 0x003c0000
And so on.

Pretty straight forward.

When we run tftpboot 0x8000000 I'm not sure why this is running way away from the memory bindings from this partition tables.

I must understand that since these are memory mappings, and all is relative it doesn't really matter where you start. You could start in 0x80000000 or in 0x20000000, completely irrelevant AFAIK, wherever you like.

Then about the NAND in the DTS. If we take into consideration the previous MTD the right thing would be:

partitions {
                compatible = "fixed-partitions";
                #address-cells = <1>;
                #size-cells = <1>;

                partition@0 {
                        label = "u-boot";
                        reg = <0x0 0x100000>;
                };

                partition@100000 {
                        label = "u-boot-env";
                        reg = <0x100000 0x100000>;
                };

                factory: partition@200000 {
                        label = "factory";
                        reg = <0x200000 0x1c0000>;
                        read-only;
                };

                partition@3c0000 {
                        label = "firmware";
                        reg = <0x3c0000 0x2800000>;
                };

                partition@2bc0000 {
                        label = "firmware2";
                        reg = <0x2bc0000 0x2800000>;
                };

                 partition@53c0000 {
                        label = "other";
                        reg = <0x53c0000 0x2c40000>;
                };
        };

Is all this right or I'm missing something?

2

You're right on the sizes + offsets for the DTS.

When the tftpboot 0x80000000 is called, it's all in RAM, not on FLASH.
So it uses tftp to obtain the image, and puts this to RAM, and then it may decompress this image (again into RAM), and then finally it jumps to a location (in RAM) to start executing this image.

A similar thing happens when you boot normally (from flash). The bootload (normally the second stage boot loader, or something like UBoot) will decompress the flash firmware image into RAM. Then it will jump to the entry point of this image.
Often if you watch the bootloaders messages you will even see it saying 'Uncompressing legacy kernel image...' or something similar.

3

So answering my question, is it completely irrelevant to map them on 0x20M or 0x80M, right?

4

It will depend where the RAM starts, and other potential IO mappings, including things like interrupt vectors. You may find that the RAM actually starts at 0x80000000...

The addresses for your flash are not necessarily (nor often) actual CPU mapped memory addresses. They are addresses within the flash chip itself. Which will often be on an SPI bus. Access to the SPI flash is normally via a small number of registers, sometimes just a single data register (normally 32-bits wide on the SoCs commonly involved with OpenWRT).. the whole gigabytes of flash data is not generally directly addressable directly (although some SoCs may have a dedicated SPI nor/nand controller that might allow this as well, this is commonly used in XIP flash systems).

Unless there's a really good reason otherwise, you're best to keep things in line with convention.

5

I must assume that this is why generally very high mappings are used

In this case, most routers are not a full-featured computer so I've found that given the micro size of the firmwares, anything HEX beyond 0x1M will work out.

But I think I've had a good idea of all this by now