Date   

Use different memory bank

Antoine Zen-Ruffinen
 

Hi,


I have trouble getting full usage of the RAM on my SoC using zephyr and I might need a little help as I have not found the needed information in the doc. Here's the situation:


I'm using Zephyr on the iMXRT1062 platform which is an Cortex-M7 with 3 separate non-contigus memory banks, from the datasheet (I's a little more complicated than that, but here I simplify):

ITCM (Instruction Tight Coupled Memory) @ 0x0000'0000, size 128K

DTCM (Data Tight Coupled Memory) @ 0x2000'0000, size 128K

OCRAM (General RAM, slower) @ 0x2020'0000, size 768 K


This setup is clearly defined in the .dts and the linker script in `zephyr/soc/arm/nxp_imx/rt/linker.ld`. When compiling an image, I get this same setup printed form the build system too (OCRAM is renamed SRAM by the build system, don't know why):


....

[7/12] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
            DTCM:          0 GB       128 KB      0.00%
            ITCM:          0 GB       128 KB      0.00%
           FLASH:      276524 B        16 MB      1.65%
            SRAM:      114196 B       768 KB     14.52%
        IDT_LIST:         344 B         2 KB     16.80%
[12/12] Linking C executable zephyr/zephyr.elf

As you can see all is placed in SRAM section. I can change and have everything linked to DTCM using KConfig option "CONFIG_DATA_DTCM", but then it's EVERTHING there . I've discovered that there is a macro `__dtcm_data_section` defined in `zephyr/include/linker/section_tags.h` that I thought it will place the variable in DTCM, but if I use it, I got the following error from the linker:


/home/antoine/tools/SDKs/zephyr-sdk-0.11.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/9.2.0/../../../../arm-zephyr-eabi/bin/ld: warning: orphan section `.dtcm_data' from `app/libapp.a(com_uart.c.obj)' being placed in section `.dtcm_data'


My questions: 


 - How to use different non-contigus  memory region with Zephyr ?

 - How can I specify what data should be placed on witch RAM bank ?

 - How to specify that code should be relocated to ITCM while using CODE_DATA_RELOCATION ? I have tried "zephyr_code_relocate(ram_func.c ITCM)" but with no success.

 - Can I place, for instance, all kernel code into ITCM with similar mechanism as "zephyr_code_relocate()" (ITCM  is faster than flash as the flash is external on this SoC)? 




Antoine Zen-Ruffinen

Riedo Networks Ltd
Route de la Fonderie 6, 1700 Fribourg, Switzerland
Tel: +41 26 505 50 03, Fax: +41 26 505 50 01 www.riedonetworks.com


Re: HAL architecture

Erwan Gouriou
 

Additionally to Carles's answer, let me point you to an on going PR that aims at implementing lp modes on stm32:

It only supports L4/WB series for now, but you can contact François in CC if you have some questions to adapt this to your use case.

Cheers

On Thu, 4 Jun 2020 at 16:58, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Noëlle,

 

Thanks for the kind words.

You can use CMSIS, which is built-in with Zephyr, for WFI.

 

Simply use:

 

__WFI();

 

in your C code.

 

The definition is here:

https://github.com/zephyrproject-rtos/cmsis/blob/master/CMSIS/Core/Include/cmsis_gcc.h#L909

 

That said, are you sure you  need to invoke the WFI instruction manually? this is automatically done by Zephyr when the core can be powered down, for example:

https://github.com/zephyrproject-rtos/zephyr/blob/master/arch/arm/core/aarch32/cpu_idle.S#L101

 

Thanks,

 

Carles

 

From: users@... <users@...> On Behalf Of Noëlle Clement via lists.zephyrproject.org
Sent: 04 June 2020 15:09
To: users@...
Subject: [Zephyr-users] HAL architecture

 

Hi everyone!

 

First of all: thanks specifically to Carles Cufi for taking the time a few months ago to give very detailed answers to my questions on whether Zephyr would be a right choice for our device. Partially because of this we're going with Zephyr for now - at least for the upcoming phase where I'm going to develop a prototype!

 

The first step for this prototype is making sure that the OS actually supports the low power mode we need to still meet our battery life requirements. Some context:

- We use the STM32L151CC MCU

- We need to be able to request the WFI (wait_for_interrupt) instruction (we use that one right now)

- In our current (bare-metal) code we use CMSIS +  a separate library (STM32 Standard Peripheral Library), of which the latter actually includes functions for requesting low power modes (including WFI)

 

I'm trying to figure out whether this specific instruction is already part of the HAL of Zephyr for the STM32Lxx MCU's. However, I'm kind of getting lost in the code, since the abstraction seems to be dispersed over multiple locations. I've looked into the documentation of course, but wasn't able to find an answer for my specific question. 

 

It would help me tremendously if someone could point me in the right direction or give a summary of the architecture, so I can check whether it's already supported or can start with implementing it myself.

 

Quick note that I'm relatively new to this, so if you need more information to understand my question or help me, I'm happy to provide it!

 

All the best,

Noelle 

 


Re: HAL architecture

Carles Cufi
 

Hi Noëlle,

 

Thanks for the kind words.

You can use CMSIS, which is built-in with Zephyr, for WFI.

 

Simply use:

 

__WFI();

 

in your C code.

 

The definition is here:

https://github.com/zephyrproject-rtos/cmsis/blob/master/CMSIS/Core/Include/cmsis_gcc.h#L909

 

That said, are you sure you  need to invoke the WFI instruction manually? this is automatically done by Zephyr when the core can be powered down, for example:

https://github.com/zephyrproject-rtos/zephyr/blob/master/arch/arm/core/aarch32/cpu_idle.S#L101

 

Thanks,

 

Carles

 

From: users@... <users@...> On Behalf Of Noëlle Clement via lists.zephyrproject.org
Sent: 04 June 2020 15:09
To: users@...
Subject: [Zephyr-users] HAL architecture

 

Hi everyone!

 

First of all: thanks specifically to Carles Cufi for taking the time a few months ago to give very detailed answers to my questions on whether Zephyr would be a right choice for our device. Partially because of this we're going with Zephyr for now - at least for the upcoming phase where I'm going to develop a prototype!

 

The first step for this prototype is making sure that the OS actually supports the low power mode we need to still meet our battery life requirements. Some context:

- We use the STM32L151CC MCU

- We need to be able to request the WFI (wait_for_interrupt) instruction (we use that one right now)

- In our current (bare-metal) code we use CMSIS +  a separate library (STM32 Standard Peripheral Library), of which the latter actually includes functions for requesting low power modes (including WFI)

 

I'm trying to figure out whether this specific instruction is already part of the HAL of Zephyr for the STM32Lxx MCU's. However, I'm kind of getting lost in the code, since the abstraction seems to be dispersed over multiple locations. I've looked into the documentation of course, but wasn't able to find an answer for my specific question. 

 

It would help me tremendously if someone could point me in the right direction or give a summary of the architecture, so I can check whether it's already supported or can start with implementing it myself.

 

Quick note that I'm relatively new to this, so if you need more information to understand my question or help me, I'm happy to provide it!

 

All the best,

Noelle 

 


JSON

Xavier Naveira
 

Hello,

I am building an application on top of Zephyr that does communicate via MQTT to AWS IoT. I have been using the built in JSON library [1] to encode/parse the messages in json format.

Up until now all the structures that I needed to encode/parse to/from json have been static but I am beginning to encounter cases where some or several fields of a particular object are optional. For what I have seen in the documentation there doesn't seem to be support for optional fields in this library and I was wondering if anyone is using an external library for json and if yes what is the process they followed to incorporate it into their Zephyr app.

Thank you.

Xavier


HAL architecture

Noëlle Clement
 

Hi everyone!

First of all: thanks specifically to Carles Cufi for taking the time a few months ago to give very detailed answers to my questions on whether Zephyr would be a right choice for our device. Partially because of this we're going with Zephyr for now - at least for the upcoming phase where I'm going to develop a prototype!

The first step for this prototype is making sure that the OS actually supports the low power mode we need to still meet our battery life requirements. Some context:
- We use the STM32L151CC MCU
- We need to be able to request the WFI (wait_for_interrupt) instruction (we use that one right now)
- In our current (bare-metal) code we use CMSIS +  a separate library (STM32 Standard Peripheral Library), of which the latter actually includes functions for requesting low power modes (including WFI)

I'm trying to figure out whether this specific instruction is already part of the HAL of Zephyr for the STM32Lxx MCU's. However, I'm kind of getting lost in the code, since the abstraction seems to be dispersed over multiple locations. I've looked into the documentation of course, but wasn't able to find an answer for my specific question. 

It would help me tremendously if someone could point me in the right direction or give a summary of the architecture, so I can check whether it's already supported or can start with implementing it myself.

Quick note that I'm relatively new to this, so if you need more information to understand my question or help me, I'm happy to provide it!

All the best,
Noelle 


Re: Error in Getting Started Guide

Carles Cufi
 

Hi Jim,

 

Zephyr requires Python 3.6, you seem to be using Python 3.5.

 

Carles

 

 

From: users@... <users@...> On Behalf Of jim slaughter via lists.zephyrproject.org
Sent: 04 June 2020 00:33
To: users@...
Cc: jim slaughter <jim.slaughter@...>
Subject: [Zephyr-users] Error in Getting Started Guide

 

Hello,

 

I am new to Zephyr. Problem with Getting Started Guide, UBUNTU Tab

 

Get Zephyr and install Python dependencies

2. Get the Zephyr source code:  

1.  west init ~/zephyrproject

jws@DESKTOP-AJSFNLH:~$ west init ~/zephyrproject
Traceback (most recent call last):
  File "/home/jws/.local/bin/west", line 7, in <module>
    from west.app.main import main
  File "/home/jws/.local/lib/python3.5/site-packages/west/app/main.py", line 180
    log.die(f"file not found: {self.mle.filename}")                                              ^
SyntaxError: invalid syntax

 

Did I miss something in the instructions?

What is wrong?  Line 180

               # This should ordinarily only happen when the top
                # level west.yml is not found.
                log.die(f"file not found: {self.mle.filename}")

 

Thanks.

--

Jim Slaughter


Error in Getting Started Guide

jim slaughter <jim.slaughter@...>
 

Hello,

I am new to Zephyr. Problem with Getting Started Guide, UBUNTU Tab

Get Zephyr and install Python dependencies

2. Get the Zephyr source code:  
  1. west init ~/zephyrproject
jws@DESKTOP-AJSFNLH:~$ west init ~/zephyrproject
Traceback (most recent call last):
  File "/home/jws/.local/bin/west", line 7, in <module>
    from west.app.main import main
  File "/home/jws/.local/lib/python3.5/site-packages/west/app/main.py", line 180
    log.die(f"file not found: {self.mle.filename}")                                              ^
SyntaxError: invalid syntax

Did I miss something in the instructions?
What is wrong?  Line 180
               # This should ordinarily only happen when the top
                # level west.yml is not found.
                log.die(f"file not found: {self.mle.filename}")

Thanks.
--
Jim Slaughter


Zephyr 2.3.0-rc2 tagged

Carles Cufi
 

Hi all,

The second release candidate for Zephyr 2.3.0 has now been tagged (v2.3.0-rc2).

The current issue counts are:

- 1 high-priority bug
- 16 medium-priority bugs

The high-priority bug (#23364) has a PR (#25954), but a waiver to release without a fix for this particular issue has been requested, due to the invasiveness of the Pull Request and the risk of merging it this late in the release cycle. A note would be added to the release notes and a subsequent 2.3.1 would be released to address this issue.

During the days left until the release, I would encourage everybody to test thoroughly and file any issues found so that they can be fixed as quickly as possible. Additionally, there are still sections in the release notes that need filling, those can be tracked here:
https://github.com/zephyrproject-rtos/zephyr/issues/25869

The full release log can be found here:
https://github.com/zephyrproject-rtos/zephyr/releases/tag/v2.3.0-rc2

More details about Zephyr releases can found on the pages below:
https://docs.zephyrproject.org/latest/development_process/release_process.html
https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management

The final release remains scheduled for June 5th.

Thank you to everybody who contributed to this release so far!

Carles


Re: Full supported 802.15.4 modules (i.e as radio interfaces by zephyr's kernel) #nrf52840

Nikos Karamolegkos
 

Thank you Jukka for your reply. I think I will stay with the nrf52840 dk. If there is no other suggestion

On 6/2/20 4:10 PM, Jukka Rissanen wrote:
nrf52840 dk
--
Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


Re: Support for Atmel SAMG55

Kumar Gala
 

On Jun 1, 2020, at 8:25 AM, Michael Hope <michaelh@juju.nz> wrote:

Hi Adam. I just so happen to be adding support for the Adafruit
ItsyBitsy M4 board ATM. It's SAMD51 based which seems to be basically
the same as the SAMG55.

I've checked the UART, GPIO, SPI, and watchdog drivers so far. I'm
adding a PWM and QSPI driver, and will check the USB driver.

You'll need to create your own board definition and to create the
device tree files.

-- Michael
Just an FYI, working on moving pinmux for SAM0 over to DTS like I did for atmel SAM.

Also, we’re under some discussions on QSPI so good to know that you are looking at support for that as well on SAM0.

- k


API meeting: agenda

Carles Cufi
 

Hi all,

*************************************************
We will be using Teams instead of Zoom:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_YzYzZTAzNGItOWFiMS00MDBkLTkyYmMtNzljZjkwNDVlMThm%40thread.v2/0?context=%7b%22Tid%22%3a%22686ea1d3-bc2b-4c6f-a92c-d99c5c301635%22%2c%22Oid%22%3a%2262b63b80-05d3-4465-b5a0-f04e4e156f10%22%7d
*************************************************

Today's topics:

- QSPI flash drivers:
- Should we revisit the common QSPI API? https://github.com/zephyrproject-rtos/zephyr/pull/20069
- Should it be part of the current SPI API? https://github.com/zephyrproject-rtos/zephyr/issues/17902
- If not, should we try to unify the common functionality in the multiple QSPI flash drivers?
- https://github.com/zephyrproject-rtos/zephyr/pull/25806
- https://github.com/zephyrproject-rtos/zephyr/pull/25669

- SPI JEDEC runtime support
- PR https://github.com/zephyrproject-rtos/zephyr/pull/23658

- RTC API follow-up (if the relevant people are present and there is material for discussion)
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23526

Pending additional investigation:
- Documenting API behavior in Doxygen:
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/18970
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/21061

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


Re: Full supported 802.15.4 modules (i.e as radio interfaces by zephyr's kernel) #nrf52840

Jukka Rissanen
 

Hi Nikos,

Don't know about exact boards, but currently we have 802.15.4 drivers
for following chips/shields in drivers/ieee802154

source "drivers/ieee802154/Kconfig.cc2520"
source "drivers/ieee802154/Kconfig.kw41z"
source "drivers/ieee802154/Kconfig.mcr20a"
source "drivers/ieee802154/Kconfig.nrf5"
source "drivers/ieee802154/Kconfig.cc1200"
source "drivers/ieee802154/Kconfig.cc13xx_cc26xx"
source "drivers/ieee802154/Kconfig.rf2xx"
source "drivers/ieee802154/Kconfig.dw1000"

so if your board or shield supports one of these radios, then 6lowpan
and lwm2m should work there too.


Cheers,
Jukka

On Tue, 2020-06-02 at 03:19 -0700, Nikos Karamolegkos wrote:
Hello to everyone, in this link1 there is a list with all the modules
supported by zephyr. I am interested in 802.15.4 modules that are
fully supported by Zephyr's kernel. Based on this discussion and some
more research I conclude that the supported modules can be the
following:
1) reel board
2) frdm kw41z
3) quark se dev board
4) frdm k64f with the cr20a shield
5) nucleo wb55rg
6) nrf52840 dk

However, the #3 does not exist in the latest zephyr documentation,
the #1 and #5 are supported by the kernel only for the Bluetooth
radio interface. The #2 according the documentation is not supported
for any radio interface although in the fore-mentioned discussion is
reported that the user used ping6 and also there is the NXP KW41Z
driver in the zephyr/drivers/ieee802154/ folder. For the #4 the
things are almost the same with #2, the only difference is that I can
not find in the documentation what radio interfaces are supported.
Finally, for the #6 seems that both 802.15.4 and Bluetooth are
supported as radio interfaces and also there is the driver in the
drivers folder (so is the only option?).

To conclude, what 802.15.4 device should I buy which will be fully
supported and tested (the minimum number of bugs)? Are there any
other devices? (the driver folder has enough devices)
At this time I have nucleo wb55rg but I don't have enough time to
port it into Zephyr RTOS. I need a robust solution to use with
6lowpan stack and lwm2m


Full supported 802.15.4 modules (i.e as radio interfaces by zephyr's kernel) #nrf52840

Nikos Karamolegkos
 

Hello to everyone, in this link1 there is a list with all the modules supported by zephyr. I am interested in 802.15.4 modules that are fully supported by Zephyr's kernel. Based on this discussion and some more research I conclude that the supported modules can be the following:
1) reel board
2) frdm kw41z
3) quark se dev board
4) frdm k64f with the cr20a shield
5) nucleo wb55rg
6) nrf52840 dk

However, the #3 does not exist in the latest zephyr documentation, the #1 and #5 are supported by the kernel only for the Bluetooth radio interface. The #2 according the documentation is not supported for any radio interface although in the fore-mentioned discussion is reported that the user used ping6 and also there is the NXP KW41Z driver in the zephyr/drivers/ieee802154/ folder.  For the #4 the things are almost the same with #2, the only difference is that I can not find in the documentation what radio interfaces are supported. Finally, for the #6 seems that both 802.15.4 and Bluetooth are supported as radio interfaces and also there is the driver in the drivers folder (so is the only option?).

To conclude, what 802.15.4 device should I buy which will be fully supported and tested (the minimum number of bugs)? Are there any other devices? (the driver folder has enough devices)
At this time I have nucleo wb55rg but I don't have enough time to port it into Zephyr RTOS. I need a robust solution to use with 6lowpan stack and lwm2m


Re: Support for Atmel SAMG55

Michael Hope
 

Yip, looks like I jumped the gun. Sorry about that!

On Mon, 1 Jun 2020 at 18:10, Adam Podogrocki <a.podogrocki@gmail.com> wrote:

Hi Michael,

I'm afraid it won't be as easy as using definition for SAMD51. I've compared memory mapping. It is enough to see that Internal Flash has different address, there is Internal ROM in G55. G55 has a single AHB-APB Brigde, wheres D51 has 4 Bridges. In D51 there are Serial Communication Interfaces (SERCOM) which can be configured in I2C, SPI, or USART mode. In G55 similar role is played by FLEXCOM, but memory addresses are different.

In short words it looks like G55 needs its own HAL files.

BR,
Adam

On Mon, 1 Jun 2020 at 15:25, Michael Hope <michaelh@juju.nz> wrote:

Hi Adam. I just so happen to be adding support for the Adafruit
ItsyBitsy M4 board ATM. It's SAMD51 based which seems to be basically
the same as the SAMG55.

I've checked the UART, GPIO, SPI, and watchdog drivers so far. I'm
adding a PWM and QSPI driver, and will check the USB driver.

You'll need to create your own board definition and to create the
device tree files.

-- Michael

On Mon, 1 Jun 2020 at 14:32, Adam Podogrocki <a.podogrocki@gmail.com> wrote:

Hi,

are there any activities ongoing to add support for SAMG55 MCU to Zephyr?

Regards,
Adam


Re: Support for Atmel SAMG55

Adam Podogrocki
 

Hi Michael,

I'm afraid it won't be as easy as using definition for SAMD51. I've compared memory mapping. It is enough to see that Internal Flash has different address, there is Internal ROM in G55. G55 has a single AHB-APB Brigde, wheres D51 has 4 Bridges. In D51 there are Serial Communication Interfaces (SERCOM) which can be configured in I2C, SPI, or USART mode. In G55 similar role is played by FLEXCOM, but memory addresses are different.

In short words it looks like G55 needs its own HAL files.

BR,
Adam

On Mon, 1 Jun 2020 at 15:25, Michael Hope <michaelh@...> wrote:
Hi Adam.  I just so happen to be adding support for the Adafruit
ItsyBitsy M4 board ATM.  It's SAMD51 based which seems to be basically
the same as the SAMG55.

I've checked the UART, GPIO, SPI, and watchdog drivers so far.  I'm
adding a PWM and QSPI driver, and will check the USB driver.

You'll need to create your own board definition and to create the
device tree files.

-- Michael

On Mon, 1 Jun 2020 at 14:32, Adam Podogrocki <a.podogrocki@...> wrote:
>
> Hi,
>
> are there any activities ongoing to add support for SAMG55 MCU to Zephyr?
>
> Regards,
> Adam


Re: Support for Atmel SAMG55

Michael Hope
 

Hi Adam. I just so happen to be adding support for the Adafruit
ItsyBitsy M4 board ATM. It's SAMD51 based which seems to be basically
the same as the SAMG55.

I've checked the UART, GPIO, SPI, and watchdog drivers so far. I'm
adding a PWM and QSPI driver, and will check the USB driver.

You'll need to create your own board definition and to create the
device tree files.

-- Michael

On Mon, 1 Jun 2020 at 14:32, Adam Podogrocki <a.podogrocki@gmail.com> wrote:

Hi,

are there any activities ongoing to add support for SAMG55 MCU to Zephyr?

Regards,
Adam


Support for Atmel SAMG55

Adam Podogrocki
 

Hi,

are there any activities ongoing to add support for SAMG55 MCU to Zephyr?

Regards,
Adam 


Re: USB Questions

Adam Podogrocki
 

Hi Anton,

regarding point 2 to use the USB device as a console, please add:
 
 CONFIG_UART_CONSOLE_ON_DEV_NAME="CDC_ACM"
 CONFIG_USB_UART_CONSOLE=y
 CONFIG_UART_LINE_CTRL=y

samples/subsys/usb/cdc_acm/src/main.c shows that binding is got for "CDC_ACM_0", so check both option at the best.

Regards,
Adam

On Sun, 24 May 2020 at 19:03, <antoker@...> wrote:

Hi,

I've been testing out Zephyr's USB connectivity options on FRDM-K22F and got some questions:

  1. samples/subsys/usb/console/ compiles and runs okay as long as the USB is connected. If usb is not connected the application will not run, this happens, as I can see it because of flag CONFIG_USB_UART_DTR_WAIT=y. My understanding was that if i compile the app with CONFIG_USB_UART_DTR_WAIT=n the application will run immediately, however after compiling and uploading it to target the USB CDC Serial is not being recognized by the host operating system. Is it all possible to have a console via USB without the DTR flag?
  2. Is it possible to have shell redirected to USB Serial? The documentation is kinda of cryptic regarding this.

BR

Anton


Re: Compile as much code as possible.

Paul Sokolovsky
 

On Sat, 30 May 2020 19:25:48 +0000
"Carles Cufi" <carles.cufi@nordicsemi.no> wrote:

Hi there,

No, there is not. In part because Zephyr requires a board to be
passed as a parameter to the build system, and the board determines
the basic set of Kconfig options. You could I guess create a board
that tries to enable everything (at least everything in an arch).
We for example have
https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/net/all/prj.conf ,
can extend such a practice to other subsystems (if they don't have it,
didn't look), and then to entire Zephyr. (Except that we have CI which
can't build 500 one-line changes, so would need to deal with that
first^W too).


Carles
[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: Compile as much code as possible.

Carles Cufi
 

Hi there,

 

No, there is not. In part because Zephyr requires a board to be passed as a parameter to the build system, and the board determines the basic set of Kconfig options.

You could I guess create a board that tries to enable everything (at least everything in an arch).

 

Carles

 

From: users@... <users@...> On Behalf Of istuoli via lists.zephyrproject.org
Sent: 30 May 2020 10:27
To: users@...
Subject: [Zephyr-users] Compile as much code as possible.

 

Hello! I want to compile as much code as possible. Is there any command like make allyesconfig in linux?

681 - 700 of 2707