urclock support for optiboot_x and optiboot_dx #1200
Comments
mcuee
added
enhancement
|
And it sems to work with ATtiny817 XPlainedPro optiboot_x as well. Again the question is why the meta data are location at 0x1dc0. |
mcuee
added
enhancement
|
@stefanrueger |
|
Right now,
I have yet to study the data sheets of these parts. How would AVRDUDE know the difference? Is there something in avrdude.conf that would tell it that a part is one or the other (other than parsing the name). They all have
Metadata (unless switched off by |
|
Thanks for the explanations. I will label this as enhancement now. Since I think the AVR DA/DB/DD problem may be with |
|
To cut a long short: I would suggest the community try So my personal strategy for solving this avrdude issue (as well as Issue 1, Issue 2 and Issue 4 of the urboot project) is to do nothing about this right now, and let more talented people in the community play with this idea first. |
|
Fair enough. I totally agree with your thoughts. Our priority now is to get avrdude 7.1 release done by end of this year. I really hope that happens. I have long holiday in December so I can help on testing side. I will carry out more tests with regard to this issue (also learn more about UPDI AVR parts) but do not feel pressured to do anything on new parts. |
Yes, I have pushed an update to avrdude.conf.in in PR #1198 (but |
I will test it out later. Actually it is the same situation for Mega0 and Tiny0/1/2 (optiboot_x). Please refer to the following run log posted before, the chip is ATtiny817 using optiboot_x from megaTinyCore. You can see that 0x00 - 0x200: Bootloader Not exactly sure why the metadata goes to 0x1dc0 though, still since there is nothing below 0x00 so it has to go to the top of the flash. So it kind of makes sense as well. Edit: now I understand why it goes to 0x1dc0. |
Guess what, it works now. 👍 Again the meta data location makes perfect sense to me now. |
|
OK, understood. [edit:
Well it does in a sense, but not correctly so: I realise there need changes to be made to
|
|
I think you should be able to answer the question from @stefanrueger
I believe the answer is yes. Correct me if I am wrong.
I believe the answer is yes. Correct me if I am wrong. |
|
And
|
Not sure if @dl8dtl can help to answer your question or not. Or maybe @SpenceKonde can help here.
At least DxCore works fine to build the blink sketch for my testing. |
|
The optiboot_dx code is at The compiler needs to know about the bootloader's size when it compiles the application on modern AVRs, because it needs to start the app code at 0x0200 instead of 0x0000 (or whatever the right size is). This was not imo the best decision that went into the design of the AVR Dx-series. As for how optiboot knows where the app code starts and hence where to jump to - it gets told explicitly where: LDSECTIONS = -Wl,-section-start=.text=0 \
-Wl,--section-start=.application=0x200 \
-Wl,--section-start=.spmtarg=0x1fa \
-Wl,--section-start=.version=0x1feThen - I'm not entirely sure why they use this method, but I haven't had a need to change change it, even though it makes me kind of nauseous. // Dummy application that will loop back into the bootloader if not overwritten
// This gives the bootloader somewhere to jump, and by referencing otherwise
// unused variables/functions in the bootloader, it prevents them from being
// omitted by the linker, with fewer mysterious link options.
void __attribute__((section( ".application")))
__attribute__((naked)) app();
void app()
{
// some code here that references variables and functions in the bootloader.
// I would rather the mysterious linker options, personally...
}and the actual test for entry conditions and jumping to app then is simply: Yeah avr-gcc works with modern AVRs - you just need to build the toolchain with the correct ATpacks (there is nothing magic about the AVR Dx-series as far as the compiler is concerned - the compiler doesn't provide any handling of flash mapping or anything - you have to implement anything like that that yourself. But thats a design decision microchip made, because they want to promote their XC8 compiler, which nobody else wants to come within 10 meters of because it's a closed source (hence inherently untrustworthy) toolchain. They recently added some features to support using the flash in mapped mode automatically there) https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino6-aarch64-pc-linux-gnu.tar.bz2 |
That's what I thought. And how does the compiler know? Which option does the user need when compiling blink.c? Linker options like
How can avrdude tell from
So no one in the design team has asked the question And how would the compiler know the start address of the application?. I see poor design like this so often that I am convinced that a higher proportion of people in the IT industry would have failed the Sally-Anne test as children than the average population.
Simply? I don't know. Optiboot's default conditions easily lead to WDT timeout reset loops, alternating between application/bootloader. It's the reason that arduino.c needs to sleep 250 ms before it resets the board b/c otherwise two successive avrdude calls don't work; it leads to a more complicated getsync routine than necessary etc. But hey, ho each to its own. |
I don't like it either; I believe "the bootloader should be transparent and the application shouldn't even have to know (at either compile or run time) whether there is a bootloder in use." The old AVR scheme that allowed the bootloader to be in high memory was ideal. I did come up with a scheme that lets the start address be specified in SOURCE CODE rather than linker switches. ( https://github.com/Optiboot/optiboot/blob/master/optiboot/bootloaders/optiboot/optiboot.c#L605 ) |
That's OK. Who knows what optimisation this buys the hardware developers; they might actually have a reason for this which we fail to see - I simply don't know.
... of the bootloader (not the application), I assume. Mmh, yes, this is a perennial problem for bootloader writers to which the urboot project found a different solution. That project uses a wrapper |
It seems to me many ARM Cortex MCUs will have factory installed bootloader (some USB AVRs have factory installed bootloader as well). STM32: factory installed bootloader, activated by boot pins NXP: many have factory installed bootloader Microchip/Atmel SAM-BA, usually reside in ROM monitor, but some need to be in flash (eg: SAM D21) |
Yes, I believe that is the way for MegaCoreX, megaTinyCore and DxCore. Example from megaTinyCore |
I believe that should be fine, basically Mega0/1 (optiboot_x), Tiny0/1/2 (optiboot_x) and AVR DA/DB/DD (optiboot_dx) as of now. |
As or now urboot does not support AVR Mega0, Tiny01/2 and AVR DA/DB/DD yet.
What about the support of optiboot_x and optiboot_dx in
-c urclock?One of the issue is that the bootloader is on top of the flash memory. But it seems to work fine based on my quick testing.
@stefanrueger
Can I assumen it works out of the box? Or we should be cautious and not to try it as of now.
And I am wondering why the meta data are located at 0xbdc0?
The text was updated successfully, but these errors were encountered: