I'd like to dump my current firmware from NAND flash via uboot + serial but I don't know which parameters to use. Count number seems to be the size of the flash in bytes.
But how do you get the offset values? bootm according to the link is at 0x9f020000
but pepe2k starts dumping at 0x9F000000. Is this just a typo or is there a specific reason?
I'm also wondering why you don't start at offset 0x00000000. According to mtdparts uboot starts at this address, with ubootenv, config, kernel ... following.
U-boot starts at 0 relative to the flash start. Where the flash itself is located it hardware dependent. If you want to know the offset values for your hardware, have a look in the dts file for your hardware.
No, actually I'd like to dump everything just in case I break something in the next steps.
But when I start dumping from 0x0 it will crash at 0x00030000 and only around 1 MB gets dumped.
Sure the address would be different in my case. But why does he use 0x9F000000 vs 0x9F020000 in the link.
So the uboot address which I get from mtdparts is not the real address, uboot does not really start at 0x0 (beginning of the NAND flash?) ?
I could not find any dts. Is there some other way to get the address. uboot env shows the address for bootm which at least according to the link should be the address where the flash starts.
Depending on the architecture, it may have a first-stage bootloader in the chip, which calls a second-stage boot loader (sometimes called "SBL") from flash (typically at 0x0), which may then call something like U-Boot at another location.
When I run "mtdparts default" (not sure if this is the correct procedure) and then "mtdparts" it will show uboot starts at 0x0. So I guess the SBL in this case is uboot.
Are the addresses for RAM memory and flash memory in any way related?
Currently I run "md.b 0x20200000 134217728" which is supposed to dump the whole flash. When using the wrong offset could I dump accidently the RAM region?
The dump is currently around 100 MB so at least I'm sure I did not just dump the RAM somehow up to now.
Typically, no. Flash is generally copied to RAM prior to execution. For something like a kernel, it needs to be placed somewhere that it won't overwrite itself as it extracts itself and begins to execute.
An excerpt as an illustration from the U-Boot environment of the device on my bench at the moment:
altkern=5f80000 # location in NAND of the alternate kernel
# These load a kernel from NAND to the "loadaddr" in RAM, starting at the kernel's starting address in NAND, for the size of the kernel
bootpart1=set bootargs $partbootargs && nand read $loadaddr $prikern $kernsize && bootm $loadaddr
bootpart2=set bootargs $partbootargs2 && nand read $loadaddr $altkern $kernsize && bootm $loadaddr
# These accept an image over TFTP, putting it at "loadaddr" in RAM, then write it to the "proper" place in NAND
flashimg=tftp $loadaddr $image && nand erase $prikern $imgsize && nand write $loadaddr $prikern $filesize
flashimg2=tftp $loadaddr $image && nand erase $altkern $imgsize && nand write $loadaddr $altkern $filesize
imgsize=5800000 # Expected size (max) of the image
kernsize=300000 # Expected size of a kernel
loadaddr=84000000 # A "safe" spot in RAM for dealing with images, either for writing, or for booting
prikern=780000 # Location of the primary kernel in NAND
Unlikely, as RAM is addressed differently than flash for most devices.