Repository navigation
[BUG] DSP writes to low addresses like 0x10 don't cause exceptions #6093
Description
Describe the bug
A line of code clearly has to dereference a pointer, where the above line prints it as NULL, and no exception is generated, when built with xcc.
To Reproduce
Use 95b128e and build an XTOS based firmware for TGL, then run it on an SDW platform. Observe the following log:
[ 223577.473958] ( 6.666667) c0 ipc src/ipc/ipc3/handler.c:1605 INFO ipc: new cmd 0x30130000
[ 223598.463542] ( 20.989584) c0 pipe 1.3 ......./pipeline-graph.c:307 INFO pipeline complete, clock freq 400000000Hz
[ 223701.380208] ( 102.916664) c0 ipc src/ipc/ipc3/handler.c:1605 INFO ipc: new cmd 0x60010000
[ 223714.296875] ( 12.916667) c0 pipe 30.53 ....../pipeline-params.c:246 INFO pipe params dir 0 frame_fmt 0 buffer_fmt 0 rate 48000
[ 223723.619792] ( 9.322917) c0 pipe 30.53 ....../pipeline-params.c:250 INFO pipe params stream_tag 1 channels 2 sample_valid_bytes 2 sample_container_bytes 2
[ 223844.973958] ( 121.354164) c0 dai 1.2 src/ipc/ipc3/dai.c:109 INFO dai_data_config() dai type = 4 index = 2 dd 0x9e11e400
[ 223855.052083] ( 10.078125) c0 dai 1.2 src/ipc/ipc3/dai.c:142 INFO DMA buffer (nil)
[ 223881.015625] ( 25.963541) c0 dai 1.2 src/audio/dai-legacy.c:362 INFO dai_playback_params() dest_dev = 22 stream_id = 7 src_width = 4 dest_width = 4
[ 223891.197917] ( 10.182292) c0 dai 1.2 src/audio/dai-legacy.c:368 INFO dai_playback_params() fifo 0x7141c
[ 223906.848958] ( 15.651042) c0 pipe 30.53 ....../pipeline-params.c:343 INFO pipe prepare
[ 223982.656250] ( 75.807289) c0 dai 1.2 src/audio/dai-legacy.c:655 INFO dai_prepare()
[ 223992.734375] ( 10.078125) c0 dai 1.2 src/audio/dai-legacy.c:621 INFO dai_config_prepare(), channel = 7
[ 224001.875000] ( 9.140625) c0 dw-dma src/drivers/dw/dma.c:194 INFO dw_dma_channel_get(): dma 0 request channel 7
[ 224011.979167] ( 10.104167) c0 dai 1.2 src/audio/dai-legacy.c:640 INFO dai_config_prepare(): new configured dma channel index 0
specifically see this line:
[ 223855.052083] ( 10.078125) c0 dai 1.2 src/ipc/ipc3/dai.c:142 INFO DMA buffer (nil)
which is produced by this code:
Lines 142 to 143 in 95b128e
where the next line after the print dereferences the NULL pointer, and no exception happens. A full log is attached.
Reproduction Rate
100%
Expected behavior
A DSP exception should be triggered.
Impact
The compiler seems to have a severe bug
Environment
- Name of the topology file
- Topology: sof-tgl-rt711-rt1316-rt714.tplg
- Name of the platform(s) on which the bug is observed.
- Platform: jf-tglu-sku0a32-sdca-02
Activity
lyakh commentedon Aug 5, 2022
I modified the code a bit:
to make the location between the two calls to
platform_timer_get()obvious. Here's the disassembly:marc-hb commentedon Aug 5, 2022
Was this discovered while debugging recent regressions #6075 and/or #6091? Just trying to connect some dots, sorry if unrelated.
lyakh commentedon Aug 5, 2022
@marc-hb #6075 , yes
lyakh commentedon Aug 5, 2022
Further, the same problem also appears on TGL, where the code was modified to add that NULL-dereference, also when built with crosstool gcc and with the Zephyr toolchain. Apparently that code should run during initial DAI configuration and during potential run-time DAI re-configuration. The
ipc_dai_data_config()function is only called fromdai_params()in dai-legacy.c and dai-zephyr.c, and in both casesdd->dma_bufferis first allocated there - during initialisation, or re-used - during re-configuration.[-][BUG] a line seems to be optimised out, that should cause a NULL dereference exception[/-][+][BUG] DSP writes to low addresses like 0x10 don't cause exceptions[/+]lyakh commentedon Aug 9, 2022
Update: just checked, that doing the same - adding a low address (e.g. 0x10) dereference in
main()behaves in one of two ways: (1) causes an exception when reading from it - as expected or (2) causes no problem when writing to it.lgirdwood commentedon Aug 9, 2022
@lyakh what happens when
OR
lyakh commentedon Aug 9, 2022
Update Nr.2: on BYT neither writes to nor reads from low addresses cause exceptions.
Update Nr.3: actually using 0 instead of a low address has the same effect
lyakh commentedon Aug 9, 2022
@lgirdwood sorry, I checked assembly. I'm rather sure those actual addresses (0x10, 0, etc.) are used, which of course are outside of any RAM addresses - cached or uncached.
lyakh commentedon Aug 9, 2022
@mmaka1 any idea about this?
lgirdwood commentedon Aug 9, 2022
Can you check anyway, this could be misconfiguration of the cache_attr for the HW (see the linker script for value and pls check it's value is aligned with HW).
lyakh commentedon Aug 9, 2022
@lgirdwood I see what you mean... IIRC @andyross and @ceolin checked and double-checked those flags for Zephyr, do you think such an effect could be possible via their misconfiguration?
andyross commentedon Aug 9, 2022
Unfortunately the cAVS/MTL platforms put registers in that low 512M block, so we can't use the region protection bits to deny access. That region is marked rw/uncached. Whether or not an address faults (some do, for sure) is entirely up to the bus hardware.
Once there's hardware available with an MMU, there will be more options. Also on some of the devices (I want to say cAVS 1.5 can do this but 1.8+ can't?) we have the "RPO with Translation" feature, which allows the top 3 bits of memory to remap each 512M region. That would allow us (with a lot of work to the devicetree definitions!) to move the registers somewhere else and mark the null region invalid. But it would only work on the older hardware, IIRC.
andyross commentedon Aug 9, 2022
Just checked: indeed, the core-isa.h files in the sof tree have XCHAL_HAVE_XLT_CACHEATTR==1 for BYT and APL, but all other platforms (AMD/NXP/MediaTek included) are 0. So that's not really much of an option.
andyross commentedon Aug 9, 2022
FWIW: the cacheattr register actually doesn't exist on platforms with Region Protection Option, the HAL code to set it actually interprets the register value at runtime. We have a smaller, plausibly-too-optimized-for-its-own-good version here: https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/arch/xtensa/cache.h#L163
ceolin commentedon Aug 9, 2022
Just for curiosity, can you check what is the access mode for this address ? Not familiar with this part of SoF code, but I think
glb_addr_attrshould give you it.ceolin commentedon Aug 9, 2022
We are using identity map without translation, aren't we ?
andyross commentedon Aug 9, 2022
Right. The code is aware of the "with translation" distinction (because it has to set up the top three bits differently), but for compatibility we don't try to do any mapping.
ceolin commentedon Aug 9, 2022
I may be missing something, but only baytrail and apollolake have support for translation.
andyross commentedon Aug 9, 2022
Right. Thus "not much of an option". :)
lyakh commentedon Aug 10, 2022
that all sounds wonderful... But reading from those addresses does generate an exception, so the DSP "knows" that they are invalid? I looked at some of the registers and the lowest addresses I see begin soon after 0x1000 so about the low 4k of addresses seem to be invalid? So it's the bus hardware bug, that it raises exceptions on reading from there but not on writing to that area?
andyross commentedon Aug 10, 2022
That matches my experience, though I never tried to probe the exact behavior. For sure I've gotten some reasonable-looking exceptions on null pointer dereferences. It makes perfect sense that the hardware designers would put a poison region at the bottom of memory. Frustrating if it only works for reads, though.
ceolin commentedon Aug 10, 2022
Did you were able to get the access mode for these address that are behaving like this ? There are access mode that raises exceptions in fetch but not in load and store operations.
github-actions commentedon Jun 19, 2025
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.