home.social

#zephyr — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #zephyr, aggregated by home.social.

fetched live
  1. I really need to work out a better way to include libraries into #Zephyr applications. My current setup (using projects in a West manifest, and then a bunch of CMake mumbo-jumbo feels wrong). Perhaps using FetchContent?

  2. I really need to work out a better way to include libraries into #Zephyr applications. My current setup (using projects in a West manifest, and then a bunch of CMake mumbo-jumbo feels wrong). Perhaps using FetchContent?

  3. I really need to work out a better way to include libraries into applications. My current setup (using projects in a West manifest, and then a bunch of CMake mumbo-jumbo feels wrong). Perhaps using FetchContent?

  4. I really need to work out a better way to include libraries into #Zephyr applications. My current setup (using projects in a West manifest, and then a bunch of CMake mumbo-jumbo feels wrong). Perhaps using FetchContent?

  5. I really need to work out a better way to include libraries into #Zephyr applications. My current setup (using projects in a West manifest, and then a bunch of CMake mumbo-jumbo feels wrong). Perhaps using FetchContent?

  6. Note that all of this worked, and as far as I can tell, nothing on my side changed, and it suddenly didn't work any more. Yet, if I look at the commits from the last few weeks, I don't see anything that would indicate any possible area. #Zephyr

  7. Note that all of this worked, and as far as I can tell, nothing on my side changed, and it suddenly didn't work any more. Yet, if I look at the commits from the last few weeks, I don't see anything that would indicate any possible area. #Zephyr

  8. Note that all of this worked, and as far as I can tell, nothing on my side changed, and it suddenly didn't work any more. Yet, if I look at the commits from the last few weeks, I don't see anything that would indicate any possible area.

  9. Note that all of this worked, and as far as I can tell, nothing on my side changed, and it suddenly didn't work any more. Yet, if I look at the commits from the last few weeks, I don't see anything that would indicate any possible area. #Zephyr

  10. Note that all of this worked, and as far as I can tell, nothing on my side changed, and it suddenly didn't work any more. Yet, if I look at the commits from the last few weeks, I don't see anything that would indicate any possible area. #Zephyr

  11. It seems like it should *only* be in libapp.a, so why is it ending up in libzephyr.a? Shouldn't that *just* be OS-level code, and not anything from my code?

    And yet, there it is (nm -C):

    utils.cpp.obj:
    00000000 T coherent::utils::get_random_uint8(unsigned char)
    00000000 T coherent::utils::get_random_uint8(unsigned char, unsigned char)
    00000000 T coherent::utils::get_random_uint8()
    00000000 T coherent::utils::get_random_uint32(unsigned int)
    00000000 T coherent::utils::get_random_uint32(unsigned int, unsigned int)
    00000000 T coherent::utils::get_random_uint32()

    What, for the love of Zeus, is going on here? #Zephyr

  12. It seems like it should *only* be in libapp.a, so why is it ending up in libzephyr.a? Shouldn't that *just* be OS-level code, and not anything from my code?

    And yet, there it is (nm -C):

    utils.cpp.obj:
    00000000 T coherent::utils::get_random_uint8(unsigned char)
    00000000 T coherent::utils::get_random_uint8(unsigned char, unsigned char)
    00000000 T coherent::utils::get_random_uint8()
    00000000 T coherent::utils::get_random_uint32(unsigned int)
    00000000 T coherent::utils::get_random_uint32(unsigned int, unsigned int)
    00000000 T coherent::utils::get_random_uint32()

    What, for the love of Zeus, is going on here? #Zephyr

  13. It seems like it should *only* be in libapp.a, so why is it ending up in libzephyr.a? Shouldn't that *just* be OS-level code, and not anything from my code?

    And yet, there it is (nm -C):

    utils.cpp.obj:
    00000000 T coherent::utils::get_random_uint8(unsigned char)
    00000000 T coherent::utils::get_random_uint8(unsigned char, unsigned char)
    00000000 T coherent::utils::get_random_uint8()
    00000000 T coherent::utils::get_random_uint32(unsigned int)
    00000000 T coherent::utils::get_random_uint32(unsigned int, unsigned int)
    00000000 T coherent::utils::get_random_uint32()

    What, for the love of Zeus, is going on here?

  14. It seems like it should *only* be in libapp.a, so why is it ending up in libzephyr.a? Shouldn't that *just* be OS-level code, and not anything from my code?

    And yet, there it is (nm -C):

    utils.cpp.obj:
    00000000 T coherent::utils::get_random_uint8(unsigned char)
    00000000 T coherent::utils::get_random_uint8(unsigned char, unsigned char)
    00000000 T coherent::utils::get_random_uint8()
    00000000 T coherent::utils::get_random_uint32(unsigned int)
    00000000 T coherent::utils::get_random_uint32(unsigned int, unsigned int)
    00000000 T coherent::utils::get_random_uint32()

    What, for the love of Zeus, is going on here? #Zephyr

  15. It seems like it should *only* be in libapp.a, so why is it ending up in libzephyr.a? Shouldn't that *just* be OS-level code, and not anything from my code?

    And yet, there it is (nm -C):

    utils.cpp.obj:
    00000000 T coherent::utils::get_random_uint8(unsigned char)
    00000000 T coherent::utils::get_random_uint8(unsigned char, unsigned char)
    00000000 T coherent::utils::get_random_uint8()
    00000000 T coherent::utils::get_random_uint32(unsigned int)
    00000000 T coherent::utils::get_random_uint32(unsigned int, unsigned int)
    00000000 T coherent::utils::get_random_uint32()

    What, for the love of Zeus, is going on here? #Zephyr

  16. OK, this is the thing that's happening again... maybe I didn't fix it? First, the error (tweaked to reduce lots of noise)

    .../ld.bfd: zephyr/libzephyr.a(utils.cpp.obj): in function `coherent::utils::get_random_uint8(unsigned char, unsigned char)':
    /Users/petrilli/workspace/foo/lib/coherent-common/src/utils.cpp:22: multiple definition of `coherent::utils::get_random_uint8(unsigned char, unsigned char)'; app/libapp.a(utils.cpp.obj):/Users/petrilli/workspace/foo/lib/coherent-common/src/utils.cpp:22: first defined here

    Which, as best as I can unravel, means that for some reason, Cmake put the utils.cpp.obj compiled file into two different libraries, and then tried to link them together. Yes, that seems bad.

    But why? I have one of these in the application CMakeLIst.txt:

    add_subdirectory_ifdef(CONFIG_COHERENT_COMMON ../../lib/coherent-common coherent-common)

    That should look at the configuration, and add the top-level directory to all the search paths. Great, that's working just fine it seems.

    Then in the coherent-common, I have this in CMakeList.txt:

    if(CONFIG_COHERENT_COMMON)
    zephyr_library_sources(src/utils.cpp)
    zephyr_include_directories(include)
    endif()

    Again, I'm being super careful right now with not using any globbing. What's even more confusing is... this is triggered even if I never include the header file and never call any functions in the library. It *should* be pruning all that out in the process.

    #Zephyr

  17. OK, this is the thing that's happening again... maybe I didn't fix it? First, the error (tweaked to reduce lots of noise)

    .../ld.bfd: zephyr/libzephyr.a(utils.cpp.obj): in function `coherent::utils::get_random_uint8(unsigned char, unsigned char)':
    /Users/petrilli/workspace/foo/lib/coherent-common/src/utils.cpp:22: multiple definition of `coherent::utils::get_random_uint8(unsigned char, unsigned char)'; app/libapp.a(utils.cpp.obj):/Users/petrilli/workspace/foo/lib/coherent-common/src/utils.cpp:22: first defined here

    Which, as best as I can unravel, means that for some reason, Cmake put the utils.cpp.obj compiled file into two different libraries, and then tried to link them together. Yes, that seems bad.

    But why? I have one of these in the application CMakeLIst.txt:

    add_subdirectory_ifdef(CONFIG_COHERENT_COMMON ../../lib/coherent-common coherent-common)

    That should look at the configuration, and add the top-level directory to all the search paths. Great, that's working just fine it seems.

    Then in the coherent-common, I have this in CMakeList.txt:

    if(CONFIG_COHERENT_COMMON)
    zephyr_library_sources(src/utils.cpp)
    zephyr_include_directories(include)
    endif()

    Again, I'm being super careful right now with not using any globbing. What's even more confusing is... this is triggered even if I never include the header file and never call any functions in the library. It *should* be pruning all that out in the process.

    #Zephyr

  18. OK, this is the thing that's happening again... maybe I didn't fix it? First, the error (tweaked to reduce lots of noise)

    .../ld.bfd: zephyr/libzephyr.a(utils.cpp.obj): in function `coherent::utils::get_random_uint8(unsigned char, unsigned char)':
    /Users/petrilli/workspace/foo/lib/coherent-common/src/utils.cpp:22: multiple definition of `coherent::utils::get_random_uint8(unsigned char, unsigned char)'; app/libapp.a(utils.cpp.obj):/Users/petrilli/workspace/foo/lib/coherent-common/src/utils.cpp:22: first defined here

    Which, as best as I can unravel, means that for some reason, Cmake put the utils.cpp.obj compiled file into two different libraries, and then tried to link them together. Yes, that seems bad.

    But why? I have one of these in the application CMakeLIst.txt:

    add_subdirectory_ifdef(CONFIG_COHERENT_COMMON ../../lib/coherent-common coherent-common)

    That should look at the configuration, and add the top-level directory to all the search paths. Great, that's working just fine it seems.

    Then in the coherent-common, I have this in CMakeList.txt:

    if(CONFIG_COHERENT_COMMON)
    zephyr_library_sources(src/utils.cpp)
    zephyr_include_directories(include)
    endif()

    Again, I'm being super careful right now with not using any globbing. What's even more confusing is... this is triggered even if I never include the header file and never call any functions in the library. It *should* be pruning all that out in the process.

  19. OK, this is the thing that's happening again... maybe I didn't fix it? First, the error (tweaked to reduce lots of noise)

    .../ld.bfd: zephyr/libzephyr.a(utils.cpp.obj): in function `coherent::utils::get_random_uint8(unsigned char, unsigned char)':
    /Users/petrilli/workspace/foo/lib/coherent-common/src/utils.cpp:22: multiple definition of `coherent::utils::get_random_uint8(unsigned char, unsigned char)'; app/libapp.a(utils.cpp.obj):/Users/petrilli/workspace/foo/lib/coherent-common/src/utils.cpp:22: first defined here

    Which, as best as I can unravel, means that for some reason, Cmake put the utils.cpp.obj compiled file into two different libraries, and then tried to link them together. Yes, that seems bad.

    But why? I have one of these in the application CMakeLIst.txt:

    add_subdirectory_ifdef(CONFIG_COHERENT_COMMON ../../lib/coherent-common coherent-common)

    That should look at the configuration, and add the top-level directory to all the search paths. Great, that's working just fine it seems.

    Then in the coherent-common, I have this in CMakeList.txt:

    if(CONFIG_COHERENT_COMMON)
    zephyr_library_sources(src/utils.cpp)
    zephyr_include_directories(include)
    endif()

    Again, I'm being super careful right now with not using any globbing. What's even more confusing is... this is triggered even if I never include the header file and never call any functions in the library. It *should* be pruning all that out in the process.

    #Zephyr

  20. OK, this is the thing that's happening again... maybe I didn't fix it? First, the error (tweaked to reduce lots of noise)

    .../ld.bfd: zephyr/libzephyr.a(utils.cpp.obj): in function `coherent::utils::get_random_uint8(unsigned char, unsigned char)':
    /Users/petrilli/workspace/foo/lib/coherent-common/src/utils.cpp:22: multiple definition of `coherent::utils::get_random_uint8(unsigned char, unsigned char)'; app/libapp.a(utils.cpp.obj):/Users/petrilli/workspace/foo/lib/coherent-common/src/utils.cpp:22: first defined here

    Which, as best as I can unravel, means that for some reason, Cmake put the utils.cpp.obj compiled file into two different libraries, and then tried to link them together. Yes, that seems bad.

    But why? I have one of these in the application CMakeLIst.txt:

    add_subdirectory_ifdef(CONFIG_COHERENT_COMMON ../../lib/coherent-common coherent-common)

    That should look at the configuration, and add the top-level directory to all the search paths. Great, that's working just fine it seems.

    Then in the coherent-common, I have this in CMakeList.txt:

    if(CONFIG_COHERENT_COMMON)
    zephyr_library_sources(src/utils.cpp)
    zephyr_include_directories(include)
    endif()

    Again, I'm being super careful right now with not using any globbing. What's even more confusing is... this is triggered even if I never include the header file and never call any functions in the library. It *should* be pruning all that out in the process.

    #Zephyr

  21. @azonenberg so, single stepping through the code, the RNG comes up, the entropy sources are running, all the conditioning is working, it's dropping 32b into RNG_DR (the data register), that's constantly changing ..

    So I can't figure out why it thinks the RNG is broken?

    But since it looks like the problem is now in #Zephyr misunderstanding result codes?

    Computers were a mistake.

  22. @azonenberg so, single stepping through the code, the RNG comes up, the entropy sources are running, all the conditioning is working, it's dropping 32b into RNG_DR (the data register), that's constantly changing ..

    So I can't figure out why it thinks the RNG is broken?

    But since it looks like the problem is now in #Zephyr misunderstanding result codes?

    Computers were a mistake.

  23. @azonenberg so, single stepping through the code, the RNG comes up, the entropy sources are running, all the conditioning is working, it's dropping 32b into RNG_DR (the data register), that's constantly changing ..

    So I can't figure out why it thinks the RNG is broken?

    But since it looks like the problem is now in misunderstanding result codes?

    Computers were a mistake.

  24. @azonenberg so, single stepping through the code, the RNG comes up, the entropy sources are running, all the conditioning is working, it's dropping 32b into RNG_DR (the data register), that's constantly changing ..

    So I can't figure out why it thinks the RNG is broken?

    But since it looks like the problem is now in #Zephyr misunderstanding result codes?

    Computers were a mistake.

  25. @azonenberg so, single stepping through the code, the RNG comes up, the entropy sources are running, all the conditioning is working, it's dropping 32b into RNG_DR (the data register), that's constantly changing ..

    So I can't figure out why it thinks the RNG is broken?

    But since it looks like the problem is now in #Zephyr misunderstanding result codes?

    Computers were a mistake.

  26. Mercedes-Benz hosts open-source hardware Automotive Rapid DEvelopment Platform (ARDEP)

    ARDEP (Automotive Rapid DEvelopment Platform) is an open-source hardware and software platform hosted on Mercedes-Benz’s GitHub account and…
    #Germany #DE #Europe #EU #Europa #Mercedes-Benz #Automotive #crowdsupply #developmentboard #kicad #motorcontrol #OpenSource #stm32 #zephyr
    europesays.com/germany/49818/

  27. I wonder what it would take to get LispBM running along side #Zephyr as an extension/scripting layer? There is an example that is walked through, but I feel like this is just using Zephyr as the bottom layer and not as a peer.

    Much to think about.

    I'd honestly like to use Micropython, but it's just too porky. Performance is fine, but if I'm gonna blow that much memory, I might as well use wasm and let someone bring whatever they want.

    lispbm.com/pages/lispbm-zephyr

  28. I wonder what it would take to get LispBM running along side #Zephyr as an extension/scripting layer? There is an example that is walked through, but I feel like this is just using Zephyr as the bottom layer and not as a peer.

    Much to think about.

    I'd honestly like to use Micropython, but it's just too porky. Performance is fine, but if I'm gonna blow that much memory, I might as well use wasm and let someone bring whatever they want.

    lispbm.com/pages/lispbm-zephyr

  29. I wonder what it would take to get LispBM running along side as an extension/scripting layer? There is an example that is walked through, but I feel like this is just using Zephyr as the bottom layer and not as a peer.

    Much to think about.

    I'd honestly like to use Micropython, but it's just too porky. Performance is fine, but if I'm gonna blow that much memory, I might as well use wasm and let someone bring whatever they want.

    lispbm.com/pages/lispbm-zephyr

  30. I wonder what it would take to get LispBM running along side #Zephyr as an extension/scripting layer? There is an example that is walked through, but I feel like this is just using Zephyr as the bottom layer and not as a peer.

    Much to think about.

    I'd honestly like to use Micropython, but it's just too porky. Performance is fine, but if I'm gonna blow that much memory, I might as well use wasm and let someone bring whatever they want.

    lispbm.com/pages/lispbm-zephyr

  31. I wonder what it would take to get LispBM running along side #Zephyr as an extension/scripting layer? There is an example that is walked through, but I feel like this is just using Zephyr as the bottom layer and not as a peer.

    Much to think about.

    I'd honestly like to use Micropython, but it's just too porky. Performance is fine, but if I'm gonna blow that much memory, I might as well use wasm and let someone bring whatever they want.

    lispbm.com/pages/lispbm-zephyr

  32. Zephyr HTTP server (4.0.0 – 4.4.x) is affected by CVE-2026-8023 (HIGH): improper path handling enables unauthenticated remote file access via path traversal (../). Patch status unclear — check advisories & restrict exposure. radar.offseq.com/threat/cve-20 #OffSeq #Zephyr #Infosec #PathTraversal

  33. Zephyr HTTP server (4.0.0 – 4.4.x) is affected by CVE-2026-8023 (HIGH): improper path handling enables unauthenticated remote file access via path traversal (../). Patch status unclear — check advisories & restrict exposure. radar.offseq.com/threat/cve-20 #OffSeq #Zephyr #Infosec #PathTraversal

  34. Zephyr HTTP server (4.0.0 – 4.4.x) is affected by CVE-2026-8023 (HIGH): improper path handling enables unauthenticated remote file access via path traversal (../). Patch status unclear — check advisories & restrict exposure. radar.offseq.com/threat/cve-20 #OffSeq #Zephyr #Infosec #PathTraversal

  35. Zephyr HTTP server (4.0.0 – 4.4.x) is affected by CVE-2026-8023 (HIGH): improper path handling enables unauthenticated remote file access via path traversal (../). Patch status unclear — check advisories & restrict exposure. radar.offseq.com/threat/cve-20 #OffSeq #Zephyr #Infosec #PathTraversal

  36. Zephyr 4.0.0 – 4.4.0 is affected by CVE-2026-10646 (HIGH, CVSS 7.4): use-after-free in getaddrinfo() can cause memory corruption via spoofed DNS responses. Patch pending — limit untrusted network access. radar.offseq.com/threat/cve-20 #OffSeq #Zephyr #CVE #Security

  37. Zephyr 4.0.0 – 4.4.0 is affected by CVE-2026-10646 (HIGH, CVSS 7.4): use-after-free in getaddrinfo() can cause memory corruption via spoofed DNS responses. Patch pending — limit untrusted network access. radar.offseq.com/threat/cve-20 #OffSeq #Zephyr #CVE #Security

  38. Zephyr 4.0.0 – 4.4.0 is affected by CVE-2026-10646 (HIGH, CVSS 7.4): use-after-free in getaddrinfo() can cause memory corruption via spoofed DNS responses. Patch pending — limit untrusted network access. radar.offseq.com/threat/cve-20 #OffSeq #Zephyr #CVE #Security

  39. Zephyr 4.0.0 – 4.4.0 is affected by CVE-2026-10646 (HIGH, CVSS 7.4): use-after-free in getaddrinfo() can cause memory corruption via spoofed DNS responses. Patch pending — limit untrusted network access. radar.offseq.com/threat/cve-20 #OffSeq #Zephyr #CVE #Security

  40. CVE-2026-10643: Zephyr (3.6.0 – 4.4.0) HIGH severity bug enables out-of-bounds kernel heap writes via recvmsg() with IP_PKTINFO. Local users can exploit for memory corruption or escalation. Patch pending — check advisories. radar.offseq.com/threat/cve-20 #OffSeq #Zephyr #CVE202610643 #infosec

  41. CVE-2026-10643: Zephyr (3.6.0 – 4.4.0) HIGH severity bug enables out-of-bounds kernel heap writes via recvmsg() with IP_PKTINFO. Local users can exploit for memory corruption or escalation. Patch pending — check advisories. radar.offseq.com/threat/cve-20 #OffSeq #Zephyr #CVE202610643 #infosec

  42. CVE-2026-10643: Zephyr (3.6.0 – 4.4.0) HIGH severity bug enables out-of-bounds kernel heap writes via recvmsg() with IP_PKTINFO. Local users can exploit for memory corruption or escalation. Patch pending — check advisories. radar.offseq.com/threat/cve-20 #OffSeq #Zephyr #CVE202610643 #infosec

  43. CVE-2026-10643: Zephyr (3.6.0 – 4.4.0) HIGH severity bug enables out-of-bounds kernel heap writes via recvmsg() with IP_PKTINFO. Local users can exploit for memory corruption or escalation. Patch pending — check advisories. radar.offseq.com/threat/cve-20 #OffSeq #Zephyr #CVE202610643 #infosec

  44. And now I have a choice to make... do I rewrite the stm32c5x.c handling of flash erase for #Zephyr to properly account for the EDATA flash (starting at 0x0840 0000), or just "lose" 64K of flash on the chip?

    So weird that ST submitted the code originally (2025-12-16) but it doesn't fully support this part of the chip? That's a lot of storage on an embedded chip to leave on the table.

    I'm just trying to figure out if there's more that needs to be done than just passing LL_FLASH_ERASE_EDATA_AREA instead in erase_page()?

    I think the root of the problem is that I'm not sure how Zephyr deals with multiple different flashes on the same SOC? EDATA is different with either 1.5K or 2K page sizes (versus 8K), depending on some register bits (EDATASEL), so while it's contiguous with the rest of the flash, it isn't the same.

    This may be why it isn't supported... because Zephyr doesn't seem to have a really clear way to implement this.

    Gonna stew on this. Right now, I can burn other flash for configuration storage, but I resent having that much space wasted for no reason.

  45. And now I have a choice to make... do I rewrite the stm32c5x.c handling of flash erase for #Zephyr to properly account for the EDATA flash (starting at 0x0840 0000), or just "lose" 64K of flash on the chip?

    So weird that ST submitted the code originally (2025-12-16) but it doesn't fully support this part of the chip? That's a lot of storage on an embedded chip to leave on the table.

    I'm just trying to figure out if there's more that needs to be done than just passing LL_FLASH_ERASE_EDATA_AREA instead in erase_page()?

    I think the root of the problem is that I'm not sure how Zephyr deals with multiple different flashes on the same SOC? EDATA is different with either 1.5K or 2K page sizes (versus 8K), depending on some register bits (EDATASEL), so while it's contiguous with the rest of the flash, it isn't the same.

    This may be why it isn't supported... because Zephyr doesn't seem to have a really clear way to implement this.

    Gonna stew on this. Right now, I can burn other flash for configuration storage, but I resent having that much space wasted for no reason.

  46. And now I have a choice to make... do I rewrite the stm32c5x.c handling of flash erase for to properly account for the EDATA flash (starting at 0x0840 0000), or just "lose" 64K of flash on the chip?

    So weird that ST submitted the code originally (2025-12-16) but it doesn't fully support this part of the chip? That's a lot of storage on an embedded chip to leave on the table.

    I'm just trying to figure out if there's more that needs to be done than just passing LL_FLASH_ERASE_EDATA_AREA instead in erase_page()?

    I think the root of the problem is that I'm not sure how Zephyr deals with multiple different flashes on the same SOC? EDATA is different with either 1.5K or 2K page sizes (versus 8K), depending on some register bits (EDATASEL), so while it's contiguous with the rest of the flash, it isn't the same.

    This may be why it isn't supported... because Zephyr doesn't seem to have a really clear way to implement this.

    Gonna stew on this. Right now, I can burn other flash for configuration storage, but I resent having that much space wasted for no reason.

  47. And now I have a choice to make... do I rewrite the stm32c5x.c handling of flash erase for #Zephyr to properly account for the EDATA flash (starting at 0x0840 0000), or just "lose" 64K of flash on the chip?

    So weird that ST submitted the code originally (2025-12-16) but it doesn't fully support this part of the chip? That's a lot of storage on an embedded chip to leave on the table.

    I'm just trying to figure out if there's more that needs to be done than just passing LL_FLASH_ERASE_EDATA_AREA instead in erase_page()?

    I think the root of the problem is that I'm not sure how Zephyr deals with multiple different flashes on the same SOC? EDATA is different with either 1.5K or 2K page sizes (versus 8K), depending on some register bits (EDATASEL), so while it's contiguous with the rest of the flash, it isn't the same.

    This may be why it isn't supported... because Zephyr doesn't seem to have a really clear way to implement this.

    Gonna stew on this. Right now, I can burn other flash for configuration storage, but I resent having that much space wasted for no reason.