Evaluation Board 3.0 - Need CM3 USB boot enabled

[Thomas.Baur]

By mistake I wrote an broken image to the EMMC of compute module 3.
Now I have the problem, that I cannot access USB port any more because of frequent reset and kernel panic.
I wanted to force the PI to use the USB port and documentation tells about EMMC_EN_N pin alias GPIO 47.
The problem ist: There is neither the one nor the other on the board marked as that.
Can anybody tell me, which exakt pin on the IO board (the location) I have to pull to 0V to make the USB boot work?

[jamesh]

On my IO3 board there is a link labelled USB boot enable - not sure if its the same on the IO1, but I think so. Set the link appropriately.

[gregeric]

If your intention is to re-write the image, then repeat what you did to program the CM3 in the first place.

As jamesh describes, this involves moving a jumper on the board to disable the eMMC flash and force USB slave boot. The jumper is close to the second micro USB ie the one which is not used for power.

[Thomas.Baur]

No to both. Independent from that I tried all permutations, the documentation although says something different. Look here:
https://www.raspberrypi.org/documentati ... T-V1_0.pdf

On Page 8 you see what the USB_DISABLE Jumper makes. It disables th EMMC an makes a connection to external USB. Ducumentation clearly says, that this only works for the light version of the compute module (what I don't have, mine is the full version of compute board 3).
At Page 16 it also states, that it is signal (NOT EMMC_DISABLE_N) which has to be pulled to 0V during start (the singal is on the to of page 8). Therefrom it is painted in combination with HDMI_HPD_N_1V8, I suggest (guess), the signal is the middle pin of the second of the two jumper row on the right to of the board. But with jumper, this signal can only be switched between 1.8V and 3.3V. (By the way, the description of EMMC_EN_N_1V8 ist on page 16).
I guess this pin must be hold to 0V with a seperate wire during start. But I'm not shure (and don't want to produce "magic smoke" ).
Does anybody KNOW if I'm right or not?

[gregeric]

The CM3(L) datasheet gives you a better more accurate insight as to what the jumper does. In effect, it operates an electronic switch which disconnects the SD_CMD line from either the on board eMMC (CM3) or external eMMC/SD (CM3L). That diagram on page 8 is in error - it shows the SD_CLK as the one being isolated.

tl;dr: put the USB slave boot jumper to EN & re-program your CM3.

[6by9]

If you look at the CMIO schematics, the jumper controls a FET, so the actual voltage on the pins is largely irrelevant.

EMMC_EN_N_1V8 is NOT GPIO47 on a CM3. It was on CM1, but has been moved to an expander.

The SoC has that pin as an OUTPUT to allow it to override the jumper and re-enable the EMMC once it has been booted into the usbboot tool. That's what FET Q2 is doing in the USB boot enable circuitry. The thing that makes it boot from USB is that the EMMC is not going to respond due to the CMD line being disconnected.

Power down. Move the jumper. Power up. The SoC should fail to boot off the EMMC as it is disabled, and you can then use the same tools to reflash it. If you don't power down then I guess the expander may have been left in the state that turns off Q2 and then Q1 can't result in the line being pulled to 0V.

[Thomas.Baur]

O.K. at first you are right. I'ts an output, my failure.
But: The problem is: The procedure you propose does not work. As result of sudo ./rpiboot -v I get:

Found device 1 idVendor=0x0424 idProduct=0x9514
Found device 2 idVendor=0x1d6b idProduct=0x0002
Found device 3 idVendor=0x0424 idProduct=0xec00
Found device 4 idVendor=0x2676 idProduct=0xba03

Never 0x2763 or 0x2764.
And I'm shure that the hardware is o.k., 'cause if I move the jumper back and make a restart, the board is going on to make his startup-try. And destroying USB by plugging in and out is (should be) a little bit difficult, isn't it?

Any new ideas?

[jamesh]

Are you using the latest rpiboot?

[Thomas.Baur]

I use the rpiboot I get with:
$ git clone --depth=1 https://github.com/raspberrypi/usbboot

[jamesh]

I use the rpiboot I get with:
$ git clone --depth=1 https://github.com/raspberrypi/usbboot

OK, that is the latest one (if you can downloaded this week, it changed at the weekend).

[Thomas.Baur]

I downloaded it yesterday. And it worked. The only failure I did was, that I transfered the correct image from mmcblk and forgot to downsize it before. Now it looks for file system nodes that don't exist and makes frequently kernel panic and restart.

[jamesh]

So you can download images to the CM3 then? What exactly is the problem?

[Thomas.Baur]

The problem is as descriped. The image I uploaded is for 8 GB. The upload to the EMMC ends after 4 GB. So, the image is broken. That means: The prozessor begins to boot, checks the filesystem nodes and realizes, that they don't exist, because auf a 4 GB EMMC has not 8 GB.
After that I get 'kernel panic', the system resets an the game starts again. An there is no possibility to interrupt this process.
The only possibility to get out of this is would be to write an other image. An therefore I have to get access to the USB and this is now not possible any more. Even not if I set the jumper for external USB/SD-card. IMHO this is a simple design failure of one of both: The prozessor board or the extension board.
tl;dr: An errornous written EMMC cannot be rewritten any more because of no more access to USB port.

[gregeric]

You should still be able to write the flash irrespective of whatever non-bootable, random data might be on there.

Where in the world are you Thomas? I'm in the UK & happy to help. I could even fit eMMC > 4GB if that's what you need. See viewtopic.php?f=98&t=172235

[Thomas.Baur]

No,
I did the following:

$ git clone --depth=1 https://github.com/raspberrypi/usbboot
$ cd usbboot
$ sudo apt-get install libusb-1.0-0-dev
$ make
$ sudo ./rpiboot

Thats's o-k. ?

Then I transferred my (wrong or to big) I image with:
sudo dd if=/dev/mmcblk0 of=/sda bs=100M
That worked - the transfer, only once! You understood?

Now I have the state, that this combination makes a reset and don't give me a chance to get to USB-bus to overrite it, because the written part of the file system doesn't let me, it makes his boot before I become access to the bus.

Therefrom I cannot reprogram it.

What is there to be misunderstood ?

[W. H. Heydt]

You can't load the full version of Raspbian to a CM. It's too big to fit, at around 4.3GB. You need to use the Lite version. When I finally managed to flash a CM1, I pre-loaded and set up (i.e. updated/upgraded and added the packages I wanted) using a 2GB SD card. One could dd from such a card, or make a "backup" copy of the card as an img file and get that onto whatever system you are going to use to flash the eMMC.

Personally, I am looking forward to using a CM3L with boot-from-USB bit set and an SSD with Raspbian already built on it.

[gregeric]

Hi Thomas.

You have follwed the recipe to create rpiboot - no problem there.

While the host Pi/PC is "Waiting for BCM2835/6/7", ensure jumper is at the Slave Boot Enable position, attach the data cable, then lastly the power cable to the CMIO board. It will take about 5 seconds for the VPU to timeout on booting from eMMC, then it will try USB. At that point you should get the idProduct=2763, prior to bootcode.bin being squirted over to the L1 cache.

Note that up till now, no ARM cores are turned on, it's all running off the SoC's VPU. It remains that way for the rest of the process: the whole mass storage device application is running on the VPU under ThreadX OS (or VPU bare metal maybe). It is completely agnostic about what data is on the eMMC - the corrupt root partition is all ARM code, which it cannot execute.

Whatever is causing your CM3 not to enumerate, I doubt very much it is the data on the eMMC.

I had a CM1 stuck midway in the slave boot process. That was using a WD Media Stick to flash the CM. Tried & tried, gave up, then put the CM in a CMIO board & no issue. I'd be tempted to try a different PSU &/or USB lead, & if that doesn't work, get in touch with @gsh re new test fw. See viewtopic.php?f=98&t=171975&p=1104111#p1103209

[Thomas.Baur]

Hi Thomas.
While the host Pi/PC is "Waiting for BCM2835/6/7", ensure jumper is at the Slave Boot Enable position, attach the data cable, then lastly the power cable to the CMIO board. It will take about 5 seconds for the VPU to timeout on booting from eMMC, then it will try USB. At that point you should get the idProduct=2763, prior to bootcode.bin being squirted over to the L1 cache.

O.k. That's one of the first thing I thought about too. How do you attach the data cable before attaching the power cable? In that moment you plug in the USB cable, the board automatically gets power supply. I thought already about, that perhaps, the board comes into some "brown out" state.
By the way - the power supply is shurely not too leak. It's enough to support an USB3 camera, with all host systems I tried it out (raspberry pi2, raspberry pi3, orange pi pc, konventional pc). Everywhere the same effect: no enumeration on the usb bus.

