Optiboot without EEPROM support returns flash on EEPROM request #1227
Labels
wontfix
This will not be worked on
Comments
|
Even if I change the bootloader FW to @MCUdude's MiniCore and specified the right chip (ATmega328PB), then the first behavior is gone but the second behavior is still there. |
|
Same for an Nano Clone with ATmega328P with the original 4.4 Optiboot bootloader FW. |
|
Now I actually think the second issue is a bug for |
Correct. The bootloader firmware actually does not read the signature memory of the part. The bootloader returns hard-coded signature bytes of the part for which it was compiled. This is normal bootloader practice to save space. If the user burns an ATmega328P bootloader onto an ATmega328PB chip then AVRDUDE will see an m328p signature.
This is a well-known optiboot bug. It returns flash for EEPROM if optiboot has been compiled to not handle EEPROM. This bug has been around for a long time (and possibly still is today but defo was 2016 when I last looked closely at optiboot). It is not actually AVRDUDE's job to invent workarounds for all the bugs in bootloaders or programmer FW (though I have provided a fair deal of workarounds in the past). In this specific case, knowing about this bug,
Now, @mcuee, your example is one where the user tells AVRDUDE Soooooo, can you guess what my opinion is? Ditch optiboot. Never look back. Use urboot. Be happy ever after. As there is a good alternative in this case I believe we should not spend our energy dancing around optiboot bugs. |
|
Haha, I support urboot. We need to get avrdude 7.1 released to enable Hopefully @MCUdude can start to distribute urboot early next year to make urboot more popular. |
Yes, this is the plan. However, I need to make sure that my cores will continue to support legacy optiboot bootloaders while using -c urclock, so users aren't forced to replace their bootloaders, even though it's highly recommended. It's also important that potential bugs found by mass-testing urboot gets fixed quickly. |
You are welcome to add to the hash table those legacy optiboot bootloaders that were shipped with your boards and/or frequently downloaded from your github core; I am happy to help you compute the hashes if you struggle with that. And our legacy bootloaders will continue to work with
That is my intention... |
Is this something you could help me automate? The optiboot flash repo is pretty easy for a script to run through. From what I know, these are the most popular bootloaders: 20 MHz, 115200 baud For UART 0, 1, 2, and 3 where present. The only parts that should not be added are the AT90USB* parts, as I provide no Arduino core for them. |
|
The bootloader-hashes script finds all bootloaders recursively in the current directory and outputs the hash lines that can be cut and paste into the table. Sounds like the only thing you'd need to do is grep out the ones you are interested in. BTW, I think the bootloaders for 16 MHz, 115200 baud are probably identical to the ones 8 MHz, 57600 baud (so will have the same hash) |
|
@stefanrueger this is the list of bootloader combinations I think are the most common. Optiboot flash hash |
Hash function clashes are vvv unlikely (1/4bn). The different parts will have the same signature, and therefore the bootloaders will be identical. Here one example: My bet is that the bootloaders for these three parts are identical, and in particular that the signatures are the same. Your list has 480 different hashes. (And I very much predict your 542-strong bootloader list has only 480 unique ones.) You get the 57 hashes that occur multiple times by It makes sense to keep only one representative of bootoaders that are identical (though there is no harm in having identical hashes in the list: the algorithm copes). |
|
The more important question is: which of these bootloaders have EEPROM support and which don't. The script uses the heuristic(!) that all bootloaders that have bigboot or BIGBOOT in its names cope with EEPROM (ie, get a 1 in the second column). |
I realize now that I should have built these bootloaders for ATmega165A and ATmega169A instead of the non-A models. There seems to be a bug in the avr-libc version I used where the non-A parts incorrectly has the same signature values in their io.h file. I should fix this, re-build the bootloader and update the hash table
All bootloaders that have BIGBOOT in their name support EEPROM read/write, so the script is correct. |
|
| I should fix this, re-build the bootloader and update the hash table We had the discussion before: signatures are no good indicator for the part. So, this cannot be fixed! Unless you switch to urboot that is. 😀 And for good measure, signatures can be different between avr-libc and avrdude. |
|
@MCUdude I've been wondering why your (8 MHz, 57600 baud) bootloaders are different from (16 MHz, 115200 baud) bootloaders, but I now suspect that optiboot flashes the LED for a while with a certain frequency - and that therefore the code will be different for these two bootloader versions. For the comms alone the code would be identical. |
stefanrueger
changed the title
stefanrueger
added
wontfix
|
I agree with change the lable to We can even create a FAQ Wiki page to include information like this one. |
I can confirm the issue is still there with latest optiboot git. I consider this as a serious bug of optiboot. The only saving grace is that writing to EEPROM will fail. |
|
@WestfW @MCUdude and @SpenceKonde |
Signatures aren't the best, I agree. Atmel is to blame here for their inconsistency. However, in my case, uploading to an ATmega169A will fail, because the signature hardcoded into the device differs from the one in the bootloader. I'll ditch the non-A parts for now. I'm doing this because I want a last "known-good" MegaCore release before migrating everything to Urboot.
I wasn't aware of it, but since Arduino IDE doesn't support uploading directly to EEPROM, it has never really been an issue. If I'm going to switch to Urboot later, I don't think I'll bother fixing it and compiling all new hex files. |
Ah, that explains why this issue was not noticed for so long. |
|
Optiboot/optiboot#357 raised against Optiboot. |
|
Re-open this issue so that we can continue which hash to be included in avrdude. |
|
@MCUdude: What is this "Urboot" thing"? |
|
@SpenceKonde I am thinking it may be useful for your ATTinyCore. In paticular, it may be the ultimate fix for the issue you raised against Optiboot.
But @stefanrueger and @MCUdude may be able to give you better perspectives about switching from Optiboot to urboot. |
|
@SpenceKonde It's a new bootloader written together with the Avrdude implementation of the protocol. It has all the bells and whistles you might dream of (Only for classic AVRs for now), and it occupies very little flash space. The virtual bootloaders are very interesting and are impossible to brick as long as you don't wipe or modify the flash contents with an ISP programmer. It lets you:
More about the Urboot bootloader here: https://github.com/stefanrueger/urboot/blob/b068ad0a16ac6e11690a72172c43ef689c8b8425/src/urboot.c#L1-L709 More about the Avrdude protocol implementation (Urclock) and what it supports here: The Avrdude docs (avrdude.texi and avrdude.1) also contain lots of information. Bottom line: It's an incredibly feature-rich and packed bootloader designed around a custom protocol specifically for bootloader usage. It's an impressive piece of software, and I'm planning to migrate all my Arduino cores to use Urboot and ditch Optiboot completely. And for ATtinyCore where lots of parts use virtual bootloaders, It's a no-brainer. |
|
From urboot.c: |
That has been addressed in PR #1226. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I think this may not be a real issue but kind of strange behavior of the optiboot bootloader firmware.
I jusgt bought a few Uno Clones with CH340. Apparently due to chip shortages the boards come with ATmega328PB and not ATmega328P. The 4.4 version of Optiboot Arduino FW is still used wihout any changes. It does not support EEPROM and it is meant for ATmega328P.
https://github.com/arduino/ArduinoCore-avr/blob/master/bootloaders/optiboot/optiboot_atmega328.hex
A few interesting behaviors here.
-c arduinoand-c urclockwill insist that the chip connected is ATmega328P and not ATmega328PB. I think this is because of the bootloader firmware and we can not do anything about it.-c arduinowill read Flash contents as EEPROM contents.-c urclockwill do that as well if I specify-xeepromrw.@stefanrueger
Do you think if No. 2 is a problem for avrdude? If yes what can we do here? Is it also the limitation of the paticular old optiboot firmware shipped by Arduino?
The text was updated successfully, but these errors were encountered: