-
Notifications
You must be signed in to change notification settings - Fork 1.4k
boards/arm/samv7: remove unused options on defconfig #17340
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
base: master
Are you sure you want to change the base?
boards/arm/samv7: remove unused options on defconfig #17340
Conversation
|
If someone has this board to validate the changes it would be greatly appreciated. |
I have only SAM[L21,R21,W25]. These V70/V71 looks far more expensive and I already bought some rPI boards so probably not going to buy them sorry :-(
I guess if there are no users with the boards, and the build is fixed, that is okay, will ask on the mailing list :-) |
|
Hi, I still have one SAMV71-XULT borrowed from Elektroline.cz from GSoC. I suppose I could run some tests with it. |
Thank you very much @matiamic! |
|
@TimJTi told on the mailing list he has some spare boards with SAMv7 and can share for testing, big thank you Tim! I would be grateful to take one board for NXDART, anyone else needs one? :-) |
I have found 1 x SAMV71-XULT and have emailed you 👍 |
Remove the unused Nuttshell and RAMTEST to free up some space on boot partition. Signed-off-by: Filipe Cavalcanti <[email protected]>
39d3955 to
60c9b81
Compare
|
I have changed the defconfig. |
|
michallenc
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes should be ok based on what I use on custom SAMv71 boards.
|
Hi, I brought the changes from the changed defconfig to samv71-xult's defconfig. Compilation OK, execution gets stuck on But that behavior is the same for the build without the changes. And it makes sense as I am providing no firmware image. I tried to provide a valid image by following the steps in the |
|
cederom
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Big Thank You @fdcavalcanti Amazin Work!! :-)
|
@pkarashchenko could you please take a look? |
|
Okay I just got the SAMv7 board from @TimJTi delivered! |
|
Okay first steps working :-) Can flash with OpenOCD over the built-in Atmel debug probe (luckily its generic So far so good :-) Now into this mcuboot stuff :-) https://nuttx.apache.org/docs/latest/platforms/arm/samv7/boards/samv71-xult/index.html#mcuboot-loader |
|
|
Hi, SAMv70 and SAMv71 MCUs should be basically the same (if the number of pins is the same, they ship it in 70, 100 and 144 pin variant if I recall), the difference will likely be just between UART pins routing. And peripherals on Xult vs QMTECH might be connected differently. SAMv7-Xult board has serial console on There are two MCUs on Xult board, one is SAM and other is the older 16 bit PIC from Atmel's series that works as a bootloader and programmer. |
|
I will be able to look into this EOW (probably on Friday or Saturday). I'll provide my feedback |
|
As an alternative to this I was experimenting with So basically update and extend MCUboot loader maximum size from 128K to 144K and reducing scratch area. What do you think? |
|
@pkarashchenko it's a possibility, but I think we shouldn't give more space to the bootloader unless really necessary - and there are options we can disable without affecting its functionality. Reducing scratch size means more copying and erasing in that area, thus more flash wear. The current size 128 kB also has an advantage that we can fit the bootloader into first flash's sector. |
Ok. Then we can disable some functionality. I tried to compile the current configuration with the current MCUboot hash and see that the result binary is close to 128K (uses 99.6% of allocated flash). Taking into consideration wear leveling is good, but what if the next MCUboot version will add some code and the resulting image will overflow the allocated size for 100bytes more? There are not many things to disable left. And having nsh for bootloader sometimes is useful. At least in my case I was adding some command to display version information or initiating OTA update by a command. SAMe70 512Kb flash variant is not very usable in terms of MCUboot and was here for demo purposes, so we can ever drop that configuration and keep only options with bigger flash. I'm just looking for some solution that is usable and scalable. The bigger flash SAMv7 options still have a sufficient scratch area. |
Oh, I expected we would be around 60 kB with these changes and have a lot of reserved space. Ok then, that changes things and I suppose we can reserve more space for the bootloader. |
|
I tried to add one more page (16Kb) for bootloader that should put us to the safe stop I hope. |
1 similar comment
|
I tried to add one more page (16Kb) for bootloader that should put us to the safe stop I hope. |
Summary
Remove the unused Nuttshell and RAMTEST to free up some space on boot partition.
This should fix linker issues reported in nuttx-apps #3200.
Impact
Affects common linker script for
arm/samv7when using MCUBoot.Testing
Before changes:
After changes: