Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[v0.1] Simplify bootloader entry #2

Open
whitequark opened this issue Jan 21, 2021 · 5 comments
Open

[v0.1] Simplify bootloader entry #2

whitequark opened this issue Jan 21, 2021 · 5 comments

Comments

@whitequark
Copy link

The ID pin based bootloader entry scheme is highly inconvenient and requires using an illegal USB cable. Most end users will probably only need to enter the ROM bootloader once, so a test point is fine. I can see developers entering the ROM bootloader more often, so a button in parallel with a test point (which could be DNP) would be quite nice, especially on a high density board like this.

@vpalatin
Copy link

vpalatin commented Feb 9, 2021

I find the trick highly convenient, but whatever ;-)
if you are planning to re-use part of the original firmware, it does include a 'dfu' command over the USB-serial console to switch it back to bootloader mode, you don't need special hardware most of the time:
https://chromium.googlesource.com/chromiumos/platform/ec/+/7a16e40adb108eaedb3a46619fcdf99cdd9a1b9d

@whitequark
Copy link
Author

whitequark commented Feb 9, 2021

if you are planning to re-use part of the original firmware, it does include a 'dfu' command over the USB-serial console to switch it back to bootloader mode

Yeah and the command is broken... Instead of all this error-prone complex stuff just use a button.

@whitequark
Copy link
Author

I think the command might actually be broken because of #1? I don't know how exactly it works, but the symptoms are that I can enter DFU mode but trying to flash anything instantly resets the device. I haven't tried it with the workaround for #1 yet.

@whitequark
Copy link
Author

Sorry, I understand I probably sound quite hostile, that's not my intention. I've just had a lot of trouble with both USB PD and USB PD debuggers and after a few months of it that gets frustrating.

@dnschneid
Copy link

Buttons are nice as long as you can access them when the unit is enclosed in its enclosure and including it doesn't cause the enclosure to be larger than absolutely necessary (since any increase in case size results in more torque on the Type-C plug).

I think the USB-ID trick is especially convenient for us since we've been using the trick across multiple internal boards for years, so our devs tend to have them on-hand. Never had an issue with it (although it's best to plug in the micro-B side before the usb-A side).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants