Date   

Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1278 : sensor: fix coding style (bmc150 and lsm9ds0)
- https://gerrit.zephyrproject.org/r/1280 : Bluetooth: BR/EDR: Get proper L2CAP CID limits
- https://gerrit.zephyrproject.org/r/1279 : Bluetooth: BR/EDR: Increase L2CAP signal channel pool
- https://gerrit.zephyrproject.org/r/1281 : Bluetooth: BR/EDR: Make available L2CAP signal channel
- https://gerrit.zephyrproject.org/r/1273 : spi: intel: fix port 1 pin setup

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1232 : kernel: Make idle task sleep
- https://gerrit.zephyrproject.org/r/1271 : sensors: Using new GPIO API callbacks
- https://gerrit.zephyrproject.org/r/914 : gpio: Improve the public API to handle multi callbacks
- https://gerrit.zephyrproject.org/r/1190 : drivers: Renaming directory "802.15.4" into "ieee802154"
- https://gerrit.zephyrproject.org/r/804 : ieee802154: Replace the CC2520 driver with a new implementation
- https://gerrit.zephyrproject.org/r/1226 : sys_clock: Add a helper to compute micro seconds
- https://gerrit.zephyrproject.org/r/1217 : stm32: reorganise soc directory and use family/series
- https://gerrit.zephyrproject.org/r/1135 : boards: nucleo: Adding flash support
- https://gerrit.zephyrproject.org/r/1215 : stm32: rename SOC_STM32F1X -> SOC_SERIES_STM32F1X
- https://gerrit.zephyrproject.org/r/1214 : stm32: rename CONFIG_SOC_STM32 -> CONFIG_SOC_FAMILY_STM32
- https://gerrit.zephyrproject.org/r/1216 : kinetis: reorganise soc directory using soc family
- https://gerrit.zephyrproject.org/r/1219 : soc: introduce SoC families and series
- https://gerrit.zephyrproject.org/r/1221 : new SoC naming convention
- https://gerrit.zephyrproject.org/r/1255 : relocate_sdk.patch: Fix file sections overwrites

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1277 : Bluetooth: Fix not using endianess helper in LE L2CAP conn req
- https://gerrit.zephyrproject.org/r/1276 : Bluetooth: Fix BLUETOOTH_NRF51_PM Kconfig definition
- https://gerrit.zephyrproject.org/r/1275 : sanitycheck: fix initlevel section being mentioned twice
- https://gerrit.zephyrproject.org/r/1274 : rtc/qmsi: Fix the IRQ priority setting according to the SoC specific option
- https://gerrit.zephyrproject.org/r/1272 : sensors: fix coding style regarding max line length
- https://gerrit.zephyrproject.org/r/1254 : ethernet/dw: remove kconfigs that are SoC specific
- https://gerrit.zephyrproject.org/r/1270 : Bluetooth: tester: Use bt enable cb to indicate cmd rsp success
- https://gerrit.zephyrproject.org/r/1253 : job: jira: change recipient email


Re: nRF52 port for Zephyr

Xue Liu
 

Hello Johan Hedberg,

Thank you for your info.


2016-04-07 12:47 GMT+02:00 Johan Hedberg <johan.hedberg(a)intel.com>:

Hi Xue Liu,

On Wed, Apr 06, 2016, Xue Liu wrote:
Now I am working on the port of nRF52 DK board for Zephyr project. I have
several questions about the procedures of port.

1. I use nRF5x SDK v11.0 as a start point. This SDK dependence on CMSIS.
Since currently there is no CMSIS in the Zephyr, should I rewrite the
register and bitfields definitions or just copy these files from nRF52
SDK
to the Zephyr ?
2. From the technical review
https://www.zephyrproject.org/sites/local-zephyr/files/zephyr_project_technical_overview.pdf
.
The Zephyr project will support CMSIS. But until now there is no source
code or support of CMSIS. Is it right ?
3. Could someone gives me some suggestions or guide to port a new SOC to
the Zephyr.
Have you taken a look at how MyNewt has implemented support for the
nRF52? It's one of their supported platforms. IIRC they have copies of
the nRF5x SDK header files in their source tree.
Yes. I have seen the soc source code of nr52. But nRF5x SDK depends on
header files from CMSIS.
Maybe I should go on porting with CMSIS in the "lib" like MyNewt done, and
wait for the official CMSIS support in Zephyr.


Johan
Regards,

Xue Liu



--


Re: nRF52 port for Zephyr

Xue Liu
 

Hello Daniel,

Thank you for your feedback

2016-04-07 2:30 GMT+02:00 Kalowsky, Daniel <daniel.kalowsky(a)intel.com>:

Xue,

-----Original Message-----
From: Xue Liu [mailto:liuxuenetmail(a)gmail.com]
Sent: Wednesday, April 6, 2016 2:27 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] nRF52 port for Zephyr

Hello,

Now I am working on the port of nRF52 DK board for Zephyr project. I have
several questions about the procedures of port.

1. I use nRF5x SDK v11.0 as a start point. This SDK dependence on CMSIS.
Since currently there is no CMSIS in the Zephyr, should I rewrite the
register
and bitfields definitions or just copy these files from nRF52 SDK to the
Zephyr
?
Can you provide a bit more detail about the options you're trying?
Now I chose the way of copying header files from nrf52 SDK and some macros
of CMSIS, such as __I, __O and __IO.


2. From the technical review https://www.zephyrproject.org/sites/local-
zephyr/files/zephyr_project_technical_overview.pdf. The Zephyr project
will support CMSIS. But until now there is no source code or support of
CMSIS. Is it right ?
There is work being done for this. It's one of the many pieces currently
being executed.
I am really looking forwarding the merge to the master. That will be much
easier for me to port nrf52.


3. Could someone gives me some suggestions or guide to port a new SOC to
the Zephyr.
I'd encourage you to look at the arch/ directory for samples of how to
model the SOC.
Yes. I have seen the soc of FRDM-K64F and stm32. They use unique
definitions of register and bit field.

Regards,

Xue Liu

--


Re: nRF52 port for Zephyr

Johan Hedberg
 

Hi Xue Liu,

On Wed, Apr 06, 2016, Xue Liu wrote:
Now I am working on the port of nRF52 DK board for Zephyr project. I have
several questions about the procedures of port.

1. I use nRF5x SDK v11.0 as a start point. This SDK dependence on CMSIS.
Since currently there is no CMSIS in the Zephyr, should I rewrite the
register and bitfields definitions or just copy these files from nRF52 SDK
to the Zephyr ?
2. From the technical review
https://www.zephyrproject.org/sites/local-zephyr/files/zephyr_project_technical_overview.pdf.
The Zephyr project will support CMSIS. But until now there is no source
code or support of CMSIS. Is it right ?
3. Could someone gives me some suggestions or guide to port a new SOC to
the Zephyr.
Have you taken a look at how MyNewt has implemented support for the
nRF52? It's one of their supported platforms. IIRC they have copies of
the nRF5x SDK header files in their source tree.

Johan


Re: Daily JIRA Digest

Kalowsky, Daniel <daniel.kalowsky@...>
 

-----Original Message-----
From: donotreply(a)jenkins.zephyrproject.org
[mailto:donotreply(a)jenkins.zephyrproject.org]
Sent: Wednesday, April 6, 2016 9:47 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Daily JIRA Digest

NEW JIRA items within last 24 hours: 2
B [ZEP-184] (P 2) QMSI 'CONFIG_RTC_IRQ_PRI' undeclared.
B [ZEP-183] (P 3) [regression]PINMUX_NUM_PINS is missing in
arch/x86/soc/quark_se/soc.h
The fact that I'm needing a decoder key/ring for these emails is not useful.

What does the B before each line mean?

Not convinced the priority is needed in these emails. It really does nothing to add to the title except create some bizarre string encryption.


UPDATED JIRA items within last 24 hours: 2
B [ZEP-75] (P 1) REOPENED Zephyr compiler fails with error about executing
cc1
B [ZEP-7] (P 3) REOPENED Arduino 101 GPIO_INT_LEVEL not working as
expected

CLOSED JIRA items within last 24 hours: 3
B [ZEP-174] (Fixed) Hello_world app build fail with error:
'PINMUX_BASE_ADDR' undeclared when
PINMUX_DEV,PINMUX_DEV_QUARK_MCU were enabled
B [ZEP-161] (Won't Do) Nothing output when run hello_world app with x86
SDK for quark platforms
B [ZEP-151] (Fixed) QMSI AON_TIMER_IRQ and AON_TIMER_IRQ_PRI have
not been configured in quark_se_devboard
Why is the closed status being inserted here? Anyone interested in that can and should go look at the JIRA.


RESOLVED JIRA items within last 24 hours: 0


Re: nRF52 port for Zephyr

Kalowsky, Daniel <daniel.kalowsky@...>
 

Xue,

-----Original Message-----
From: Xue Liu [mailto:liuxuenetmail(a)gmail.com]
Sent: Wednesday, April 6, 2016 2:27 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] nRF52 port for Zephyr

Hello,

Now I am working on the port of nRF52 DK board for Zephyr project. I have
several questions about the procedures of port.

1. I use nRF5x SDK v11.0 as a start point. This SDK dependence on CMSIS.
Since currently there is no CMSIS in the Zephyr, should I rewrite the register
and bitfields definitions or just copy these files from nRF52 SDK to the Zephyr
?
Can you provide a bit more detail about the options you're trying?

2. From the technical review https://www.zephyrproject.org/sites/local-
zephyr/files/zephyr_project_technical_overview.pdf. The Zephyr project
will support CMSIS. But until now there is no source code or support of
CMSIS. Is it right ?
There is work being done for this. It's one of the many pieces currently being executed.

3. Could someone gives me some suggestions or guide to port a new SOC to
the Zephyr.
I'd encourage you to look at the arch/ directory for samples of how to model the SOC.


Re: state of development and participation

Kalowsky, Daniel <daniel.kalowsky@...>
 

-----Original Message-----
From: Idupsle [mailto:idupsle(a)gmail.com]
Sent: Wednesday, April 6, 2016 8:50 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] state of development and participation

Hello,

I'm still wondering about this project. Is it right, that most work is
from intel? I was hoping, that NXP is continuing it's work on it - or
was it only for the early- support?
Having just spent the last few days with NXP at Open IoT / Embedded Linux Conference, I can say that they are still active on the project. I will let the member of NXP on the mailing list share their own thoughts about this.

Otherwise I'd like start to develop a little more for my K64, but
looking at those amount of daily changes, especially at the core api -
is it wiser to wait a few months? I really would like to contribute a
litte bit in my sparse spare time to get this board a little bit more
usable :)
I'd encourage you to submit such patches. The APIs should no longer be bouncing around. If they are, please call us out on when it is happening.


nRF52 port for Zephyr

Xue Liu
 

Hello,

Now I am working on the port of nRF52 DK board for Zephyr project. I have
several questions about the procedures of port.

1. I use nRF5x SDK v11.0 as a start point. This SDK dependence on CMSIS.
Since currently there is no CMSIS in the Zephyr, should I rewrite the
register and bitfields definitions or just copy these files from nRF52 SDK
to the Zephyr ?
2. From the technical review
https://www.zephyrproject.org/sites/local-zephyr/files/zephyr_project_technical_overview.pdf.
The Zephyr project will support CMSIS. But until now there is no source
code or support of CMSIS. Is it right ?
3. Could someone gives me some suggestions or guide to port a new SOC to
the Zephyr.

Thank you for your help.

Regards,

Xue Liu

--


Re: [RFC] Device: device_get_binding() returns NULL if device fails initialization

Daniel Leung <daniel.leung@...>
 

On Wed, Apr 06, 2016 at 02:02:17PM +0000, Kalowsky, Daniel wrote:
-----Original Message-----
From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Wednesday, April 6, 2016 12:00 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC] Device: device_get_binding() returns NULL if
device fails initialization

Hi Daniel,

That's actually a good point.

And that reminds me, that most of our drivers do not set driver API to
NULL if they fail.
But they do return an explicit code which no one care about:
see _sys_device_do_config_level() in kernel/nanokernel/device.c

I think there you can add also a tiny test:

if (device->init(info) < 0) {
info->driver_api = NULL;
}
Good point Tomasz. Might need to be part of the RFC patch that Daniel posted.
The original discussion was actually started about getting rid of returns of
initialization functions. The idea was that the kernel could not really do
anything when a driver failed initialization, so why not getting rid of returns
to save a few bytes. The burden of determining whether it is a critical error
during init is up to the driver. If there is a critical error, the driver
should assert (and setting driver_api to NULL).

There are situations where there are non-critical erros during initialization.
For example, the I2C driver, failure to set default configuration is not
critical. As long as the developer sets it later, the driver can still function.
However, with the above code, this non-critical error will cause driver_api
to be NULL, which prevents its usage at all. The driver writer should know
whether an error prevents the device from functioning at all. So it should be
up to driver writer to set driver_api to NULL. One can argue that a non-critical
error should not return anything other than 0. But then it is not passing on
the information that there is a non-critical error (though the kernel does not
really care).

(actually, naming in this function should be reversed: struct device
should be "device" and
struct device_config should be "info" or "config", even better. But I am
diverging from subject)

It's better to let device.c doing it, instead of making sure all driver
behaves well on that aspect.
As long as they return a relevant status, it will be fine.
Correct. If the OS is going to depend upon a feature/function being set to
indicate a specific status, the OS should be doing this not the device driver.
Although it doesn't hurt if the device driver does it as well :-)
(see above.)


Tomasz

Problem Statement:
Currently, there is no way to know if a driver fails initialization.

Problem Description:
Zephyr currently does not provide a way to check programmatically
whether a device can be used. The device_get_binding() always
returns a valid device struct (if such device driver instance
exists). This causes a bit of headache when debugging apps as
the developer assumes the devices are ready to be used.

Solution:
The solution was actually proposed in [1] a while ago. The idea
is to piggy-back onto driver_api pointer. If the pointer is NULL,
the device driver has failed in its own initialization function.
The driver_api is set to NULL (or in other words, never set to
the actual API struct). When device_get_binding() sess that
the driver_api is NULL for a particular device struct, it returns
NULL to the caller, and thus preventing its use in the app.
Since this is a binary state, instead of creating another variable
inside device struct, this uses driver_api to avoid unnecessarily
enlarging the ROM size. Since this is a simple change, a patch
has been created in [2].

[1]
https://lists.zephyrproject.org/archives/list/devel(a)lists.zephyrproject.org/
message/MZB5PYBSRHV3NIEHJYXYQVLTPFIIHPB3/
[2] https://gerrit.zephyrproject.org/r/1261


----------
Daniel Leung


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 2
B [ZEP-184] (P 2) QMSI 'CONFIG_RTC_IRQ_PRI' undeclared.
B [ZEP-183] (P 3) [regression]PINMUX_NUM_PINS is missing in arch/x86/soc/quark_se/soc.h

UPDATED JIRA items within last 24 hours: 2
B [ZEP-75] (P 1) REOPENED Zephyr compiler fails with error about executing cc1
B [ZEP-7] (P 3) REOPENED Arduino 101 GPIO_INT_LEVEL not working as expected

CLOSED JIRA items within last 24 hours: 3
B [ZEP-174] (Fixed) Hello_world app build fail with error: 'PINMUX_BASE_ADDR' undeclared when PINMUX_DEV,PINMUX_DEV_QUARK_MCU were enabled
B [ZEP-161] (Won't Do) Nothing output when run hello_world app with x86 SDK for quark platforms
B [ZEP-151] (Fixed) QMSI AON_TIMER_IRQ and AON_TIMER_IRQ_PRI have not been configured in quark_se_devboard

RESOLVED JIRA items within last 24 hours: 0


Re: Daily Gerrit Digest

Perez Hernandez, Javier B <javier.b.perez.hernandez@...>
 

Dan,


On Wed, 2016-04-06 at 06:44 +0000, Kalowsky, Daniel wrote:
While I like getting these emails, any reason why I've received 3
different copies today, and at that they all seem to have different
data in them?
You should only see 1 everyday.
The scripts runs everyday at around 8am PST.

Regards

Javier B. Perez



-----Original Message-----
From: donotreply(a)jenkins.zephyrproject.org
[mailto:donotreply(a)jenkins.zephyrproject.org]
Sent: Tuesday, April 5, 2016 8:12 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Daily Gerrit Digest

NEW within last 24 hours:
 - https://gerrit.zephyrproject.org/r/1230  : test:
kernel/test_timer/nanokernel increase timeout.
 - https://gerrit.zephyrproject.org/r/1251  : sensor: make runtime
configurable attrs continuous
 - https://gerrit.zephyrproject.org/r/1250  : samples: revert to
default
CFLAGS
 - https://gerrit.zephyrproject.org/r/1247  : Bluetooth: Enable
Nordic BLE chip
with compatible firmware
 - https://gerrit.zephyrproject.org/r/1246  : quark_se_devboard:
Move UART
default name from soc to board
 - https://gerrit.zephyrproject.org/r/1248  : Bluetooth/shell: Add
configuration for Nordic BLE with HCI
 - https://gerrit.zephyrproject.org/r/1245  : Bluetooth: Add option
for Nordic
BLE with HCI firmware
 - https://gerrit.zephyrproject.org/r/1235  : hosttools-tarball.bb:
Integrate
Python 3 into SDK
 - https://gerrit.zephyrproject.org/r/1231  : test
 - https://gerrit.zephyrproject.org/r/1232  : kernel: Make idle
task sleep

UPDATED within last 24 hours:
 - https://gerrit.zephyrproject.org/r/1199  : drivers/nble: Add
support for attr
iteration functions
 - https://gerrit.zephyrproject.org/r/1201  : Bluetooth: tester:
Add support
for seqence gatt database
 - https://gerrit.zephyrproject.org/r/1202  : Bluetooth: tester:
Return pre
defined db offset on start server
 - https://gerrit.zephyrproject.org/r/1200  : Bluetooth: tester:
Update server
commands with sequence params
 - https://gerrit.zephyrproject.org/r/804   : ieee802154: Replace
the CC2520
driver with a new implementation
 - https://gerrit.zephyrproject.org/r/1226  : sys_clock: Add a
helper to
compute micro seconds
 - https://gerrit.zephyrproject.org/r/1190  : drivers: Renaming
directory
"802.15.4" into "ieee802154"
 - https://gerrit.zephyrproject.org/r/1161  : doc: Add sensor
section in API
documentation
 - https://gerrit.zephyrproject.org/r/1228  : sensor: lsm9ds0-gyro:
fix
FULL_SCALE attribute
 - https://gerrit.zephyrproject.org/r/1162  : doc: Add sensor
section to kernel
primer
 - https://gerrit.zephyrproject.org/r/1217  : stm32: reorganise soc
directory
and use family/series
 - https://gerrit.zephyrproject.org/r/1219  : soc: introduce SoC
families and
series
 - https://gerrit.zephyrproject.org/r/1215  : stm32: rename
SOC_STM32F1X -

SOC_SERIES_STM32F1X
 - https://gerrit.zephyrproject.org/r/1214  : stm32: rename
CONFIG_SOC_STM32 -> CONFIG_SOC_FAMILY_STM32
 - https://gerrit.zephyrproject.org/r/1227  : doc: Editing notices
page to be
more concise and relevant to Zephyr
 - https://gerrit.zephyrproject.org/r/1193  : tests:
test_early_sleep: Let's test
at all initialization level
 - https://gerrit.zephyrproject.org/r/1093  : doc: index config
variable only
once
 - https://gerrit.zephyrproject.org/r/992   : Bluetooth: BR/EDR:
Refactor
internals of 'Cancel' authentication API
 - https://gerrit.zephyrproject.org/r/1123  : Bluetooth: BR/EDR:
Rename pair
method field
 - https://gerrit.zephyrproject.org/r/1055  : Bluetooth: shell: Use
same config
for arm and x86 build
 - https://gerrit.zephyrproject.org/r/1205  : gcc-4.sc.iamcu.inc:
Enable LTO
 - https://gerrit.zephyrproject.org/r/1194  : samples: add
environmental
sensing sample for Arduino 101

MERGED within last 24 hours:
 - https://gerrit.zephyrproject.org/r/1234  : gerrit digest: rename
subject of
email for gerrit changes.
 - https://gerrit.zephyrproject.org/r/1233  : step: doc: use
website template
only on daily and tag build
 - https://gerrit.zephyrproject.org/r/1249  : drivers/nble: Move
Nordic
Bluetooth LE driver inside drivers/bluetooth
 - https://gerrit.zephyrproject.org/r/1244  : Bluetooth: Add stub
for
bt_storage_clear()
 - https://gerrit.zephyrproject.org/r/1240  : Bluetooth: Don't
update random
address unnecessarily
 - https://gerrit.zephyrproject.org/r/1238  : Bluetooth: Add
Privacy Feature
support
 - https://gerrit.zephyrproject.org/r/1242  : Bluetooth: Export
bt_storage
inside the stack
 - https://gerrit.zephyrproject.org/r/1239  : Bluetooth: Use
bt_addr_t inside
bt_addr_le_t
 - https://gerrit.zephyrproject.org/r/1243  : Bluetooth: Rename
bt_register_storage to bt_storage_register
 - https://gerrit.zephyrproject.org/r/1237  : Bluetooth: Introduce
SMP helper
to generate RPAs
 - https://gerrit.zephyrproject.org/r/1236  : Bluetooth: Export
is_bonded
through hci_core.c
 - https://gerrit.zephyrproject.org/r/1178  : ia32: Allow to
connect Nordic chip
to qemu
 - https://gerrit.zephyrproject.org/r/1224  : drivers/nble: Update
RPC to
Nordic firmware 0404 version
 - https://gerrit.zephyrproject.org/r/996   : quark_se_devboard:
Configure
UART0 for quark_se_devboard
 - https://gerrit.zephyrproject.org/r/1177  : drivers/nble:
Refactor Nordic BLE
chip enable functions
 - https://gerrit.zephyrproject.org/r/1225  : drivers/nble: Fix
typo in
compatible_firmware name
 - https://gerrit.zephyrproject.org/r/995   : quark_se_devboard:
Enable NBLE
for quark_se_devboard in Kconfig
 - https://gerrit.zephyrproject.org/r/1130  : drivers/nble:
Implement GATT
read Characteristic Presentation Format
 - https://gerrit.zephyrproject.org/r/1129  : samples/nble: Remove
default
driver debug for samples
 - https://gerrit.zephyrproject.org/r/1210  : Bluetooth: Add
support for
reading local address from storage
 - https://gerrit.zephyrproject.org/r/1209  : Bluetooth: Add
skeleton for
persistent storage API


state of development and participation

Idupsle <idupsle@...>
 

Hello,

I'm still wondering about this project. Is it right, that most work is
from intel? I was hoping, that NXP is continuing it's work on it - or
was it only for the early- support?
Otherwise I'd like start to develop a little more for my K64, but
looking at those amount of daily changes, especially at the core api -
is it wiser to wait a few months? I really would like to contribute a
litte bit in my sparse spare time to get this board a little bit more
usable :)

Idups


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1271 : sensors: Using new GPIO API callbacks
- https://gerrit.zephyrproject.org/r/1255 : relocate_sdk.patch: Fix file sections overwrites
- https://gerrit.zephyrproject.org/r/1272 : sensors: fix coding style regarding max line length
- https://gerrit.zephyrproject.org/r/1254 : ethernet/dw: remove kconfigs that are SoC specific
- https://gerrit.zephyrproject.org/r/1270 : Bluetooth: tester: Use bt enable cb to indicate cmd rsp success
- https://gerrit.zephyrproject.org/r/1261 : device_get_binding() returns NULL if driver_api is not set
- https://gerrit.zephyrproject.org/r/1260 : spi/intel: move driver_api assignment later
- https://gerrit.zephyrproject.org/r/1262 : serial/uart.h: no need to check driver_api being NULL
- https://gerrit.zephyrproject.org/r/1259 : uart/nsim: fixed missing driver_api assignment
- https://gerrit.zephyrproject.org/r/1258 : gpio/pcal_9535a: move driver_api assignment later
- https://gerrit.zephyrproject.org/r/1257 : 802.15.4/cc2520: move driver_api assignment later
- https://gerrit.zephyrproject.org/r/1256 : pwm/pca_9685: move driver_api assignment later

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1235 : hosttools-tarball.bb: Integrate Python 3 into SDK
- https://gerrit.zephyrproject.org/r/1226 : sys_clock: Add a helper to compute micro seconds
- https://gerrit.zephyrproject.org/r/1217 : stm32: reorganise soc directory and use family/series
- https://gerrit.zephyrproject.org/r/914 : gpio: Improve the public API to handle multi callbacks
- https://gerrit.zephyrproject.org/r/932 : drivers: Quark flash support
- https://gerrit.zephyrproject.org/r/1194 : samples: add environmental sensing sample for Arduino 101
- https://gerrit.zephyrproject.org/r/1251 : sensor: make runtime configurable attrs continuous
- https://gerrit.zephyrproject.org/r/1232 : kernel: Make idle task sleep
- https://gerrit.zephyrproject.org/r/1205 : gcc-4.sc.iamcu.inc: Enable LTO
- https://gerrit.zephyrproject.org/r/1135 : boards: nucleo: Adding flash support
- https://gerrit.zephyrproject.org/r/1029 : device: Remove DEV_* codes
- https://gerrit.zephyrproject.org/r/1193 : tests: test_early_sleep: Let's test at all initialization level
- https://gerrit.zephyrproject.org/r/1250 : samples: revert to default CFLAGS
- https://gerrit.zephyrproject.org/r/1219 : soc: introduce SoC families and series
- https://gerrit.zephyrproject.org/r/1221 : new SoC naming convention
- https://gerrit.zephyrproject.org/r/1230 : test: kernel/test_timer/nanokernel increase timeout.

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1265 : drivers/nble: Add support to bt_gatt_attr_next
- https://gerrit.zephyrproject.org/r/1268 : Bluetooth: drivers/nble: Require callback for bt_enable()
- https://gerrit.zephyrproject.org/r/1264 : drivers/nble: Refactor PM code to make it reusable
- https://gerrit.zephyrproject.org/r/1252 : job: new job to create daily JIRAs changes notification
- https://gerrit.zephyrproject.org/r/1247 : Bluetooth: Enable Nordic BLE chip using PM helpers
- https://gerrit.zephyrproject.org/r/1246 : quark_se_devboard: Remove UART default name from soc config
- https://gerrit.zephyrproject.org/r/1245 : Bluetooth: Add option for PM with Nordic BLE chip


Re: [RFC] Device: device_get_binding() returns NULL if device fails initialization

Kalowsky, Daniel <daniel.kalowsky@...>
 

-----Original Message-----
From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Wednesday, April 6, 2016 12:00 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC] Device: device_get_binding() returns NULL if
device fails initialization

Hi Daniel,

That's actually a good point.

And that reminds me, that most of our drivers do not set driver API to
NULL if they fail.
But they do return an explicit code which no one care about:
see _sys_device_do_config_level() in kernel/nanokernel/device.c

I think there you can add also a tiny test:

if (device->init(info) < 0) {
info->driver_api = NULL;
}
Good point Tomasz. Might need to be part of the RFC patch that Daniel posted.

(actually, naming in this function should be reversed: struct device
should be "device" and
struct device_config should be "info" or "config", even better. But I am
diverging from subject)

It's better to let device.c doing it, instead of making sure all driver
behaves well on that aspect.
As long as they return a relevant status, it will be fine.
Correct. If the OS is going to depend upon a feature/function being set to indicate a specific status, the OS should be doing this not the device driver. Although it doesn't hurt if the device driver does it as well :-)



Tomasz

Problem Statement:
Currently, there is no way to know if a driver fails initialization.

Problem Description:
Zephyr currently does not provide a way to check programmatically
whether a device can be used. The device_get_binding() always
returns a valid device struct (if such device driver instance
exists). This causes a bit of headache when debugging apps as
the developer assumes the devices are ready to be used.

Solution:
The solution was actually proposed in [1] a while ago. The idea
is to piggy-back onto driver_api pointer. If the pointer is NULL,
the device driver has failed in its own initialization function.
The driver_api is set to NULL (or in other words, never set to
the actual API struct). When device_get_binding() sess that
the driver_api is NULL for a particular device struct, it returns
NULL to the caller, and thus preventing its use in the app.
Since this is a binary state, instead of creating another variable
inside device struct, this uses driver_api to avoid unnecessarily
enlarging the ROM size. Since this is a simple change, a patch
has been created in [2].

[1]
https://lists.zephyrproject.org/archives/list/devel(a)lists.zephyrproject.org/
message/MZB5PYBSRHV3NIEHJYXYQVLTPFIIHPB3/
[2] https://gerrit.zephyrproject.org/r/1261


----------
Daniel Leung


when release spi driver for arduino_duo

david.dai@...
 

Hello,

I am planing to integrate cc2520 to arduino_duo board, but zephyr does not
provide spi driver for this board in current zephyr-1.1.0.
Could anybody tell me when zephyr offers it, Or who is work at it?
So that I can take part in the job and help to integrate and test.


Best Regards
David Dai(戴卫彬)
Position:上海
*********************************************************
This message contains information that may be confidential and/or privileged and is intended only for the individual or entity named in the body of email above. If this message has been received in error, your receipt of this message is not intended to waive any applicable privilege. No one else may disclose, copy, distribute or use the contents of this message. Unauthorized use, dissemination and duplication is strictly prohibited, and may be unlawful.


Re: [RFC] Device: device_get_binding() returns NULL if device fails initialization

Tomasz Bursztyka
 

Hi Daniel,

That's actually a good point.

And that reminds me, that most of our drivers do not set driver API to
NULL if they fail.
But they do return an explicit code which no one care about:
see _sys_device_do_config_level() in kernel/nanokernel/device.c

I think there you can add also a tiny test:

if (device->init(info) < 0) {
info->driver_api = NULL;
}

(actually, naming in this function should be reversed: struct device
should be "device" and
struct device_config should be "info" or "config", even better. But I am
diverging from subject)

It's better to let device.c doing it, instead of making sure all driver
behaves well on that aspect.
As long as they return a relevant status, it will be fine.

Tomasz

Problem Statement:
Currently, there is no way to know if a driver fails initialization.

Problem Description:
Zephyr currently does not provide a way to check programmatically
whether a device can be used. The device_get_binding() always
returns a valid device struct (if such device driver instance
exists). This causes a bit of headache when debugging apps as
the developer assumes the devices are ready to be used.

Solution:
The solution was actually proposed in [1] a while ago. The idea
is to piggy-back onto driver_api pointer. If the pointer is NULL,
the device driver has failed in its own initialization function.
The driver_api is set to NULL (or in other words, never set to
the actual API struct). When device_get_binding() sess that
the driver_api is NULL for a particular device struct, it returns
NULL to the caller, and thus preventing its use in the app.
Since this is a binary state, instead of creating another variable
inside device struct, this uses driver_api to avoid unnecessarily
enlarging the ROM size. Since this is a simple change, a patch
has been created in [2].

[1] https://lists.zephyrproject.org/archives/list/devel(a)lists.zephyrproject.org/message/MZB5PYBSRHV3NIEHJYXYQVLTPFIIHPB3/
[2] https://gerrit.zephyrproject.org/r/1261


----------
Daniel Leung


Re: Daily Gerrit Digest

Kalowsky, Daniel <daniel.kalowsky@...>
 

While I like getting these emails, any reason why I've received 3 different copies today, and at that they all seem to have different data in them?

-----Original Message-----
From: donotreply(a)jenkins.zephyrproject.org
[mailto:donotreply(a)jenkins.zephyrproject.org]
Sent: Tuesday, April 5, 2016 8:12 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Daily Gerrit Digest

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1230 : test:
kernel/test_timer/nanokernel increase timeout.
- https://gerrit.zephyrproject.org/r/1251 : sensor: make runtime
configurable attrs continuous
- https://gerrit.zephyrproject.org/r/1250 : samples: revert to default
CFLAGS
- https://gerrit.zephyrproject.org/r/1247 : Bluetooth: Enable Nordic BLE chip
with compatible firmware
- https://gerrit.zephyrproject.org/r/1246 : quark_se_devboard: Move UART
default name from soc to board
- https://gerrit.zephyrproject.org/r/1248 : Bluetooth/shell: Add
configuration for Nordic BLE with HCI
- https://gerrit.zephyrproject.org/r/1245 : Bluetooth: Add option for Nordic
BLE with HCI firmware
- https://gerrit.zephyrproject.org/r/1235 : hosttools-tarball.bb: Integrate
Python 3 into SDK
- https://gerrit.zephyrproject.org/r/1231 : test
- https://gerrit.zephyrproject.org/r/1232 : kernel: Make idle task sleep

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1199 : drivers/nble: Add support for attr
iteration functions
- https://gerrit.zephyrproject.org/r/1201 : Bluetooth: tester: Add support
for seqence gatt database
- https://gerrit.zephyrproject.org/r/1202 : Bluetooth: tester: Return pre
defined db offset on start server
- https://gerrit.zephyrproject.org/r/1200 : Bluetooth: tester: Update server
commands with sequence params
- https://gerrit.zephyrproject.org/r/804 : ieee802154: Replace the CC2520
driver with a new implementation
- https://gerrit.zephyrproject.org/r/1226 : sys_clock: Add a helper to
compute micro seconds
- https://gerrit.zephyrproject.org/r/1190 : drivers: Renaming directory
"802.15.4" into "ieee802154"
- https://gerrit.zephyrproject.org/r/1161 : doc: Add sensor section in API
documentation
- https://gerrit.zephyrproject.org/r/1228 : sensor: lsm9ds0-gyro: fix
FULL_SCALE attribute
- https://gerrit.zephyrproject.org/r/1162 : doc: Add sensor section to kernel
primer
- https://gerrit.zephyrproject.org/r/1217 : stm32: reorganise soc directory
and use family/series
- https://gerrit.zephyrproject.org/r/1219 : soc: introduce SoC families and
series
- https://gerrit.zephyrproject.org/r/1215 : stm32: rename SOC_STM32F1X -
SOC_SERIES_STM32F1X
- https://gerrit.zephyrproject.org/r/1214 : stm32: rename
CONFIG_SOC_STM32 -> CONFIG_SOC_FAMILY_STM32
- https://gerrit.zephyrproject.org/r/1227 : doc: Editing notices page to be
more concise and relevant to Zephyr
- https://gerrit.zephyrproject.org/r/1193 : tests: test_early_sleep: Let's test
at all initialization level
- https://gerrit.zephyrproject.org/r/1093 : doc: index config variable only
once
- https://gerrit.zephyrproject.org/r/992 : Bluetooth: BR/EDR: Refactor
internals of 'Cancel' authentication API
- https://gerrit.zephyrproject.org/r/1123 : Bluetooth: BR/EDR: Rename pair
method field
- https://gerrit.zephyrproject.org/r/1055 : Bluetooth: shell: Use same config
for arm and x86 build
- https://gerrit.zephyrproject.org/r/1205 : gcc-4.sc.iamcu.inc: Enable LTO
- https://gerrit.zephyrproject.org/r/1194 : samples: add environmental
sensing sample for Arduino 101

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1234 : gerrit digest: rename subject of
email for gerrit changes.
- https://gerrit.zephyrproject.org/r/1233 : step: doc: use website template
only on daily and tag build
- https://gerrit.zephyrproject.org/r/1249 : drivers/nble: Move Nordic
Bluetooth LE driver inside drivers/bluetooth
- https://gerrit.zephyrproject.org/r/1244 : Bluetooth: Add stub for
bt_storage_clear()
- https://gerrit.zephyrproject.org/r/1240 : Bluetooth: Don't update random
address unnecessarily
- https://gerrit.zephyrproject.org/r/1238 : Bluetooth: Add Privacy Feature
support
- https://gerrit.zephyrproject.org/r/1242 : Bluetooth: Export bt_storage
inside the stack
- https://gerrit.zephyrproject.org/r/1239 : Bluetooth: Use bt_addr_t inside
bt_addr_le_t
- https://gerrit.zephyrproject.org/r/1243 : Bluetooth: Rename
bt_register_storage to bt_storage_register
- https://gerrit.zephyrproject.org/r/1237 : Bluetooth: Introduce SMP helper
to generate RPAs
- https://gerrit.zephyrproject.org/r/1236 : Bluetooth: Export is_bonded
through hci_core.c
- https://gerrit.zephyrproject.org/r/1178 : ia32: Allow to connect Nordic chip
to qemu
- https://gerrit.zephyrproject.org/r/1224 : drivers/nble: Update RPC to
Nordic firmware 0404 version
- https://gerrit.zephyrproject.org/r/996 : quark_se_devboard: Configure
UART0 for quark_se_devboard
- https://gerrit.zephyrproject.org/r/1177 : drivers/nble: Refactor Nordic BLE
chip enable functions
- https://gerrit.zephyrproject.org/r/1225 : drivers/nble: Fix typo in
compatible_firmware name
- https://gerrit.zephyrproject.org/r/995 : quark_se_devboard: Enable NBLE
for quark_se_devboard in Kconfig
- https://gerrit.zephyrproject.org/r/1130 : drivers/nble: Implement GATT
read Characteristic Presentation Format
- https://gerrit.zephyrproject.org/r/1129 : samples/nble: Remove default
driver debug for samples
- https://gerrit.zephyrproject.org/r/1210 : Bluetooth: Add support for
reading local address from storage
- https://gerrit.zephyrproject.org/r/1209 : Bluetooth: Add skeleton for
persistent storage API


[RFC] Device: device_get_binding() returns NULL if device fails initialization

Daniel Leung <daniel.leung@...>
 

Problem Statement:
Currently, there is no way to know if a driver fails initialization.

Problem Description:
Zephyr currently does not provide a way to check programmatically
whether a device can be used. The device_get_binding() always
returns a valid device struct (if such device driver instance
exists). This causes a bit of headache when debugging apps as
the developer assumes the devices are ready to be used.

Solution:
The solution was actually proposed in [1] a while ago. The idea
is to piggy-back onto driver_api pointer. If the pointer is NULL,
the device driver has failed in its own initialization function.
The driver_api is set to NULL (or in other words, never set to
the actual API struct). When device_get_binding() sess that
the driver_api is NULL for a particular device struct, it returns
NULL to the caller, and thus preventing its use in the app.
Since this is a binary state, instead of creating another variable
inside device struct, this uses driver_api to avoid unnecessarily
enlarging the ROM size. Since this is a simple change, a patch
has been created in [2].

[1] https://lists.zephyrproject.org/archives/list/devel(a)lists.zephyrproject.org/message/MZB5PYBSRHV3NIEHJYXYQVLTPFIIHPB3/
[2] https://gerrit.zephyrproject.org/r/1261


----------
Daniel Leung


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1230 : test: kernel/test_timer/nanokernel increase timeout.
- https://gerrit.zephyrproject.org/r/1251 : sensor: make runtime configurable attrs continuous
- https://gerrit.zephyrproject.org/r/1250 : samples: revert to default CFLAGS
- https://gerrit.zephyrproject.org/r/1247 : Bluetooth: Enable Nordic BLE chip with compatible firmware
- https://gerrit.zephyrproject.org/r/1246 : quark_se_devboard: Move UART default name from soc to board
- https://gerrit.zephyrproject.org/r/1248 : Bluetooth/shell: Add configuration for Nordic BLE with HCI
- https://gerrit.zephyrproject.org/r/1245 : Bluetooth: Add option for Nordic BLE with HCI firmware
- https://gerrit.zephyrproject.org/r/1235 : hosttools-tarball.bb: Integrate Python 3 into SDK
- https://gerrit.zephyrproject.org/r/1231 : test
- https://gerrit.zephyrproject.org/r/1232 : kernel: Make idle task sleep

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1199 : drivers/nble: Add support for attr iteration functions
- https://gerrit.zephyrproject.org/r/1201 : Bluetooth: tester: Add support for seqence gatt database
- https://gerrit.zephyrproject.org/r/1202 : Bluetooth: tester: Return pre defined db offset on start server
- https://gerrit.zephyrproject.org/r/1200 : Bluetooth: tester: Update server commands with sequence params
- https://gerrit.zephyrproject.org/r/804 : ieee802154: Replace the CC2520 driver with a new implementation
- https://gerrit.zephyrproject.org/r/1226 : sys_clock: Add a helper to compute micro seconds
- https://gerrit.zephyrproject.org/r/1190 : drivers: Renaming directory "802.15.4" into "ieee802154"
- https://gerrit.zephyrproject.org/r/1161 : doc: Add sensor section in API documentation
- https://gerrit.zephyrproject.org/r/1228 : sensor: lsm9ds0-gyro: fix FULL_SCALE attribute
- https://gerrit.zephyrproject.org/r/1162 : doc: Add sensor section to kernel primer
- https://gerrit.zephyrproject.org/r/1217 : stm32: reorganise soc directory and use family/series
- https://gerrit.zephyrproject.org/r/1219 : soc: introduce SoC families and series
- https://gerrit.zephyrproject.org/r/1215 : stm32: rename SOC_STM32F1X -> SOC_SERIES_STM32F1X
- https://gerrit.zephyrproject.org/r/1214 : stm32: rename CONFIG_SOC_STM32 -> CONFIG_SOC_FAMILY_STM32
- https://gerrit.zephyrproject.org/r/1227 : doc: Editing notices page to be more concise and relevant to Zephyr
- https://gerrit.zephyrproject.org/r/1193 : tests: test_early_sleep: Let's test at all initialization level
- https://gerrit.zephyrproject.org/r/1093 : doc: index config variable only once
- https://gerrit.zephyrproject.org/r/992 : Bluetooth: BR/EDR: Refactor internals of 'Cancel' authentication API
- https://gerrit.zephyrproject.org/r/1123 : Bluetooth: BR/EDR: Rename pair method field
- https://gerrit.zephyrproject.org/r/1055 : Bluetooth: shell: Use same config for arm and x86 build
- https://gerrit.zephyrproject.org/r/1205 : gcc-4.sc.iamcu.inc: Enable LTO
- https://gerrit.zephyrproject.org/r/1194 : samples: add environmental sensing sample for Arduino 101

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1234 : gerrit digest: rename subject of email for gerrit changes.
- https://gerrit.zephyrproject.org/r/1233 : step: doc: use website template only on daily and tag build
- https://gerrit.zephyrproject.org/r/1249 : drivers/nble: Move Nordic Bluetooth LE driver inside drivers/bluetooth
- https://gerrit.zephyrproject.org/r/1244 : Bluetooth: Add stub for bt_storage_clear()
- https://gerrit.zephyrproject.org/r/1240 : Bluetooth: Don't update random address unnecessarily
- https://gerrit.zephyrproject.org/r/1238 : Bluetooth: Add Privacy Feature support
- https://gerrit.zephyrproject.org/r/1242 : Bluetooth: Export bt_storage inside the stack
- https://gerrit.zephyrproject.org/r/1239 : Bluetooth: Use bt_addr_t inside bt_addr_le_t
- https://gerrit.zephyrproject.org/r/1243 : Bluetooth: Rename bt_register_storage to bt_storage_register
- https://gerrit.zephyrproject.org/r/1237 : Bluetooth: Introduce SMP helper to generate RPAs
- https://gerrit.zephyrproject.org/r/1236 : Bluetooth: Export is_bonded through hci_core.c
- https://gerrit.zephyrproject.org/r/1178 : ia32: Allow to connect Nordic chip to qemu
- https://gerrit.zephyrproject.org/r/1224 : drivers/nble: Update RPC to Nordic firmware 0404 version
- https://gerrit.zephyrproject.org/r/996 : quark_se_devboard: Configure UART0 for quark_se_devboard
- https://gerrit.zephyrproject.org/r/1177 : drivers/nble: Refactor Nordic BLE chip enable functions
- https://gerrit.zephyrproject.org/r/1225 : drivers/nble: Fix typo in compatible_firmware name
- https://gerrit.zephyrproject.org/r/995 : quark_se_devboard: Enable NBLE for quark_se_devboard in Kconfig
- https://gerrit.zephyrproject.org/r/1130 : drivers/nble: Implement GATT read Characteristic Presentation Format
- https://gerrit.zephyrproject.org/r/1129 : samples/nble: Remove default driver debug for samples
- https://gerrit.zephyrproject.org/r/1210 : Bluetooth: Add support for reading local address from storage
- https://gerrit.zephyrproject.org/r/1209 : Bluetooth: Add skeleton for persistent storage API