Note that up till now, no ARM cores are turned on, it's all running off the SoC's VPU. It remains that way for the rest of the process: the whole mass storage device application is running on the VPU under ThreadX OS (or VPU bare metal maybe). It is completely agnostic about what data is on the eMMC - the corrupt root partition is all ARM code, which it cannot execute.

I'm not a specialist in relation to VPU. But my suspicion is, that it first checks if there is >any< code what can be executed and then gives the control to the cpu unit. I'm not shure, but perhaps disabling the EMM on CB3 >could< result in reading zero to 0xffffffff what drives the VPU to the misunderstanding, that there is any bootable code. I said COULD, I'm not shure. This would have the consequence, that the VPU doesn't feel responsible for init usb unit register and the cpu cannot. Please keep in mind, that I'm talking about CB3 not CB1.

The second case - EMM enabled, CPU boots but never reaches init of usb is clear in this (my) case.
Or not - because: Who inits the usb unit when EMM is enabled and NOT programmed at the first time?

By the way - it also could be a problem, that CB3 and its conterpart dont't get at one, who is master and who is slave. The plug combination m/m is unusual and the more I think about, the more I'm wondering why it at least worked for one time.

[PhilE]

The CMIO board has two micro-USB sockets - the one on the upper left (viewed with the headers towards you) labelled "USB Boot", near the USB slave jumper, is for flashing, and the one lower down ("Power In") is for power. To reflash you should, with the power disconnected:
1) Move the jumper to the slave position.
2) Connect a cable from the "USB Boot" socket to one of the four Pi USB sockets.
3) Run "rpi-boot" on the Pi.
4) Connect the CM power supply to the "Power In" socket.

The Pi should then see the CM as /dev/sd, possibly with partitions like /dev/sd0 and /dev/sd1 depending on the state of the eMMC.

[gregeric]

How do you attach the data cable before attaching the power cable? In that moment you plug in the USB cable, the board automatically gets power supply.

Check the schematic of the CMIOv3 board

Plugging in the data cable to the USB slave port will *not* power the baseboard or module.

If your CMIO red LED comes on with just the data cable, it makes me suspect you are confusing the power port (far corner) for the data port (right next to the USB-A socket).

[Thomas.Baur]

I think we are all right in some kind. It seems that the trick with the A-A connection doesn't work for the second time. It seems that it has to do with that, that power comes together with data connection (brown out theorie). The solution is:
Plug the data cable into the left micro usb (thanks to China sending me a lot of stuff and adapters I never ordered). Put the power in the left connector. Enjoy.
One last question: Is there a hub between this 3 connectors or are they cabled (nearly) one by one?

[gregeric]

Glad you go it working.

Again, you can check the schematics for the real reason a USB A-A cable does not work: without VBUSB present, the eMMC is not disabled.

It may have worked the first time because there was no first FAT partition found, or no bootcode.bin to be found on first FAT partition, so the next boot option was tried.

Edit: re your "last question":

One micro USB is *power only*. Then there is USB i/o: a *host* port, plus a micro-USB *slave* port. Host & slave are mutually exclusive, by way of a switch thrown by VUSBB. No. Hub. Anywhere.

Put that USB A-A to one side, labelling it with "use only on Raspberry Pi Model A, A+, 3A, or CM1/3(L) (first time only)".

[Skysense]

Hi,

Sorry to bring this to life again but I'm having a problem here as well.

I flashed a non-working image and now it won't boot it. OK. Just re-flash Raspbian.

So in order to re-flash I:

1. Have my CM3 in the V3 CMIO board.
2. Move "USB SLAVE BOOT ENABLE" jumper to EN.
2. Attach data cable to computer and "USB SLAVE" micro-USB port.
3. Run "sudo ./rpiboot" on Ubuntu. Freshly cloned.
4. Attach power to CMIO.
5. "Waiting for BCM2835/6/7..." forever.

I tried it on Win10 as well. Same result. Tried different USB ports.

If I attach the HDMI cable I see that it starts booting from the eMMC and then panics. So it won't enumerate.

[Skysense]

OK, I resolved this by using rpiboot from another RPi3 I had up and running.

Now it works as expected!