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

[BUG] MK3.5 bootloader does not work. #146

Closed
vintagepc opened this issue Mar 3, 2024 · 5 comments · Fixed by #149
Closed

[BUG] MK3.5 bootloader does not work. #146

vintagepc opened this issue Mar 3, 2024 · 5 comments · Fixed by #149
Labels
bug Something isn't working MK3.5

Comments

@vintagepc
Copy link
Owner

Per title, trying to run the MK3.5 v5.2.1 firmware using the .bbf file fails to run; the bootloader is not functional in the sim .

@vintagepc vintagepc added bug Something isn't working MK3.5 labels Mar 3, 2024
@BlueFyre
Copy link

BlueFyre commented Mar 3, 2024

Per #145:

Unfortunately that means even if you do get past the GPIO error, you'd need to have a locally built "noboot" ELF or BIN file built from the Prusa repository rather than a BBF at this time. Since the bootloader is closed source, I don't know when or if I'll be able to fix that. Sorry.

I imagine that's different than just the regular bootloader from Prusa? Does that also apply to the MK4?

@vintagepc
Copy link
Owner Author

The file you linked is the one I retrieved for my test with the official 5.2.1 BBF and resulted in this issue.

As far as I know the MK4 bootloader and .bbf combo works fine; the 3.5 is a relative newcomer here and so I'm not sure what is different yet. Based on the early firmware examinations when I added the 3.5 support (most of my work here is based on reverse-engineering the firmware sources if schematics are not available) it's not all that different from the Mk4 board - it's actually defined in the mk4 machine here just like the 3.9.

That said, there are no entries or pictures of this board up in the e-shop so I can't say for certain how "different" it is or what would cause this, and the e-shop doesn't list the xbuddy board as compatible with the 3.5, so something must be different.

The "noboot" firmware is a binary that doesn't require the bootloader (nor expect it) and is located in a different region in the printer flash space so it can be booted directly. I did confirm I was able to boot and start that (though it does complain the hotend fan isn't spinning, so there may be more changes I need to make.)

@vintagepc
Copy link
Owner Author

image

Figured it out, there was a stupid ordering bug with how the GPIO pins were being initialized, that led to the display data being bad and the boot not able to proceed.

@BlueFyre
Copy link

BlueFyre commented Mar 3, 2024

Awesome! I do have both MK3.5 and MK4. It's the same board as far as I can tell. From when I was looking through the code the only difference is the detection based on the presence of the loveboard (among other checks) and then they do now have different firmware files but you can be shipped the wrong firmware on it (which then would complain and tell you to flash the right one)

@vintagepc
Copy link
Owner Author

Yep, if there is no loveboard there's some additional detection that happens and this was bugged.

Just need to fix the unit tests I broke now before I can merge that 😁

vintagepc added a commit that referenced this issue Mar 3, 2024
* Fix bug in GPIO initialization sequence. Fixes #146

* Adjust failing unit tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working MK3.5
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants