clone boards memory

Hello,
I would like to clone flash memory from a portux board to another. From now I was doing :
- using sam-ba under windows to erase nand, then send debootstrap/uboot/kernel
- boot on sd card to flash rootfs to the flash
- then change boot variable to boot on flash
It is clearly not very practical and I want to improve that to have just 1 action to make, by cloning the flash from a portux to an other.
Thx in advance for your replies and advices.
BR.

Re: clone boards memory

You can also erase and reprogram the nand flash with your Linux SD card. Use the tools flash_erase/flash_eraseall and nandwrite. There is one caveat: By default, the first mtd partitions are marked read-only via the bootargs. You have to alter them in U-Boot, before booting the SD card.

Please be aware that by erasing the whole nand flash, you are also erasing the MAC address in the U-Boot environment.

Re: clone boards memory

Hello, thx for your reply but i'm already doing that by hand.
I would like to have a unique operation so that I can clone easily flash content.
I'm already flashing rootfs on mtd5 with nandwrite but I'm not sure that flashing bootstrap/uboot/kernel with the same method on a running board will be very nice :)
BR.

Re: clone boards memory

There is actually no difference between flashing the first partitions from Linux or with SAM-BA. So you can flash bootstrap/uboot/kernel with Linux or the rootfs with SAM-BA. In both cases you could script the procedure. Under Linux you can use a shell script, under SAM-BA you can write a TCL script (look into tcl_lib/at91sam9g20-taskit).

If you have in mind to use one image for the whole flash, that is not really usable. The problem is, NAND flash can have bad blocks. If one of these is encountered by the flash routine, it skipped and writing/reading continues in the next block. If one of the first blocks is bad that would offset the writing of the following partitions. Bootstrap, U-Boot and Linux have fixed offsets, from where they start reading the images so in case of bad blocks they would read from the wrong address. So all images have to be written one by one, not as a single file.

Re: clone boards memory

Ok thanks a lot for your answer.
If you don't mind I have another question : is it possible to speed up data transfer when we use usb to serial driver, tipically with sam-ba for example ? I Think the driver emulates maybe 115200 rate but as we are on usb it may be possible to use a better speed ?
I have one last question not really related to that and less interesting : did you have test the last release of sam-ba (v3) ? Is it then usable with legacy tcl scripts or is it mandatory to still use sam-ba 2.10 ?
Thank you again for your replies :)
BR.

Re: clone boards memory

I don't think you can improve the speed of the USB interface with SAM-BA. I think this has more to do with the fact, that it is only a USB full speed connection (12MBps) and the way, USB and SAM-BA work architecturaly. Newer Atmel microcontroller with a High Speed interface (480MBps) are also much faster in SAM-BA.

We haven't tested SAM-BA 3, so I cannot say, how easy one can transfer our board support to this version. So for now, I would say, 2.10 is still mandatory.

Re: clone boards memory

Ok thank you for this reply. I've been testing/trying sam-ba 2.12 since 2/3 days as I've seen in the release notes that support of jffs2 appeared in 2.11 and a bufix for that was in 2.12.
I've try to flash my own jffs2 rootfs and yours but it does not work. For now the only option for me is to flash this jffs2 file with flash_eraseall -j /dev/mtd5 + nandwrite commands.
I got ECC errors when flashing the rootfs with sam-ba, can you say what I can to in order to flash jffs2 image with samba ?
Thank you again for yours answers :)
BR.

Re: clone boards memory

Hello, I still have issues with ecc when flashing roots with sam-ba, if you have some hints I would be grateful :)
Have a nice day.

Re: clone boards memory

Hi one more question since then : I've tried to recompile a uboot version, I've tried the last 2013.01.01 tag on denx u-boot git repository, i've tried 2013.04 tag and the last 2015 tag. For the 2015 tag the portux and stamp boards are no longer in the repository, so that was quick to test ...
For the 2013.01 and 2013.04 tags the compilation is ok with the following commands :
make CROSS_COMPILE=/usr/local/angstrom/arm/bin/arm-angstrom-linux-gnueabi- ARCH=arm portuxg20_config
make CROSS_COMPILE=/usr/local/angstrom/arm/bin/arm-angstrom-linux-gnueabi- ARCH=arm all

I get a functionnal u-boot.bin, which I've flashed at 0x20000, like always :)
When u-boot try to load the kernel I've got the following error :
----
NAND read: device 0 offset 0x100000, size 0x600000
NAND read from offset 100000 failed -74
0 bytes read: ERROR
Wrong Image Format for bootm command
ERROR: can't get kernel image!
---
printenv gives :
---
basicargs=console=ttyS0,115200
baudrate=115200
bootargs=console=ttyS0,115200 mtdparts=atmel_nand:128k(bootstrap)ro,256k(uboot)ro,128k(env1)ro,128k(env2)ro,6M(linux),-(root)rw root=/dev/mtdblock5 rootfstype=jffs2
bootcmd=run flashboot
bootdelay=3
ethact=macb0
flashboot=setenv bootargs ${basicargs} ${mtdparts} root=/dev/mtdblock5 rootfstype=jffs2; nand read 0x22000000 0x100000 0x600000; bootm 22000000
mtdparts=mtdparts=atmel_nand:128k(bootstrap)ro,256k(uboot)ro,128k(env1)ro,128k(env2)ro,6M(linux),-(root)rw
nfsboot=setenv autoload yes; setenv autoboot yes; setenv bootargs ${basicargs} ${mtdparts} root=/dev/nfs ip=dhcp nfsroot=${serverip}:/srv/nfs/rootfs; dhcp
sdboot=setenv bootargs ${basicargs} ${mtdparts} root=/dev/mmcblk0p1 rootwait; nand read 0x22000000 0x100000 0x600000; bootm 22000000
---

I assume these options are not correct, for example the size of kernel partition is not 6M but 2M, and the nand read arguments have changed too.
So i tried that with both 2013.01 and 2013.04 versions :
---
U-Boot> setenv mtdparts 'mtdparts=atmel_nand:128k(bootstrap)ro,256k(uboot)ro,128k(env1),128k(env2),2M(linux),-(root)'
U-Boot> setenv flashboot 'setenv bootargs ${basicargs} ${mtdparts} root=/dev/mtdblock5 rootfstype=jffs2; nand read 0x22000000 linux; bootm 22000000'
U-Boot> setenv sdboot 'setenv bootargs ${basicargs} ${mtdparts} root=/dev/mmcblk0p1 rootwait; nand read 0x22000000 linux; bootm 22000000'
U-Boot> setenv disable-wd 'mw fffffd44 8000'
U-Boot> setenv bootcmd 'run disable-wd;run sdboot'
U-Boot> saveenv
U-Boot> reset
---

So after that it's a little bit better, but not perfect :
---
NAND read: offset is not a number
Wrong Image Format for bootm command
ERROR: can't get kernel image!
---

So my question is : which version of uboot was compiled to produce the binary which is available on this site for the portux ?
If I use the u-boot you provided named "u-boot-2013.01-bch-portuxg20-reset-fix.bin" with version "U-Boot 2013.01-00009-g8c26231 (Jun 27 2013 - 15:18:08)", it's wworking well but the default environnement is not correct for my use, so I would like to recompile a new uboot, with my settings.

Have a good day !

Re: clone boards memory

The latest two downloads for PortuxG20 contain not only the images but also the patches for the corresponding images. The patches from both download packages have to be combined to get the source used for the latest image. So download http://download.armbedded.eu/software/Stamp9G20_PortuxG20-BCH-upgrade.ta... and http://download.armbedded.eu/software/Stamp9G20_PortuxG20-u-boot-2013.01... and apply the files u-boot-2013.01.patch and reset-fix.patch to the clean U-Boot 2013.01 sources and it should work as expected.

Re: clone boards memory

Hello,
Ok thank you I'll try again, I'll let you know the progress on that point ;)
If you prefer I can split the posts, it's a bit messy now with all my questions !
BR.

Re: clone boards memory

Hi again, I've successfully build & flashed uboot.bin, thanks.
The thing is I was using portuxG20 target instead of portuxg20_128M, maybe that's why it wasnt operationnal.
Anyway it's ok now, thanks :)

Do you have any clue concerning flashing jffs2 rootfs with samba ?
Have a nice day.

Re: clone boards memory

Hello, I tried to play a bit with sam-ba 2.15, it works quite well. I've tried ECC settings too, for example to enable (I think) software ECC before flashing the rootfs but it's not working.
Do you have any idea about that ?
BR.

Re: clone boards memory

Hello everybody, I would be very grateful if someone has a clue concerning my problem of ECC errors when flashing the roots on flash mtd5, have a nice year/

Re: clone boards memory

Which ECC settings are you trying to use?
Our kernel and at91bootstrap for the PortuxG20 uses 4bit BCH to load the rootfs.
For SAM-BA 2.10 where 4bit BCH was not supported, we provided an update (see http://armbedded.eu/node/8). If SAM-BA 2.15 supports this ECC mode and also supports our memory configuration, our SAM-BA 2.10 package is not needed.

Best way to test would be to:
1.) Connect with SAM-BA 2.15.
2.) Copy your rootfs (or better a very large file occupying most of the RAM) into SD-RAM and verify this step. If the data reads without altering, you can continue.
3.) Enable 4bit BCH on NAND and flash your rootfs.

If these steps don't work, you have can use SAM-BA 2.10 with our support package as fallback at least.

Re: clone boards memory

Hello, thank you for your answer. I'm using 4bit bch with sam-ba to flash debootstrap/uboot/kernel.
The problem is that I don't want to boot on sdcard to flash the rootfs. This option works for me but I need a solution to make the whole flashing process the easier way.
So I would want to flash as well the roots on nand flash (on mtd5) with the same process with sam-ba so I just have to write a nice script to flash a complete portux debootstrap+uboot+kernel+rootfs.
But unfortunately flashing the jffs2 rootfs with sam-ba, with the same process than the other binaries, leads to ecc error when the kernel is trying to mount the FS.
I've tested several versions of sam-ba : 2.10/2.12/2.15 and I have the same results. I may specify that the rootfs I tested are the one you provided in jffs2 and a debian custom one in jffs2 too. For each rootfs the process of booting on sdcard + flash_eraseall + nandwrite /dev/mtd5 works, but I would want to do that in sam-ba.
I don't know then if the problem comes from ECC enabling, jffs2 management from sam-ba, or other things ...

I hope I've covered your answers, thank again for your help.

BR.

Re: clone boards memory

Okay, that sounds strange.
I will try/check the procedure described by you.

Can you provide a bad block list from your device?
SAM-BA should be able to produce one (see the scripts pull-down menu in the GUI).

Re: clone boards memory

Hello, Thank you.
I'll give you that list, but even with a brand new portux, with (I think) no bad block the problem is still here unfortunately :-(
I'll describe you step by step too every procedure I've tried, but it'll take a bit more time.
Have a nice day.

Re: clone boards memory

Hello again. I've tried to flash the rootfs on a new card, with no bad blocks, with the same results.

Here are the step in sam-ba that I follow to flash my boards :
- enable 4 bits bch
- erase all
- send boot file with your "bootstrap-stamp9g20-nandflashboot-uboot-3.4-128mb-bcg.bin" file, I've not my own file for that, I use yours it works well :)
- send file at 0x20000 with my uboot file : I've made my own from the 2013.01 release, applying the 2 patchs you provided because I needed default environments arguments which are not yours. This part works well too, I can now for example boot directly by default on flash instead on sdcard
- send file at 0xA0000 with a custom 2.6.35.3 kernel, I've applied too several patches like adc & w1 ; I've applied several modifications too to match my needs, and it works well too

Then there is the problematic part : the rootfs. I've too options : the one with sam-ba which fails, and the one where I use the sdcard boot which is not convenient for industrialisation matters :
sam-ba way : after the previous steps, send file at 0x2A0000 with my rootfs (debian) I've dump in jffs2 from mtd5 ; If I use your rootfs i.e. "angstrom-taskit-image-glibc-ipk-2009.X-stable-portuxG20.rootfs.jffs2" I've the same problems mentionned in my previous posts. I don't know why this way of flashing fails ...
sdcard way : I boot on sdcard using disable-wd & run sdboot ; Then I use flash-eraseall -j /dev/mtd5 && nand_write /dev/mtd5 myrootfs.jffs2 ; Here this way works with both of my rootfs and yours.

I've tried multiples possibilities with various FS and sam-ba versions, nothing good ... I've tried sam-ba 2.10, 2.12, and 2.15 which I patched to be able to work correctly with the taskit tcl script, the interfaces having changed. With all sam-ba versions I've been able to flash bootfile/uboot/kernel with no problem and the rootfs each time is problematic.

With sam-ba 2.15 there is a ECC panel available to specify hard/soft ECC and several other options. I've played a bit with that but I didnt think it was promising so I've abandonned this possibilty.

In my last post I mentionned a weird behaviour when flashing a rootfs : the last packet sent is of size 0x20000, as all the others. It may means that the file is too big for sam-ba to manage so it's stopping at a certain point ... ? I've not counted the numbers of packets sent in the logs but it may be a lead ... ?

Let me know if you need other information I can provide you anything you need of course !

Thank again for your help I hope we will be able to manage rootfs flashing on nand with sam-ba quickly with your expertise.

BR.

Re: clone boards memory

I checked the procedure on my own without encountering any problems when booting the board (rootfs from NAND) afterwards.

As you say, you compiled a custom kernel on your own.
The following scenario could explain your issues:

1.) Your boot loaders (bootstrap & U-Boot) support 4bit BCH and were flashed with SAM-BA using 4bit BCH.
2.) Your kernel does not support 4bit BCH and is flashed with SAM-BA using 4bit BCH. (kernel uses 1bit ECC)

The effects from this match with your description:

a) The board can load the kernel correctly, so you can boot a rootfs from SD card without errors. U-Boot loads the kernel using 4bit-BCH; the kernel was written to NAND using 4bit BCH.
b) When using this kernel to flash the rootfs to NAND from Linux, the system will boot without errors from NAND. It works because Linux writes the rootfs using 1bit ECC and loads it with the same parameters.
c) The same rootfs flashed with SAM-BA using 4bit BCH does not load correctly, because Linux uses 1bit ECC to load it.

It is not recommended to use 1bit ECC for the rootfs, so - if my assumption is right - you'll need to enable BCH support in your kernel.

Re: clone boards memory

Ok thanks a lot. I've tried your kernel too, but I'll check my own ecc configuration in my kernel.
I'll let you know the results.
Have a nice day.
BR.

Re: clone boards memory

Hello,

I've tried the same procedure as before in sam-ba but switching to 1bit hamming before flashing rootfs and evrything runs just fine.
So you were correct :)

Do you have a patch or a bz2 which would help me adding 4bit bch ecc to a 2.6 kernel please ?

I've found this doc => "https://www.micron.com/~/media/documents/products/technical-note/nand-flash/tn2971_software_bch_ecc_on_linux.pdf" do you think it could be ok to implement 4bit as it ?
And finally did you test yourself speed differences between 1 and 4bit ecc ?

It is again more questions but they are less important as now at least I've a complete way of flashing my boards with sam-ba. Thanks again for your help !

Have a nice day.

Re: clone boards memory

I have prepared a patch that should work, I have only compile tested it, but it is based on patch for another product:
http://download.armbedded.eu/support/linux-2.6.35-stamp9g20-portuxg20-bc...

Don't forget to enable the BCH support in the kernel config, otherwise the kernel will crash while booting.

Regarding the speed difference, I tested the throuhput some years ago and I think went from 7MB/s (1-bit Hamming) to 5MB/s (4-Bit BCH).

Re: clone boards memory

Hello, thank you for your reply. I'll try that as soon as I have a small amount of time ... I'll keep you updated !
Thanks a lot for your help.
BR.

Re: clone boards memory

I don't know if it can be a clue but when I'm flashing the rootfs which is 33,6Mo sam-ba sends several packets of 0x20000 bytes. I find it strange that the last packet is 0x20000 too, it should not be a round number like this I think. For example when we write uboot or kernel the last packet is smaller, which is normal ... Maybe sam-ba can't write more than a specific size, which would lead to ecc error if the complete file is not flashed ?

Re: clone boards memory

JFFS2 images are padded to block sizes. On this NAND a block is 128k or 0x20000 bytes.
So it is normal to see no smaller SAM-BA transfers.

Syndicate content