jcmvbkbc

A curious creature, sw engineer, casual hockey player, roller and long distance runner. Free software addict.

[jcmvbkbc @jcmvbkbc]

Linux gave me an unexpected choice: either be able to use UBIFS or be able to erase a 4KB block on an spi nor FLASH, but not both. Even when I want to erase in one partition and use UBIFS on another.

[jcmvbkbc @jcmvbkbc]

Linus Torvalds on bad hardware architectures: https://t.co/apYj6WVAjO
xtensa scores a lot of points in that list with confidence and a few more as optional features.

[jcmvbkbc @jcmvbkbc]

@Larushka_G @ElectroUral https://t.co/339IUhA6Xb

[jcmvbkbc @jcmvbkbc]

A couple new changes in the esp32-linux-build scripts:
- update to linux-6.11 and buildroot-2024.08
- new configuration for the Espressif Box-3 supporting SPI display and USB host controller

[jcmvbkbc @jcmvbkbc]

@voteforpedro @KevinNaughtonJr Fun fact: it's also a treadmill.

[jcmvbkbc @jcmvbkbc]

@cnlohr But if 'happen' was really meant, then in this and similar cases (only logical operators) it's left-to-right, because logical operators make sequence points.

[jcmvbkbc @jcmvbkbc]

@cnlohr If it's about precedence, then 'happen' is the wrong word, because if a is true, (b && c) does not 'happen' at all. I.e. printf("a") || printf("b") && printf("c"); would only output 'a'.

[jcmvbkbc @jcmvbkbc]

Xtensa FDPIC ABI draft RFC: https://t.co/DrTxY0SEAn

[jcmvbkbc @jcmvbkbc]

xtensa FDPIC toolchain gets initial TLS and NPTL support with uClibc-ng. New linux builds for esp32s3 and esp32 will have it enabled by default. xtensa FDPIC support in musl libc is next.

[jcmvbkbc @jcmvbkbc]

xtensa gcc switches from reload to LRA thanks to Takayuki 'January June' Suwa.

[jcmvbkbc @jcmvbkbc]

@gojimmypi The registers and the bits are documented, but in a rather obscure way, without mentioning their relation to Vaddr* regions. I played with them a bit, turning them on and off and checking how it affects what's visible in the Vaddr2 and Vaddr3 ranges.

[jcmvbkbc @jcmvbkbc]

On esp32 as long as DPORT_{PRO,APP}_CACHE_CTRL1_REG bits DPORT_{PRO,APP}_CACHE_MASK_IRAM1 are set, reads from the region 0x4040_0000..0x407F_FFFF (VAddr2 in esp32 TRM terminology) return 0xbad00bad. Clearing these bits makes the VAddr2 mappings work.

[jcmvbkbc @jcmvbkbc]

@gojimmypi And although memory map that I get with these bits changed works well for linux, there still may be issues in the most recent esp32 chips that I just haven't hit in my use case.

[jcmvbkbc @jcmvbkbc]

@gojimmypi To me it looks like chicken bits, left there to disable features that may have issues not found before the tapeout. There might be issues in the early esp32 chips that resulted in adoption of the existing memory map in the IDF.

[jcmvbkbc @jcmvbkbc]

And as long as bits DPORT_{PRO,APP}_CACHE_MASK_IROM0 are set, reads from the region 0x4080_0000..0x40BF_FFFF (VAddr3) return 0xbad00bad. Clearing these bits makes the VAddr3 mappings work.

[jcmvbkbc @jcmvbkbc]

@gojimmypi I just realized that despite that I've posted the workaround details in the issue thread on github, it's not visible to anyone but me. As well as the posts in the issues that I've made in the last few weeks. Ok.

[jcmvbkbc @jcmvbkbc]

@gojimmypi It's about the fact that despite ~11M of address space of ESP32 are dedicated to FLASH only about 3M are usable with the default IDF settings. This is my original report and the workaround details: https://t.co/fRie5ZIiYM

[jcmvbkbc @jcmvbkbc]

Got linux-6.7-rc8 + userspace running on esp32 with 4M FLASH and 4M PSRAM. It took some time to find a workaround for the unfortunate default FLASH mapping. Build script: https://t.co/F39S4k1Inc

[jcmvbkbc @jcmvbkbc]

c++ exceptions and c cleanup routines are now working in the xtensa FDPIC toolchain. TLS and NPTL are next.