Updating u-boot imx6-rex pro

[Suriken]

Hello,

I am having some doubts trying to update u-boot from my new board. I have not find a contact in the tutorial I am following so I hope you can point my in the right direction.
I have a imx6-rex pro with a development kit. I want to replace the ubuntu version which came with the microSD with yocto version but I am having a hard time to make it works.
I have been able to download the repository, compile images (base image since time needed to compile them is huge) but at the time of loading them, u-boot seems not to recognize the zImage as good so I get an error.
Then, I read on the internet that the 2009 u-boot version usually gives errors with other linux distros so I started to think about uploading the version to a newer one.

Then, here is when I found this page: http://www.imx6rex.com/contributors/uboot-2014/ which teaches how to upload u-boot without all the problems of tftpd and so on.
After such long introduction, here are my doubts:
Which version should I use (http://www.imx6rex.com/ > binaries)? 2GB I guess, but I'd prefer to be sure.

The biggest doubt comes when I try to modify ucl2.xml on MFGTools:
<LIST name="RexuBoot-2014" desc="Only boot u-Boot.bin">
<CMD state="BootStrap" type="boot" body="BootStrap" file ="u-boot-2014.imx" >Loading U-boot</CMD>
<CMD state="BootStrap" type="load" file="firmware/zImage" address="0x12000000" loadSection="OTH" setSection="OTH" HasFlashHeader="FALSE">Loading Kernel.</CMD>

<CMD state="BootStrap" type="load" file="firmware/fsl-image-mfgtool-initramfs-imx6qdlsolo.cpio.gz.u-boot" address="0x12C00000"
loadSection="OTH" setSection="OTH" HasFlashHeader="FALSE">Loading Initramfs.</CMD>

<CMD state="BootStrap" type="load" file="firmware/zImage-imx6q-%board%.dtb" address="0x18000000"
loadSection="OTH" setSection="OTH" HasFlashHeader="FALSE">Loading device tree.</CMD>

<CMD state="BootStrap" type="jump" > Jumping to OS image. </CMD>
</LIST>
Should I update all imx6qdlsolo, imx6x and other names with my board name (imx6-rexpro...) or I can leave them as they are in the example.
Also, inside cfg.ini file, all SabreSD and sabresd names to imx6-rexpro or same as before?

Sorry for this long post but I have expent some days trying to figure out how to do this and I do not dare to try it becasuse of the risk of bricking the board.

[robertferanec]

Suriken, this may help you http://www.imx6rex.com/open-rex/openrex-content/

Also, have a look at VOIPAC's wiki: http://wiki.voipac.com/xwiki/bin/view/imx6+rex/

- If you would like to update uBoot, do not forget, it is stored in SPI memory. Also, for Kernel 3.14 you can not use uBoot 2009 (it doesn't support Device tree).

- Rex PRO has 2GB DDR3.

- this may help you with MFG TOOL: http://www.imx6rex.com/open-rex/soft...setup-mfgtool/

For the latest MFGTOOL, just use this, should work:
<LIST name="OpenRex-uBootOnly" desc="Only boot u-boot.imx">
<CMD state="BootStrap" type="boot" body="BootStrap" file ="u-boot.imx" >Loading u-boot</CMD>
<CMD state="BootStrap" type="jump" > Jumping to u-boot. </CMD>
</LIST>

Also, have a look at our latest course, that could help you too: Learn the Essentials of creating uBoot, Linux and YOCTO for a board >

[Suriken]

I have read that 2014 u-boot from voipac DvD is the 2009 version adapted to imx6 rex by fedevel. So I should download, compile and reflash the 2015 version.
So, names in mfg tool are just to identify the uboot I am flashing, nothing else. Putting the right uboot file is key. I will try to understand the proccess by reading a little bit more and I will come back with doubts.

If I follow the documentation for open-rex, there is a key step I have to modify to adapt it for rexpro? I guess, all related to fetch files but compiling, uploading... should be the same.

[Suriken]

Well, I already got the u-boot 2015 compiled (bin and imx files). I copied to my windows machine under /OS Firmware folder and added the lines on ucl2.xml and cfg.ini

Just one question I am concerned about. Reading the tutorial, I see that it explains what those lines on ucl2.xml do. I see that there is one to load uboot, load kernel (zImage), load initramfs, device tree and jump to the OS image.

With your lines, it just load uboot and jump to the Os image. What is about zImage, initramfs and device tree? What are they for?

Also, on cfg.ini, platform board could be left as SabreSD or should I replace for another name? REXPRO? Rex-PRO??? same for variable board...

[robertferanec]

You need to replace LIST name with "OpenRex-uBootOnly". Only what you need is load the new uBoot into CPU. Don't worry about other stuff. You can start Linux from uBoot.

If it works oki, use this uBoot to re-flash SPI with the same uBoot image.

[Suriken]

If I don't re-flash SPI with the new uboot image, when I power it down, and up again, the uboot will be the original one? Can I do some resets (with reset command) to see if it works ok?

[robertferanec]

Yes, if you do not re-flash SPI, you still will have the original uBoot in the SPI and when you switch off MFGTOOLS, the original uBoot will boot up after power down / up.

For uBoot debugging is always the best do power off / on, rather then using RESET (unless you are sure you have configured the critical pins correctly).

[Suriken]

Ok, I will try to upload it and if it works, then I will reflash spi. I don't know which mmc use. I have 2009 uboot (but I have read it is the 2014 version from fedevel). So which mmc should I use? 0 or 1?

When my uboot boots, I see this line:
MMC: FSL_USDHC: 0,FSL_USDHC: 1

Also, for SPI re-flash, I see:

"First, fill the RAM with 0xFF’s for 512kb (0×80000 = 524288 bytes), at the location 0×10800000. We use this location in RAM to store the uBoot. I think this location could vary, but this is what is used on the official website so we will stick to that.
mw.b 0x10800000 0xFF 0x80000"

In my case, 2GB...0x80000 should be 0x200000. Same location?

I guess offsets 1kb and 511kb are ok.

Last but not least, machine id (f8c) is needed? Well, I think I will find this when I try to boot kernel for the first time.

[robertferanec]

MMC: Depends in what socket the SD card is plugged in. You can simply try MMC commands. Just run help in uBoot, you will see how to use it, it is not difficult. Then, check info about the inserted card - you will immediately see what mmc number will work.

- 0x80000 is length. This is the space which is needed for uBoot (when you will be transferring uBoot over network, you will see how big it is and 0x80000 must be larger than uBoot size)

- I think machine ID is not used in the new kernels, but I am not 100% sure about this

[Suriken]

I had both resistors switched to micro usb position, also I switched JP1 to JP2 (JP1 no jumper, JP2 and JP3 with jumper) but the board doesn't boot up. When I plug it it sounds a bit (something electrical) but at a couple of seconds later, that sound stops and start over again.

That sound was made before moving resistors and jumper but it was constant all the time.

MFGTool doesn't detect anything (No device connected) and hyperterminal doesn't show anything on screen neither.

I think I will not be able to upload the uboot this way.

[robertferanec]

The sound is ok. These are inductors and it may depend on the current flowing into the module. So do not worry.

This is important ( http://www.imx6rex.com/software/how-...t_empty_module ):
If your module is completely new, JP2 must not be fitted. If you have already programmed efuses, JP2 must be fitted. The USB series resistors must be in positions: R62 Fitted / R65 Fitted / R63 Not Fitted / R67 Not Fitted.

It should then work. You need to wait until driver is installed.

[Suriken]

Sorry I have been out of work this very last week. I will try today or tomorrow to move resistors again and see what happens. I think my module is not completely new as it already has a uboot and mac address.

In this case (mine) I should fit JP2 and JP3 but JP1 should be unfitted, shouldn't I?

I am re-reading my notes from the previous week to see where I left, other question:

"0x80000 is length. This is the space which is needed for uBoot (when you will be transferring uBoot over network, you will see how big it is and 0x80000 must be larger than uBoot size)"

It is suppose that I don't transfer the uboot over network. The file size in my sd card or my computer should be enough, shouldn't it? so I convert the bytes to an hex value and it would be ok.

[robertferanec]

It is suppose that I don't transfer the uboot over network. The file size in my sd card or my computer should be enough, shouldn't it? so I convert the bytes to an hex value and it would be ok.

Approximately. Some software shows a little bit different numbers (e.g. file size vs space occupied etc.)

[Suriken]

Approximately. Some software shows a little bit different numbers (e.g. file size vs space occupied etc.)

in Windows, it takes about 322Kb. So if I set 0x80000 (512Kb) it would be ok. I won't break anything, will I?

I will try to have the dev board with the resistors changed by tomorrow so I can test the proccess again.

EDIT: I had the board modified today. I tested it with mfgtools and I got what you can see on the images.

the first one shows a bad crc... anything wrong? The second one, the version supposed to be at this time. Is everything ok? Should I be worried about something? Ready to replace uboot on SPI? What about my original question in this post?

[robertferanec]

Try "saveenv", that may help to fix the bad CRC error.

Before you flash it, you may want to test if your new uBoot is working correctly e.g. can you read SD cards, is ethernet working, can you access SPI memory, are the memory registers sets correctly and DDR memory is working reliably, etc ... Even if you flash it now, you still should able to use MFGTOOLS to reflash the SPI later - if needed.