Date   

Re: Unable to run USB samples on STM32F411E-DISCO #samples

Erwan Gouriou
 

Hi Brian,

Raising an issue would indeed help to provide support.
Don't hesitate to share the work you've already done to ease things.

BR
Erwan

On Tue, 12 May 2020 at 21:14, <bbradley@...> wrote:
So I think there are a few things going on here, and have begun to unravel it but I might need some guidance on how to proceed. 

I intend to utilize the STM32F411E MCU on an upcoming board, but I wanted to test the DISCO board in zephyr to get a feel for it first. One of the features I will need is USB, which the DISCO board appears to have available in the form of an OTG port. I only need the cdc mode of operation, so I think this shouldn't be too difficult of a task.

I pretty quickly realized that USB wasn't supported on this board on latest version of zephyr (2.3-rc0), so I started by trying to add it. I was able to get it compiled pretty quickly with some changes to the dts and pinmux.c by referencing other implementations and the datasheet for the MCU. 

So after some minor changes, I was able to get it to compile without any problems. Upon flashing it to the board *something* appears to be happening, but I am not sure if there is more that I am missing. Right now, the USB_OTG LED is illuminating on the DISCO board, which I think indicates something is happening, and the Device Manager (Windows 10) is recognizing a device, which is also good. But it is unable to setup the device and giving a "Device Descriptor Request Failed" error. I am curious if I am missing some additional steps to properly implement USB, and if I should possibly start an issue and work towards a PR on github.

Thanks for any advice!
Brian


Unable to run USB samples on STM32F411E-DISCO #samples

bbradley@...
 

So I think there are a few things going on here, and have begun to unravel it but I might need some guidance on how to proceed. 

I intend to utilize the STM32F411E MCU on an upcoming board, but I wanted to test the DISCO board in zephyr to get a feel for it first. One of the features I will need is USB, which the DISCO board appears to have available in the form of an OTG port. I only need the cdc mode of operation, so I think this shouldn't be too difficult of a task.

I pretty quickly realized that USB wasn't supported on this board on latest version of zephyr (2.3-rc0), so I started by trying to add it. I was able to get it compiled pretty quickly with some changes to the dts and pinmux.c by referencing other implementations and the datasheet for the MCU. 

So after some minor changes, I was able to get it to compile without any problems. Upon flashing it to the board *something* appears to be happening, but I am not sure if there is more that I am missing. Right now, the USB_OTG LED is illuminating on the DISCO board, which I think indicates something is happening, and the Device Manager (Windows 10) is recognizing a device, which is also good. But it is unable to setup the device and giving a "Device Descriptor Request Failed" error. I am curious if I am missing some additional steps to properly implement USB, and if I should possibly start an issue and work towards a PR on github.

Thanks for any advice!
Brian


Zephyr SDK 0.11.x and Python support query

Kumar Gala
 

As part of the SDK 0.11.x SDK we moved from python2.7 to python3.6 as the version of python that GDB is linked against, partially due to the deprecation of python2.7.

There have been several issues opened about this on various Linux distributions. It was suggested that Python3.8 would be a better choice since there are options on most of the major distribution versions to install a python3.8 package.

I wanted to see if this change caused any major concerns.

If you want to test out the python3.8 version, here’s a link a test SDK build:

https://builds.zephyrproject.org/zephyrproject-rtos/sdk-ng/210/zephyr-sdk-0.11.3-beta-1-pr-210-setup.run

Please let me know by end of Thur (May 14th) if you have concerns.

Thanks

- k


Upcoming Event: Zephyr Project: APIs - Tue, 05/12/2020 9:00am-10:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: APIs

When: Tuesday, 12 May 2020, 9:00am to 10:00am, (GMT-07:00) America/Los Angeles

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join Microsoft Teams Meeting:
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

+1 213-437-3346 United States, Los Angeles (Toll)

Conference ID: 262 362 129#

Local numbers: 
https://dialin.teams.microsoft.com/488d1b50-0dd2-4ca1-aee4-92bb50a48081?id=262362129


 Live meeting minutes: https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit?usp=sharing


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:

- dma: enable edma drivers for mcux
- PR https://github.com/zephyrproject-rtos/zephyr/pull/23689

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

- 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

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


[Zephyr 2.3] Please set the 2.3.0 milestone on all relevant PRs

Carles Cufi
 

Hi all,

I'd like to ask you to set the milestone in all Pull Requests that need to be merged during the stabilization period (be them bugfix and documentation or special cases, in which case they also require the "TSC" label).
This will help filter out any PRs that can wait until 2.3 is released, thus alleviating the burden on reviewers and maintainers.

Thanks in advance.

Regards,

Carles


Re: #networking #ppp #gsm_modem #mbedtls #ppp #gsm_modem #mbedtls #networking

Bo.Kragelund@...
 

Hi Jukka
And thank you very much for your very quick answer.
I am sorry I haven't repsonded before, but we had a national Holiday in Denmark Friday the 8th.

I will try to answer on your comments.

Regarding the buffer counts, having a value of 14 is written in the documentation of zephyr 2.2.0 as the link below shows.
https://docs.zephyrproject.org/2.2.0/reference/kconfig/CONFIG_NET_PKT_RX_COUNT.html?highlight=config_net_pkt_rx_count#cmdoption-arg-config-net-pkt-rx-count

Regarding the buffer counts, having a value of 36 is written in the documentation of zephyr 2.2.0 as the link below shows.
https://docs.zephyrproject.org/2.2.0/reference/kconfig/CONFIG_NET_BUF_TX_COUNT.html?highlight=config_net_buf_tx_count#cmdoption-arg-config-net-buf-tx-count

We are already using a maximum heap size for CONFIG_MBEDTLS_HEAP_SIZE of 65356.
CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN is set to 8196.
And it is the same configuration in both Ethernet and GSM modem.

Using the maximum value of 16384 for CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN gives another error of "<err> net_sock_tls: TLS handshake error: -4310" when running state MBEDTLS_SSL_CERTIFICATE_VERIFY.

Anyway, this is the "maximum" configuration we use now, where some buffers and also some NET RX and TX stacks are increased to the double of default.

I have disabled some shell to get more memory available for this.
And I am still stuck with the same error in the GSM modem variant.
The Ethernet variant still works perfect.

Again, I have attached the two auto generated header files, so they can be compared directly.
Basically the header file for Ethernet has some ETH related configuration and the GSM modem header has some MODEM and PPP related configuration.
I have also attached the two proj.cnf so they can be compared directly.
And basically you will see, that there is a section at the bottom for using GSM modem, which is based on the GSM_modem sample project.
And when building for Ethernet, you will see this section outcommented more or less, except for the buffers and some net stacks. The only other thing Ethernet variant has enabled is the DHCPV4.


Regarding using latest upstream zephyr version I have tried using 2.2.3rc1 and compare with 2.2.0.
I am only testing the gsm_modem sample project, but using UART 3 on the frdm_k64f board, which is compatible with Arduino pinout, which my modem shield uses.

Using an oscilloscope, no data is sent out on UART 3 for communicating with the modem shield, when I test with zephyr 2.2.3rc1.
Everything works fine with zephyr version 2.2.0 and I can use the net shell to ping some IP addresses, meaning the modem is being configured correct via PPP over UART 3.

What am I missing in order to sent out data on UART 3 on the frdm_k64f board??
 
There are some changes to the configuration of UART 3 between zephyr 2.2.3rc1 and 2.2.0.

In zephyr 2.2.0 the following configuration parameters are needed to make the UART 3 work, which can be seen in the attahced proj.2.2.0.conf for the gms_modem sample project:
CONFIG_SERIAL=y CONFIG_UART_MCUX_3=y CONFIG_MODEM_GSM_UART_NAME="UART_3" 

In zephyr 2.2.3rc1 it seems like CONFIG_UART_MCUX_3=y is no longer needed and I only have to set the two other configuration parameters, which can be seen in the attached proj.2.2.3rc1.conf for the gms_modem sample project: CONFIG_SERIAL=y CONFIG_MODEM_GSM_UART_NAME="UART_3"

I hope to get 2.2.3rc1 up and running to see if it solves my issues with mbedtls certificate handshaking, as you also suggest as first thing to try.

Best regards,
Bo


Re: Thread Scheduling question

Peter A. Bigot
 

> I'm not quite sure what you are trying to mitigate, exactly.  This is the desired behavior.  You WANT your two custom threads to run instead of  your main thread, that's why they're higher priority.

I think the mitigation is of Zephyr's default behavior: that the main thread is preemptible by default.  I've also run into this where starting a repeating timer with no initial delay in main caused a work item to be submitted (from interrupt) and started (from system work thread, which is default cooperative) before I'd finished configuring the work item back in main.

Not that it's wrong, but it's unexpected to have main be preemptible, and since every thread declared in the samples and drivers is cooperative people just starting with threads are likely to make this "mistake".

Peter


Re: Thread Scheduling question

Raj Gundi
 

This will help, Andy. Thanks for your inputs!

 

Regards,

Raj

 

From: Ross, Andrew J <andrew.j.ross@...>
Sent: 11 May 2020 10:53
To: Gundi, Rajavardhan <rajavardhan.gundi@...>; devel@...
Subject: Re: [Zephyr-devel] Thread Scheduling question

 

Your understanding is correct.  If a higher priority thread is available to run, then a preemptible thread will yield to that thread at every scheduling point.

I'm not quite sure what you are trying to mitigate, exactly.  This is the desired behavior.  You WANT your two custom threads to run instead of  your main thread, that's why they're higher priority.  I think you might want to revisit the priority design in your app, basically.  The priorities you've assigned to your threads don't reflect what you want them to do.

If you just need the custom threads to get out of the way at startup, why not just have them sleep a bit, or (much better) block on a semaphore or whatever waiting for main to signal them to begin.  Or you can change priorities at runtime -- have main start at a very high priority but then lower itself, for example.  Or launch the threads dynamically via k_thread_create() at runtime once you know it's safe for them to run...

Andy

On 5/10/2020 9:24 PM, Raj Gundi wrote:

Hi,

 

This is a question related to thread scheduling. Imagine you have 2 custom threads in addition to the “main thread”. The custom threads are created static (K_THREAD_DEFINE) and are cooperative threads (let’s say the priority is -5) whereas the main thread is preemptive (priority 0). Now, as soon as the main thread is handed control (via switch_to_main_thread), it is possible the scheduler gets triggered and one of the cooperative threads gets scheduled. This may be undesirable since main thread may need to get some stuff done before the cooperative threads take over.

 

Is my reading of the above situation correct? If yes, I would like to see how this can be mitigated. One easy thing is to make main thread also cooperative (say, a priority of -6). The other is to lock the scheduler as soon as the main thread is entered and unlock only after the relevant stuff is addressed. Please let me know your views.

 

Regards,

Raj


Re: Thread Scheduling question

Andy Ross
 

Your understanding is correct.  If a higher priority thread is available to run, then a preemptible thread will yield to that thread at every scheduling point.

I'm not quite sure what you are trying to mitigate, exactly.  This is the desired behavior.  You WANT your two custom threads to run instead of  your main thread, that's why they're higher priority.  I think you might want to revisit the priority design in your app, basically.  The priorities you've assigned to your threads don't reflect what you want them to do.

If you just need the custom threads to get out of the way at startup, why not just have them sleep a bit, or (much better) block on a semaphore or whatever waiting for main to signal them to begin.  Or you can change priorities at runtime -- have main start at a very high priority but then lower itself, for example.  Or launch the threads dynamically via k_thread_create() at runtime once you know it's safe for them to run...

Andy

On 5/10/2020 9:24 PM, Raj Gundi wrote:

Hi,

 

This is a question related to thread scheduling. Imagine you have 2 custom threads in addition to the “main thread”. The custom threads are created static (K_THREAD_DEFINE) and are cooperative threads (let’s say the priority is -5) whereas the main thread is preemptive (priority 0). Now, as soon as the main thread is handed control (via switch_to_main_thread), it is possible the scheduler gets triggered and one of the cooperative threads gets scheduled. This may be undesirable since main thread may need to get some stuff done before the cooperative threads take over.

 

Is my reading of the above situation correct? If yes, I would like to see how this can be mitigated. One easy thing is to make main thread also cooperative (say, a priority of -6). The other is to lock the scheduler as soon as the main thread is entered and unlock only after the relevant stuff is addressed. Please let me know your views.

 

Regards,

Raj


Thread Scheduling question

Raj Gundi
 

Hi,

 

This is a question related to thread scheduling. Imagine you have 2 custom threads in addition to the “main thread”. The custom threads are created static (K_THREAD_DEFINE) and are cooperative threads (let’s say the priority is -5) whereas the main thread is preemptive (priority 0). Now, as soon as the main thread is handed control (via switch_to_main_thread), it is possible the scheduler gets triggered and one of the cooperative threads gets scheduled. This may be undesirable since main thread may need to get some stuff done before the cooperative threads take over.

 

Is my reading of the above situation correct? If yes, I would like to see how this can be mitigated. One easy thing is to make main thread also cooperative (say, a priority of -6). The other is to lock the scheduler as soon as the main thread is entered and unlock only after the relevant stuff is addressed. Please let me know your views.

 

Regards,

Raj


Re: 回复:[Zephyr-devel] How to compile riscv64 program with 0.10.3 sdk "riscv64-zephyr-elf-gcc" toolchain?

Stephanos Ioannidis
 

Sure, that was why “riscv32-zephyr-elf-“ toolchain was removed in the SDK 0.11.0 release:

https://github.com/zephyrproject-rtos/sdk-ng/commit/5997df8e3dc78184543f05ccbbc425c2d3c2818b

 

Stephanos

 

From: 曹子 <caozilong@...>
Sent: Monday, May 11, 2020 12:48 PM
To: Stephanos Ioannidis <root@...>; devel <devel@...>
Subject:
复:[Zephyr-devel] How to compile riscv64 program with 0.10.3 sdk "riscv64-zephyr-elf-gcc" toolchain?

 

Thank you!

 

if so,it seems riscv32 toolchain also can take this flag and generate the 64 bit program.

 

riscv32-zephyr-elf-gcc -march=rv64i -mabi=lp64 -c  main.c -o main

 

caozilong@Exdroid94:~/WorkSpace/riscvilp32$ file main

main: ELF 64-bit LSB  relocatable, version 1 (SYSV), not stripped

 

so, it seems still no difference of two sets of toolchain,

 

曹子

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技29

TEL13824125580

Emailcaozilong@...

网址: http://www.allwinnertech.com

 

 

------------------------------------------------------------------

件人:Stephanos Ioannidis <root@...>

时间2020511(星期一) 09:50

收件人:曹子 <caozilong@...>; devel <devel@...>

主 RE: [Zephyr-devel] How to compile riscv64 program with 0.10.3 sdk "riscv64-zephyr-elf-gcc" toolchain?

 

Hi,

 

You need to specify the correct ABI type through `-mabi` alongside the `-march` flag.

 

Try `-march=rv64i -mabi=lp64` for instance.

 

Regards,

 

Stephanos

 

From: devel@... <devel@...> On Behalf Of "??? via lists.zephyrproject.org
Sent: Sunday, May 10, 2020 9:28 PM
To: devel <devel@...>
Subject: [Zephyr-devel] How to compile riscv64 program with 0.10.3 sdk "riscv64-zephyr-elf-gcc" toolchain?

 

I try to compile program with "zephyr-sdk-0.10.3/riscv64-zephyr-elf/bin/riscv64-zephyr-elf-gcc " to compile my program,

 

but it seems the result still be 32 bit program:

a.out: ELF 32-bit LSB executable, UCB RISC-V, version 1 (SYSV), statically linked, with debug_info, not stripped

 

and i event try to compile with rv64 flag -march=rv64i

./riscv64-zephyr-elf-gcc -g main.c  -march=rv64i

cc1: error: ABI requires -march=rv32

 it seems still dont work 

 

at the beginning i guess it mybe use a ilp32 abi based on rv64 toolchan, so i try a program like that:

 20 unsigned long long foolbar2(unsigned long long a, unsigned long long b)

 21 {

 22         return a + b;

 23 }

whch unsigned long should be compile to "ld" and "sd" pare means ilp32 abi on RV64ISA ARCH.

but

  95 {          

  96    10194:       fe010113                addi    sp,sp,-32

  97    10198:       00812e23                sw      s0,28(sp)

  98    1019c:       02010413                addi    s0,sp,32

  99    101a0:       fea42423                sw      a0,-24(s0)

 100    101a4:       feb42623                sw      a1,-20(s0)

 101    101a8:       fec42023                sw      a2,-32(s0)

 102    101ac:       fed42223                sw      a3,-28(s0)

 103         return a + b;

 104    101b0:       fe842783                lw      a5,-24(s0)

 105    101b4:       fec42803                lw      a6,-20(s0)

 106    101b8:       fe042583                lw      a1,-32(s0)

 107    101bc:       fe442603                lw      a2,-28(s0)

 108    101c0:       00b786b3                add     a3,a5,a1

 

it purely total no!!!

 

so why? now that an rv32-zephyr-elf-gcc exist, if the iscv64-zephyr-elf-gcc  cat compile the 64 bit program, why it here ? 

 

曹子

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技29

TEL13824125580

Emailcaozilong@...

网址: http://www.allwinnertech.com

 

 

 


回复:[Zephyr-devel] How to compile riscv64 program with 0.10.3 sdk "riscv64-zephyr-elf-gcc" toolchain?

"曹子龙
 

Thank you!

if so,it seems riscv32 toolchain also can take this flag and generate the 64 bit program.

riscv32-zephyr-elf-gcc -march=rv64i -mabi=lp64 -c  main.c -o main

caozilong@Exdroid94:~/WorkSpace/riscvilp32$ file main
main: ELF 64-bit LSB  relocatable, version 1 (SYSV), not stripped

so, it seems still no difference of two sets of toolchain,

曹子龙

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 


------------------------------------------------------------------
发件人:Stephanos Ioannidis <root@...>
发送时间:2020年5月11日(星期一) 09:50
收件人:曹子龙 <caozilong@...>; devel <devel@...>
主 题:RE: [Zephyr-devel] How to compile riscv64 program with 0.10.3 sdk "riscv64-zephyr-elf-gcc" toolchain?

Hi,

 

You need to specify the correct ABI type through `-mabi` alongside the `-march` flag.

 

Try `-march=rv64i -mabi=lp64` for instance.

 

Regards,

 

Stephanos

 

From: devel@... <devel@...> On Behalf Of "??? via lists.zephyrproject.org
Sent: Sunday, May 10, 2020 9:28 PM
To: devel <devel@...>
Subject: [Zephyr-devel] How to compile riscv64 program with 0.10.3 sdk "riscv64-zephyr-elf-gcc" toolchain?

 

I try to compile program with "zephyr-sdk-0.10.3/riscv64-zephyr-elf/bin/riscv64-zephyr-elf-gcc " to compile my program,

 

but it seems the result still be 32 bit program:

a.out: ELF 32-bit LSB executable, UCB RISC-V, version 1 (SYSV), statically linked, with debug_info, not stripped

 

and i event try to compile with rv64 flag -march=rv64i

./riscv64-zephyr-elf-gcc -g main.c  -march=rv64i

cc1: error: ABI requires -march=rv32

 it seems still dont work 

 

at the beginning i guess it mybe use a ilp32 abi based on rv64 toolchan, so i try a program like that:

 20 unsigned long long foolbar2(unsigned long long a, unsigned long long b)

 21 {

 22         return a + b;

 23 }

whch unsigned long should be compile to "ld" and "sd" pare means ilp32 abi on RV64ISA ARCH.

but

  95 {          

  96    10194:       fe010113                addi    sp,sp,-32

  97    10198:       00812e23                sw      s0,28(sp)

  98    1019c:       02010413                addi    s0,sp,32

  99    101a0:       fea42423                sw      a0,-24(s0)

 100    101a4:       feb42623                sw      a1,-20(s0)

 101    101a8:       fec42023                sw      a2,-32(s0)

 102    101ac:       fed42223                sw      a3,-28(s0)

 103         return a + b;

 104    101b0:       fe842783                lw      a5,-24(s0)

 105    101b4:       fec42803                lw      a6,-20(s0)

 106    101b8:       fe042583                lw      a1,-32(s0)

 107    101bc:       fe442603                lw      a2,-28(s0)

 108    101c0:       00b786b3                add     a3,a5,a1

 

it purely total no!!!

 

so why? now that an rv32-zephyr-elf-gcc exist, if the iscv64-zephyr-elf-gcc  cat compile the 64 bit program, why it here ? 

 

曹子

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技29

TEL13824125580

Emailcaozilong@...

网址: http://www.allwinnertech.com

 

 



Re: How to compile riscv64 program with 0.10.3 sdk "riscv64-zephyr-elf-gcc" toolchain?

Stephanos Ioannidis
 

Hi,

 

You need to specify the correct ABI type through `-mabi` alongside the `-march` flag.

 

Try `-march=rv64i -mabi=lp64` for instance.

 

Regards,

 

Stephanos

 

From: devel@... <devel@...> On Behalf Of "??? via lists.zephyrproject.org
Sent: Sunday, May 10, 2020 9:28 PM
To: devel <devel@...>
Subject: [Zephyr-devel] How to compile riscv64 program with 0.10.3 sdk "riscv64-zephyr-elf-gcc" toolchain?

 

I try to compile program with "zephyr-sdk-0.10.3/riscv64-zephyr-elf/bin/riscv64-zephyr-elf-gcc " to compile my program,

 

but it seems the result still be 32 bit program:

a.out: ELF 32-bit LSB executable, UCB RISC-V, version 1 (SYSV), statically linked, with debug_info, not stripped

 

and i event try to compile with rv64 flag -march=rv64i

./riscv64-zephyr-elf-gcc -g main.c  -march=rv64i

cc1: error: ABI requires -march=rv32

 it seems still dont work 

 

at the beginning i guess it mybe use a ilp32 abi based on rv64 toolchan, so i try a program like that:

 20 unsigned long long foolbar2(unsigned long long a, unsigned long long b)

 21 {

 22         return a + b;

 23 }

whch unsigned long should be compile to "ld" and "sd" pare means ilp32 abi on RV64ISA ARCH.

but

  95 {          

  96    10194:       fe010113                addi    sp,sp,-32

  97    10198:       00812e23                sw      s0,28(sp)

  98    1019c:       02010413                addi    s0,sp,32

  99    101a0:       fea42423                sw      a0,-24(s0)

 100    101a4:       feb42623                sw      a1,-20(s0)

 101    101a8:       fec42023                sw      a2,-32(s0)

 102    101ac:       fed42223                sw      a3,-28(s0)

 103         return a + b;

 104    101b0:       fe842783                lw      a5,-24(s0)

 105    101b4:       fec42803                lw      a6,-20(s0)

 106    101b8:       fe042583                lw      a1,-32(s0)

 107    101bc:       fe442603                lw      a2,-28(s0)

 108    101c0:       00b786b3                add     a3,a5,a1

 

it purely total no!!!

 

so why? now that an rv32-zephyr-elf-gcc exist, if the iscv64-zephyr-elf-gcc  cat compile the 64 bit program, why it here ? 

 

曹子

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技29

TEL13824125580

Emailcaozilong@...

网址: http://www.allwinnertech.com

 

 


Zephyr 2.3.0-rc1 tagged

Carles Cufi
 

Hi all,

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

The merge window for features and enhancements is now closed for this release, and it will remain closed until 2.3.0 is released; the stabilization period is now open.
During said stabilization period only bug-fix, documentation, and stabilization-related patches may be merged to master.
Additional features or enhancements for the 2.3 release will require approval by the TSC.
As we need to reduce bug counts for the release, you are all encouraged to submit PRs that close existing bug reports, and to help reviewing such PRs submitted by other contributors or maintainers.
Testing Zephyr master branch during the stabilization period is also requested; please test the code base and file bug reports so they can be addressed before the release deadline.

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

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 is tentatively scheduled for May 29th.

Note 1: You are of course free to send Pull Requests for new features in order to gather feedback early or collaborate with others, but the release team would like to encourage everyone to focus on bugfixes and documentation improvements to the larges extent possible, so that we can release 2.3.0 on time and in the best shape possible.
Note 2: If you have a feature or enhancement you would like to submit to the TSC, please tag the Pull Request in question with the "TSC" label, make sure it is approved and passing CI, and attend the next TSC meeting.

A big Thank You to everyone that contributed to this release so far, be it with code, reviews, documentation or any other type of contribution.

Thanks,

Carles


How to compile riscv64 program with 0.10.3 sdk "riscv64-zephyr-elf-gcc" toolchain?

"曹子龙
 

I try to compile program with "zephyr-sdk-0.10.3/riscv64-zephyr-elf/bin/riscv64-zephyr-elf-gcc " to compile my program,

but it seems the result still be 32 bit program:
czl@czl-Vostro-3268:~/zephyr-sdk-0.10.3/riscv64-zephyr-elf/bin$ file a.out
a.out: ELF 32-bit LSB executable, UCB RISC-V, version 1 (SYSV), statically linked, with debug_info, not stripped

and i event try to compile with rv64 flag -march=rv64i
./riscv64-zephyr-elf-gcc -g main.c  -march=rv64i
cc1: error: ABI requires -march=rv32
 it seems still dont work 

at the beginning i guess it mybe use a ilp32 abi based on rv64 toolchan, so i try a program like that:
 20 unsigned long long foolbar2(unsigned long long a, unsigned long long b)
 21 {
 22         return a + b;
 23 }
whch unsigned long should be compile to "ld" and "sd" pare means ilp32 abi on RV64ISA ARCH.
but
  95 {          
  96    10194:       fe010113                addi    sp,sp,-32
  97    10198:       00812e23                sw      s0,28(sp)
  98    1019c:       02010413                addi    s0,sp,32
  99    101a0:       fea42423                sw      a0,-24(s0)
 100    101a4:       feb42623                sw      a1,-20(s0)
 101    101a8:       fec42023                sw      a2,-32(s0)
 102    101ac:       fed42223                sw      a3,-28(s0)
 103         return a + b;
 104    101b0:       fe842783                lw      a5,-24(s0)
 105    101b4:       fec42803                lw      a6,-20(s0)
 106    101b8:       fe042583                lw      a1,-32(s0)
 107    101bc:       fe442603                lw      a2,-28(s0)
 108    101c0:       00b786b3                add     a3,a5,a1

it purely total no!!!

so why? now that an rv32-zephyr-elf-gcc exist, if the iscv64-zephyr-elf-gcc  cat compile the 64 bit program, why it here ? 

曹子龙

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 



API Change: video

Carles Cufi
 

Hi all,

A recent stable API has been modified to adapt it to the recent kernel timeout change.

video_dequeue() now takes a k_timeout_t instead of a u32_t for the type of the timeout parameter.

Note that if you enable `CONFIG_LEGACY_TIMEOUT_API` then k_timeout_t is reverted to be an s32_t.

Regards,

Carles


Re: Dev-Review Meeting Agenda May 7

Bolivar, Marti
 

Sorry, found it in the notes!

- Simon

On Thu, 7 May 2020 at 08:49, Simon Glass <@sjg1> wrote:

Hi Kumar,

Is there a link to the meeting somewhere please?

Regards,
Simon

On Thu, 7 May 2020 at 08:24, Kumar Gala <kumar.gala@...> wrote:

Here’s the agenda topics for this week:

* Review PR’s tagged with dev-review

* Any topics anyone else has.

- k


Re: Dev-Review Meeting Agenda May 7

Simon Glass
 

Sorry, found it in the notes!

- Simon

On Thu, 7 May 2020 at 08:49, Simon Glass <@sjg1> wrote:

Hi Kumar,

Is there a link to the meeting somewhere please?

Regards,
Simon

On Thu, 7 May 2020 at 08:24, Kumar Gala <kumar.gala@...> wrote:

Here’s the agenda topics for this week:

* Review PR’s tagged with dev-review

* Any topics anyone else has.

- k


Upcoming Event: Zephyr Project: Dev Meeting - Thu, 05/07/2020 8:00am-9:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 7 May 2020, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join Microsoft Teams Meeting: https://teams.microsoft.com/l/meetup-join/19%3ameeting_M2Q2ZDk4OWItMWE2MS00MTExLTkyYTQtNmUwOTA4MzgwOGYw%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

+1 213-437-3346 United States, Los Angeles (Toll)
Conference ID: 750 623 026#


Local numbers: 
https://dialin.teams.microsoft.com/488d1b50-0dd2-4ca1-aee4-92bb50a48081?id=750623026