fastboot for fusee: a workflow improvement #1209
Conversation
…rgets to get rebuild when they did not need to be rebuilt
The SDMMC driver is currently the only user of the AHB redirect, but the upcoming XUSB driver will also need to use the AHB redirect, potentially at the same time. This ensures that the AHB redirect will not be disabled unexpectedly if one driver is deinitialized without the other.
Add dram section to link script, and also creates a framebuffer section so we can start to use the link script as a single source of truth for how fusee-primary uses dram.
BCT0 is now only parsed once into a struct this is shared between log level logic and stage2 logic. This has been done in anticipation of needing config items for fastboot gadget.
This code is essentially a giant unrolled loop over an array of register copies. I've manually re-rolled the loop so that rather than emitting code for each parameter to read it, perform bit arithmetic on it, and write it, there is instead a static list of parameters which can be encoded using much less memory.
|
Will review in more detail over the next few days. Few things off the top of my head before then:
I guess the other big thing I have to ask is this:
Basically no big features are getting in of any kind before mariko is merged/in, because of the risks of the mariko stuff becoming broken/hard to merge especially with possible sysupdates in the near future. |
|
Ugh @ approval for specific commit approving whole thing. I'll undo that, why is GitHub's UI such ass |
The
Ok.
They only really appear here, where I have to unpack the boot image format that
Easy. Change the register access patterns to whatever libexosphere has settled on, and the rest of it I've tried to keep pretty close to the rest of Atmosphere's C++ style already. |
|
Documenting some conversation with SciresM and some ideas I had:
The intent behind paving over the entire SD card in a single image and having In practice, the overhead that comes from ensuring these guarantees may not be worth it. |
|
FWIW, I think the the hot key should be volume down. People use volume up to enter RCM. Many have dongles for convenience, causing the boot process to start almost immediately after power on, so using volume up could send people into fastboot when it was not intended (not letting go of volume up fast enough). |
It checks for a not-pressed -> pressed transition instead of just whether the button is pressed. ^^ |
|
It would be great not only have fastboot but also search on start for update.zip in root folder of sdcard and auto apply it. |
@SciresM solution to the live updating from userland problem? ^ |
|
I don't want on-device updating in the main atmosphere repo's codebase, still. |
This PR adds a USB gadget to fusee-primary to allow users to download files to the SD card and proceed to boot in a way that is robust and scriptable (compare to USB mass storage; it is hard to script to wait for device, then proceed with filesystem mount/copy/unmount, etc.). The USB device stack is based on the XUSB controller, so it should work on Mariko in theory.
It is intended to improve Atmosphere development workflow. Instead of ejecting SD card and copying files over every time you make a change, you can instead set your configuration file to enable fastboot. Next time you boot, you can run
make flashand the device will wait until your build completes and flashes a fresh filesystem onto the SD card, and then it can proceed to boot as normal.Isn't fastboot an Android thing? This isn't Android! What's it doing in Atmosphere?!
It's a simple USB protocol that does what we need it to do, and it comes with a client for all three major desktop operating systems. This means we get to avoid writing, debugging, maintaining, and teaching people how to install our USB code for three different platforms. Plus, fastboot has seen some limited use outside of Android in e.g. Tizen. (admittedly, not all that different from Android)
That being said, the client-side tool does have a lot of Android-isms in it. It would be great to be able to extract a zip file over the filesystem with
fastboot update, but the tool tries to verify that the zip file is a proper Android update. Thefastboot bootcommand tries to create a "boot image", which is supposed to include kernel and ramdisk and other such things. It's not a great match, but it works and imo beats maintaining desktop USB code.Isn't this bloat in fusee-primary?
Yes, but I wanted to be able to overwrite and reload fusee-secondary in place, which I wouldn't have been able to do if I implemented this in fusee-secondary. If we really want it in fusee-secondary, that can be arranged.
Usage
There is a new BCT configuration section:
The
force_enablekey will cause fusee-primary to always enter Fastboot. Thebutton_timeout_mskey will offer a period of time for the user to press the volume up button to enter fastboot on each boot. If it is set to zero (the default), it will not prompt to enter fastboot.From there, it enables the USB gadget and it can be accessed from the host. These are the supported fastboot usages:
I've also added a Makefile rule (
make flash) to prepare and flash an image directly to the device. It uses GNU mtools to create a 64 MiB FAT filesystem in userspace. This size downloads pretty quickly and is enough for a base atmosphere install. It will also include any files under theextras/directory, which can be used to override the default config templates or symlink in custom sysmodules.There is currently some issue with Mac hosts where it will hang after one fastboot command. I don't have consistent enough access to a Mac device to debug this myself.
Review
This PR is meant to be reviewed one commit at a time. There are a lot of small changes to fusee-primary, before the main commit that includes the bulk of the USB stack and gadget. After that are various commits adding more features, which should each be able to be easily removed.
Apologies to hexkyz for the conflicts if this gets merged before the mariko_fusee branch.