ConnectCore 6UL 1G-1G u-boot flashing using imx_uart

everyone,

I’m struggling with a downloading u-boot using the serial util imx_uart.

The most compatible board I found is Digi ConnectCore 6UL SBC Pro.

I’m using the following command when trying to flash the reference u-boot image

imx_uart -n /dev/ttyUSB0 /usr/etc/imx-loader.d/mx6ull_usb_work.conf /opt/boqpod/gsmbox_firmware/misc/ccimx6ulsbc-installer/u-boot-ccimx6ulsbc1GB.imx

I have no RTC/CTS lines connected, so I’m using ‘-n’ option.

Nevertheless, I’m not sure if I’m doing everything correctly.

Step-by-step.

  1. I’m launching the command
imx_uart -n /dev/ttyUSB0 /usr/etc/imx-loader.d/mx6ull_usb_work.conf /opt/boqpod/gsmbox_firmware/misc/ccimx6ulsbc-installer/u-boot-ccimx6ulsbc1GB.imx

and see the following output

config file 
parse /usr/etc/imx-loader.d//mx6ull_usb_work.conf
starting associating phase..........
and it fails if the reset button is not pressed.
  1. Once I’ll press the reset button, I see the following response
association phase succeeded, response was 0x23454523
... and it stalls until I press the reset again.
  1. After I’m pressing the reset again, I see the following
HAB security state: development mode (0x0a0d0a0d)
== work item
filename /opt/boqpod/gsmbox_firmware/misc/ccimx6ulsbc-installer/u-boot-ccimx6ulsbc1GB.imx
load_size 0 bytes
load_addr 0x00000000
dcd 1
clear_dcd 0
plug 1
jump_mode 3
jump_addr 0x00000000
== end work item
loading DCD table @0x910000

<<<520, 520 bytes>>>
failed (security 0x74206361, status 0x7573653a)
clear dcd_ptr=0x877ff42c

loading binary file(/opt/boqpod/gsmbox_firmware/misc/ccimx6ulsbc-installer/u-boot-ccimx6ulsbc1GB.imx) to 877ff400, skip=0, fsize=b1c00 type=aa

It takes 1 minute to ‘load’ the binary and that’s what I see in the end

<<<728064, 728064 bytes>>>
failed (security 0x07070707, status 0x07070707)
jumping to 0x877ff400
failed (security 0x07070707, status 0x07070707)

Could somebody please explain if I’m doing smth wrong and how to flash the binary properly.

never tried imx_uart here. Is it a bootstrap option? Is your board properly bootstrapped to boot from UART?
We use USB boot for recovery? do you have access to USB OTG/device pins?

1 Like

I have managed to solder directly to USB OTG pins and use imx_usb command.
Nevertheless, there’s another question - the u-boot image is still resides in a RAM memory, and I see the bricked board after reset, so I need it to be stored in the flash memory. How to do this ?

Hi…
The MCA in the ConnectCore 6UL system-on-module also supports one or more UARTs depending on the firmware version. See MCA UART serial port for additional information on MCA UARTs. For information about using the serial port from user space, see the Serial Programming Guide for POSIX Operating Systems .
you can take the more information then click here https://klantenservicenederland.co/google/

you boot of the u-boot in SDRAM then you use that u-boot to program correct image to flash.

Thanks for quick reply !
Is there’s an exact command to do this ?

for digi cc6ul platform you can find documentation here:
https://www.digi.com/resources/documentation/digidocs/embedded/dey/3.0/cc6ul/yocto_t_program-firmware-from-uboot
I am not sure it applies to other non-digi platforms.
How do you normally update flash on your target?

We have digi cc6ul SOM.

Yes, I took a look at the u-boot documentation (specifically - https://www.digi.com/resources/documentation/digidocs/PDFs/90000852.pdf) and my biggest question is how to update u-boot from RAM. We have no external flash connected, so 1 GB on-board flash is used.

Answering your question - we’re updating images using xmodem protocol and loadx command on u-boot side.

the document you refer to is from 2011 and is for a very different version of u-boot for very different products.

the answer to your question again is here:
https://www.digi.com/resources/documentation/digidocs/embedded/dey/3.0/cc6ul/yocto_t_program-firmware-from-uboot
once u-boot is running, you should be able to update either from uSD card or via network/TFTP/NFS

Leonid, thank you for your reply and sorry for long response.

You’ve correctly catched up the idea of updating u-boot image.
However hard I tried, I can’t update u-boot.
Let me describe a bit more so you’ll understand my problem.

I’m bringing up the board based on CC6UL (1G-1G) module. In order to make the board boot into u-boot after the reset, I need to flash u-boot on internal NAND device in order to have it flashed on board.
What I’ve tried:

  • Looking ahead, the digi doc section ‘Recover Your Device’ is not works for me because I neither have the SD card slot, nor ethernet set up (more about this below). Anyway, I have flashed u-boot from RAM memory.

What I’ve tried:
(update using ‘update’ command)

  • loadx 0x88000000 115200
  • update uboot ram 0x88000000 0xbec00

(update using direct nand write)

  • loadx 0x88000000 115200
  • nand erase 0 0xbec00
  • nand write 0x88000000 0 0xbec00
  • reset

In both cases I have compared if u-boot has been written to NAND by reading NAND memory with offset 0 to one memory location and loadx’ed u-boot image to another and making ‘cmp’ against them.

In anyway, the board is not running u-boot after the reset.

Could you please explain if I’m doing smth wrong there ?
What else should I take a look at ?

I think you need to use update command. Update can use ram as source:
=> update
update - Digi modules update command

Usage:
update source [extra-args…]
Description: updates in NAND via
If the partition is UBI formatted, or a filename with
extension *.ubifs is passed, writing a UBIFS is assumed
Otherwise, this command raw-writes the file to the partition.

Arguments:

  • partition: a partition index, a GUID partition name, or one
    of the reserved names: uboot

  • [extra-args]: extra arguments depending on ‘source’

    source=tftp|nfs -> [filename]

    • filename: file to transfer (if not provided, filename
      will be taken from variable $_file)

    source=mmc -> [device:part] [filesystem] [filename]

    • device:part: number of device and partition
    • filesystem: fat (default)|ext4
    • filename: file to transfer (if not provided, filename
      will be taken from variable $_file)

    source=ram -> [image_address] [image_size]

    • image_address: address of image in RAM
      ($update_addr if not provided)
    • image_size: size of image in RAM
      ($filesize if not provided)

Thank you for copying the whole help for ‘update’ command, that was very HELPful.
In my previous message I have mentioned that I have used that command, but still result is the same.

Do you have any clues what might go wrong during a boot process, so I can not boot from NAND ?

Did the board ever boot from NAND? Why did you have to program it in the first place? All modules come with preprogrammed U-boot that is guaranteed to boot. If the module never booted from NANd, I would say the bootstrapping is wrong. How are you configuring bootstrapping to boot from USB vs booting from NAND?

what do you see if you do from u-boot:
=> fuse read 0 5
Reading bank 0:

Word 0x00000005: 00000000
=> fuse read 0 6
Reading bank 0:

Word 0x00000006: 00080040

LeonidM, Thank you for your reply. It seems like you’re my last hope XD

Yes, it has booted from NAND with a default firmware on it and I was able to interact with its u-boot and read Ethernet PHY registers from it.
After playing around with that board, I have wiped out its NAND contents (in anyway, I will be needed to) and now I’m working with u-boot from RAM.

> How are you configuring bootstrapping to boot from USB vs booting from NAND?
I have CC6UL 1G-1G with a castellated pads, so my only option to control the boot process is to use BOOT_MODE1 pin. It is pulled by 10K to 3V on a board and for debug purposes I have soldered pulling down button to the same pad. I also have soldered a USB cable to a dedicated USB pins. This way, when I need to start u-boot from RAM, I’m pressing the button, restarting the board and running ‘sudo imx_usb u-boot-ccimx6ulstarter1GB-2017.03-r0.imx’.

BOOT_CFG1 setup seems to be ok too, it’s setup to boot from NAND device (BOOT_CFG1[7] = 1).

> what do you see if you do from u-boot:
Exactly the same picture

=> fuse read 0 5
Reading bank 0:

Word 0x00000005: 00000000
=> fuse read 0 6
Reading bank 0:

Word 0x00000006: 00080040