Uuu fails with exception

For the first time, I try to flash my devkit.
I use:

ii  uuu  1.2.31-1  amd64  Freescale/NXP I.MX Chip image deploy tools

but I get an exception:

uuu (Universal Update Utility) for nxp imx chips -- lib                                                                                                                  

Enjoy auto [tab] command complete by put below script into /etc/bash_completion.d/uuu
       COMPREPLY=($(/usr/bin/uuu $1 $2 $3))
  complete -o nospace -F _uuu_autocomplete  uuu

terminate called after throwing an instance of 'std::invalid_argument'
  what():  stoll
Traceback (most recent call last):
  File "./scripts/librem5-devkit-flash-image", line 308, in <module>
  File "./scripts/librem5-devkit-flash-image", line 292, in main
    flash_image(uuu_target, args.debug)
  File "./scripts/librem5-devkit-flash-image", line 226, in flash_image
    subprocess.check_call(['uuu', uuu_target])
  File "/usr/lib/python3.7/subprocess.py", line 347, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['uuu', 'images/flash_devkit.lst']' died with <Signals.SIGABRT: 6>.

What am I doing wrong?

What command did you use to run the librem5-devkit-flash-image script?

I used this command:

./scripts/librem5-devkit-flash-image --dir images/ --skip-cleanup

Have you tried using the version of uuu from this repository, described in the documentation? It might be the same as the version you are already using, but perhaps there is a difference in the way command line arguments are handled.

1 Like

I used exactly that repository, only I build a Debian package from it using the branch https://source.puri.sm/Librem5/mfgtools/tree/pureos/purple.

I wonder, whether device is recognized correctly?
lsusb says:

Bus 001 Device 009: ID 0525:a4a7 Netchip Technology, Inc. Linux-USB Serial Gadget (CDC ACM mode)

My PC does not have USB 3, so I use a powered USB hub, which should be able to power up to 1.5 A.

According to this section you should see something like this in the output of lsusb (the bus and device numbers may be different):

Bus 001 Device 005: ID 1fc9:012b NXP Semiconductors

Can you check that the “boot mode” switch is set to the USB position and reboot or power cycle the board?

If it’s still showing the serial gadget in USB boot mode then there may be something wrong with the board itself and we would need to check that.

I don’t have my board with me to check but I think that’s just serial connection of a board not in USB boot.

What kind of hub are you using?

Does this powered USB hub have data pass-through for your computer to connect through the hub?

The “boot mode switch” was set wrongly, indeed. Many thanks for that hint! Now lsusb shows correctly:

Bus 001 Device 014: ID 1fc9:012b NXP Semiconductors i.MX 8M Dual/8M QuadLite/8M Quad Serial Downloader

Unfortunately, the errors stays exactly the same. When I call strace uuu images/flash_devkit.lst on the command line, I get:

stat("images/flash_devkit.lst", {st_mode=S_IFREG|0444, st_size=447, ...}) = 0
openat(AT_FDCWD, "images/flash_devkit.lst", O_RDONLY) = 3
mmap(NULL, 447, PROT_READ, MAP_SHARED, 3, 0) = 0x7fd10f980000
close(3)                                = 0
stat("images/flash_devkit.lst", {st_mode=S_IFREG|0444, st_size=447, ...}) = 0
futex(0x5647540271f0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(2, "terminate called after throwing "..., 48terminate called after throwing an instance of ') = 48
write(2, "std::invalid_argument", 21std::invalid_argument)   = 21
write(2, "'\n", 2'
)                      = 2
write(2, "  what():  ", 11  what():  )             = 11
write(2, "stoll", 5stoll)                    = 5
write(2, "\n", 1
)                       = 1
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
getpid()                                = 10803
gettid()                                = 10803
tgkill(10803, 10803, SIGABRT)           = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=10803, si_uid=1005} ---
+++ killed by SIGABRT +++

Btw, I’m sure the hub has data pass-through, because with the switch in the other position, I can log in on the devkit using picocom.

I’m on Debian 10 (buster/sid), maybe I should try Debian 9 (stretch) instead?

I’m also using Debian 10 (buster/sid). Have you tried using the board without the hub? My PC only has USB 2, so USB 3 isn’t an absolute requirement.

The lib version seems to be missing from your first post. It should be on the end of the "uuu (Universal Update Utility) " line.

Could you also post the images/flash_devkit.lst as the issue seems to be a missing/broken argument.

Without the hub in between I get the same error from the script.

The lib version is:

uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.2.31-1-g6983a9c

The .lst file content is:

$ cat images/flash_devkit.lst 
uuu_version 1.0.1

SDP: boot -f u-boot-devkit-recovery.imx
# This command will be run when use SPL
SDPU: delay 1000
SDPU: write -f u-boot-devkit-recovery.imx -offset 0x57c00
SDPU: jump
# This command will be run when ROM support stream mode
SDPS: boot -f u-boot-devkit-recovery.imx
SDPU: delay 1000
#FB: ucmd setenv fastboot_buffer 0x43000000
FB: ucmd setenv fastboot_dev mmc
FB: ucmd setenv mmcdev 0
FB: flash -raw2sparse all devkit.img
FB: Done

Maybe running uuu with the -v option would help to figure out exactly what it’s missing.

After not being able to flash with my rather old computers (all Thinkpads from 2011), I used a newer computer of a friend and could flash without problems, not using the powered hub.

1 Like

That’s good to hear - that you got it to work in the end. I think most of the updates from now on won’t require flashing, so hopefully you can get going with developing and experimenting with the board.

1 Like

I had a very similar problem with uuu, solved the same way. Uuu just won’t work on 32-bit architecture with images bigger then, I suppose, 2GB. But i used self-compiled uuu, and got clear errors in strace instead of exceptions and aborts: mmap of 3600000 bytes failed - out of memory. And it seems uuu will not support 32bit systems, unless someone like You or I will submit a working patch.

1 Like

That’s a different issue then. My computers are old, but already amd64 :slight_smile:
I blame the very old USB, but maybe it’s something else.

1 Like