Gerrit changes

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1227 : doc: Editing notices page to be more concise and relevant to Zephyr
- https://gerrit.zephyrproject.org/r/1228 : sensor: lsm9ds0-gyro: fix FULL_SCALE attribute
- https://gerrit.zephyrproject.org/r/1226 : sys_clock: Add a helper to compute micro seconds
- https://gerrit.zephyrproject.org/r/1225 : drivers/nble: Fix typo in compatible_firmware name
- https://gerrit.zephyrproject.org/r/1224 : drivers/nble: Update RPC to Nordic firmware 0404 version

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1216 : kinetis: reorganise soc directory using soc family
- https://gerrit.zephyrproject.org/r/1194 : samples: add environmental sensing sample for Arduino 101
- https://gerrit.zephyrproject.org/r/1162 : doc: Add sensor section to kernel primer
- https://gerrit.zephyrproject.org/r/1217 : stm32: reorganise soc directory and use family/series
- https://gerrit.zephyrproject.org/r/1190 : drivers: Renaming directory "802.15.4" into "ieee802154"
- https://gerrit.zephyrproject.org/r/804 : ieee802154: Replace the CC2520 driver with a new implementation
- https://gerrit.zephyrproject.org/r/1202 : Bluetooth: tester: Return pre defined db offset on start server
- https://gerrit.zephyrproject.org/r/1200 : Bluetooth: tester: Update server commands with sequence params
- https://gerrit.zephyrproject.org/r/1199 : drivers/nble: Add support for attr iteration functions
- https://gerrit.zephyrproject.org/r/1201 : Bluetooth: tester: Add support for seqence gatt database
- https://gerrit.zephyrproject.org/r/996 : quark_se_devboard: Configure UART0 for quark_se_devboard
- https://gerrit.zephyrproject.org/r/995 : quark_se_devboard: Enable NBLE for quark_se_devboard in Kconfig
- https://gerrit.zephyrproject.org/r/1178 : ia32: Allow to connect Nordic chip to qemu
- https://gerrit.zephyrproject.org/r/1177 : drivers/nble: Refactor Nordic BLE chip enable functions
- https://gerrit.zephyrproject.org/r/1215 : stm32: rename SOC_STM32F1X -> SOC_SERIES_STM32F1X
- https://gerrit.zephyrproject.org/r/1214 : stm32: rename CONFIG_SOC_STM32 -> CONFIG_SOC_FAMILY_STM32
- https://gerrit.zephyrproject.org/r/1221 : new SoC naming convention
- https://gerrit.zephyrproject.org/r/1219 : soc: introduce SoC families and series
- https://gerrit.zephyrproject.org/r/932 : drivers: Quark flash support

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1229 : include: sanitycheck: increase default re-try to 3
- https://gerrit.zephyrproject.org/r/1130 : drivers/nble: Implement GATT read Characteristic Presentation Format
- https://gerrit.zephyrproject.org/r/1129 : samples/nble: Remove default driver debug for samples
- https://gerrit.zephyrproject.org/r/1210 : Bluetooth: Add support for reading local address from storage
- https://gerrit.zephyrproject.org/r/1209 : Bluetooth: Add skeleton for persistent storage API
- https://gerrit.zephyrproject.org/r/1208 : Bluetooth: Rework local address tracking

7601 - 7620 of 8046