Skip to content
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

drivers/sdmmc: store SDMMC device descriptor references in XFA #19899

Merged
merged 1 commit into from
Sep 12, 2023

Conversation

gschorcht
Copy link
Contributor

@gschorcht gschorcht commented Aug 23, 2023

Contribution description

SDIO/SD/MMC device descriptor references are now defined as members of an XFA array sdmmc_devs. The i-th device in this array can then be accessed with sdmmc_devs[i]. The number of SDIO/SD/MMC device descriptors SDMMC_NUMOF is XFA_LEN(sdmmc_devs).

Testing procedure

Green CI

Issues/PRs references

@github-actions github-actions bot added the Area: drivers Area: Device drivers label Aug 23, 2023
@gschorcht gschorcht added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Aug 23, 2023
@gschorcht gschorcht requested a review from benpicco August 23, 2023 22:07
@gschorcht gschorcht changed the title drivers/sdmmc: store SDMMC devs in XFA drivers/sdmmc: store SDMMC device descriptor references in XFA Aug 23, 2023
@gschorcht
Copy link
Contributor Author

I'm a bit unsure

  • whether the XFA array should be called simply sdmmc_devs instead of sdmmc_dev_xfa and
  • whether SDMMC_NUMOF should be called SDMMC_NUMOF_TOTAL to keep SDMMC_NUMOF free for the number configurations in sdmmc_config[] in board's periph_conf.h.

@riot-ci
Copy link

riot-ci commented Aug 23, 2023

Murdock results

✔️ PASSED

4a6f4ad drivers/sdmmc: store SDMMC devs in XFA

Success Failures Total Runtime
7968 0 7968 14m:46s

Artifacts

@benpicco
Copy link
Contributor

benpicco commented Sep 6, 2023

  • whether the XFA array should be called simply sdmmc_devs instead of sdmmc_dev_xfa

¯\(ツ)

  • whether SDMMC_NUMOF should be called SDMMC_NUMOF_TOTAL to keep SDMMC_NUMOF free for the number configurations in sdmmc_config[] in board's periph_conf.h.

What would that be used for? It's purely internal, right?

Copy link
Contributor

@benpicco benpicco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If that makes things simpler going forward, sure

@gschorcht
Copy link
Contributor Author

  • whether the XFA array should be called simply sdmmc_devs instead of sdmmc_dev_xfa

¯_(ツ)_/¯

I decided to rename sdmmc_dev_xfa to sdmmc_devs as it is more essential that it contains all SDMMC device descriptors than it is important that it is an XFA.

  • whether SDMMC_NUMOF should be called SDMMC_NUMOF_TOTAL to keep SDMMC_NUMOF free for the number configurations in sdmmc_config[] in board's periph_conf.h.

What would that be used for? It's purely internal, right?

I decided to use SDMMC_NUMOF for the number of SDMMC device descriptors in the XFA and to use a private symbol SDMMC_XYZ_NUMOF in the backend if needed for internal purpose.

@benpicco
Copy link
Contributor

Please squash and merge at your own discretion

@gschorcht
Copy link
Contributor Author

bors merge

@bors
Copy link
Contributor

bors bot commented Sep 12, 2023

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here.
For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

@bors bors bot merged commit f32b661 into RIOT-OS:master Sep 12, 2023
23 checks passed
bors bot added a commit that referenced this pull request Sep 24, 2023
19760: cpu/sam0_common/periph: add low-level SDMMC peripheral driver for SDHC r=benpicco a=gschorcht

### Contribution description

This PR implements the low-level SDIO/SDMMC peripheral driver for SAM0 SDHC according to the definition in #19539.

### Testing procedure

```
BOARD=same54-xpro make -C tests/drivers/sdmmc
```
```
BOARD=same54-xpro make -C tests/sys/vfs_default
```

### Issues/PRs references

~Depends on PR #19539~
Depends on PR #19899

19942: pkg/littlefs2: bump to v2.8 r=benpicco a=benpicco




Co-authored-by: Gunar Schorcht <[email protected]>
Co-authored-by: Benjamin Valentin <[email protected]>
bors bot added a commit that referenced this pull request Sep 24, 2023
19760: cpu/sam0_common/periph: add low-level SDMMC peripheral driver for SDHC r=benpicco a=gschorcht

### Contribution description

This PR implements the low-level SDIO/SDMMC peripheral driver for SAM0 SDHC according to the definition in #19539.

### Testing procedure

```
BOARD=same54-xpro make -C tests/drivers/sdmmc
```
```
BOARD=same54-xpro make -C tests/sys/vfs_default
```

### Issues/PRs references

~Depends on PR #19539~
Depends on PR #19899

Co-authored-by: Gunar Schorcht <[email protected]>
bors bot added a commit that referenced this pull request Sep 29, 2023
19760: cpu/sam0_common/periph: add low-level SDMMC peripheral driver for SDHC r=benpicco a=gschorcht

### Contribution description

This PR implements the low-level SDIO/SDMMC peripheral driver for SAM0 SDHC according to the definition in #19539.

### Testing procedure

```
BOARD=same54-xpro make -C tests/drivers/sdmmc
```
```
BOARD=same54-xpro make -C tests/sys/vfs_default
```

### Issues/PRs references

~Depends on PR #19539~
Depends on PR #19899

19946: posix_sockets.c: Fix 2 byte int compilation errors r=benpicco a=mrdeep1



19956: cpu/esp32: fix heap definition for ESP32-S2 and ESP32-S3 r=benpicco a=gschorcht

### Contribution description

For ESP32-S2 and ESP32-S3 the symbol `_heap_end` must not be used as `_eheap` for the newlibc `malloc` and function `sbrk`.

`_heap_end` is used by the ESP-IDF heap implementation `esp-idf-heap` and points to the highest possible address (0x40000000) that could be used for the heap in ESP-IDF. It doesn't point to the top address of the unused SRAM area that can be used in newlibc `malloc` and function `sbrk`. Instead, the origin and the length of `dram0_0_seg` must be used to calculate the end of the heap `_eheap`.

The problem only occurs for the newlibc `malloc` when the `sbrk` function is used but not for the ESP-IDF heap implementation `esp_idf_heap`.

### Testing procedure

Use any ESP32-S2 or ESP32-S3 board and flash `tests/sys/malloc`, e.g.
```
CFLAGS='-DCHUNK_SIZE=16384' USEMODULE='stdio_uart' BOARD=esp32s3-pros3 make -j8 -C tests/sys/malloc flash
```
Without the PR the `nm` command will give the wrong address 
```
nm -s tests/sys/malloc/bin/esp32s3-pros3/tests_malloc.elf | grep _eheap
40000000 A _eheap
```
The test will stuck, i.e. the allocation of memory stops when the top of unused SRAM is reached and the board restarts when the watchdog timer expires. With the PR it should work as expected
```
Help: Press s to start test, r to print it is ready
START
main(): This is RIOT! (Version: 2023.10-devel-309-g4669e)
calloc(zu, zu) = 0x10000000
CHUNK_SIZE: 16384
NUMBER_OF_TESTS: 3
Allocated 16384 Bytes at 0x3fc8c4b0, total 16384
...
Allocated 16384 Bytes at 0x3fcec6f0, total 409792
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x403763e3
```

With this PR the `nm` command should give a address in unused SRAM address space
```
nm -s tests/sys/malloc/bin/esp32s3-pros3/tests_malloc.elf | grep _eheap
3fcca000 A _eheap
```
and the test should pass.

### Issues/PRs references


19957: cpu/esp32: fix Octal SPI RAM for ESP32-S3 r=benpicco a=gschorcht

### Contribution description

This PR fixes Octal SPI RAM handling for ESP32-S3.

