[packetlost]

The SDCard is not listed as a supported boot target, though you could almost certainly build a small bootloader that's stored in the qSPI flash and then load the rest of your code into RAM from there.

I'm not the most familiar with it, but I believe all hardware init (setting clock source, initialing USB, GPIO, etc.) is handled by the flashable firmware of which there are open source SDKs for.

[sylware]

Then, it means I would need to flash my keyboard firmware, or a SDcard loader firmware.

I guess this is a "standard" flashing protocol over usb, enabled by the right button pressed at power on (plugging the USB cable). Would I need to including the flashing support code into my keyboard/SDcard loader firmware or is it handled separately by a different piece of hardware?

Any specs on the format of the firmware image, to know which core will run the real boot code?

Erk... soooo many questions in the wrong news :(

[packetlost]

I'm not sure you could flash over USB either without significant work. There's no UART <-> USB device on the Ox64, so you need to use an external one connected to some GPIO pins. You could maybe build a DFU mode yourself, but I'm somewhat skeptical it would work (though it might be possible, there's 3 cores in the thing). Despite there being not one, but TWO USB ports on the Ox64, neither are used for flashing. The micro USB type B connector is only used for power delivery and the USB-c is primarily intended for being a host device, ie. for plugging in a camera module.

Edit: to clarify, there's a bug in the bootrom that prevents the initialization of the USB device. Newer revisions of the Ox64 may fix this.

[sylware]

Then:

- how do you run anything with that board if you cannot flash anything, I don't understand?

- I cannot use it as usb keyboard controller because of a bootrom bug? (power/data via usb-c)

Now I am confused.

[packetlost]

You can flash it, but you need to use GPIO pins and UART to do so.

The bootrom bug only prevents you from flashing via the on-board USB-c port. You can use a separate USB <-> UART device plugged into GPIO pins to boot/flash.

[sylware]

How such a massive bug could slip thru?

This is weird.

If resellers with stocks know that, they will send back the boards and ask for a refund.

[packetlost]

I'm told it's a bug in the chip from the upstream supplier (BL808 by Bouffalo Lab), so there's not much they can do. IMO it's not a huge deal, and like I said, you can both flash with UART over GPIO pins or implement a bootloader yourself

[imtringued]

You just flash it with your hardware programmer like the rest of the industry. It is not a massive bug at all.