-
Notifications
You must be signed in to change notification settings - Fork 145
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
Optiboot EEPROM support cannot be detected by avrdude #1224
Comments
I can reproduce the issue with a new Uno CH340 Clone.
|
Here is another bigboot hex file and I can reproduce the issue as well.
|
@stefanrueger |
I happend to keep the different exe files from PR #1171. I checked the commit history of PR #1171.
But apprently later version does not work and I did not test the bigboot EEPROM after the initial testing. This is at commit 20b86fb
|
Same problem for ATmega2560 Optiboot hex file from @MCUdude's MegaCore. And it is the same if I look into the commit history of PR #1171.
|
BTW, no issues with urboot EEPROM support.
|
Okay, this may not be a real problem. It seems to me that need to add
|
Do you think it is possible to detect the EEPROM R/W capability of optiboot hex file?
@WestfW has not answered the question so maybe it is not possible. In this case, maybe the best thing we can do now is to change the warning message to something like the following.
Affected lines: |
Thanks, @mcuee. Yes, Are the bootloaders you used common bootloaders (eg, distributed with commonly sold hardware)? If so, we might include their hash into our little table that caters for known bootloaders:
Pro tip: When you have more such bootloaders that are often used, why not run the |
I think PR#1226 is good to go.
|
I think these bootloaders are not distributed with commonly sold hardware. Therefore maybe it is not really necessary to include them in avrdude. I am more familiar with Microchip official tools and cheap boards from AliExpress/Taobao. Microchip does not seem to ship any official boards with Optiboot. Then the commonly available Uno/Nano clones are usually shipped with Arduino original bootloader without EEPROM support, or even non-working bootloaders in the case of Nano clones (ATmega328P or ATmega168P, many with 16MHz crystal and not 8MHz). The Mega2560 clones are usually shipped with the Wiring (stk500v2) bootloader. For my testing of Uno/Nano clones I tend to use @MCUdude's MiniCore optiboot bootloader which by default does not support EEPROM for the ATmega328P/ATmega168P. Then I will test with bigboot firmware as well since it supports EEPROM. One of the hex file is from @WestfW but I forgot where I got the second one. As for Mega2560 clones, I will usually use @MCUdude's MegaCore optiboot bootloader which by default does support EEPROM for ATmega2560. Then I've seen a few boards from AliExpress/Taobao (by a company called Muzi Technology) which uses @MCUdude's MightyCore for the ATmega32A/64A/128A. I got one such board using ATmega32A and it also does not support EEPROM by default. The board is dead now though. Then there are quite some ATtiny13/85/88/167based boards, they do not usually come with optiboot FW. Quite some of them (especially ATtiny88 based Nano style board) come with micronucleus bootloaders. As for the Leonardo/Micro clones with ATmega32U4, they usually ship with AVR109 based USB bootloader (caterina). There is also one company selling xMega based boards and they do not come with optiboot bootloader either. There are very few UPDI boards available from AliExpress/Taobao except Nano Every 4808 clone (with ATmega4808). They do not come with any bootloader either. @MCUdude does not support optiboot_x for this board even though he provided me optiboot_x compatible bootloader for testing. Ref: programmers and boards I have for avrdude testing. |
I know you are selling some boards which will ship with optiboot bootloader, do you want to include the bootloaders in avrdude by running the botloader-hash tool to create more table entries to be included in avrdude? Thanks. |
I am not so sure about the vast amount of bootloaders in optiboot_flash. It is probably too many. But is it possible to include a few specific ones?
|
@stefanrueger and @MCUdude |
For Dr Azzy's following bootloaders, I am not so sure. The following optiboot_x bootloader may be worth adding, similar to MegaCoreX. The following two (ATTinyCore and DxCore) are probbaly too many to be included. |
I suggest only including bootloaders that are commonly used. The hash table in |
I see. In that case, I think the current list is already good enough from my side. I do not think picoboot is commonly used but since we have already included so we can keep it. It is good for testing as well. Let's see if there are some hex files @MCUdude would like to include. |
BTW, I believe that Just tested a new Nano Clone with ATmega328P (5V, 16MHz).
For AVR fuse settings, WORD is used as the unit. |
Well, by hardcoding in hashes, this means that I can never re-compile the bootloaders again since the hash would then be different. I understand it makes sense for official boards that haven't changed their in more than 10 years, but I tend to re-compile whenever a bug is discovered or a new feature gets crammed in there. |
This makes sense. In that case, we can keep status quo. |
| For AVR fuse settings, WORD is used as the unit. @mcuee Yes, all sizes are in bytes. Yes, I realise Atmel has this odd and confusing mixture of using bytes (es, to say how big flash, eeprom etc is) and words in their tables for fuse settings. That's a generic and self-inflicted Atmel pitfall. I am not aware that AVRDUDE routinely reports sizes in words, in fact I struggle to find a single example. We should not start confusing AVRDUDE users in the same way as Atmel/Microchip sometimes does. |
| by hardcoding in hashes, this means that I can never re-compile the bootloaders again It's wrong to compile optiboot bootloaders! Compile urboot bootloaders. 😄 Seriously, switch. Urboot is shorter and more powerful (can do EEPROM and chip erase and protext itself from overwriting in the same size as optiboot that does neither). Just to put this into perspective: So to cut a long short: Feel free to put existing and widely-distributed bootloader hashes into the |
Have you talked the Arduino folk into switching, yet? Or just including the avrdude with urboot support in their tools distribution? In the ~10years since version 4.4 of Optiboot, Arduino has not updated the version of the bootloader that they ship with Unos. :-( |
Sure, it may well be that arduino folks see no need for a better bootloader than optiboot v4.4. And that's fair enough. That and the fact that there are so many chips with optiboot out there made me put some effort into making
Whether or not the arduino folks want any of that is their prerogative |
I do not think Arduino has any motivation to upgrade their bootloaders (and often the same for built-in FW as well). Just an example, the following is a confirmed bug for the wiring (STK500V2) bootloader for the Mega2560 and there is a pull-request (dated June 2018) to fix it. They have not adopted The bootloader file they are shipping is more than 10 years ago. Same for this FW issue I reported. Right now I actually use @MCUdude's MiniCore and MegaCore for the Uno and Mega2560 Clones. @MCUdude has adopted the fix for the Mega2560 wiring bootloader once I informed him the fix. |
Just wondering if you have fixed or have intentions to fix the paticular optiboot bug.
|
For the Arduino compatible core developers like @MCUdude, maybe there is one more questions: which flavour of urboot FW to use?
The following should be a given. |
Which urboot? Here are some tips: https://github.com/stefanrueger/urboot/blob/main/howtoselect.md TLDR? EEPROM support is neat, autobaud is neat (I've finally come round to it as it only costs 16 bytes). If there is space left compile for frills ( If you have a certain bootloader usage budget (ie, the size the bootloader will take away from flash): browse the README.md of the autobaud directory of a part, you will see the "best" bootloaders suggested for the bootloader usage that you can afford, eg, https://github.com/stefanrueger/urboot/blob/main/bootloaders/atmega328p/autobaud/README.md Also notice I have similar pages for (some) popular boards, eg, https://github.com/stefanrueger/urboot/blob/main/bootloaders/board_uno/autobaud/README.md |
@WestfW BTW, I hugely admire your work; without that the urboot project with ensuing |
Well, it's a shame there is no label for "have no idea how do any better than the current workaround for a problem that originates elsewhere". My attempt to get avrdude to know whether a particlular optiboot instantiation deals with EEPROM is to look that up in a hash table of known instatiations... So, lucky us, Arduino has only ever shipped one... |
I agree with change the lable to wontfix. We can keep this issue open for a while and then close it. 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.
|
Optiboot/optiboot#358 raised against Optiboot. |
Strange that I am seeing issues with EEPROM write for the bigboot optiboot for the ATmega328P with
-c urclock
.-c arduino
is okay.This is with a new Nano clone with ATmega328P and FT232RL. Strange. I did test bigboot before on other boards.
The text was updated successfully, but these errors were encountered: