|
Re: Using/misusing k_sem_init()
Yeah, I guess, and there has to be some protocol between the thread that
does the flush which then has to wait for the threads that take the
semaphore which then all have to reply to it before it can
Yeah, I guess, and there has to be some protocol between the thread that
does the flush which then has to wait for the threads that take the
semaphore which then all have to reply to it before it can
|
By
Benjamin Walsh <benjamin.walsh@...>
·
#4254
·
|
|
Re: Using/misusing k_sem_init()
I meant that would wake up the thread waiting on the semaphore, since
reinitializing it would not do that.
OK, cool. No need to add a feature to the semaphore API that does not
have at least one real
I meant that would wake up the thread waiting on the semaphore, since
reinitializing it would not do that.
OK, cool. No need to add a feature to the semaphore API that does not
have at least one real
|
By
Benjamin Walsh <benjamin.walsh@...>
·
#4253
·
|
|
Re: Chain booting in Zephyr
This is one of the reasons I'd like to at least be able to keep the
vector table in ROM.
On the devices I'm using, address 0 is ROM, so this is less of a
concern, but it is still possible to have
This is one of the reasons I'd like to at least be able to keep the
vector table in ROM.
On the devices I'm using, address 0 is ROM, so this is less of a
concern, but it is still possible to have
|
By
David Brown
·
#4252
·
|
|
Re: Quark Flash driver application issue
Yes I know that app is for spi flash , but I have already mentioned in the mail that I have modified the SPI flash application to suite the Quark Flash.
I have used device_get_binding("QUARK_FLASH");
Yes I know that app is for spi flash , but I have already mentioned in the mail that I have modified the SPI flash application to suite the Quark Flash.
I have used device_get_binding("QUARK_FLASH");
|
By
Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao@...>
·
#4251
·
|
|
Re: Quark Flash driver application issue
The app is for spi flash, not for soc flash.
Thanks
Baohong
Sent: Tuesday, December 13, 2016 10:20 AM
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: Quark
The app is for spi flash, not for soc flash.
Thanks
Baohong
Sent: Tuesday, December 13, 2016 10:20 AM
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: Quark
|
By
Liu, Baohong
·
#4250
·
|
|
Re: Quark Flash driver application issue
Hi Liu
Thanks for the reply
Its given as #define FLASH_TEST_REGION_OFFSET.
Offset means I thought that starting address + offset ( eg: 0x40000000 + 0)
So, you meant to say , I need to give
Hi Liu
Thanks for the reply
Its given as #define FLASH_TEST_REGION_OFFSET.
Offset means I thought that starting address + offset ( eg: 0x40000000 + 0)
So, you meant to say , I need to give
|
By
Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao@...>
·
#4249
·
|
|
Re: Chain booting in Zephyr
Sent: Tuesday, December 13, 2016 7:29 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Chain booting in Zephyr
Do we have any expectation of having a RAM vector table in the
Sent: Tuesday, December 13, 2016 7:29 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Chain booting in Zephyr
Do we have any expectation of having a RAM vector table in the
|
By
Chuck Jordan <Chuck.Jordan@...>
·
#4248
·
|
|
Re: Quark Flash driver application issue
SoC flash is on the system address space. Here are the size and starting address on quark SE SoC.
System Flash 192KB 0x40000000
System ROM 8KB 0xFFFFE000
Thanks
Baohong
Sent:
SoC flash is on the system address space. Here are the size and starting address on quark SE SoC.
System Flash 192KB 0x40000000
System ROM 8KB 0xFFFFE000
Thanks
Baohong
Sent:
|
By
Liu, Baohong
·
#4247
·
|
|
Re: Quark Flash driver application issue
Starting address is not zero. Please use the same address x86 cpu uses when it accesses the soc flash.
Regards
Baohong
Sent: Tuesday, December 13, 2016 6:09 AM
To:
Starting address is not zero. Please use the same address x86 cpu uses when it accesses the soc flash.
Regards
Baohong
Sent: Tuesday, December 13, 2016 6:09 AM
To:
|
By
Liu, Baohong
·
#4246
·
|
|
Re: Chain booting in Zephyr
This all seems reasonable. I'm currently working on an overhaul on how the
vector table is created at build time and will add a Kconfig option to place it
in either RAM or ROM as required.
Andrew
This all seems reasonable. I'm currently working on an overhaul on how the
vector table is created at build time and will add a Kconfig option to place it
in either RAM or ROM as required.
Andrew
|
By
Boie, Andrew P
·
#4245
·
|
|
Re: how long do we keep jenkins logs
Greetings folks,
Giving an update to this as I just merged a change to improve the log
shipping to also include a version of the console log with the timestamping.
You'll find a console log and a
Greetings folks,
Giving an update to this as I just merged a change to improve the log
shipping to also include a version of the console log with the timestamping.
You'll find a console log and a
|
By
Andrew Grimberg <agrimberg@...>
·
#4244
·
|
|
Daily JIRA Digest
NEW JIRA items within last 24 hours: 3
[ZEP-1435] Improve Quark SE C1000 ARC Floating Point Performance
https://jira.zephyrproject.org/browse/ZEP-1435
[ZEP-1432] ksdk pinmux driver should
NEW JIRA items within last 24 hours: 3
[ZEP-1435] Improve Quark SE C1000 ARC Floating Point Performance
https://jira.zephyrproject.org/browse/ZEP-1435
[ZEP-1432] ksdk pinmux driver should
|
By
donotreply@...
·
#4243
·
|
|
Re: Chain booting in Zephyr
There is one more argument if favor of putting vector table in RAM.
Typically during flash write/erase operations which tend to be long any
read access to flash will generate idle cycles on AHB bus
There is one more argument if favor of putting vector table in RAM.
Typically during flash write/erase operations which tend to be long any
read access to flash will generate idle cycles on AHB bus
|
By
Piotr Mieńkowski <piotr.mienkowski at gmail.com...>
·
#4242
·
|
|
Daily Gerrit Digest
NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/9023 : k64f: Default the ETH_KSDK on if NET_L2_ETHERNET enabled.
- https://gerrit.zephyrproject.org/r/9002 : board: v2m_beetle:
NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/9023 : k64f: Default the ETH_KSDK on if NET_L2_ETHERNET enabled.
- https://gerrit.zephyrproject.org/r/9002 : board: v2m_beetle:
|
By
donotreply@...
·
#4241
·
|
|
Re: Using/misusing k_sem_init()
Hi Ben,
Sorry, I wrote a somehow longish description of the issue but didn't
mentioned the expected behavior.
When I clean up the descriptor list and re-initialize the semaphores I
would expect the
Hi Ben,
Sorry, I wrote a somehow longish description of the issue but didn't
mentioned the expected behavior.
When I clean up the descriptor list and re-initialize the semaphores I
would expect the
|
By
Piotr Mieńkowski <piotr.mienkowski at gmail.com...>
·
#4240
·
|
|
Quark Flash driver application issue
Hi
I have referred samples/drivers/spi_flash and modified main.c to support the quark c1000 flash.
Driver binding is successful , but its giving erase failure.
I have attached the code and prj.conf
Hi
I have referred samples/drivers/spi_flash and modified main.c to support the quark c1000 flash.
Driver binding is successful , but its giving erase failure.
I have attached the code and prj.conf
|
By
Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao@...>
·
#4239
·
|
|
Re: Using/misusing k_sem_init()
To reinitialize things here implies that the owner of the buffer has
lost so much state that it can no longer release it as normal. Why does
an unrecoverable error cause such a catastrophic loss of
To reinitialize things here implies that the owner of the buffer has
lost so much state that it can no longer release it as normal. Why does
an unrecoverable error cause such a catastrophic loss of
|
By
Daniel Thompson <daniel.thompson@...>
·
#4238
·
|
|
Re: Chain booting in Zephyr
Hi David,
By
Carles Cufi
·
#4237
·
|
|
Re: Chain booting in Zephyr
Hi David,
This is similar to how the NRF51 operates. In Mynewt these values are
trampolined to SRAM locations (i.e. the interrupt vectors jump to code
in SRAM.) We locate the bootloader after the
Hi David,
This is similar to how the NRF51 operates. In Mynewt these values are
trampolined to SRAM locations (i.e. the interrupt vectors jump to code
in SRAM.) We locate the bootloader after the
|
By
Sterling Hughes <sterling@...>
·
#4236
·
|
|
Chain booting in Zephyr
As some of you may know, I've been working on making the Mynewt
bootloader work as a bootloader build with Zephyr. One issue I've
been running into is setting the vector table address in the
As some of you may know, I've been working on making the Mynewt
bootloader work as a bootloader build with Zephyr. One issue I've
been running into is setting the vector table address in the
|
By
David Brown
·
#4235
·
|