Date   

How to figure out the stack size for a thread?

Li, Jun R
 

 

Hi there,

I’m wondering by which means to figure out the static stack size for a thread? Thank you!

 

Jun Li

NTG | Intel Corporation | Santa Clara

 


Re: Link error "undefined reference to `__heap_sentry'"

Boie, Andrew P
 

Thank you for the patch.

 

The test case tests/kernel/test_build should have caught this in its newlib configuration, but the build passes in that scenario. I'm looking into why this is the case.

 

Andrew

 

From: Aska Wu [mailto:aska.wu@...]
Sent: Thursday, August 10, 2017 12:42 AM
To: Boie, Andrew P <andrew.p.boie@...>; Paul Sokolovsky <paul.sokolovsky@...>
Cc: zephyr-devel@...; team-lite@...
Subject: Re: [Zephyr-devel] Link error "undefined reference to `__heap_sentry'"

 

Andrew,

 

Thanks for the information. It turns out an typo in the xtensa linker.ld. newlib references "__heap_sentry" but "_heap_sentry" is defined in the linker script. I've created a PR #1072 for this. But I just found that all linker scripts under arch/xtensa/soc have the same problem. I will update my PR.

 

Regards

 

Aska Wu

 

On Thu, 10 Aug 2017 at 12:39 Boie, Andrew P <andrew.p.boie@...> wrote:

Aska,

 

__heap_sentry is a linker symbol, defined for qemu_xtensa in the linker script, arch/xtensa/soc/sample_controller/linker.ld, near the bottom.  It marks the beginning of a RAM area used for heap memory storage.

Are you able to run 'sanitycheck' with all tests passing?

What version SDK are you using? What BOARD target are you using?

I think there is some problem in your build environment if you are getting this error.

 

Paul,

 

As far as I know all samples/ and tests/ are at least built (if not executed) in our sanitycheck CI runs for all arches, so if you are encountering build errors for any sample that sanitycheck doesn't expose, that would be a gap in our CI and we would be interested to know it.

 

Andrew

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Aska Wu
Sent: Wednesday, August 9, 2017 7:40 PM
To: Paul Sokolovsky <paul.sokolovsky@...>
Cc: zephyr-devel@...; team-lite@...
Subject: Re: [Zephyr-devel] Link error "undefined reference to `__heap_sentry'"

 

Paul,

 

I might take some time to investigate it. But I think I should exclude qemu_xtensa as a short-term workaround.

 

Regards.

 

Aska

 

On Wed, 9 Aug 2017 at 20:56 Paul Sokolovsky <paul.sokolovsky@...> wrote:

Hello Aska,

I'd send this message to Zephyr mailing list (maybe with a bit more of
info). All I can say that some time ago when building some random
sample for different architectures, I also had some issues with Xtensa
and ARC builds, but now I don't remember if I saw error below. And I
definitely didn't try to investigate them, just noted to myself that
Xtensa/ARC support needs more work in Zephyr ;-).


On Wed, 09 Aug 2017 11:20:06 +0000
Aska Wu <aska.wu@...> wrote:

> Hi all,
>
> I'm writing some test cases and I got following error while building
> test cases for qemu_xtensa.
>
> lib/built-in.o:(.literal._sbrk+0x4): undefined reference to
> `__heap_sentry' collect2: error: ld returned 1 exit status
>
> I can only find something related in "lib/libc/newlib/libc-hooks.c",
> but it's a extern reference. Do you have any idea about this error?
>
> Thanks
>
> Aska Wu



--
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: Link error "undefined reference to `__heap_sentry'"

aska.wu
 

Andrew,

Thanks for the information. It turns out an typo in the xtensa linker.ld. newlib references "__heap_sentry" but "_heap_sentry" is defined in the linker script. I've created a PR #1072 for this. But I just found that all linker scripts under arch/xtensa/soc have the same problem. I will update my PR.

Regards

Aska Wu

On Thu, 10 Aug 2017 at 12:39 Boie, Andrew P <andrew.p.boie@...> wrote:

Aska,

 

__heap_sentry is a linker symbol, defined for qemu_xtensa in the linker script, arch/xtensa/soc/sample_controller/linker.ld, near the bottom.  It marks the beginning of a RAM area used for heap memory storage.

Are you able to run 'sanitycheck' with all tests passing?

What version SDK are you using? What BOARD target are you using?

I think there is some problem in your build environment if you are getting this error.

 

Paul,

 

As far as I know all samples/ and tests/ are at least built (if not executed) in our sanitycheck CI runs for all arches, so if you are encountering build errors for any sample that sanitycheck doesn't expose, that would be a gap in our CI and we would be interested to know it.

 

Andrew

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Aska Wu
Sent: Wednesday, August 9, 2017 7:40 PM
To: Paul Sokolovsky <paul.sokolovsky@...>
Cc: zephyr-devel@...; team-lite@...
Subject: Re: [Zephyr-devel] Link error "undefined reference to `__heap_sentry'"

 

Paul,

 

I might take some time to investigate it. But I think I should exclude qemu_xtensa as a short-term workaround.

 

Regards.

 

Aska

 

On Wed, 9 Aug 2017 at 20:56 Paul Sokolovsky <paul.sokolovsky@...> wrote:

Hello Aska,

I'd send this message to Zephyr mailing list (maybe with a bit more of
info). All I can say that some time ago when building some random
sample for different architectures, I also had some issues with Xtensa
and ARC builds, but now I don't remember if I saw error below. And I
definitely didn't try to investigate them, just noted to myself that
Xtensa/ARC support needs more work in Zephyr ;-).


On Wed, 09 Aug 2017 11:20:06 +0000
Aska Wu <aska.wu@...> wrote:

> Hi all,
>
> I'm writing some test cases and I got following error while building
> test cases for qemu_xtensa.
>
> lib/built-in.o:(.literal._sbrk+0x4): undefined reference to
> `__heap_sentry' collect2: error: ld returned 1 exit status
>
> I can only find something related in "lib/libc/newlib/libc-hooks.c",
> but it's a extern reference. Do you have any idea about this error?
>
> Thanks
>
> Aska Wu



--
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: Link error "undefined reference to `__heap_sentry'"

Boie, Andrew P
 

Aska,

 

__heap_sentry is a linker symbol, defined for qemu_xtensa in the linker script, arch/xtensa/soc/sample_controller/linker.ld, near the bottom.  It marks the beginning of a RAM area used for heap memory storage.

Are you able to run 'sanitycheck' with all tests passing?

What version SDK are you using? What BOARD target are you using?

I think there is some problem in your build environment if you are getting this error.

 

Paul,

 

As far as I know all samples/ and tests/ are at least built (if not executed) in our sanitycheck CI runs for all arches, so if you are encountering build errors for any sample that sanitycheck doesn't expose, that would be a gap in our CI and we would be interested to know it.

 

Andrew

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Aska Wu
Sent: Wednesday, August 9, 2017 7:40 PM
To: Paul Sokolovsky <paul.sokolovsky@...>
Cc: zephyr-devel@...; team-lite@...
Subject: Re: [Zephyr-devel] Link error "undefined reference to `__heap_sentry'"

 

Paul,

 

I might take some time to investigate it. But I think I should exclude qemu_xtensa as a short-term workaround.

 

Regards.

 

Aska

 

On Wed, 9 Aug 2017 at 20:56 Paul Sokolovsky <paul.sokolovsky@...> wrote:

Hello Aska,

I'd send this message to Zephyr mailing list (maybe with a bit more of
info). All I can say that some time ago when building some random
sample for different architectures, I also had some issues with Xtensa
and ARC builds, but now I don't remember if I saw error below. And I
definitely didn't try to investigate them, just noted to myself that
Xtensa/ARC support needs more work in Zephyr ;-).


On Wed, 09 Aug 2017 11:20:06 +0000
Aska Wu <aska.wu@...> wrote:

> Hi all,
>
> I'm writing some test cases and I got following error while building
> test cases for qemu_xtensa.
>
> lib/built-in.o:(.literal._sbrk+0x4): undefined reference to
> `__heap_sentry' collect2: error: ld returned 1 exit status
>
> I can only find something related in "lib/libc/newlib/libc-hooks.c",
> but it's a extern reference. Do you have any idea about this error?
>
> Thanks
>
> Aska Wu



--
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: Link error "undefined reference to `__heap_sentry'"

aska.wu
 

Paul,

I might take some time to investigate it. But I think I should exclude qemu_xtensa as a short-term workaround.

Regards.

Aska

On Wed, 9 Aug 2017 at 20:56 Paul Sokolovsky <paul.sokolovsky@...> wrote:
Hello Aska,

I'd send this message to Zephyr mailing list (maybe with a bit more of
info). All I can say that some time ago when building some random
sample for different architectures, I also had some issues with Xtensa
and ARC builds, but now I don't remember if I saw error below. And I
definitely didn't try to investigate them, just noted to myself that
Xtensa/ARC support needs more work in Zephyr ;-).


On Wed, 09 Aug 2017 11:20:06 +0000
Aska Wu <aska.wu@...> wrote:

> Hi all,
>
> I'm writing some test cases and I got following error while building
> test cases for qemu_xtensa.
>
> lib/built-in.o:(.literal._sbrk+0x4): undefined reference to
> `__heap_sentry' collect2: error: ld returned 1 exit status
>
> I can only find something related in "lib/libc/newlib/libc-hooks.c",
> but it's a extern reference. Do you have any idea about this error?
>
> Thanks
>
> Aska Wu



--
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: info about device tree for stm32f412zg

Andy Gross
 

On 9 August 2017 at 11:01, massimiliano cialdi
<massimiliano.cialdi@powersoft.it> wrote:
Fo the nucleo_f412zg there is the file

zephyr/dts/arm/nucleo_f412zg.dts

that includes st/stm32f412.dtsi and then
#include <st/stm32f412-pinctrl.dtsi>
#include <st/stm32f411.dtsi>

stm32f411.dtsi indirectly includes stm32f4-pinctrl.dtsi

file stm32f4-pinctrl.dtsi contains

usart2_pins_a: usart2@0 {
rx_tx {
rx = <STM32_PIN_PA3 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL)>;
tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_NOPULL)>;
};
};
usart2_pins_b: usart2@1 {
rx_tx {
rx = <STM32_PIN_PA15 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL)>;
tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_NOPULL)>;
};
};
usart2_pins_c: usart2@2 {
rx_tx {
rx = <STM32_PIN_PD6 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL)>;
tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_NOPULL)>;
};
};

and if I want to use USART2 I have to add to stm32f412-pinctrl.dtsi

usart2_pins_a: usart2@0 {
rx_tx {
rx = <STM32_PIN_PA3 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
};
};
usart2_pins_b: usart2@1 {
rx_tx {
rx = <STM32_PIN_PD6 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
tx = <STM32_PIN_PD5 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
};
};

because chip has only those two mux for USART2.

In the compiled dts there is also usart2_pins_c that it doen't actually
exist in the chip, how to remove it?
So if there are pin differences between the two, then anything non
generic needs to be removed from the .dtsi and put inside a more
specific .dtsi file that is included. The intent of the definitions
was to allow reuse and make it easier to choose things without having
to consult the manual.

The pins_c should only be appearing if it is defined and someone is using it.


the file stm32f4-pinctrl.dtsi should be generic for stm32f4 family chips. So
why it contains a specific multiplexing for the usart that has to be
overridden by specific pinmux files?
If the f412 has differences in pinmuxing from the f4, then those
things needs to be separated out. The entries in the -pinctrl.dtsi
are used in the actual nodes in the board specific files. Just
because something is defined does not mean that it is used unless
there is a pinctrl-0/pinctrl-1/pinctrl-2 property in the node that
uses one of the definitions.


info about device tree for stm32f412zg

Massimiliano Cialdi
 

Fo the nucleo_f412zg there is the file

zephyr/dts/arm/nucleo_f412zg.dts

that includes st/stm32f412.dtsi and then
#include <st/stm32f412-pinctrl.dtsi>
#include <st/stm32f411.dtsi>

stm32f411.dtsi indirectly includes stm32f4-pinctrl.dtsi

file stm32f4-pinctrl.dtsi contains

usart2_pins_a: usart2@0 {
rx_tx {
rx = <STM32_PIN_PA3 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL)>;
tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_NOPULL)>;
};
};
usart2_pins_b: usart2@1 {
rx_tx {
rx = <STM32_PIN_PA15 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL)>;
tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_NOPULL)>;
};
};
usart2_pins_c: usart2@2 {
rx_tx {
rx = <STM32_PIN_PD6 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL)>;
tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_NOPULL)>;
};
};

and if I want to use USART2 I have to add to stm32f412-pinctrl.dtsi

usart2_pins_a: usart2@0 {
rx_tx {
rx = <STM32_PIN_PA3 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
};
};
usart2_pins_b: usart2@1 {
rx_tx {
rx = <STM32_PIN_PD6 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
tx = <STM32_PIN_PD5 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
};
};

because chip has only those two mux for USART2.

In the compiled dts there is also usart2_pins_c that it doen't actually exist in the chip, how to remove it?

the file stm32f4-pinctrl.dtsi should be generic for stm32f4 family chips. So why it contains a specific multiplexing for the usart that has to be overridden by specific pinmux files?

best regards
Max


Re: info about device tree entry for STM32 micros

Andy Gross
 

On 8 August 2017 at 10:52, massimiliano cialdi
<massimiliano.cialdi@powersoft.it> wrote:
this make sense (but the address of RCC_APB1RSTR is 0x20)

But this raises the question: where is it defined STM32_CLOCK_BUS_APB1 and
how?

Grepping the entire zephyr source I find:

#define STM32_CLOCK_BUS_APB1 2

in file zephyr/include/dt-bindings/clock/stm32_clock.h

that is not 0x20 as I expect
Looking at the drivers/clock_control/stm32_ll_clock.c, they use switch
statements to steer the programming for the clock enables. The actual
call makes a macro/function call to set the enable bit. So in this
case, the device tree denotes the switch value to use and the bit
mask.

I was assuming they were using the offsets. that isn't the case.
they are using ext hal code selected via the switch.

Sorry bout that.

Andy


Re: info about device tree entry for STM32 micros

Massimiliano Cialdi
 

this make sense (but the address of RCC_APB1RSTR is 0x20)

But this raises the question: where is it defined STM32_CLOCK_BUS_APB1 and how?

Grepping the entire zephyr source I find:

#define STM32_CLOCK_BUS_APB1 2

in file zephyr/include/dt-bindings/clock/stm32_clock.h

that is not 0x20 as I expect


best regards

Max

On 08/08/2017 16:59, Andy Gross wrote:
I am pretty sure the encoding is the following:

<&rcc STM32_CLOCK_BUS_APB1 0x00040000>

First cell is reference to the clock node. That node will have a base
address. The second cell is which RCC register. In this case it is
APB1 (0x1c). Third cell is the mask for the enable bit for USART3.



On 8 August 2017 at 09:15, Kinder, David B <david.b.kinder@intel.com> wrote:
Start here for kernel clocks documentation:
https://www.zephyrproject.org/doc/kernel/timing/clocks.html#clocks-v2

-- david kinder

On Aug 8, 2017, at 9:53 AM, massimiliano cialdi
<massimiliano.cialdi@powersoft.it> wrote:

I am surfing in the device tree files for stm32f412 micro

I found

usart3: serial@40004800 {
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40004800 0x400>;
clocks = <&rcc STM32_CLOCK_BUS_APB1 0x00040000>;
interrupts = <39 0>;
status = "disabled";
label = "UART_3";
};

I wonder where to find documentation about clocks entry. It seems to be a 3
element array, but I don't know the meaning of each of them


best regards

Max

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
.


Re: info about device tree entry for STM32 micros

Andy Gross
 

I am pretty sure the encoding is the following:

<&rcc STM32_CLOCK_BUS_APB1 0x00040000>

First cell is reference to the clock node. That node will have a base
address. The second cell is which RCC register. In this case it is
APB1 (0x1c). Third cell is the mask for the enable bit for USART3.

On 8 August 2017 at 09:15, Kinder, David B <david.b.kinder@intel.com> wrote:
Start here for kernel clocks documentation:
https://www.zephyrproject.org/doc/kernel/timing/clocks.html#clocks-v2

-- david kinder

On Aug 8, 2017, at 9:53 AM, massimiliano cialdi
<massimiliano.cialdi@powersoft.it> wrote:

I am surfing in the device tree files for stm32f412 micro

I found

usart3: serial@40004800 {
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40004800 0x400>;
clocks = <&rcc STM32_CLOCK_BUS_APB1 0x00040000>;
interrupts = <39 0>;
status = "disabled";
label = "UART_3";
};

I wonder where to find documentation about clocks entry. It seems to be a 3
element array, but I don't know the meaning of each of them


best regards

Max

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: info about device tree entry for STM32 micros

Kinder, David B <david.b.kinder@...>
 

Start here for kernel clocks documentation: 
https://www.zephyrproject.org/doc/kernel/timing/clocks.html#clocks-v2

-- david kinder

On Aug 8, 2017, at 9:53 AM, massimiliano cialdi <massimiliano.cialdi@...> wrote:

I am surfing in the device tree files for stm32f412 micro

I found

usart3: serial@40004800 {
   compatible = "st,stm32-usart", "st,stm32-uart";
   reg = <0x40004800 0x400>;
   clocks = <&rcc STM32_CLOCK_BUS_APB1 0x00040000>;
   interrupts = <39 0>;
   status = "disabled";
   label = "UART_3";
};

I wonder where to find documentation about clocks entry. It seems to be a 3 element array, but I don't know the meaning of each of them


best regards

Max

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


info about device tree entry for STM32 micros

Massimiliano Cialdi
 

I am surfing in the device tree files for stm32f412 micro

I found

usart3: serial@40004800 {
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40004800 0x400>;
clocks = <&rcc STM32_CLOCK_BUS_APB1 0x00040000>;
interrupts = <39 0>;
status = "disabled";
label = "UART_3";
};

I wonder where to find documentation about clocks entry. It seems to be a 3 element array, but I don't know the meaning of each of them


best regards

Max


Re: Switching debuggers/flashers

Piotr Mienkowski
 

On 08.08.2017 10:57, Erwin Rol wrote:
Is there a standardized way to switch debugger/flash tool ?

The only thing I could find was a config file that uses
OPENOCD_INTERFACE variable to select a debugger.

Is the OPENOCD_INTERFACE variable the correct way to do this? With other
words can I also use that variable in the Olimexino openocd config
file ?
I believe there is no standard way in Zephyr to select debug interface
so far but if you use OPENOCD_INTERFACE environment variable we would
establish a standard, for OpenOCD that is.

In case of existing implementation for sam_e70_xplained board OpenOCD
will look for the appropriate interface configuration in an
interface/$(OPENOCD_INTERFACE).cfg file on its internal search path.
I.e. we should be able to support any debugger/flasher as long as
OpenOCD provides an interface file for it.

To flash via a default interface one would use 'make flash', and for
non-default interface e.g. to select J-Link probe 'make
OPENOCD_INTERFACE=jlink flash'.

You would of course need to modify openocd.cfg to add such support for
olimexino_stm32 board.

- Piotr


Switching debuggers/flashers

Erwin Rol
 

Hello All,

Is there a standardized way to switch debugger/flash tool ?

I want to use the ST-Link2 with the Olimexino board, but I have to
change the openocd.conf file to do so, because the board uses another
debugger by default.

The only thing I could find was a config file that uses
OPENOCD_INTERFACE variable to select a debugger.

Is the OPENOCD_INTERFACE variable the correct way to do this? With other
words can I also use that variable in the Olimexino openocd config
file ?

- Erwin


Re: [devel] How to generate .hex image

Tidy(Chun hua)Jiang <tidyjiang@...>
 

Hi Boie,

Got it, thanks!

2017年1月18日 00:41于 "Boie, Andrew P" <andrew.p.boie@...>写道:

At the moment, you can add these two lines to your soc or arch-level Makefile to get ihex files generated.

A better enhancement would be to control this with Kconfig.

 

zephyr: $(KERNEL_HEX_NAME)

all: $(KERNEL_HEX_NAME)

 

From: Tidy(ChunHua) Jiang [mailto:tidyjiang@...]
Sent: Sunday, January 15, 2017 6:40 PM
To: devel@...
Subject: [devel] How to generate .hex image

 

Hello,

When building, some BOARDs will generate both .bin and .hex, but others only .bin.
Is there a build switch to control this ?

My current stupid method is that, enter the directory where zephyr.elf is located, and then type:
/opt/zephyr-sdk/sysroots/i686-pokysdk-linux/usr/bin/arm-poky-eabi/arm-poky-eabi-objcopy -S -O ihex -R .note -R .comment -R COMMON -R .eh_frame zephyr.elf zephyr.hex

Thanks.

 

 


回复: did zephyr support armcc and fromelf toolchain?

luobaidunpaigu@sina.com <luobaidunpaigu@...>
 

yes, follow the instructions:
Page: https://www.zephyrproject.org/doc/getting_started/getting_started.html
Section: Using Custom and 3rd Party Cross Compilers

OR

https://www.zephyrproject.org/doc/getting_started/getting_started.html#using-custom-and-3rd-party-cross-compilers
 

luobaidunpaigu@...

 
发件人: 曹子龙
发送时间: 2017-08-04 17:54
收件人: zephyr-devel
主题: [Zephyr-devel] did zephyr support armcc and fromelf toolchain?
HI all:

   Did zephyr support armcc and fromelf toolchain present? 


 


Re: Shipable timeout

Erwin Rol
 

On Sat, 2017-08-05 at 13:21 +0000, Kinder, David B wrote:
Might try a PR close/open to give shippable a kick?

-- david kinder

On Aug 5, 2017, at 6:09 AM, Erwin Rol <mailinglists@erwinrol.com> wrote:

Hey all,

my PR caused a shipable timeout;

https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/3031/3/console

What do I do now ?

It seems to have figured out by itself that it has to rerun shipable.

- Erwin


Re: Shipable timeout

Kinder, David B <david.b.kinder@...>
 

Might try a PR close/open to give shippable a kick?

-- david kinder

On Aug 5, 2017, at 6:09 AM, Erwin Rol <mailinglists@erwinrol.com> wrote:

Hey all,

my PR caused a shipable timeout;

https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/3031/3/console

What do I do now ?

- Erwin


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Shipable timeout

Erwin Rol
 

Hey all,

my PR caused a shipable timeout;

https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/3031/3/console

What do I do now ?

- Erwin


USB device stack and class drivers

Johann Fischer
 

Hi all,

I got closer with Zephyr USB device stack while I wrote USB device driver for
Kinetis [1]. There are a few things that are not optimal and which I would like
to improve.

* USB controllers like Kinetis USBFSOTG do not have a FIFO for the endpoints but
own DMA controller configured over a buffer descriptor table. Depending on the
number of endpoints, the endpoint buffer has to be configured in the driver
with little effort (and the buffer content is copied unnecessarily with every
ep_read and ep_write). Would it be acceptable to use memory slabs or memory
pools for the endpoint buffers?

* device stack does not handle the USB reset and does not re-initialize the
endpoints and it sets the device address before sending ACK with ZLP. Both
issues need workaround in device driver.

* the header files usb_common.h and usbstruct.h can be merged

* the class drivers in subsys/usb/class, each have their own complete device
descriptor, vid/pid and strings are not configurable, no composite device
support. The headers of the class drivers can also be used by USB host stack
(if there is one in the future) and I think these belong to include/usb. I
started here and there is a RFC PR [2].

* there are several USB device stack applications and class driver which are
in sample directory but can be moved to subsys/usb, for example dfu, webusb and
wpanusb. e.g. composite device consisting of dfu and wpanusb would be nice.

* wpanusb API looks based on atusb, but the interface is quite
different, where is the linux driver as a counterpart of it?

[1] https://github.com/zephyrproject-rtos/zephyr/pull/542
[2] https://github.com/zephyrproject-rtos/zephyr/pull/716

--
Best Regards,
Johann Fischer

5001 - 5020 of 8189