nand-flash-programming

[Mariano Lasala]

Hello,

Trying to nand-flash a new compilation with the corecdp-openjdk-image from corecdp-2.0.0 we have had an issue and the system doesn’t boot properly.

We’re now trying to nand-flash again any compilation but we are blocked when through minicom we send the uboot-setenv script. We’ve tried to execute line by line the script and this is the result with the second line:

U-Boot> setenv bootcmd ‘nboot.jffs2 ${loadaddr} 0 ${kernel_addr}; bootm ${loadaddr}’

Wrong Image Format for bootm command

ERROR: can’t get kernel image!

Is this normal? Are we doing something wrong?

Regards,

Mariano Lasala

[Jesse Gilles]

How did you attempt to flash the openjdk image in? If you tried it from u-boot using tftp, it won’t work unfortunately, because the image is too large to fit in RAM (64 MB). OpenJDK is very large so any image created that includes it will be too large to flash via u-boot/tftp and has to be flashed from Linux by putting it on the SD card first.

If your unit doesn’t boot anymore, flash the base-image from u-boot first. Then boot up and transfer the openjdk-image to the SD card and flash it that way. There are instructions on flashing from Linux farther down on the NAND flash programming page.

Not exactly sure what your issue is with the uboot-setenv script…it looks like there is a new line in your setenv bootcmd, which causing it to try to execute the bootm command rather than saving it in the bootcmd variable.

What linux distro and version are you using? There is a known issue with using the uboot-setenv script from Minicom on Ubuntu 10.04 where it looks like the script never finishes, but it actually does work. Upgrading minicom fixes it (you can grab the package from a newer Ubuntu version).

[Mariano Lasala]

Hello Jesse,

We’ve attempt to flash the openjdk image by putting it on the SD card into a folder called flash-upgrade. But it doesn’t work for us. Well, the proccess began but i think it doesn’t finished successfuly.

We’re going to reflash the device with the corecdp-base-image (is this the factory image?), and then let’s see if this time works.

The linux dirstro and vesion is:

DISTRIB_ID=Ubuntu

DISTRIB_RELEASE=11.04

Linux 2.6.38-12-generic #51-Ubuntu i686 i686 i386 GNU/Linux

I think it’s up to date.

The file rootfs.jffs2 size is 57.088 KB, it’s too big for U-Boot?

[Jesse Gilles]

The factory image is corecdp-full-image from CoreCDP 1.1.1. CoreCDP 2.0.x isn’t released yet, so no units are shipping with it.

There is a minor change to the flashing from Linux procedure for CoreCDP 2.0.0. So if you flash in a 2.0.0 corecdp-base-image, you’ll need to add one more step to your flash procedure using Linux. If you have 1.1.1 on there when you flash from Linux, then you don’t need the extra step.

If you’re flashing from 2.0.0, you need to create the file /var/volatile/do_flash_upgrade before rebooting. If this file doesn’t exist, it will skip upgrading even if the appropriate files are in /media/card/flash-upgrade. This is useful because it prevents unintended flashing if the unit is rebooted again without removing the files in /media/card/flash-upgrade.

So put the files in the usual spot with right names in /media/card/flash-upgrade and then run:

touch /var/volatile/do_flash_upgrade

reboot

This will get added to documentation once 2.0.x is released.

[Mariano Lasala]

We’re flashing from 1.1.1 (corecdp-full-image). Now we’re trying to go back and reflash with the factory image. But with same results. In minicom we only see, saving… for a long time. Not sure what’s happening.

We’ll continue next Monday with this task. I’ll tell you if there has been any news.

Thanks!

Regards,

Mariano Lasala

[Jesse Gilles]

That sounds like the issue I had with minicom and Ubuntu 10.04. The uboot-setenv script never exits, but I think it works properly. Try resetting the unit and then run ‘print’. If all of the variables are set correctly then it worked.

Then try flashing again.

[Mariano Lasala]

Still having the same problem.

We’re not able to load an image from U-Boot.

There is any other way to do this task? Remember we have no boot ATM.

We have the SAM-BA v2.10 app, it’s possible to load an image with this app?

Any hint in how to successfully finish this task?

[Jesse Gilles]

Flashing from U-boot is by far the easiest and fastest method.

Did you examine your U-boot environment and make sure everything got set correctly?

“We’re not able to load an image from U-Boot.”

Please be more specific. Are you still having problems setting environment variables? Failing to TFTP files? Failing to boot from an already flashed image?

[Mariano Lasala]

We’ve tried to send the script uboot-setenv through minicom ALT+A G and then we put in C /home/username/uboot-setenv, enter + enter and it begins to send the script. It never finishes.

We’ve tried to see what’s happening there using screen command but can’t see anything.

Not sure why but several times we have broken the u-boot and we have used the procedure to restore it.

I don’t remember last time we have this problem it were so problematic. The only thing we change in the uboot-setenv is the serverip and the ipaddr.

As we told you before, we’ve tried to execute the uboot-setenv step by step and we still are seen that output wen executing this setenv:

setenv bootcmd ‘nboot.jffs2 ${loadaddr} 0 ${kernel_addr}; bootm ${loadaddr}’

Wrong Image Format for bootm command

ERROR: can’t get kernel image!

I think that this script reaches the erase part but doesn’t load anything.

Can we be sure this script is correct?

ATM the deploy environment we are using is a Ubuntu 11.10 Desktop distro.

[Mariano Lasala]

Hello,

I think we’ve made some progress. I’m pretty sure we had a problem sending the uboot-setenv through minicom.

Trying to find a workaround, we’ve connected to serial port with teraterm. We get the U-Boot> prompt and send one by one all the setenv that appears in uboot-setenv (without send and characters). At the end we send a printenv and we can see all the variables.

At this point, we send a ping to the xinet.d/tftp server ip address and we can see:

U-Boot> ping 1.2.3.4

macb0: Starting autonegotiation…

macb0: Autonegotiation complete

macb0: link up, 100Mbps full-duplex (lpa: 0xcde1)

Using macb0 device

host 1.2.3.4 is alive

But, when we try to execute run tftp_kernel it seems like start to work but doesn’t do anything.

This is the output:

macb0: link up, 100Mbps full-duplex (lpa: 0xcde1)

Using macb0 device

TFTP from server 1.2.3.4; our IP address is 1.2.3.5

Filename ‘oe_uImage.bin’.

Load address: 0x21400000

Loading: T T T T T T T T T T T T T T T T T T T T T T T

Abort

U-Boot> <INTERRUPT>

Any idea?

We have another IPs configured.

[Mariano Lasala]

Hello,

The issue is solved! We had a misconfiguration with the tftp server.

At this moment we have reached to load the corecdp-openjdk-image but only the rootfs.jffs2. We loaded the uImage.bin from the corecdp-full-image (corecdp 1.1.1) with the rootfs.jffs2 from the corecdp-openjdk-image (corecdp 2.0.0). We did in this way because if we tried to load both files from corecdp 2.0.0 compilation, the device never boots. The proccess finished but the output only shows RomBOOT and we can’t do anything.

Does each uImage.bin must be loaded with their rootfs? There is some trouble in this practice?

We have realise for example that there wasn’t a /dev/ttyS1 and we’ve to use the command:

mknod /dev/ttyS1 c 4 65

This is because the uImage.bin file doesn’t correspond to their rootfs?

If we have to load another uImage.bin, how can we compile only the uImage.bin file and how can we be sure this file will work properly before to transfer to the device?

Regards,

Mariano Lasala

[Jesse Gilles]

Yeah, you need to load the kernel image from 2.0 along with the rootfs. The kernel in 2.0 is different than in 1.1.1, so you don’t have any kernel modules in your rootfs that match your kernel you are running.

I would rebuild your kernel in case something went wrong.

bitbake linux -c clean; bitbake corecdp-base-image

Then try flashing just the kernel from U-Boot. There isn’t really a way to test the uImage before you load it, you can only really checksum it to ensure the file transfer worked. If the flashing goes badly, you can just boot back into U-Boot and flash a different kernel again.

[Author]

Posts