JianyuWang0623 commented on PR #3760:
URL: https://github.com/apache/nuttx-apps/pull/3760#issuecomment-5452916540
## Testing
Verified the multi-transport fastboot daemon end-to-end on real hardware for
both **USB** and **TCP** transports. For each transport: `getvar` control
commands, `download` (bulk data), `flash`, and a board-side byte-level
read-back of the flashed data.
**Board:** lckfb-szpi-esp32s3 (ESP32-S3, chip MAC `a0:85:e3:f4:43:30`)
**Flash target:** a 64 KB RAM disk created on the board (`mkrd -m 1 -s 512
128` -> `/dev/ram1`), since `fastboot flash <name>` maps to
`open("/dev/<name>", O_RDWR)`.
**Verification pattern:** byte `(i*7+3) & 0xff`, first 16 bytes `03 0a 11 18
1f 26 2d 34 3b 42 49 50 57 5e 65 6c`.
| Transport | defconfig | getvar | download | flash
| read-back | Result |
| --------- | --------------------------------- | :------: | :--------: |
:-----: | :----------: | :--------: |
| USB | `lckfb-szpi-esp32s3:fastboot_usb` | OK | OK | OK
| byte-match | **PASS** |
| TCP | `lckfb-szpi-esp32s3:fastboot_tcp` | OK | OK | OK
| byte-match | **PASS** |
### USB transport
fastbootd is auto-started by init.rc (PID 5 in `ps`); USB enumerates as
`18d1:4e11`, `fastboot devices` shows `1234 fastboot`.
```
$ sudo fastboot getvar product -> product: NuttX
$ sudo fastboot getvar version -> version: 13.0.1-RC0
$ sudo fastboot getvar max-download-size -> max-download-size: 40960
$ sudo fastboot flash ram1 fb_test.bin # 4 KB
Sending 'ram1' (4 KB) OKAY [ 0.005s]
Writing 'ram1' OKAY [ 0.001s]
$ sudo fastboot flash ram1 fb_big.bin # 32 KB
Sending 'ram1' (32 KB) OKAY [ 0.242s]
Writing 'ram1' OKAY [ 0.198s]
$ sudo fastboot erase ram1
Erasing 'ram1' OKAY
```
Board-side read-back (byte-exact):
```
nsh> hexdump /dev/ram1 count=16 # after 4 KB flash
0000: 03 0a 11 18 1f 26 2d 34 3b 42 49 50 57 5e 65 6c # matches host image
nsh> hexdump /dev/ram1 skip=32512 count=32 # after 32 KB flash, tail
@0x7f00
7f00: 05 12 1f 2c 39 46 53 60 6d 7a 87 94 a1 ae bb c8 # full 32 KB landed
correctly
nsh> hexdump /dev/ram1 count=32 # after erase
0000: ff ff ff ff ff ff ff ff ... # erased to 0xff
```
download -> flash -> erase -> re-flash cycle all pass; fastbootd
(PID 5) stays alive throughout.
### TCP transport
Board joins a WiFi AP and gets `192.168.137.144` (fastbootd listens on
`0.0.0.0:5554`); host uses `fastboot 36.0.0` on the same subnet.
```
> fastboot -s tcp:192.168.137.144:5554 getvar product -> product:
NuttX
> fastboot -s tcp:192.168.137.144:5554 getvar version -> version:
13.0.1-RC0
> fastboot -s tcp:192.168.137.144:5554 getvar max-download-size ->
max-download-size: 40960
> fastboot -s tcp:192.168.137.144:5554 flash ram1 ./fb_net.bin # 4 KB
Sending 'ram1' (4 KB) OKAY [ 0.087s]
Writing 'ram1' OKAY [ 0.091s]
Finished. Total time: 0.312s
```
Board-side read-back after flash matches the host `(i*7+3)` pattern
byte-for-byte.
> Note: for the TCP defconfig, the RAM-disk flash target also requires
`CONFIG_BCH=y` (opening a block device via `open()` needs BCH in NuttX; without
it `open("/dev/ram1")` returns `-ENXIO` and flash fails with `Flash open
failure`). This matches what `fastboot_usb` already pulls in.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
