Date   

Re: Increasing bss section in Zephyr

Sukumar Ghorai
 

I was checking ROM and RAM size in arduino_101:
CONFIG_XIP=y
CONFIG_PHYS_LOAD_ADDR=0x40030000
CONFIG_PHYS_RAM_ADDR =0xA8006400
CONFIG_RAM_SIZE=55
CONFIG_ROM_SIZE=144

Why load-address(0x40030000) is lower compare to ram-address (0xA8006400)?

~Sukumar

On Tue, Sep 6, 2016 at 9:39 PM, Boie, Andrew P <andrew.p.boie(a)intel.com> wrote:
Typically the RAM region is defined to be the size of the available RAM on
the target board.



You are in one of two scenarios:

- The size of RAM defined by the build is too small, there is
actually more RAM available, and the board configuration needs to be updated
to the true size

- You need more .bss than there is available RAM on the device, in
which case you need to conserve RAM elsewhere or use a different board.



Unfortunately, the latter is the most likely.

What board is this?

If Arduino 101, RAM between ARC and x86 side is shared with different
regions for each. The default is 55K for x86 and 24K for ARC, with 1K of
shared space. 80K total available. If you don’t need the ARC you could claim
its ram on the x86 side.



Andrew



From: Mahendravarman Rajarao (RBEI/EAA3)
[mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Monday, September 5, 2016 11:27 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Increasing bss section in Zephyr



Hi All



How to Increase the .bss section in Zephyr ?



There is a requirement for my project to have a big size array for 15K

If I declare and compile , getting error as



.bss will not fit in region RAM

Region ‘RAM’ overflowed by 20160 bytes



Any help on this regard is welcome !!



Mahendra


Re: Proposal to streamline GPIO, Pinmux driver API

Piotr Mienkowski <Piotr.Mienkowski@...>
 

I have created a Jira issue: https://jira.zephyrproject.org/browse/ZEP-781

I would like to encourage anyone interested to add Jira comment / watch the issue.


Re: How to handle a board with a dozen SoC's?

Jon Medhurst (Tixy) <tixy@...>
 

On Tue, 2016-09-06 at 16:03 +0000, Boie, Andrew P wrote:
What I did for Nios II (which is a soft-CPU that runs on Altera FPGAs)
is to define each different Nios II configuration as a different soc
in the Zephyr build.

So for example I have the "nios2f-zephyr" soc which is the reference
config. Then another one "nios2-qemu" for the QEMU emulator which has
slightly different settings. Each one has a system.h header file with
all the configuration details. In this case the system.h was generated
by the Altera tools.

See arch/nios2/soc/ for what I mean.
This is assuming that the CPU types you want to support are of a
family of the same basic architecture with different configuration
options.
Well, they are all ARM at least :-). Some v7 some v8 architecture, some
single core, some multi core, some with caches, memory and security
protection areas. Some with DMA.

From looking at the nios stuff, it seems there is a separate board and
soc for each combinations, so in my case 20 socs and 20 boards. :-(

Perhaps I'll end up with some custom makefiles and scripts to generate
all these from some kind of meta config. Though possibly it might be as
simple as one board, one SoC and multiple defconfigs (but zephyr top
level scripts seem to assume one board == one defconfig ??).

For now, I hacked up a couple of board directories and a soc directory
just so I can write and test device drivers, but I'm aware I'll need to
dealing with this properly at some point.

As a slight tangent, I'm also doing other things in 'non-standard'
Zephyr ways for things like drivers, because I can't bring myself to
cut'n'paste Kconfig and code segments to support multiple instances of
drivers (most boards have 5 UARTs and 5 SPI devices).

HTH,
Andrew
Not sure it did, but thanks for reply. :-)

--
Tixy


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 1
[ZEP-775] Enable USB CDC by default on Arduino 101 and redirect serial to USB
https://jira.zephyrproject.org/browse/ZEP-775


UPDATED JIRA items within last 24 hours: 1
[ZEP-346] Provide a HTTP library within Zephyr
https://jira.zephyrproject.org/browse/ZEP-346


CLOSED JIRA items within last 24 hours: 1
[ZEP-576] (Won't Do) hello_world app linking failed with zephyr sdk x86 toolchain
https://jira.zephyrproject.org/browse/ZEP-576


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4552 : build: support pre-built host tools (DO NOT MERGE)
- https://gerrit.zephyrproject.org/r/4550 : samples: move pci tests to tests/
- https://gerrit.zephyrproject.org/r/4548 : Bluetooth: Controller: Switch to Zephyr's hci.h for cmd handling
- https://gerrit.zephyrproject.org/r/4551 : tests: move test code from samples to tests
- https://gerrit.zephyrproject.org/r/4547 : Bluetooth: Controller: Unify handling of CC and CS
- https://gerrit.zephyrproject.org/r/4546 : Bluetooth: Controller: Unify handling of unknown command
- https://gerrit.zephyrproject.org/r/4557 : Bluetooth: BR/EDR Write Class of device
- https://gerrit.zephyrproject.org/r/4561 : net: yaip: Use generic memory alignement helper
- https://gerrit.zephyrproject.org/r/4560 : net: buf: Use generic memory alignement helper
- https://gerrit.zephyrproject.org/r/4559 : misc: Add an helper for memory alignement
- https://gerrit.zephyrproject.org/r/4549 : samples: move spi tests to tests/
- https://gerrit.zephyrproject.org/r/4554 : Bluetooth: HCI: Add definitions and macros
- https://gerrit.zephyrproject.org/r/4553 : Bluetooth: HCI: Rename cmd complete struct
- https://gerrit.zephyrproject.org/r/4555 : Bluetooth: HFP HF: Implementation of SLC
- https://gerrit.zephyrproject.org/r/4545 : Bluetooth: A2DP: Connect and Disconnect
- https://gerrit.zephyrproject.org/r/4541 : DONT MERGE

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4166 : samples: net: Moving the current ieee802154 sample
- https://gerrit.zephyrproject.org/r/4167 : samples: net: Qemu make utilities update
- https://gerrit.zephyrproject.org/r/4506 : build: make sysgen take optional command line arguments
- https://gerrit.zephyrproject.org/r/4508 : build: only generate the SSE group for x86
- https://gerrit.zephyrproject.org/r/4507 : sysgen: add --kernel_type argument
- https://gerrit.zephyrproject.org/r/4505 : kernel: add CONFIG_MDEF
- https://gerrit.zephyrproject.org/r/4327 : fix: "uninitialized" variables break DEBUG sanity
- https://gerrit.zephyrproject.org/r/4532 : fix: net samples no longer include unneeded 802.15.4 files
- https://gerrit.zephyrproject.org/r/4503 : slist: add sys_slist_get() to fetch and remove the head
- https://gerrit.zephyrproject.org/r/4341 : Bluetooth: HFP HF: Initialize Handsfree profile
- https://gerrit.zephyrproject.org/r/4375 : tests: fixed resulting binary name in README
- https://gerrit.zephyrproject.org/r/4471 : sanitycheck: allow extra arguments to be passed to the build
- https://gerrit.zephyrproject.org/r/4502 : dlist: add static initialization macro
- https://gerrit.zephyrproject.org/r/4504 : slist: add sys_slist_append_list/slist()
- https://gerrit.zephyrproject.org/r/4447 : Bluetooth: AVDTP: Module Initialization
- https://gerrit.zephyrproject.org/r/4501 : dlist: add SYS_DLIST_FOR_EACH_NODE/_SAFE
- https://gerrit.zephyrproject.org/r/4539 : Bluetooth: tester: Add support for L2CAP send data command
- https://gerrit.zephyrproject.org/r/4376 : Bluetooth: GAP: Support multiple peripheral role connections
- https://gerrit.zephyrproject.org/r/4253 : net: yaip: ieee802154: Add CSMA-CA non slotted radio protocol support
- https://gerrit.zephyrproject.org/r/4165 : net: drivers: Add a fake ieee802154 radio driver for qemu
- https://gerrit.zephyrproject.org/r/3848 : lib: Introduce the CoAP implementation for Zephyr
- https://gerrit.zephyrproject.org/r/4294 : net: drivers: Normalize ieee802154 Kconfig
- https://gerrit.zephyrproject.org/r/4252 : net: yaip: Centralize generic IEEE 802.15.4 radio utility functions
- https://gerrit.zephyrproject.org/r/4168 : net: samples: Add a simple Qemu sample for testing off-line 802.15.4
- https://gerrit.zephyrproject.org/r/4293 : net: drivers: cc2520 ieee802154 drivers select relevant options
- https://gerrit.zephyrproject.org/r/4164 : net: ieee802154: Add basic support for IEEE 802.15.4e on FCF
- https://gerrit.zephyrproject.org/r/3527 : console: shell: Shell enhancement - Support multiple modules
- https://gerrit.zephyrproject.org/r/4466 : Bluetooth: RFCOMM: Implement TX flow control
- https://gerrit.zephyrproject.org/r/4495 : Bluetooth: tester: Add support for L2CAP listen command
- https://gerrit.zephyrproject.org/r/4494 : Bluetooth: tester: Add support for L2CAP disconnect commands
- https://gerrit.zephyrproject.org/r/4493 : Bluetooth: tester: Add support for L2CAP connect command
- https://gerrit.zephyrproject.org/r/4492 : Bluetooth: tester: Add L2CAP init method
- https://gerrit.zephyrproject.org/r/4251 : net: yaip: ieee802154: Normalize Kconfig
- https://gerrit.zephyrproject.org/r/4304 : net: Legacy IP stack Kconfig has nothing to do with new stack
- https://gerrit.zephyrproject.org/r/4292 : net: Split debug Kconfig options from legacy to new stack
- https://gerrit.zephyrproject.org/r/4291 : net: yaip: Normalize Kconfig and fix it
- https://gerrit.zephyrproject.org/r/4290 : net: yaip: Move IPv4 related Kconfig options to its own file
- https://gerrit.zephyrproject.org/r/4289 : net: yaip: Move IPv6 related Kconfig options to its own file
- https://gerrit.zephyrproject.org/r/4248 : net: Fix net_send return value documentation
- https://gerrit.zephyrproject.org/r/4486 : Bluetooth: SDP: Server: Initialize and accept incoming connections
- https://gerrit.zephyrproject.org/r/4457 : DONT MERGE
- https://gerrit.zephyrproject.org/r/3853 : MAINTAINERS: add Zoap section
- https://gerrit.zephyrproject.org/r/3851 : samples/net: Add a sample for a CoAP server
- https://gerrit.zephyrproject.org/r/3850 : samples/net: Add a sample for a CoAP client
- https://gerrit.zephyrproject.org/r/3849 : tests: Add simple CoAP tests
- https://gerrit.zephyrproject.org/r/4540 : Bluetooth: AVDTP: Connect and Disconnect

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4542 : net: contiki: simplerdc: Fix an uninitialized variable warning
- https://gerrit.zephyrproject.org/r/4556 : Updated nav.awk file to fix yaml indentation.
- https://gerrit.zephyrproject.org/r/4543 : net: yaip: Add a macro to create specific net if instances
- https://gerrit.zephyrproject.org/r/3957 : microkernel: remove deprecated task IRQs
- https://gerrit.zephyrproject.org/r/3844 : test_context: don't test dynamic exceptions
- https://gerrit.zephyrproject.org/r/3843 : zephyr: remove deprecated dynamic interrupt API
- https://gerrit.zephyrproject.org/r/4535 : kconfig: Use HOST_OS environment variable in Makefile
- https://gerrit.zephyrproject.org/r/4491 : net: revert tcpip_poll_tcp() to not require a data_buf
- https://gerrit.zephyrproject.org/r/4448 : net: uip: Fix udp_socket_process receive data callback buffer handling.
- https://gerrit.zephyrproject.org/r/4449 : net: Fix code formatting
- https://gerrit.zephyrproject.org/r/4451 : net: uip: Fix compile fail with stats enabled, tcp disabled.
- https://gerrit.zephyrproject.org/r/4462 : Bluetooth: Controller: Enable all supported LE states
- https://gerrit.zephyrproject.org/r/4534 : Bluetooth: GATT: Fix unaligned accesses


Re: Increasing bss section in Zephyr

Boie, Andrew P
 

Typically the RAM region is defined to be the size of the available RAM on the target board.

You are in one of two scenarios:

- The size of RAM defined by the build is too small, there is actually more RAM available, and the board configuration needs to be updated to the true size

- You need more .bss than there is available RAM on the device, in which case you need to conserve RAM elsewhere or use a different board.

Unfortunately, the latter is the most likely.
What board is this?
If Arduino 101, RAM between ARC and x86 side is shared with different regions for each. The default is 55K for x86 and 24K for ARC, with 1K of shared space. 80K total available. If you don't need the ARC you could claim its ram on the x86 side.

Andrew

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Monday, September 5, 2016 11:27 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Increasing bss section in Zephyr

Hi All

How to Increase the .bss section in Zephyr ?

There is a requirement for my project to have a big size array for 15K
If I declare and compile , getting error as

.bss will not fit in region RAM
Region 'RAM' overflowed by 20160 bytes

Any help on this regard is welcome !!

Mahendra


Re: How to handle a board with a dozen SoC's?

Boie, Andrew P
 

On Fri, 2016-09-02 at 15:46 +0100, Jon Medhurst (Tixy) wrote:
I'm trying to add Zephyr support for a board [1] where the 'SoC' is an
FPGA that can be programmed with a dozen different CPU types and
varying support IP, and I'm wondering how to organise this.
I realised this and $subject may be a bit ambiguous, I meant that the FPGA can
be programmed at any one time with a single CPU type chosen from a range of
a dozen or so. I'm not trying to support multiple CPU and 'SoC' types in a single
Zephyr image at the same time. I'm looking at a separate image for each one.

What I did for Nios II (which is a soft-CPU that runs on Altera FPGAs) is to define each different Nios II configuration as a different soc in the Zephyr build.

So for example I have the "nios2f-zephyr" soc which is the reference config. Then another one "nios2-qemu" for the QEMU emulator which has slightly different settings. Each one has a system.h header file with all the configuration details. In this case the system.h was generated by the Altera tools.

See arch/nios2/soc/ for what I mean.
This is assuming that the CPU types you want to support are of a family of the same basic architecture with different configuration options.

HTH,
Andrew


Re: Increasing bss section in Zephyr

Andy Ross
 

Mahendravarman Rajarao (RBEI/EAA3) wrote:
If The CONFIG_RAM_SIZE - denotes the internal RAM of controller means,
Iam using Atlas peak controller of 80KB SRAM. Even If I declare
CONFIG_RAM_SIZE = 85 in prj.conf file in my project Zephyr.bin is
getting generated
That just means there's no per-SoC checking of linker memory regions.
Clearly there should be, but obviously that doesn't mean that such a
file is going to execute successfully.

You can check how these are used in arch/x86/soc/quark_se/linker.ld if
you're curious. The linker just emits the sections in the RAM memory
region at CONFIG_PHYS_RAM_ADDR and assumes it can use up to
CONFIG_RAM_SIZE kb.

Andy


Re: Increasing bss section in Zephyr

Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao@...>
 

Hi

Thanks for replying
Please help on the following query

If The CONFIG_RAM_SIZE - denotes the internal RAM of controller means, Iam using Atlas peak controller of 80KB SRAM.
Even If I declare CONFIG_RAM_SIZE = 85 in prj.conf file in my project
Zephyr.bin is getting generated


Please clarify

Thanks
Mahendra

-----Original Message-----
From: Gustavo Lima Chaves [mailto:gustavo.lima.chaves(a)intel.com]
Sent: Tuesday, September 06, 2016 6:54 PM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>
Cc: devel(a)lists.zephyrproject.org
Subject: Re: [devel] Increasing bss section in Zephyr

* Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com> [2016-09-05 18:27:04 +0000]:

Hi All

How to Increase the .bss section in Zephyr ?

There is a requirement for my project to have a big size array for 15K
If I declare and compile , getting error as

.bss will not fit in region RAM
Region 'RAM' overflowed by 20160 bytes

Any help on this regard is welcome !!

Mahendra
Have you taken a look at CONFIG_RAM_SIZE and friends? Last time I dealt with it these were the options I changed.

Regards,

--
Gustavo Lima Chaves
Intel - Open Source Technology Center


Re: Increasing bss section in Zephyr

Gustavo Lima Chaves <gustavo.lima.chaves@...>
 

* Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com> [2016-09-05 18:27:04 +0000]:

Hi All

How to Increase the .bss section in Zephyr ?

There is a requirement for my project to have a big size array for 15K
If I declare and compile , getting error as

.bss will not fit in region RAM
Region 'RAM' overflowed by 20160 bytes

Any help on this regard is welcome !!

Mahendra
Have you taken a look at CONFIG_RAM_SIZE and friends? Last time I
dealt with it these were the options I changed.

Regards,

--
Gustavo Lima Chaves
Intel - Open Source Technology Center


ARM _arch_irq_enable should not implicitly unpend IRQs

Chettimada, Vinayak Kariappa
 

Hi,

I am wondering why _arch_irq_enable for ARM unpends the IRQs, and not actually have a separate interfaces to pend and unpend IRQs.

Below is a diff that I want to submit, which removes the call to _NvicIrqUnpend() being made inside _arch_irq_enable. The reasoning is, sometimes an IRQ could be pending and implementations could then enable the ISR at a later time.

Regards,
Vinayak

diff --git a/arch/arm/core/irq_manage.c b/arch/arm/core/irq_manage.c
index 2d34ba5..bef7463 100644
--- a/arch/arm/core/irq_manage.c
+++ b/arch/arm/core/irq_manage.c
@@ -39,16 +39,13 @@ extern void __reserved(void);
*
* @brief Enable an interrupt line
*
- * Clear possible pending interrupts on the line, and enable the interrupt
- * line. After this call, the CPU will receive interrupts for the specified
- * <irq>.
+ * Enable the interrupt. After this call, the CPU will receive interrupts for
+ * the specified <irq>.
*
* @return N/A
*/
void _arch_irq_enable(unsigned int irq)
{
- /* before enabling interrupts, ensure that interrupt is cleared */
- _NvicIrqUnpend(irq);
_NvicIrqEnable(irq);
}


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 1
[ZEP-775] Enable USB CDC by default on Arduino 101 and redirect serial to USB
https://jira.zephyrproject.org/browse/ZEP-775


UPDATED JIRA items within last 24 hours: 1
[ZEP-346] Provide a HTTP library within Zephyr
https://jira.zephyrproject.org/browse/ZEP-346


CLOSED JIRA items within last 24 hours: 1
[ZEP-576] (Won't Do) hello_world app linking failed with zephyr sdk x86 toolchain
https://jira.zephyrproject.org/browse/ZEP-576


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4541 : DONT MERGE
- https://gerrit.zephyrproject.org/r/4540 : Bluetooth: AVDTP: Connect and Disconnect
- https://gerrit.zephyrproject.org/r/4539 : Bluetooth: tester: Add support for l2cap send data command
- https://gerrit.zephyrproject.org/r/4535 : kconfig: Use HOST_OS environment variable in Makefile

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/3853 : MAINTAINERS: add Zoap section
- https://gerrit.zephyrproject.org/r/3851 : samples/net: Add a sample for a CoAP server
- https://gerrit.zephyrproject.org/r/3850 : samples/net: Add a sample for a CoAP client
- https://gerrit.zephyrproject.org/r/3849 : tests: Add simple CoAP tests
- https://gerrit.zephyrproject.org/r/3848 : lib: Introduce the CoAP implementation for Zephyr
- https://gerrit.zephyrproject.org/r/4327 : fix: "uninitialized" variables break DEBUG sanity
- https://gerrit.zephyrproject.org/r/4457 : DONT MERGE
- https://gerrit.zephyrproject.org/r/4532 : fix: net samples no longer include unneeded 802.15.4 files
- https://gerrit.zephyrproject.org/r/4495 : Bluetooth: tester: Add support for l2cap listen command
- https://gerrit.zephyrproject.org/r/4494 : Bluetooth: tester: Add support for l2cap disconnect commands
- https://gerrit.zephyrproject.org/r/4493 : Bluetooth: tester: Add support for l2cap connect command
- https://gerrit.zephyrproject.org/r/4376 : Bluetooth: GAP: Support multiple peripheral role connections
- https://gerrit.zephyrproject.org/r/4462 : Bluetooth: Controller: Enable all supported LE states
- https://gerrit.zephyrproject.org/r/4492 : Bluetooth: tester: Add l2cap init method
- https://gerrit.zephyrproject.org/r/4463 : power_mgmt: Update Power Management device driver API
- https://gerrit.zephyrproject.org/r/4477 : uart_qmsi: Get the interrupt handling right on ARC
- https://gerrit.zephyrproject.org/r/3527 : console: shell: Shell enhancement - Support multiple modules
- https://gerrit.zephyrproject.org/r/4346 : net: yaip: Initial architecture documentation

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4534 : Bluetooth: GATT: Fix unaligned accesses
- https://gerrit.zephyrproject.org/r/4490 : Bluetooth: UUID: Add 32bit UUID support
- https://gerrit.zephyrproject.org/r/4479 : Bluetooth: Controller: Measure and use correct stack size


Increasing bss section in Zephyr

Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao@...>
 

Hi All

How to Increase the .bss section in Zephyr ?

There is a requirement for my project to have a big size array for 15K
If I declare and compile , getting error as

.bss will not fit in region RAM
Region 'RAM' overflowed by 20160 bytes

Any help on this regard is welcome !!

Mahendra


Zephyr API for I2S

Goldman, Michael <michael.goldman@...>
 

Hi all,

I would like to ask about future plans for I2S Zephyr API:


1) When are you planning to release the API?

2) Is it possible to share the code before officially releasing it?

Thanks,
Michael Goldman

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Serial Port throws error - Galileo Gen2 Boot up with USB thumb drive/MicroSD

Vaish, Atul <atul.vaish@...>
 

Hi
After a while , restated to check (earlier with the same setup, could run hello world and CoAP server) networking functionalities with Zephyr using Galileo Gen 2 , but after following https://wiki.zephyrproject.org/view/Galileo_Gen1_Gen2
(except Jumper settings) , I get stuck below . What could be the missing here ?

[cid:image001.png(a)01D206F4.06D672F0]



With Micro SD card
[cid:image002.png(a)01D206F4.B7E17A40]


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/3922 : lib: Add HTTP support for Zephyr
- https://gerrit.zephyrproject.org/r/3924 : lib/http: Add test-case
- https://gerrit.zephyrproject.org/r/3923 : lib/http: Fix size_t dependency by adding stddef.h header
- https://gerrit.zephyrproject.org/r/4531 : unified/build: allow building the unified kernel
- https://gerrit.zephyrproject.org/r/4529 : unified/test_fp: mark test so that it runs the nanokernel version
- https://gerrit.zephyrproject.org/r/4528 : unified/test_sema: fix isr wrapper names
- https://gerrit.zephyrproject.org/r/4527 : unified: Fix test_sema/microkernel
- https://gerrit.zephyrproject.org/r/4526 : unified/test_timer: adapt for unified kernel
- https://gerrit.zephyrproject.org/r/4511 : unified/doc: Kernel primer for unified kernel
- https://gerrit.zephyrproject.org/r/4524 : unified/test_mail: adapt test to not use sem groups and mem pools
- https://gerrit.zephyrproject.org/r/4530 : unified: initial unified kernel implementation
- https://gerrit.zephyrproject.org/r/4525 : unified/test_pipe: adapt to not use sem groups
- https://gerrit.zephyrproject.org/r/4521 : zperf_shell: add unified kernel string for unified kernel case
- https://gerrit.zephyrproject.org/r/4523 : unified/test_context: adapt test to run on unified kernel
- https://gerrit.zephyrproject.org/r/4522 : unified/tests: tag working tests on unified kernel as 'unified_capable'
- https://gerrit.zephyrproject.org/r/4520 : unified/object_tracing: disable object tracing in unified kernel
- https://gerrit.zephyrproject.org/r/4519 : unified/sys_timer: guard microkernel announce with !KERNEL_V2
- https://gerrit.zephyrproject.org/r/4517 : unified: include kernel.h via major top-level header files
- https://gerrit.zephyrproject.org/r/4512 : unified/build: adapt Kbuild for unified kernel
- https://gerrit.zephyrproject.org/r/4518 : unified/drivers: adapt timer drivers to unified kernel
- https://gerrit.zephyrproject.org/r/4516 : workqueue: use kernel.h for workqueue header file
- https://gerrit.zephyrproject.org/r/4513 : unified/arm: add unified kernel support for ARM arch
- https://gerrit.zephyrproject.org/r/4515 : atomic: fix bug in ATOMIC_INIT()
- https://gerrit.zephyrproject.org/r/4507 : sysgen: add --kernel_type argument
- https://gerrit.zephyrproject.org/r/4514 : unified/x86: add unified kernel support for x86 arch
- https://gerrit.zephyrproject.org/r/4510 : arm: only compile gdb stubs when CONFIG_GDB_INFO=y
- https://gerrit.zephyrproject.org/r/4509 : arm: add __ASSERT() for stack alignment
- https://gerrit.zephyrproject.org/r/4508 : build: only generate the SSE group for x86
- https://gerrit.zephyrproject.org/r/3312 : drivers/crypto: Tinycrypt shim driver
- https://gerrit.zephyrproject.org/r/3459 : soc: Add soc id and version interface
- https://gerrit.zephyrproject.org/r/4473 : i2c: Fix restart flag in burst read
- https://gerrit.zephyrproject.org/r/4477 : uart_qmsi: Get the interrupt handling right on ARC
- https://gerrit.zephyrproject.org/r/4475 : samples/drivers/uart: Fix line endings
- https://gerrit.zephyrproject.org/r/4474 : uart_console: Fix line endings
- https://gerrit.zephyrproject.org/r/4476 : samples/uart: More boards

MERGED within last 24 hours:


Re: [RFC] Provide a generic interface for getting the SOC ID and version

Kumar Gala
 

On Aug 17, 2016, at 5:20 AM, Nashif, Anas <anas.nashif(a)intel.com> wrote:

Did not expect this to generate such a big discussion. Here is a use case in addition to what was mentioned in the thread below. Think of this API as a helper API for higher lever features and not a way to select/deselect features based on HW.
I’d rather see the higher level feature that needs this first. Meaning, show me patch series that needs this info and than it will become far more clear what we should be doing. Until than I don’t think just adding a new API makes sense.

Depending on the HW/MCU being used, getting the hardware information such as model number, vendor ID, hardware revision might vary in complexity so implementing this for supported SOCs makes a lot of sense using an API that can be used by applications and higher level features such as IOT protocols. Originally this ZEP was created to prepare for LWM2M and specifically the device profile:

http://dev_devtoolkit.openmobilealliance.org/IoT/LWM2M10/doc/TS/index.html#!Documents/lwm2mobjectdevice.htm

To prepare for the implementation of the profile and to avoid implementing this for the various MCUs in different places where it can be used, the API was proposed.
For LWM2M is using SoC info actually the right choice? Should this be board specified?

Feeding this type of data at build time is always an option, but I do not think it makes sense in this case and especially when the HW has lots of information stored already that would make it very difficult to fill in at build time. Doing this at build time will encourage developers and users to enter random data and things like TODO or XYZ all over the place, just to get their app to build and move on. Why bother if the data is already provided by the hardware?

Uniqueness of the data is not key here, multiple boards of the same HW might end up generating the same ID, however, this depends on the hardware and some cases such data can be combined with other sources to achieve this.
I’m not sure I follow why uniqueness isn’t key.



Anas






On 29/07/2016, 23:48, "Kumar Gala" <kumar.gala(a)linaro.org> wrote:

If what you are talking about is really for errata than I think we should solve that specific problem. I think a combination of a consistent #define naming and usage convention:

#define CONFIG_ERRATUM_<VENDOR_NAME>_<CHIP>_<VND/CHIP SPECIFIC ERRATUM DESC>

For cases that could be handled at compile time. Than for runtime cases:

Something like:

bool has_erratum(enum erratum_list e).

where erratum_list can be defined in some SoC specific header and code to report if the given erratum is valid on the given chip.

Also, for what you describe, only the revision info is need so at most we’d have an internal API like:
uint32_t __get_soc_revision(void)

- k

On Jul 28, 2016, at 11:01 AM, Vij, Gajinder S <gajinder.s.vij(a)intel.com> wrote:

I'm confused as to what you mean by using features. Do you mean major silicon features such as different Cache size or different HW acceleration blocks? These would likely be a major rev of the silicon which would warrant a new binary. Also, how are silicon features determined without reading the underlying SOC version?

The origin of the request for the API is for a very specific scenario. When SOC vendors bring up new silicon, there are often multiple revisions of silicon available to the dev/test team before the chip is commercially available. Early versions of the silicon invariably have hardware bugs and the driver SW needs to compensate. As new iterations of the silicon are available to the dev/test team, either run-time detection is used to apply/disable the HW work-arounds, or the older HW boards become deadweight. This has significant cost and efficiency implications. This API is intended to be used at a very low level to allow drivers to enable/disable HW work-arounds. Having the API in the kernel saves the dev team from deriving their own API. I've seen scenarios where different component teams on the same project each implement their own SOC version detection scheme for this purpose.

The API is not intended for use by applications, and is not intended to distinguish between major chipset releases (example, not intended to distinguish between 384 vs a 486, or a Cortex M0 vs a Cortex M4). I'm still confused as to why a developer go through the trouble to have a single binary that runs on significantly different systems. This would be an inefficient use of FLASH and Memory, unnecessarily increasing cost of the end device.

I maintain that if an OEM picks up new silicon that has additional functionality, there will be a new HW board to enable new features/sensors, a new display etc. The OEM will naturally go through the process to create a separate binary. They may decide to use the same code-base to create multiple binaries, but that will be at compile-time, and won't require run-time detection to distinguish code-paths. It is _more_ work to create a single binary that runs on multiple HW SKUs, and a _lot more_ work to create a single binary that runs on two platforms that are significantly different.

Can you provide an example of an API that would provide feature level granularity?

Thanks,
Gajinder



-----Original Message-----
From: Kumar Gala [mailto:kumar.gala(a)linaro.org]
Sent: Thursday, July 28, 2016 6:25 AM
To: Vij, Gajinder S <gajinder.s.vij(a)intel.com>
Cc: Morgaine <morgaine.dinova(a)googlemail.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] [RFC] Provide a generic interface for getting the SOC ID and version

The use case you specify of picking SOC-version-specific code at run-time should be using features and not an ID for determining such things. This goes directly to Tixy’s email thread which I agree with 100%.

- k

On Jul 22, 2016, at 8:02 PM, Vij, Gajinder S <gajinder.s.vij(a)intel.com> wrote:

There is a clear use case for the API, as articulated by Morgaine and Pedro (included below). The purpose of the API is to provide the mechanism for a developer to be able to select SOC-version-specific code paths at run-time, reducing the need for a custom image per SOC version. When and if version specific code is used depends on the circumstances and should be left to the developer as a policy decision.

I’d like to determine if there is still objections to this API being implemented in Zephyr. I read through the thread and will attempt to address the concerns raised.

On the concerns articulated by Tixy, since the App, Kernel, and BSP are all compiled from source into a single binary, I don’t see the same app compatibility issues cropping up in a Zephyr scenario that have come up in Linux. It is conceivable that someone may attempt to use the SOC version as a way to distinguish between different variants of a product family, but that would be an inappropriate use of the API.

I don’t know where the notion of using this API as an entropy source came from. I have removed this from the Jira description.

To the question about forward support and uniqueness of the IDs – should this happen on different architectures, I don’t see a problem because I expect the BSPs will still be unique, and therefore I don’t expect a binary run on one platform to successfully be run on another.

Comments welcome.

Thanks,
Gajinder


Pedro’s use case:
Ø The user might know the SOC ID at compile time (although a user might want to check against the hardware in case of doubt).
Ø The SOC revision can change between hardware stepping, so the user might not know at compile time the version of a given model.
Ø In that case reading the hardware registers is the only way to know the revision.

Morgaine’s use case:
Ø This API creates a 1:N relationship between compiled firmware and target behaviour. In other words it allows target behaviour to be parametrized by some target identifier in a standard way given by the API, without requiring each different target to be loaded with different firmware.



From: Morgaine [mailto:morgaine.dinova(a)googlemail.com]
Sent: Thursday, July 21, 2016 10:27 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC] Provide a generic interface for getting the SOC ID and version

Kumar writes:
So I ask again, what are we trying to accomplish?
See my preceding reply, which explored exactly that question.

From the original requirement expressed in the RFC and from Tixy's subsequent comments, it's clear that there are at least two distinct purposes in people's minds: the one mentioned in the RFC which required uniqueness for generating unique per-target data, and another purpose related to feature sets. It was noted that the second of these is somewhat problematic.

My interest is in the simpler of these, the requirement expressed in the RFC, because it is such a common need. Someone else will have to argue in favour of the other if they feel it's important. The two could of course be combined if the agreed data width permits.

Morgaine.


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 1
[ZEP-768] Move defaults.tc and .known-issue under tests/
https://jira.zephyrproject.org/browse/ZEP-768


UPDATED JIRA items within last 24 hours: 1
[ZEP-767] Add FS API to flush cache of an open file
https://jira.zephyrproject.org/browse/ZEP-767


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4500 : usb: add Kconfig options for CDC ACM VID/PID
- https://gerrit.zephyrproject.org/r/4534 : Bluetooth: GATT: Fix unaligned accesses
- https://gerrit.zephyrproject.org/r/4532 : fix: net samples no longer include unneeded 802.15.4 files
- https://gerrit.zephyrproject.org/r/4499 : TCF: disable running single core testcases on Quark SE's x86+arc
- https://gerrit.zephyrproject.org/r/4533 : TCF: specify ARCH when creating initconfig
- https://gerrit.zephyrproject.org/r/4505 : kernel: add CONFIG_MDEF
- https://gerrit.zephyrproject.org/r/4503 : slist: add sys_slist_get() to fetch and remove the head
- https://gerrit.zephyrproject.org/r/4509 : arm: add __ASSERT() for stack alignment
- https://gerrit.zephyrproject.org/r/4507 : sysgen: add --kernel_type argument
- https://gerrit.zephyrproject.org/r/4504 : slist: add sys_slist_append_list/slist()
- https://gerrit.zephyrproject.org/r/4510 : arm: only compile gdb stubs when CONFIG_GDB_INFO=y
- https://gerrit.zephyrproject.org/r/4501 : dlist: add SYS_DLIST_FOR_EACH_NODE/_SAFE
- https://gerrit.zephyrproject.org/r/4531 : build: allow building the unified kernel
- https://gerrit.zephyrproject.org/r/4529 : unified/test_fp: mark test so that it runs the nanokernel version
- https://gerrit.zephyrproject.org/r/4528 : unified/test_sema: fix isr wrapper names
- https://gerrit.zephyrproject.org/r/4530 : unified: initial unified kernel implementation
- https://gerrit.zephyrproject.org/r/4527 : unified: Fix test_sema/microkernel
- https://gerrit.zephyrproject.org/r/4526 : unified/test_timer: adapt for unified kernel
- https://gerrit.zephyrproject.org/r/4525 : unified/test_pipe: adapt to not use sem groups
- https://gerrit.zephyrproject.org/r/4524 : unified/test_mail: adapt test to not use sem groups and mem pools
- https://gerrit.zephyrproject.org/r/4523 : unified/test_context: adapt test to run on unified kernel
- https://gerrit.zephyrproject.org/r/4522 : unified/tests: tag working tests on unified kernel as 'unified_capable'
- https://gerrit.zephyrproject.org/r/4521 : zperf_shell: add unified kernel string for unified kernel case
- https://gerrit.zephyrproject.org/r/4520 : unified/object_tracing: disable object tracing in unified kernel
- https://gerrit.zephyrproject.org/r/4519 : unified/sys_timer: guard microkernel announce with !KERNEL_V2
- https://gerrit.zephyrproject.org/r/4518 : unified/drivers: adapt timer drivers to unified kernel
- https://gerrit.zephyrproject.org/r/4517 : unified: include kernel.h via major top-level header files
- https://gerrit.zephyrproject.org/r/4516 : workqueue: use kernel.h for workqueue header file
- https://gerrit.zephyrproject.org/r/4515 : atomic: fix bug in ATOMIC_INIT()
- https://gerrit.zephyrproject.org/r/4514 : unified/x86: add unified kernel support for x86 arch
- https://gerrit.zephyrproject.org/r/4512 : unified/build: adapt Kbuild for unified kernel
- https://gerrit.zephyrproject.org/r/4513 : unified/arm: add unified kernel support for ARM arch
- https://gerrit.zephyrproject.org/r/4511 : unified/doc: Kernel primer for unified kernel
- https://gerrit.zephyrproject.org/r/4508 : build: only generate the SSE group for x86
- https://gerrit.zephyrproject.org/r/4506 : build: make sysgen take optional command line arguments
- https://gerrit.zephyrproject.org/r/4502 : dlist: add static initialization macro
- https://gerrit.zephyrproject.org/r/4496 : fix: fstat return value is now being checked
- https://gerrit.zephyrproject.org/r/4497 : TCF: update defaults to use configuration fragments
- https://gerrit.zephyrproject.org/r/4498 : TCF: default Quark SE's ARC core to use UART1 as console for testing

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/3312 : drivers/crypto: Tinycrypt shim driver
- https://gerrit.zephyrproject.org/r/3311 : include/crypto: Crypto abstraction header
- https://gerrit.zephyrproject.org/r/4327 : fix: "uninitialized" variables break DEBUG sanity
- https://gerrit.zephyrproject.org/r/3895 : tests/kernel/test_multilib: Test for proper multilib selection.
- https://gerrit.zephyrproject.org/r/4460 : kconfig: include configuration fragment files from output directory
- https://gerrit.zephyrproject.org/r/4372 : fs: Adds file system API to grow or shrink a file
- https://gerrit.zephyrproject.org/r/4485 : sample: fs: Add tests for fs_truncate and fs_statvfs
- https://gerrit.zephyrproject.org/r/4478 : fs: Adds file system API to get volume statistics
- https://gerrit.zephyrproject.org/r/4473 : i2c: Fix restart flag in burst read
- https://gerrit.zephyrproject.org/r/4479 : Bluetooth: Controller: Measure and use correct stack size
- https://gerrit.zephyrproject.org/r/4472 : i2c: ksdk: Add shim driver
- https://gerrit.zephyrproject.org/r/4461 : i2c: qmsi_shim: change some i2c config parameters to SoC specific
- https://gerrit.zephyrproject.org/r/4482 : mqtt: Remove the app_buf structure
- https://gerrit.zephyrproject.org/r/3843 : zephyr: remove deprecated dynamic interrupt API
- https://gerrit.zephyrproject.org/r/4139 : TCF: Tags test previously broken by ARC-x86 communication issue
- https://gerrit.zephyrproject.org/r/3846 : arc: remove deprecated dynamic interrupt implementation
- https://gerrit.zephyrproject.org/r/3845 : x86: remove dynamic interrupts and exceptions
- https://gerrit.zephyrproject.org/r/4477 : uart_qmsi: Get the interrupt handling right on ARC

MERGED within last 24 hours:

6661 - 6680 of 8046