-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
samd: Support using a board's external flash chip as boot file system. #10233
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
Conversation
7fa1233
to
c2bcbf2
Compare
c2bcbf2
to
bba89f9
Compare
bee6acd
to
31c20c0
Compare
31c20c0
to
7c3b48a
Compare
mbedtls adds about 100k of code. Therefore it is enabled at the moment for SAMD51x20 devices only. It can change if PR micropython#10233 is merged.
mbedtls adds about 100k of code. Therefore it is enabled at the moment for SAMD51x20 devices only. It can change if PR micropython#10233 is merged.
This is definitely a great feature to have. But I'm curious why you didn't use the existing |
ports/samd/modules/_boot.py
Outdated
# Try to mount an external flash drive. | ||
try: | ||
if hasattr(samd, "QSPIflash"): | ||
bdev = FlashBdev(samd.QSPIflash()) |
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.
I'm not sure why the FlashBdev
class is needed, it is a very thin wrapper. Why not just make QSPIflash
, SPIflash
and MCUflash
implement the block protocol? Then they can be used directly (and the existing samd.Flash
could just be renamed to samd.MCUFlash
).
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.
Thank you for reviewing. FlashBdevI
is intentionally as small as possible, and I wanted to be able to support more than one flash type at a device, like external flash and mcuflash. The block device driver was initially combined with the mcuflash driver. But yes, the block device driver can as well be moved back into the specific flash type drivers.
About drivers/memory/spiflash.[ch]
. I had seen them sometime during the development. The seemed to me pretty specific for Pyboard needing more driver code from the sptm32 directory, and I could not tell how to use them, besides seeming quite large..
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.
So I added a commit which integrates the block device driver into the QSPI and SPI flash drivers. It rolls also back the change to samd_flash.c. If that's ok, the last two commits can be squashed into one.
That SPI flash driver is intended to be used by any port. It supports both normal SPI and QSPI. It also supports caching to be able to erase parts that are smaller than the native erase size of the flash, but that's optional via In the code in this PR there is duplication between the SPI and QSPI driver. That duplication is gone if you use IMO it doesn't make sense to have duplicated SPI flash driver code in the samd port and in
Eventually part (2) above could be made general enough to use by other ports. |
Thank you for your hints. Part of these I had seen when considering to use drivers/memory/spiflash.c. |
Yes I appreciate that. OK, so let's stick with what we have here for the moment. Maybe we can refactor at some later stage. One thing I would suggest to simplify further what you have here is:
|
Thanks. That sounds good. I'll implement that later today. |
One challenge is that the progsize values are different. |
I suggest using 256 in all cases. (Or if it really can't spare the RAM for that, either use |
So I moved the reference to Peter's code in the copyright note, removed the reference to the not used EEPROM parts of Christopher and renamed some variables to more expressive words. Force pushed in the samd_spiflash.c file.
|
a836f6c
to
b5d6ea0
Compare
This last change makes the spi_flash object a singleton. It was dynamic before without a need. Still using spi_flash decreases the code size by >368 bytes compared to the driver for internal flash. Using qspi_flash increases the code size by 12 bytes. |
ports/samd/modsamd.c
Outdated
#error Only one type of flash must be used | ||
#endif | ||
{ MP_ROM_QSTR(MP_QSTR_Flash), MP_ROM_PTR(&spiflash_type) }, | ||
#endif |
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.
This (messy?) if logic could be simplified by either:
- having a single name for the flash type,
spiflash_type
, instead ofsamd_flash_type
andsamd_qspiflash_type
. Then the linker will give an error if multiple are defined - at the top of this file having a
#define SPIFLASH_TYPE <relevant type>
based on which one is configured. Then the preprocessor will give an error if multiple are defined.
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.
I went for Option 2. The code looks much more clean.
Updated as suggested. |
ports/samd/samd_qspiflash.c
Outdated
@param addr the address to read or write from. If the instruction doesn't require an address, this parameter is meaningless. | ||
@param buffer pointer to the data to be written or stored depending on the type is Read or Write | ||
@param size the number of bytes to read or write. | ||
*/ |
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.
It's OK to leave the comments here, just maybe in a different format that matches existing code, eg:
// Run a single QSPI instruction.
// Parameters are:
// - command: instruction code
// - iframe: ...
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.
Done
ports/samd/modsamd.c
Outdated
#endif | ||
#if MICROPY_HW_SPIFLASH | ||
extern const mp_obj_type_t spiflash_type; | ||
#define SPIFLASH_TYPE spiflash_type | ||
#endif | ||
#if MICROPY_HW_MCUFLASH |
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.
Can this be moved up to line 35, and wrap the extern const mp_obj_type_t samd_flash_type
?
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.
Sure & done
Updated, and sorry for the confusion. |
PIN_PA08,D4 | ||
PIN_PA08,FLASH_MOSI | ||
PIN_PA14,FLASH_MISO | ||
PIN_PA09,FLASH_SCK |
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.
Should these be renamed? There's no longer any need to have them accessible in _boot.py
as these names.
It's a little inconsistent that these are called FLASH and the others below are QSPI.
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.
They are used in samd_spiflash.c. And they are called FLASH_xxxx, to make clear that they are connected to the on-board flash chip, and user accessible SPI pins of a board.
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.
You're right!
OK, this is fine then.
ports/samd/modmachine.h
Outdated
@@ -39,6 +39,9 @@ extern const mp_obj_type_t machine_dac_type; | |||
extern const mp_obj_type_t machine_i2c_type; | |||
#endif | |||
extern const mp_obj_type_t machine_pin_type; | |||
#ifdef MICROPY_HW_QSPIFLASH | |||
extern const mp_obj_type_t machine_qspiflash_type; |
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.
I think this can be removed, it's the wrong name anyway (doesn't match what's in the .c file).
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.
Oh yes. That should not be there.
{ MP_ROM_QSTR(MP_QSTR_pininfo), MP_ROM_PTR(&samd_pininfo_obj) }, | ||
{ MP_ROM_QSTR(MP_QSTR_Flash), MP_ROM_PTR(&SPIFLASH_TYPE) }, |
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.
This can be put back above in its original order (before pininfo).
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.
Sure.
ports/samd/modules/_boot.py
Outdated
uos.mount(vfs, "/") | ||
|
||
del vfs, fs_type, bdev, uos, samd, progsize |
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.
I'm surprised this doesn't crash... progsize
isn't defined!
Also, why not delete after the gc.collect()
, so that gc
can also be deleted?
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.
Maybe it crashed, but silently. Removed and added del gc
.
ports/samd/samd_flash.c
Outdated
@@ -27,10 +27,13 @@ | |||
#include <stdio.h> | |||
|
|||
#include "py/runtime.h" | |||
#include "py/mphal.h" |
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.
Is this extra include needed?
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.
No.
ports/samd/samd_flash.c
Outdated
} | ||
STATIC MP_DEFINE_CONST_FUN_OBJ_0(samd_flash_init_obj, samd_flash_init); | ||
|
||
// FLASH stuff |
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.
I think this comment can go. It's not doing anything useful.
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.
Old, not gold.
ports/samd/samd_spiflash.c
Outdated
uint32_t size; | ||
} spiflash_obj_t; | ||
|
||
extern const mp_obj_type_t spiflash_type; |
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.
I think this should be named samd_spiflash_type
, to match the other two (flash, qspi).
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.
Done. It had that name initially, and then I considered to make it independent from the SAMD port, and so I dropped the samd
part of the name. That independent mode required to supply the SPI object to the driver, which was changed. And now it's again a SAMD only driver.
Updated again into the last commit. Thank you for the detailed review. |
For SAMD21 devices, the board flash signals must be named in pins.csv as FLASH_MOSI, FLASH_MISO, FLASH_SCK, FLASH_CS for creating the SPI object. And rename the QSPI pins to QSPI_xxxx instead of FLASH_xxx. Signed-off-by: robert-hh <robert@hammelrath.com>
The SPI flash driver includes the block device for being used as a filesystem. It provides the same methods as the driver for the internal flash. Signed-off-by: robert-hh <robert@hammelrath.com>
The QSPI driver provides the interface for using an on-board QSPI flash for the filesystem. It provides the same methods as the driver for the internal flash and uses the same name. Therefore, only one of the drivers for internal flash, SPI flash and QSPI flash must be enabled at a time. Signed-off-by: robert-hh <robert@hammelrath.com>
Checks are added to ensure, that only one of the flash drivers is selected. Signed-off-by: robert-hh <robert@hammelrath.com>
Code size limits are charged to: - SAMD21: 184K -> 248K - SAMD51x19: 368K -> 496K - SAMD51x20: 368K -> 1008K Signed-off-by: robert-hh <robert@hammelrath.com>
Thanks for updating. I broke up and squashed the last commit as appropriate, and tweaked the wording of the commits. |
Thank you. Sorry for making wore work than needed. My next question would have been, whether I should resort the changes into the respective commits. |
It's all good. It's easy for me to fix minor things during merge, and saves going back and forth. |
Quite a few boards provide an external on-board flash chip, which this PR supports for the default file system. That provides a larger file system and faster I/O operation, especially for the SAMD51 devices:
The flash device to be used for the boot file system is defined in the board's mpconfigboard.h.
Note: On some SAMD51 devices, using the QSPI flash for the boot file system increases the code execution speed by about 60%.