optiboot_x: How are different entry conditions specified for the precompiled hex? #971
-
Looking into customizing the optiboot_x loader for a project and I noticed that the megaTinyCore/megaavr/bootloaders/optiboot_x/optiboot_x.c Lines 376 to 394 in 672e35e Is there a reason why we stopped using
(By the way, I think there is no need to have separate versions of the megaTinyCore/megaavr/bootloaders/optiboot_x/optiboot_x.c Lines 371 to 375 in 672e35e Does that mean we don't actually have the 7 possible combinations of entry conditions as mentioned by the README? In fact, if the Makefile is used, there's only one option being built (number 4 above), since neither |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 4 replies
-
Where the hell did that version of the file come from? That doesn't match the file I build the bootloader binaries from. And assume direct entry safe is insanity. You can't EVER assume that! It is in fact guaranteed that the bootloader will never function correctly upon direct entry from a sketch compiled for megaTinyCore without more code in the app to make that jump safe than a software reset takes (which is 8-10 bytes, depending on whether the compiler happens to have any registers it knows can only contain a 1 that it can reuse). Thus, nobody who would be capable of making their app safely perform direct entry would ever attempt it, because they could simply perform a software reset, use less flash, expose themselves to fewer hazards). Just off the top of my head, the direct jump itself is 4 bytes (jmp) plus 10 bytes to reset the prescaler for the system clock to the power on setting (we do not support operating at the chips' default power-on F_CPU of 2.67 or 3.33 MHz - 16/6 or 20/6) is the bare minimum; if the same UART has been used, any register not written by the bootloader at initialization which will have observable effects on operation must be reset as well. If either of the pins of the UART were inverted, or used to trigger an interrupt, or had input disabled, that must be reset as well. And so on. The software reset command provides an incredibly economical way to reset registers to power on values Especially with the actual code (not that ancient version), which detects if no flags are set, and would fire software reset anyway if there aren't any set. Otherwise, if it's an entry condition it starts the bootloader, else it clears the reset flags, stashes their old value in GPIOR. (the flags are not cleared until the jump to the app - that way we preserve the cause of the reset that entered the bootloader when an entry condition is met. The ENTRY_CONDITION_REQUIRE absolutely is used to build the binaries. i don't know how the file was not updated when I changed it in the build location, but apparently I didn't copy it back to the repo (remember, I don't know shit about how to set up working build environments, so I use scripts that assume I've copied the optiboot_x directory into (arduino 1.0.6 install location)/hardware/arduino/avr/bootloaders, and that the toolchain package that came with 1.0.6 has been updated to the one distributed with the core (because that's exactly what I do) - thus there are two distinct copies of the contents of the optiboot_x directory, one of them in github and my local repo, and a second one in the build directory, which have to be manually kept in sync |
Beta Was this translation helpful? Give feedback.
-
THE VERSION YOU NEED WAS NEVER COMMITTED TO GITHUB. There is no copy of it anywhere in the world other than my computer (and since, my earlier reply, the google drive backup, because it's been copied back to repo folder but it is not ready to commit yet, some of the comments are fucked up and itdoesn't pass codespell. The files were dated 12/31/22 and 1/1/23. The ENTRYCOND_REQUIRE was done AFTER ALL OF THOSE VERSIONS. I am currently in the process of tidying up the file and running spellcheck before checking it in. What are you planning to modify? There are a whole bunch of hazards that are easy to get caught by if you are used to classic AVRs and/or sane design decisions |
Beta Was this translation helpful? Give feedback.
-
Changes checked in. Can anyone test some of the bootloaders and make sure I didn't break anything? I see no red flags in the assembly listings, except that almost every byte is different indicating that I did something that caused the compiler to make a decision with wide-ranging consequences for the form of the emitted hex file boot_opt.h removed because it was unused, because boot.h was unused, because boot.h only applies to classic AVRs |
Beta Was this translation helpful? Give feedback.
Changes checked in. Can anyone test some of the bootloaders and make sure I didn't break anything? I see no red flags in the assembly listings, except that almost every byte is different indicating that I did something that caused the compiler to make a decision with wide-ranging consequences for the form of the emitted hex file
boot_opt.h removed because it was unused, because boot.h was unused, because boot.h only applies to classic AVRs