Functions that are used during the initialization of the Octal SPI RAM must reside in IRAM instead of Flash. Otherwise, the system stucks during boot once the Octal SPI RAM is enabled. The reason is that the Flash is not available during the initialization of the Octal SPI RAM and the functions that are called during that initialization can't be accessed in Flash. As a result the call of such a function leads to code that is messed up and the system crashes.

The PR also includes the documentation fixe for the `esp32s3-box`. It also includes a small documentation fix regarding the SPI RAM for the `esp32s3-pros3` board.

### Testing procedure

Use a board that has Octal SPI RAM and flash `tests/sys/malloc`, e.g.:
```
CFLAGS='-DCHUNK_SIZE=16384' USEMODULE='stdio_uart esp_spi_ram esp_log_startup' \
BOARD=esp32s3-box make -C tests/sys/malloc
```
Without the PR, the system stuck during boot once the information for the Octal SPI RAM is print
```
ESP-ROM:esp32s3-20210327
...
I (133) boot: Loaded app from partition at offset 0x10000
I (134) boot: Disabling RNG early entropy source...
vendor id : 0x0d (AP)
dev id    : 0x02 (generation 3)
density   : 0x03 (64 Mbit)
good-die  : 0x01 (Pass)
Latency   : 0x01 (Fixed)
VCC       : 0x01 (3V)
SRF       : 0x01 (Fast Refresh)
BurstType : 0x01 (Hybrid Wrap)
BurstLen  : 0x01 (32 Byte)
Readlatency  : 0x02 (10 cycles@Fixed)
DriveStrength: 0x00 (1/1)
```
and the board restarts when the watchdog timer expires.

With this PR, the system starts as expected.
```
ESP-ROM:esp32s3-20210327
...
I (132) boot: Loaded app from partition at offset 0x10000
I (133) boot: Disabling RNG early entropy source...
vendor id : 0x0d (AP)
dev id    : 0x02 (generation 3)
density   : 0x03 (64 Mbit)
good-die  : 0x01 (Pass)
Latency   : 0x01 (Fixed)
VCC       : 0x01 (3V)
SRF       : 0x01 (Fast Refresh)
BurstType : 0x01 (Hybrid Wrap)
BurstLen  : 0x01 (32 Byte)
Readlatency  : 0x02 (10 cycles@Fixed)
DriveStrength: 0x00 (1/1)
Found 64MBit SPI RAM device
SPI RAM mode: sram 40m
PSRAM initialized, cache is in normal (1-core) mode.
Pro cpu up.
Single core mode
SPI SRAM memory test OK
Initializing. RAM available for dynamic allocation:
At 3FC8C150 len 00053EB0 (335 KiB): D/IRAM
At 3FCE0000 len 0000EE34 (59 KiB): STACK/DRAM
At 3FCF0000 len 00008000 (32 KiB): DRAM

Starting ESP32x with ID: f412fafd0f8c
ESP-IDF SDK Version v4.4.1

Current clocks in Hz: CPU=80000000 APB=80000000 XTAL=40000000 SLOW=150000
PRO cpu is up (single core mode, only PRO cpu is used)
PRO cpu starts user code
Adding pool of 8192K of external SPI memory to heap allocator
Used clocks in Hz: CPU=80000000 APB=80000000 XTAL=40000000 FAST=8000000 SLOW=150000
XTAL calibration value: 3643448
Heap free: 8754851 bytes

Board configuration:
	UART_DEV(0)	txd=43 rxd=44
	LED		pins=[ ]
	BUTTONS		pins=[ 0 ]

Starting RIOT kernel on PRO cpu
Help: Press s to start test, r to print it is ready
```

### Issues/PRs references


Co-authored-by: Gunar Schorcht <[email protected]>
Co-authored-by: Jon Shallow <[email protected]>
@MrKevinWeiss MrKevinWeiss added this to the Release 2023.10 milestone Nov 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: drivers Area: Device drivers CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants