Access board that has system on eMMC and no SD card

[KennyM64]

Hi. I have a bunch of HummingBoard2 boards that have been used by a company called Vivo. Basically they allow schools to transfer video through Ethernet to monitors and projectors. I also want to do this but Vivi is a subscription based system so that SUX!

I therefore want to blow Vivi away and load a clean Armbian.

 

My issue is that the boards have no SD cards soldered to the board. They have power, 2xUSB,  RJ45, HDMI connectors. They must therefore boot from eMMC. I found info on the board manufactures website., SolidRun, on how to use jumpers to select boot type. It was set to eMMC so I set it to USB and flashed a SD card with Armbian 20.20 and rebooted. Alas it didn't work, it didn't even try and read the USB port with the flashed SD card.

 

I then hooked up an FTDI to the onboard UART and got connected. I don't have the password so had to stop it booting and try and access the system that way.

 

My problem is after the boot interruption it doesn't have any file structure so I can't edit files to change boot sequence or passwords.  I can't mount the eMMC to edit the files to remove the root password or anything like that.

 

Any suggestions as to how I can unlock this board and load a normal Armbian on to it?

 

Cheers

[RussianNeuroMancer]

https://developer.solid-run.com/knowledge-base/i-mx6-u-boot/ page mention
 

For presenting the eMMC (mmc1) as a usb storage device, execute

ums 0 mmc 1

Now on a connected PC a new usb drive should have shown up. From this point onwards anything is possible! Partitioning, mounting, writing binaries in arbitrary locations, …

Did you tried that?

[KennyM64]

Hi Russian NeuroMancer. Thanks for the suggestion.

I gave this a try but it looks like U-Boot hasn't been built with the ums command, so unfortunately it's a no go. The page you referenced has a lot of interesting stuff on it though. I'll do some more reading and experimenting and see if I can get something working. It looks like the manufacturing cycle blew the fuses so it only boots from eMMC and doesn't fall back to USB. There is little information as to how to jumper these fuses back but I'll keep looking. :-(

 

 

Cheers

 

Ken

[dalekuhn]

Hi KennyM64,

 I just had to figure this out for myself on the Hummingboard Edge. The Solidrun article on boot jumpers is a little misleading. Removing the jumpers (at least on an unfused system) boots into USB recovery mode. That's not the same as actually booting from USB. Instead, the board will sit there and wait for SDP (serial download protocol) commands to come in over the USB OTG port.

 

1. Make a custom cable following instructions here. I used a 1 ohm resistor.

2. Connect the cable to the top USB port next to the ethernet port. (This is the only port with OTG functionality)

3. Follow the instructions here to download and build the imx_usb_loader.

4. Generate SPL and u-boot images or use the attached files. Drop them into the imx_usb_loader folder or adjust the path in the commands below.

4. Run ./imx_usb SPL (if you haven't adjusted your udev rules, you have to use sudo for this and the next command)

5. Once SPL is loaded, run ./imx_usb u-boot.img

 

You can build Armbian with the CREATE_PATCHES=yes option to adjust U-Boot to include ums support. The changes required are outlined in the link from step 3. Alternately, I've attached my SPL and u-boot.img. My u-boot has ums enabled and activates mmc 1 by default so you shouldn't need a serial cable, although it is nice to see that things are working without the need for a monitor. Once mmc 1 is activated by ums, you should see the board's eMMC flash show up as a USB drive. From here you can flash an image using Etcher, dd, or whatever method you prefer. If the board is actually fused, this may not work. However I saw a Solidrun document somewhere that shows how to hold the eMMC in reset at powerup. In this case, if the board can't boot from eMMC because it's held in reset, that should cause the board to fall back to recovery mode. Either way, once you're in recovery mode, the above steps should work. I hope this helps.

 

Good luck,

Dale

SPL u-boot.img

[KennyM64]

Hi Dalekun

 

I have been bashing my head against this problem for a while now and while i've made some progress I have hit a brick wall.

 

For some reason my keyboard input isn't going to the board. I'm using putty (and have tried others) with 115200,8,1,N,N. I've followed this example here and have run ‘./runme.sh’ which then populates putty with 

 

U-Boot 2013.10-rc4-g4c7d180-dirty (Mar 23 2017 - 15:50:02)

CPU:   Freescale i.MX6Q rev1.5 at 792 MHz
Reset cause: POR
Board: MX6-HummingBoard2
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Card did not respond to voltage select!
MMC init failed
Using default environment

In:    serial
Out:   serial
Err:   serial
Net:   FEC [PRIME]
Hit any key to stop autoboot:  0
## Executing script at 17f00000
Kernel image @ 0x10a00000 [ 0x000000 - 0x1d4ac80 ]
## Flattened Device Tree blob at 18000000
   Booting using the fdt blob at 0x18000000
   Using Device Tree in place at 18000000, end 1800cd2e

Starting kernel ...

Welcome to Buildroot
buildroot login:
 

 

But no matter what I try I can't get an echo from my keyboard. I've tried different USB cables, different tty boards, different jumper wires from the tty to the board pins, different Hummingboard2 boards and even different computers running different terminal packages but no matter what I try there is no keyboard entry.

 

I do remember when I started fooling with these before this post I was able to halt an MMC boot from putty by hitting any key, however I can't do that now, which is very strange :-(

 

So I'm stuck :-(

 

Any ideas?

[wobide3]

It sounds like you are facing some challenges in unlocking and loading a clean Armbian onto your HummingBoard2 boards. Here are some suggestions that you may find helpful:

Double-check the boot sequence: Make sure that the jumpers are correctly set for booting from the USB device, and try a different USB device if possible. Also, check if your board has a boot mode switch and ensure that it is set to the correct position.

Access the bootloader: Try to access the bootloader by interrupting the boot sequence. This should allow you to modify the boot settings and choose a different boot device. The specific key or combination of keys to press during boot may vary depending on the board and bootloader used, so check the documentation for your specific board.

Use a serial console to access the system: Since you have already connected an FTDI to the onboard UART, you can use this to access the system and modify the files or settings as needed. Check the documentation for your specific board for the correct settings to use for the serial console connection.

Use a JTAG debugger: If the above methods do not work, you may need to use a JTAG debugger to gain access to the board and modify the firmware directly. This is a more advanced technique that requires specialized wall hardware and software, so it may not be suitable for everyone.

It's also worth noting that modifying the firmware or bootloader of your board carries some risk, so proceed with caution and make sure to back up any important data before attempting any changes. Good luck!