u-boot fastboot

[Pal Ivancsics]

After initially boot in then writing/porting a zircon ethernet (MAC/PHY) driver for Raspberry Pi 4, as a next step I'd like to automate (mkzedboot) the flashing/paving process for this board.

Since RPI4 has no a full featured UEFI layer yet, supporting you Gigaboot bootloader, I've been following the "Google way" and build a modified/customized u-boot bootloader as you did in case of vim2 an vim3 boards. I'm ready with this u-boot "extension" and able to boot zbi images via u-boot bootloader then launch them on RPI4 board . In the future I don't need my original ...zbi.shim images any more.

BUT when I start fastboot on RPI4 and call 'fx flash --pave' on host the only way to connect and start fastboot communication if I specify the IP address of my RPI4  device: e.g.: 'fx flash -s udp:192.168.x.x --pave'.

According to my information about fastboot protocol its bootloader side is only a server process waiting on 5554 udp port for requests. But 'fx help flash' on the host side says that "-s" option "only necessary if multiple devices in fastboot mode".

Unfortunately 'fx flash' without specific target IP address is unable to detect my board in a waiting fastboot state. U-boot has no periodic advertisements protocol like netsvc's NB_ADVERT_PORT in zedboot.

If I want to make a headless automatic flashing process, plugging an USB stick containing a proper image and an empty SD card into RPI4 then finally getting a properly flashed, partitioned, bootable SD card, I need that 'fx flash' could connect fastboot server running on the board/device automatically.

So, my question: how can you manage this scenario in your u-boot customisation in case of vim2, vim3 or other boards without UEFI compliant bootloader?

thank you for your support,

gobftald

[Suraj Malhotra]

+David Pursell +Anirudh Mathukumilli 

For vim2 and vim3 I believe we only support fastboot over direct usb connection, where the device is in a usb peripheral mode. For x86, where gigaboot is used, the device typically doesn't have the ability to act as a usb peripheral which is why we took the network route for fastboot.

Hopefully one of the folks I added can comment on how auto discovery is supposed to work when utilizing fastboot over the network.

--
All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
To unsubscribe from this group and stop receiving emails from it, send an email to connectivity-d...@fuchsia.dev.

[gobftald]

Woow, thank you for your quick answer.
You should be right, I’ve re-checked the docs on fuchsia.dev and found that it was mentioned in VIM2’s Setup section that: "USB C port: Connect to host. Provides power and fastboot”.

Unfortunately my development server with fuchsia repository and ‘compiling power' is far from my desk where RPI4 sitting. OK, initial flashing is not a frequent job, but would be much more convenient without this very physical connection of USB.

On the other hand u-boot has only USB mass storage driver for RPI4 board. So if I ever want to implement this automatic fastbooting feature I prefer to do it on u-boot's network side rather than developping a missing USB layer.

I really appreciate your feedback.
gobftald

[gobftald]

Hi David,

1 Yes, 'fx flash -s udp:192.168.x.x’ is successfully connecting to my customized u-boot running on RPI4. 

I simple followed your (Google) customization of u-boot for vim2, vim3 and imx8mevk boards I found in https://third-party-mirror.googlesource.com/u-boot/.

Since those repos are from a rather old (2015) fork from denx’ u-boot and does not contain current RPI4 drivers I prefer to branch from the current u-boot version. This way I’ve saved the development/modification time of ethernet, usb and mmc drivers on the u-boot side. Although these drivers are much simpler than e.g my RPI4 zircon ethernet driver but I prefer to spend my time playing with zircon rather than u-boot programming.

So following your old vim2/vim3 u-boot implementation I’ve been bulding a new bootloader based on the actual/official u-boot version for booting fuchsia into RPI4. Therefore I can drop my original zbi.shim layers used until now for RPI4 driver developments. This was the point when I setup and tried u-boot's fastboot server, then built an USB image to atomate the initial SD flashing/paving procedure for RPI4.

2 thank you for this ANDROID_SERIAL information, but my problem on the board/device side.

My RPI4 USB boot image contains a script picked by my new bootloader which launches DHCP requests, get IP address, then starts "fastboot udp” waiting for ‘fx flash’ requests from the host. All these without any user interaction. I can read the IP address received and listened on, but I can see it only on my serial console of RPI4. I’ve also put a simlpe menu into my u-boot script, so I can even configure a static IP address as well. But my orignal plan was to offer a fully automated headless USB image which does all these initial SD flashing job in RPI4 without user input or configuration. But as it turned out without learning and specifying the IP address on fastboot host side it is impossible with current fastboot udp protocol. YET!

3 I’m rather familiar with your Gigaboot source codes (its netboot and other functions as well), since orignally I planned to use it with current UEFI implementation of RPI4. But it turned out that RPI4 UEFI layers are in very early phase so currently it does not offer all the functions Gigaboot needs. It is why I went to build custom bootlader from u-boot.

3b I’m also familiar with your ‘bringup’ netsvc and netboot stuff, since it was the ‘runtime environment' where I tested my RPI4 zircon ethernet driver. So I learned a lot about those basic advertisement protocols and other dicovery mechamisms supporting your devshell tools. Naturally these type of 'zircon handshakes’ are not in u-boot network layer or its fastboot server.

Maybe, as an extended fastboot feature, some simple UDP broadcasts from host side fastboot can ‘emulate’ Gigaboot's fastboot behavior. It can be easily implemented in these old-fashioned/customized bootladers as well. I know that this is not a network friendly solution, so I will thinking further about this.

I’m very grateful for your help.

gobftald

On Feb 25, 2021, at 5:10 PM, David Pursell <dpur...@google.com> wrote:

Hey there, great questions thanks for reaching out!

Suraj is correct that in our u-boot we just use direct USB connections for fastboot, but that's probably not an option on RPi (at least it wasn't back on the 2 or 3) so we'll have to do something more similar to Gigaboot.

There are a few things we could try here, let me know if I'm misunderstanding or this doesn't make sense:

1. The `fx flash` docs are inaccurate here, you are correct that `fastboot` always requires -s to connect to UDP/TCP targets. So calling `fx flash -s udp:192.168.x.x` would be an appropriate use, if that works for you. But would require a stable device IP address, which I'm not sure works for you or not.

2. `fastboot` also supports an ANDROID_SERIAL environment variable, which will basically treat the value as if you always passed `-s`, e.g. something like:
  $ export ANDROID_SERIAL=udp:192.168.x.x
  $ fx flash    <- no serial needed now, it will automatically use the value above
Same caveat as (1), requires a known and stable device IP.

3. Gigaboot currently uses the netboot protocol (same protocol Zedboot uses) to advertise its presence over UDP - you could do the same here, and `fx flash` would automatically detect the device for you (see //src/firmware/gigaboot/src/netboot.c for reference). However, I am currently playing around with possibly changing this to use a more standard mDNS protocol instead, so be warned that if you do go with this approach it may stop working at some point in the future if we transition to mDNS and drop `fx flash` netboot support. However, as far as I know this is the only approach that will work right now and doesn't require a stable fixed IP.

Personally, I would probably recommend avoiding (3), it seems like quite a bit of work for something that might break in the not-too-distant future. Maybe start with (1) or (2) for now if possible, and keep an eye on //src/firmware/gigaboot/ so that once the mDNS code starts landing you can use it as a reference to add it to your u-boot implementation as well.

Hope that helps,
David

[David Pursell]

Hey there, great questions thanks for reaching out!

Suraj is correct that in our u-boot we just use direct USB connections for fastboot, but that's probably not an option on RPi (at least it wasn't back on the 2 or 3) so we'll have to do something more similar to Gigaboot.

There are a few things we could try here, let me know if I'm misunderstanding or this doesn't make sense:

1. The `fx flash` docs are inaccurate here, you are correct that `fastboot` always requires -s to connect to UDP/TCP targets. So calling `fx flash -s udp:192.168.x.x` would be an appropriate use, if that works for you. But would require a stable device IP address, which I'm not sure works for you or not.

2. `fastboot` also supports an ANDROID_SERIAL environment variable, which will basically treat the value as if you always passed `-s`, e.g. something like:

  $ export ANDROID_SERIAL=udp:192.168.x.x

  $ fx flash    <- no serial needed now, it will automatically use the value above

Same caveat as (1), requires a known and stable device IP.

3. Gigaboot currently uses the netboot protocol (same protocol Zedboot uses) to advertise its presence over UDP - you could do the same here, and `fx flash` would automatically detect the device for you (see //src/firmware/gigaboot/src/netboot.c for reference). However, I am currently playing around with possibly changing this to use a more standard mDNS protocol instead, so be warned that if you do go with this approach it may stop working at some point in the future if we transition to mDNS and drop `fx flash` netboot support. However, as far as I know this is the only approach that will work right now and doesn't require a stable fixed IP.

Personally, I would probably recommend avoiding (3), it seems like quite a bit of work for something that might break in the not-too-distant future. Maybe start with (1) or (2) for now if possible, and keep an eye on //src/firmware/gigaboot/ so that once the mDNS code starts landing you can use it as a reference to add it to your u-boot implementation as well.

Hope that helps,

David

On Thu, Feb 25, 2021 at 7:50 AM Suraj Malhotra <surajm...@google.com> wrote:

[David Pursell]

On Thu, Feb 25, 2021 at 8:10 AM David Pursell <dpur...@google.com> wrote:

Hey there, great questions thanks for reaching out!

Suraj is correct that in our u-boot we just use direct USB connections for fastboot, but that's probably not an option on RPi (at least it wasn't back on the 2 or 3) so we'll have to do something more similar to Gigaboot.

There are a few things we could try here, let me know if I'm misunderstanding or this doesn't make sense:

1. The `fx flash` docs are inaccurate here, you are correct that `fastboot` always requires -s to connect to UDP/TCP targets. So calling `fx flash -s udp:192.168.x.x` would be an appropriate use, if that works for you. But would require a stable device IP address, which I'm not sure works for you or not.

2. `fastboot` also supports an ANDROID_SERIAL environment variable, which will basically treat the value as if you always passed `-s`, e.g. something like:

  $ export ANDROID_SERIAL=udp:192.168.x.x

  $ fx flash    <- no serial needed now, it will automatically use the value above

Same caveat as (1), requires a known and stable device IP.

Oops, I lied, `fx flash` tries to be a little too helpful and won't attempt to even call `fastboot` if it can't detect a device unless you provide `-s`. So this won't actually work as-written, sorry.