usb-only rpi 3b+ (+UART foo)
Trev
freebsd-arm at sentry.org
Mon Aug 6 07:00:30 UTC 2018
John Kennedy wrote on 08/06/18 14:21:
> I'm trying to boot using only USB (no SD card). Seems like it should be easy.
>
> Booted up via my SD card with the USB drive attached, I can see and use it easily:
>
> # usbconfig
> ugen0.1: <DWCOTG OTG Root HUB> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
> ugen0.2: <vendor 0x0424 product 0x2514> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA)
> ugen0.3: <vendor 0x0424 product 0x2514> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA)
> ugen0.4: <vendor 0x0424 product 0x7800> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA)
> ugen0.5: <Logitech USB Receiver> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (98mA)
> --> ugen0.6: <Samsung Portable SSD T5> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
>
> The RPI doesn't get the green boot-light or the rainbow screen. So low-level
> stuff is obviously AWOL. I've put program_usb_boot_mode=1 into the config.txt,
> but can't verify it with vcgencmd since that won't compile on arm64 (I haven't
> tried burning raspbian and seeing if they have a working port to verify).
I didn't need to add anything to the config.txt file for my RPi2 to
attempt to boot from USB instead of the micro-SD card.
The SD card kept being assigned as disk2, with the USB memory keys
taking up disk0 and disk1, and then the system would unsuccessfully try
booting from disk0 and finding no kernel file as that happened to be
the /usr file system.
After much google-fu, the workaround I found was to halt the boot at the
uboot loader prompt (you have two seconds) and then:
setenv loaderdev disk2
saveenv
boot
The above creates a persistent uboot.env file, so no manual intervention
is needed again (unless the number of USB memory keys changes). This
might help in your situation with appropriate disk number tweak.
> As a real disk, it's power light comes up delayed. It seems like it should be
> lit before 5-seconds, but I don't know if that is enough for the RPI to try
> and enumerate it. Currently I'm trying to divide and conquer by putting the
> MSDOS boot partition on an SD card and then boot USB off of that, or at least
> try to figure out what is wrong from there.
I recall adding a 15 second delay (kern.cam.boot_delay="15000") in
bootloader.conf.local to avoid USB memory device enumeration issues.
> So my USB console cable finally arrived and I plugged it in:
>
> kernel: ugen0.4: <Silicon Labs CP2102 USB to UART Bridge Controller> at usbus0
> kernel: uslcom0 on uhub0
> kernel: uslcom0: <CP2102 USB to UART Bridge Controller> on usbus0
>
> Connecting via this from my amd64 FreeBSD box:
>
> screen /dev/cuaU0 115200
>
> It's dropping some characters, so hopefully I won't add typos:
[chomp]
> If anybody has some suggestions on how to get that cable to not murder the
> serial output (from the RPI), that would be helpful. The input (to RPI) seems
> totally fine looking at the HDMI console output, but what comes back is very
> spotty (lots of dropped characters, don't see mangling). In any case:
[chomp]
> [cat /boot/msdos/config.txt]
> arm_control=0x200
> dtparam=audio=on,i2c_arm=on,spi=on
> dtoverlay=mmc
> dtoverlay=pwm
> dtoverlay=pi3-disable-bt
> device_tree_address=0x4000
> kernel=u-boot.bin
>
> program_usb_boot_mode=1
> enable_uart=1
Did you add the enable_uart=1 too? I made no change to config.txt to get
console output (and I am also using a Silicon Labs CP2102 USB to UART
Bridge Controller on my RPi3B+). I had no dropped characters, using
screen on macOS.
[Sorry I can't check - I'm currently interstate for a few more days]
More information about the freebsd-arm
mailing list