Date   

Re: Build fails when the sdk is not installed in the default path in Archlinux.

Yannis Damigos
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/22/2016 07:26 PM, Dirk Brandewie wrote:


On 02/22/2016 08:42 AM, Yannis Damigos wrote:
On 02/22/2016 05:10 PM, Dirk Brandewie wrote:


On 02/20/2016 07:50 AM, Yannis Damigos wrote:
Dear all,

Building the philosophers sample fails when the sdk is not installed under the default path (/opt/zephyr-sdk) in Archlinux with the following error:
make[1]: Entering directory '/home/xekarfwtos/projects/zephyr'
make[2]: Entering directory '/home/xekarfwtos/projects/philosophers/outdir'
Using /home/xekarfwtos/projects/zephyr as source for kernel
GEN ./Makefile
CHK include/generated/version.h
HOSTCC scripts/basic/fixdep
HOSTCC scripts/gen_idt/version.o
HOSTCC scripts/gen_idt/gen_idt.o
HOSTLD scripts/gen_idt/gen_idt
HOSTCC scripts/gen_offset_header/gen_offset_header.o
HOSTLD scripts/gen_offset_header/gen_offset_header
CHK misc/generated/configs.c
UPD misc/generated/configs.c
i586-poky-elf-gcc: error trying to exec 'cc1': execvp: No such file or directory
/home/xekarfwtos/projects/zephyr/./Kbuild:98: recipe for target 'arch/x86/core/offsets/offsets.o' failed
make[3]: *** [arch/x86/core/offsets/offsets.o] Error 1
/home/xekarfwtos/projects/zephyr/Makefile:892: recipe for target 'prepare' failed
make[2]: *** [prepare] Error 2
make[2]: Leaving directory '/home/xekarfwtos/projects/philosophers/outdir'
Makefile:169: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '/home/xekarfwtos/projects/zephyr'
/home/xekarfwtos/projects/zephyr/Makefile.inc:61: recipe for target 'all' failed
make: *** [all] Error 2
Is ZEPHYR_SDK_INSTALL_DIR pointing to the SDK install directory?

When the sdk is installed under the default path compiling succeeded.

Best regards,
Yannis
Yes, ZEPHYR_SDK_INSTALL_DIR is pointing to the correct SDK install directory.
Hmmm :-/ Can you send the output of the make command adding V=1 to the
command line?
Here it is https://gist.github.com/xekarfwtos/78d9c85f018ed2a0ce4b


Re: Build fails when the sdk is not installed in the default path in Archlinux.

Dirk Brandewie <dirk.j.brandewie@...>
 

On 02/22/2016 08:42 AM, Yannis Damigos wrote:
On 02/22/2016 05:10 PM, Dirk Brandewie wrote:


On 02/20/2016 07:50 AM, Yannis Damigos wrote:
Dear all,

Building the philosophers sample fails when the sdk is not installed under the default path (/opt/zephyr-sdk) in Archlinux with the following error:
make[1]: Entering directory '/home/xekarfwtos/projects/zephyr'
make[2]: Entering directory '/home/xekarfwtos/projects/philosophers/outdir'
Using /home/xekarfwtos/projects/zephyr as source for kernel
GEN ./Makefile
CHK include/generated/version.h
HOSTCC scripts/basic/fixdep
HOSTCC scripts/gen_idt/version.o
HOSTCC scripts/gen_idt/gen_idt.o
HOSTLD scripts/gen_idt/gen_idt
HOSTCC scripts/gen_offset_header/gen_offset_header.o
HOSTLD scripts/gen_offset_header/gen_offset_header
CHK misc/generated/configs.c
UPD misc/generated/configs.c
i586-poky-elf-gcc: error trying to exec 'cc1': execvp: No such file or directory
/home/xekarfwtos/projects/zephyr/./Kbuild:98: recipe for target 'arch/x86/core/offsets/offsets.o' failed
make[3]: *** [arch/x86/core/offsets/offsets.o] Error 1
/home/xekarfwtos/projects/zephyr/Makefile:892: recipe for target 'prepare' failed
make[2]: *** [prepare] Error 2
make[2]: Leaving directory '/home/xekarfwtos/projects/philosophers/outdir'
Makefile:169: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '/home/xekarfwtos/projects/zephyr'
/home/xekarfwtos/projects/zephyr/Makefile.inc:61: recipe for target 'all' failed
make: *** [all] Error 2
Is ZEPHYR_SDK_INSTALL_DIR pointing to the SDK install directory?

When the sdk is installed under the default path compiling succeeded.

Best regards,
Yannis
Yes, ZEPHYR_SDK_INSTALL_DIR is pointing to the correct SDK install directory.
Hmmm :-/ Can you send the output of the make command adding V=1 to the
command line?


Re: Build fails when the sdk is not installed in the default path in Archlinux.

Yannis Damigos
 

On 02/22/2016 05:10 PM, Dirk Brandewie wrote:


On 02/20/2016 07:50 AM, Yannis Damigos wrote:
Dear all,

Building the philosophers sample fails when the sdk is not installed under the default path (/opt/zephyr-sdk) in Archlinux with the following error:
make[1]: Entering directory '/home/xekarfwtos/projects/zephyr'
make[2]: Entering directory '/home/xekarfwtos/projects/philosophers/outdir'
Using /home/xekarfwtos/projects/zephyr as source for kernel
GEN ./Makefile
CHK include/generated/version.h
HOSTCC scripts/basic/fixdep
HOSTCC scripts/gen_idt/version.o
HOSTCC scripts/gen_idt/gen_idt.o
HOSTLD scripts/gen_idt/gen_idt
HOSTCC scripts/gen_offset_header/gen_offset_header.o
HOSTLD scripts/gen_offset_header/gen_offset_header
CHK misc/generated/configs.c
UPD misc/generated/configs.c
i586-poky-elf-gcc: error trying to exec 'cc1': execvp: No such file or directory
/home/xekarfwtos/projects/zephyr/./Kbuild:98: recipe for target 'arch/x86/core/offsets/offsets.o' failed
make[3]: *** [arch/x86/core/offsets/offsets.o] Error 1
/home/xekarfwtos/projects/zephyr/Makefile:892: recipe for target 'prepare' failed
make[2]: *** [prepare] Error 2
make[2]: Leaving directory '/home/xekarfwtos/projects/philosophers/outdir'
Makefile:169: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '/home/xekarfwtos/projects/zephyr'
/home/xekarfwtos/projects/zephyr/Makefile.inc:61: recipe for target 'all' failed
make: *** [all] Error 2
Is ZEPHYR_SDK_INSTALL_DIR pointing to the SDK install directory?

When the sdk is installed under the default path compiling succeeded.

Best regards,
Yannis
Yes, ZEPHYR_SDK_INSTALL_DIR is pointing to the correct SDK install directory.


Re: RFC: return type of functions passed to DEVICE_INIT()

Dirk Brandewie <dirk.j.brandewie@...>
 

On 02/19/2016 05:20 PM, Thomas, Ramesh wrote:
I was considering the possible use case of PM app calling
_sys_device_do_config_level(). In that case a return value of 0 or 1
would help it know some thing went wrong instead of having to query all
devices to find out. But I think this does not impact the main topic of
your RFC and can be addressed separately if necessary.
_sys_device_do_config_level() is *not* a public API and is *not*
guaranteed be stable or even exist from release to release.

AFAIK calling _sys_device_do_config_level() again would not break any of
our current drivers but is the driver is is creating some state in
init() (e.g. security context, network connection) all hell is likely
to break loose. The driver could maintain whether init() has been
called to work around this but at the cost of RAM.

What is the use case? What functionality do you need?

--Dirk


Re: RFC: return type of functions passed to DEVICE_INIT()

Dirk Brandewie <dirk.j.brandewie@...>
 

On 02/19/2016 05:31 PM, Thomas, Ramesh wrote:
On Fri, 2016-02-19 at 10:05 -0800, Daniel Leung wrote:
On Fri, Feb 19, 2016 at 08:31:48AM -0800, Dirk Brandewie wrote:


On 02/18/2016 03:04 PM, Daniel Leung wrote:
On Thu, Feb 18, 2016 at 05:54:56PM -0500, Benjamin Walsh wrote:
My take on it is that for Zephyr a failed device initialization
should be considered a fatal event. My expectation is that the
Zephyr user will only be enabling relevant (and important) devices to
their project. If one of these devices should fail, then that is a
serious system error and _NanoFatalErrorHandler() should be invoked.

If this train of thought holds up to scrutiny, and if the aim is to
save a few bytes then I would think that it would be better to have
the device initialization routines return a failure code and have
_sys_device_do_config_level() check for it and invoke the fatal error
handler upon the detection of failure. Otherwise we duplicate the
overhead of calling the fatal error handler in each device
initialization routine.
Sorry for the slow response. I agree with Peter here I think we should
be checking the return value and doing something useful with the
result. Maybe not _NanoFatalErrorHandler() but something notifying
the application that something bad happened. A given device not
initializing may not be fatal to the the whole application, just one
feature is currently unavailable.
For the kind of systems we are targeting, do we really expect the
application to handle devices not initializing correctly, being designed
so that parts are disabled if some parts of the initialization fail
(devices or others), or do we expect applications to require everything
to be present for them to function correctly ? I would have thought the
latter, but I can be convinced.
Delving into the realm of the hypothetical :-)

What about devices that have drivers in the system but are not present
(pluggable) or can't initialize because some resource external to the
device can't be contacted (network server).

The application may be able to still do useful work albeit with reduced
functionality.

Then, if the latter, do we expect the application catching the errors at
runtime when deployed or during development (basically catching software
errors mostly) not malfunctionning hardware. Here, I was thinking the
latter as well, which is why I was proposing __ASSERT() calls catching
initialization errors in debug loads only. And this fits with one of the
core values of the OS, which is small footprint.
Both models are useful for different reasons :-D

Any of those could be a valid approach I think, but we have to decide on
one. And right now, we have the worst since we return those error codes
which are meant for runtime handling, but they just go into the void.
Agreed we need to pick and stay with it for some amount of time until
we see a few real uses/applications/platforms.
OK, following your proposal below, what we could put in place is
standardizing on error codes that init routines must return if they want
the kernel init system to automatically trigger a fatal error.

Then, we could also allow configuring out the error handling if someone
needs to squeeze that last amount of space. One more Kconfig option! :)
The error handling would be enabled by default of course.
For those non-fatal errors, what should we do for runtime driver behaviors?
Should the drivers themselves fail API calls? Or should we let
device_get_binding() return NULL?
How about something like this:

diff --git a/kernel/nanokernel/device.c b/kernel/nanokernel/device.c
index f86f95f..82774c4 100644
--- a/kernel/nanokernel/device.c
+++ b/kernel/nanokernel/device.c
@@ -58,7 +58,7 @@ struct device *device_get_binding(char *name)
struct device *info;

for (info = __device_init_start; info != __device_init_end; info++) {
- if (!strcmp(name, info->config->name)) {
+ if (!strcmp(name, info->config->name) && info->driver_api) {
return info;
}
}

if there is a non-fatal error the driver will not mark itself available
and we can get rid of the null checks in the API headers since the user of the
driver will never get a reference to it if init() did not complete successfully
Why not create a dedicated status field in device object?
It would take more RAM :-) Not sure exactly what you would want to
return in the status? If device init() fails there is nothing the
application code can do about it other that fail gracefully.

Additionally we can provide an API to query status of devices. This
will help query status of devices it does not bind to.
If you are not binding to a device why do you need the status? If
there is a good use case propose the API with the patch ;-)


This should work. We need to rework some of the drivers as they make
the driver_api assignment unconditionally.


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


Re: How to setup git-review

Andrew Grimberg <agrimberg@...>
 

On 02/19/2016 08:37 AM, Andre Guedes wrote:
Hi Anas,

Quoting Nashif, Anas (2016-02-19 14:07:36)
Thanks for documenting this but I don't think forcing people to use git-review is the right approach.
Yes, I agree.
Forcing people to use git-review is not the intent. Using git-review
eases the cognitive burden of working inside the enforced gerrit worfklow.

Tell me, which would you find easier to do / remember?

--[cut with git review]--
git checkout master && git pull && git checkout -b my_topic
# make changes
git commit -asm 'gee whiz feature' && git review
--[/cut with git review]--

vs

--[cut without git review]--
git checkout master && git pull && git checkout -b my_topic
# make changes
git commit -asm 'gee whiz feature' && git rebase master && git push
origin HEAD:refs/for/master/my_topic
--[/cut without git review]--

Or for pulling a remote submission for local review

--[cut with git review]--
git checkout master && git pull && git review -d $submission_number
--[/cut with git review]--

NOTES:
* not supplying a patch number gets the latest if multiple, to specify
an earlier version of a submission use $submission_number,$patch_number

* submission number gets checked out locally to
branch review/<user>/topic_name (or revision number if no topic)

vs

--[cut without git review]--
git checkout master && git pull
git fetch origin refs/changes/$change_id_mod_100/$change_id/$patch_number
git checkout -b local_review_of_$change_id FETCH_HEAD
--[/cut without git review]--

It worked for us before in many other projects, why is this
different and why can't I use vanilla git to gerrit interaction?

What is the issue here exactly?
I'm not a gerrit expert but from I could understand, this is related to the
'forge author' settings from submitter rights. I'm CCing Andrew so he might
add more details about it.
After all the issues folks have been having because of forge author I've
relaxed the restriction some. Registered users may 'Forge Author' now,
but this is honestly non-optimal. People should not be repushing changes
that they did not author. The only time that's really a proper option is
when a committer forces a rebase of a patch via the gerrit UI.

Which brings us to git-review, when using it it will detect if you're
trying to push an entire patch set and ask if you really want to do
that, it should also allow you to indicate that you only want to push
certain patches out of the set (though it's a feature I myself never use
as I usually only work a single patch at a time of a series on a
particular topic)

For those that are trying to figure out what these 'forge author' or
'forge committer' rights that we keep talking about in gerrit are, it
breaks down as follows:

A git commit has an author and a committer. Both pieces are stored in
the metadata and in the case of the author, also partly in the commit
message.

The committer is the one who actually pushes the submission to git. The
author is the one that the commit is attributed to. Gerrit takes this
one step further with the requirement of Signed-off-by lines. If the
Signed-off-by line does not match the author it gets rejected.

Enabling 'forge author' allows someone to submit code where the
signed-off-by line does not match the authorship of the code and
additionally, where the one committing the code does not match the
authorship.

'forge committer' (which was only available to committers during the
initial repository load in) allows anyone with the right to push code
that they did not actually commit to the repo. This is useful primarily
in history imports, but occasionally useful for automated processes
(jenkins) that do automatic version bumping, tagging and branching.

-Andy-

--
Andrew J Grimberg
Systems Administrator
The Linux Foundation


Re: Build fails when the sdk is not installed in the default path in Archlinux.

Dirk Brandewie <dirk.j.brandewie@...>
 

On 02/20/2016 07:50 AM, Yannis Damigos wrote:
Dear all,

Building the philosophers sample fails when the sdk is not installed under the default path (/opt/zephyr-sdk) in Archlinux with the following error:
make[1]: Entering directory '/home/xekarfwtos/projects/zephyr'
make[2]: Entering directory '/home/xekarfwtos/projects/philosophers/outdir'
Using /home/xekarfwtos/projects/zephyr as source for kernel
GEN ./Makefile
CHK include/generated/version.h
HOSTCC scripts/basic/fixdep
HOSTCC scripts/gen_idt/version.o
HOSTCC scripts/gen_idt/gen_idt.o
HOSTLD scripts/gen_idt/gen_idt
HOSTCC scripts/gen_offset_header/gen_offset_header.o
HOSTLD scripts/gen_offset_header/gen_offset_header
CHK misc/generated/configs.c
UPD misc/generated/configs.c
i586-poky-elf-gcc: error trying to exec 'cc1': execvp: No such file or directory
/home/xekarfwtos/projects/zephyr/./Kbuild:98: recipe for target 'arch/x86/core/offsets/offsets.o' failed
make[3]: *** [arch/x86/core/offsets/offsets.o] Error 1
/home/xekarfwtos/projects/zephyr/Makefile:892: recipe for target 'prepare' failed
make[2]: *** [prepare] Error 2
make[2]: Leaving directory '/home/xekarfwtos/projects/philosophers/outdir'
Makefile:169: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '/home/xekarfwtos/projects/zephyr'
/home/xekarfwtos/projects/zephyr/Makefile.inc:61: recipe for target 'all' failed
make: *** [all] Error 2
Is ZEPHYR_SDK_INSTALL_DIR pointing to the SDK install directory?

When the sdk is installed under the default path compiling succeeded.

Best regards,
Yannis


Re: Source the project environment file from zsh

Yannis Damigos
 

Hi,

I filed the bug in jira.
https://jira.zephyrproject.org/browse/ZEP-64

Yannis


Re: RFC: make _fiber_start() return a handle on the fiber

Jukka Rissanen
 

Hi Ben,

On Fri, 2016-02-19 at 10:36 -0500, Benjamin Walsh wrote:
When we start a fiber via the _fiber_start() API family, we don't
get back a handle on the created fiber. The fiber identifier is
actually the start of the fiber's stack. This hasn't been a
problem
until now since no API requires a handle on the fiber, except
one,
fiber_delayed_start_cancel(): that API is part of a pair, where
the
other API, fiber_delayed_start() starts the fiber and returns a
handle.

However, Jukka asked me an API could be created that cancels a
fiber_sleep() call, something like fiber_wakeup(). The
implementation of such an API is very simple, but it requires a
handle on the fiber we want to wake up. This in turn requires the
signature of the _fiber_start() family to return a handle to the
fiber that gets started.

The signature of _fiber_start() et al. would then change from a
void
return type to a void * return type.

Objections, comments, etc ?
No comments -> no objects -> perhaps we can continue with this
route
then?
Looks like it. You want to do the implementation yourself Jukka ?
I am a bit busy right now so I am fine if you do it.


Cheers,
Jukka


Re: Non-binary SDK?

Oliver Hahm <oliver.hahm@...>
 

Hi Anas!

Thanks for the fast response!

On Sat, Feb 20, 2016 at 01:47:19PM +0000, Nashif, Anas wrote:
Looking into this file I realized that it contains a big block of binary data.
I'm feeling somehow uncomfortable with just executing a binary from an unknown
source (particular with sudo). Is there another way to install this SDK with
non binary data (I'm willing if build it myself) or to tell me what this SDK
apart from cross-compiler-toolchains contains?
We do have instructions on how to build the SDK yourself, I can’t find the
pointer right now, but will add this to the documentation for easy access.
The SDK itself is built using Yocto.
Thanks for the explanation and looking forward for the pointer.

The Zephyr SDK is provided to help you getting started with all supported
platforms, however, you should be able to use other cross-compilers
installed on your system if you wish.
That's what I somehow assumed. Would be good to know, which variables have to
be set to use the existing toolchains. Or maybe you good even provide
something like a Makefile.toolchain.gcc, so that I can compile withe usual gcc
toolchains for ARM and x86.

What additional tools apart from a cross-compiler toolchain are required
anyway (and why) for your OS?
The SDK contains cross-compiler toolchains for all supported architectures
and host tools. Additionally it contains hosts tools like python, gcc, make,
openocd.
Okay, so this is more an optional prerequisite. Most embedded developers will
have these tools already installed, I guess.

Cheers,
Oleg

P.S. The path to the sample apps as described here
https://www.zephyrproject.org/doc/getting_started/building_zephyr.html also
seems to have changed. It's not "$ZEPHYR_BASE/samples/hello_world/microkernel"
any more, but "$ZEPHYR_BASE/samples/microkernel/apps/hello_world".


Re: Source the project environment file from zsh

Oliver Hahm <oliver.hahm@...>
 

Hi!

On Sat, Feb 20, 2016 at 02:00:18PM +0000, Nashif, Anas wrote:
Can you file a bug in https://jira.zephyrproject.org please? :-)
I would love to, but somehow the page is not loading (neither in firefox nor
in iron).

Cheers,
Oleg


Re: Source the project environment file from zsh

Oliver Hahm <oliver.hahm@...>
 

Hi!

On Sun, Feb 21, 2016 at 05:37:26PM -0000, Yannis Damigos wrote:
Hi all,

The above did not work for me. The following worked

diff --git a/zephyr-env.sh b/zephyr-env.sh
index dcb0638..21eca53 100644
--- a/zephyr-env.sh
+++ b/zephyr-env.sh
@@ -1,5 +1,5 @@

-if [ "X$(basename -- "$0")" == "Xzephyr-env.sh" ]; then
+if [ "X$(basename -z -- "$0")" = "Xzephyr-env.sh" ]; then
echo "Source this file (do NOT execute it!) to set the Zephyr Kernel environment."
exit
fi
Thanks, that seems to work for zsh and bash.

Cheers,
Oleg


Re: Source the project environment file from zsh

Yannis Damigos
 

Hi all,

The above did not work for me. The following worked

diff --git a/zephyr-env.sh b/zephyr-env.sh
index dcb0638..21eca53 100644
--- a/zephyr-env.sh
+++ b/zephyr-env.sh
@@ -1,5 +1,5 @@

-if [ "X$(basename -- "$0")" == "Xzephyr-env.sh" ]; then
+if [ "X$(basename -z -- "$0")" = "Xzephyr-env.sh" ]; then
echo "Source this file (do NOT execute it!) to set the Zephyr Kernel environment."
exit
fi

Yannis


Build fails when the sdk is not installed in the default path in Archlinux.

Yannis Damigos
 

Dear all,

Building the philosophers sample fails when the sdk is not installed under the default path (/opt/zephyr-sdk) in Archlinux with the following error:
make[1]: Entering directory '/home/xekarfwtos/projects/zephyr'
make[2]: Entering directory '/home/xekarfwtos/projects/philosophers/outdir'
Using /home/xekarfwtos/projects/zephyr as source for kernel
GEN ./Makefile
CHK include/generated/version.h
HOSTCC scripts/basic/fixdep
HOSTCC scripts/gen_idt/version.o
HOSTCC scripts/gen_idt/gen_idt.o
HOSTLD scripts/gen_idt/gen_idt
HOSTCC scripts/gen_offset_header/gen_offset_header.o
HOSTLD scripts/gen_offset_header/gen_offset_header
CHK misc/generated/configs.c
UPD misc/generated/configs.c
i586-poky-elf-gcc: error trying to exec 'cc1': execvp: No such file or directory
/home/xekarfwtos/projects/zephyr/./Kbuild:98: recipe for target 'arch/x86/core/offsets/offsets.o' failed
make[3]: *** [arch/x86/core/offsets/offsets.o] Error 1
/home/xekarfwtos/projects/zephyr/Makefile:892: recipe for target 'prepare' failed
make[2]: *** [prepare] Error 2
make[2]: Leaving directory '/home/xekarfwtos/projects/philosophers/outdir'
Makefile:169: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '/home/xekarfwtos/projects/zephyr'
/home/xekarfwtos/projects/zephyr/Makefile.inc:61: recipe for target 'all' failed
make: *** [all] Error 2

When the sdk is installed under the default path compiling succeeded.

Best regards,
Yannis


Re: Source the project environment file from zsh

Nashif, Anas
 

Hi Oleg,




On 20/02/2016, 08:24, "Oleg Hahm" <oliver.hahm(a)inria.fr> wrote:

Dear Zephyr development team,

following the instructions in your Getting Started Guide [1], I tried to run
source zephyr-env.sh
in my zsh 5.2, but get:
zephyr-env.sh:2: = not found

With my limited knowledge about shell the syntax of this script seems indeed
not to be POSIX shell compatible, but rather resemble bash syntax.
I think this can be fixed with:

diff --git a/zephyr-env.sh b/zephyr-env.sh
index dcb0638..d17780a 100644
--- a/zephyr-env.sh
+++ b/zephyr-env.sh
@@ -1,5 +1,5 @@

-if [ "X$(basename -- "$0")" == "Xzephyr-env.sh" ]; then
+if [ "X$(basename -- "$0")" = "Xzephyr-env.sh" ]; then
echo "Source this file (do NOT execute it!) to set the Zephyr Kernel environment."
exit
fi



Can you file a bug in https://jira.zephyrproject.org please? :-)


Anas



Cheers,
Oleg

P.S. Manually copying&pasting the last lines of the script seems to work
though.


[1] https://www.zephyrproject.org/doc/getting_started/installation_linux.html#environment-variables


Re: Non-binary SDK?

Nashif, Anas
 

Oleg,




On 20/02/2016, 08:35, "Oleg Hahm" <oliver.hahm(a)inria.fr> wrote:

Dear Zephy development team,

your Getting Started Guide [1] tells at some point to download a SDK, make it
executable, run it:
Run the installation binary, type:

$ chmod +x zephyr-sdk-0.7.2-i686-setup.run

$ sudo ./zephyr-sdk-0.7.2-i686-setup.run
you can also install without sudo in your home directory or any other location. The script will only extract the contents of the file.



Looking into this file I realized that it contains a big block of binary data.
I'm feeling somehow uncomfortable with just executing a binary from an unknown
source (particular with sudo). Is there another way to install this SDK with
non binary data (I'm willing if build it myself) or to tell me what this SDK
apart from cross-compiler-toolchains contains?
We do have instructions on how to build the SDK yourself, I can’t find the pointer right now, but will add this to the documentation for easy access. The SDK itself is built using Yocto.
The Zephyr SDK is provided to help you getting started with all supported platforms, however, you should be able to use other cross-compilers installed on your system if you wish.


What additional tools apart from a cross-compiler toolchain are required
anyway (and why) for your OS?
The SDK contains cross-compiler toolchains for all supported architectures and host tools. Additionally it contains hosts tools like python, gcc, make, openocd.



Anas


Thanks,
Oleg


[1] https://www.zephyrproject.org/doc/getting_started/installation_linux.html#installing-requirements-and-dependencies


Non-binary SDK?

Oliver Hahm <oliver.hahm@...>
 

Dear Zephy development team,

your Getting Started Guide [1] tells at some point to download a SDK, make it
executable, run it:
Run the installation binary, type:

$ chmod +x zephyr-sdk-0.7.2-i686-setup.run

$ sudo ./zephyr-sdk-0.7.2-i686-setup.run

Looking into this file I realized that it contains a big block of binary data.
I'm feeling somehow uncomfortable with just executing a binary from an unknown
source (particular with sudo). Is there another way to install this SDK with
non binary data (I'm willing if build it myself) or to tell me what this SDK
apart from cross-compiler-toolchains contains?

What additional tools apart from a cross-compiler toolchain are required
anyway (and why) for your OS?

Thanks,
Oleg


[1] https://www.zephyrproject.org/doc/getting_started/installation_linux.html#installing-requirements-and-dependencies


Source the project environment file from zsh

Oliver Hahm <oliver.hahm@...>
 

Dear Zephyr development team,

following the instructions in your Getting Started Guide [1], I tried to run
source zephyr-env.sh
in my zsh 5.2, but get:
zephyr-env.sh:2: = not found

With my limited knowledge about shell the syntax of this script seems indeed
not to be POSIX shell compatible, but rather resemble bash syntax.

Cheers,
Oleg

P.S. Manually copying&pasting the last lines of the script seems to work
though.


[1] https://www.zephyrproject.org/doc/getting_started/installation_linux.html#environment-variables


Re: RFC: return type of functions passed to DEVICE_INIT()

Thomas, Ramesh
 

On Fri, 2016-02-19 at 10:05 -0800, Daniel Leung wrote:
On Fri, Feb 19, 2016 at 08:31:48AM -0800, Dirk Brandewie wrote:


On 02/18/2016 03:04 PM, Daniel Leung wrote:
On Thu, Feb 18, 2016 at 05:54:56PM -0500, Benjamin Walsh wrote:
My take on it is that for Zephyr a failed device initialization
should be considered a fatal event. My expectation is that the
Zephyr user will only be enabling relevant (and important) devices to
their project. If one of these devices should fail, then that is a
serious system error and _NanoFatalErrorHandler() should be invoked.

If this train of thought holds up to scrutiny, and if the aim is to
save a few bytes then I would think that it would be better to have
the device initialization routines return a failure code and have
_sys_device_do_config_level() check for it and invoke the fatal error
handler upon the detection of failure. Otherwise we duplicate the
overhead of calling the fatal error handler in each device
initialization routine.
Sorry for the slow response. I agree with Peter here I think we should
be checking the return value and doing something useful with the
result. Maybe not _NanoFatalErrorHandler() but something notifying
the application that something bad happened. A given device not
initializing may not be fatal to the the whole application, just one
feature is currently unavailable.
For the kind of systems we are targeting, do we really expect the
application to handle devices not initializing correctly, being designed
so that parts are disabled if some parts of the initialization fail
(devices or others), or do we expect applications to require everything
to be present for them to function correctly ? I would have thought the
latter, but I can be convinced.
Delving into the realm of the hypothetical :-)

What about devices that have drivers in the system but are not present
(pluggable) or can't initialize because some resource external to the
device can't be contacted (network server).

The application may be able to still do useful work albeit with reduced
functionality.

Then, if the latter, do we expect the application catching the errors at
runtime when deployed or during development (basically catching software
errors mostly) not malfunctionning hardware. Here, I was thinking the
latter as well, which is why I was proposing __ASSERT() calls catching
initialization errors in debug loads only. And this fits with one of the
core values of the OS, which is small footprint.
Both models are useful for different reasons :-D

Any of those could be a valid approach I think, but we have to decide on
one. And right now, we have the worst since we return those error codes
which are meant for runtime handling, but they just go into the void.
Agreed we need to pick and stay with it for some amount of time until
we see a few real uses/applications/platforms.
OK, following your proposal below, what we could put in place is
standardizing on error codes that init routines must return if they want
the kernel init system to automatically trigger a fatal error.

Then, we could also allow configuring out the error handling if someone
needs to squeeze that last amount of space. One more Kconfig option! :)
The error handling would be enabled by default of course.
For those non-fatal errors, what should we do for runtime driver behaviors?
Should the drivers themselves fail API calls? Or should we let
device_get_binding() return NULL?
How about something like this:

diff --git a/kernel/nanokernel/device.c b/kernel/nanokernel/device.c
index f86f95f..82774c4 100644
--- a/kernel/nanokernel/device.c
+++ b/kernel/nanokernel/device.c
@@ -58,7 +58,7 @@ struct device *device_get_binding(char *name)
struct device *info;

for (info = __device_init_start; info != __device_init_end; info++) {
- if (!strcmp(name, info->config->name)) {
+ if (!strcmp(name, info->config->name) && info->driver_api) {
return info;
}
}

if there is a non-fatal error the driver will not mark itself available
and we can get rid of the null checks in the API headers since the user of the
driver will never get a reference to it if init() did not complete successfully
Why not create a dedicated status field in device object?

Additionally we can provide an API to query status of devices. This
will help query status of devices it does not bind to.


This should work. We need to rework some of the drivers as they make
the driver_api assignment unconditionally.


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


Re: RFC: return type of functions passed to DEVICE_INIT()

Thomas, Ramesh
 

On Fri, 2016-02-19 at 10:31 -0500, Benjamin Walsh wrote:
On Thu, Feb 18, 2016 at 10:49:01PM +0000, Thomas, Ramesh wrote:

On Thu, 2016-02-18 at 12:34 -0800, Dirk Brandewie wrote:

On 02/18/2016 10:03 AM, Benjamin Walsh wrote:

My take on it is that for Zephyr a failed device initialization
should be considered a fatal event. My expectation is that the
Zephyr user will only be enabling relevant (and important) devices to
their project. If one of these devices should fail, then that is a
serious system error and _NanoFatalErrorHandler() should be invoked.
How about a CONFIG option to determine if kernel should abort boot? The
What I was proposing in my last reply, too keep things simple, is one
Kconfig option to enable/disable handling of error codes by init
functions. If it's disabled, nothing is handled automatically and it
relies on everything working (when deployed) and __ASSERTs (when
debugging).

If it's enabled, some runtime handling is already needed, so you can
piggyback on it. One way is to standardize on a specific error code to
be returned by init functions to tell the kernel to abort boot. No need
for a Kconfig option for that case.
That should be fine. So the kernel decision to abort will be based on a
"fatal" error return from any of the device's init function.

We still need to decide what does "abort" mean for kernel. It could
mean -
1. Break out of _sys_device_do_config_level() when one device init
fails and continue boot. App takes necessary action when it finds device
inits had failed.
2. Kernel continues with all device inits and boot. Basically ignores
the error returned but devices have them logged so app will know when it
tries to use them.
3. Kernel itself aborts boot.

I prefer #2 or #1 (in that order) because that gives app flexibility of
dealing with the situation.

One more thing to note is that app will not get binding for all
required devices e.g. ioapic, loapic, sys_clock etc. So it might not
know if they failed unless it queries all devices explicitly which is
unlikely unless we provide some API for that. IMO these should never
fail and we need not consider any kernel action for this (so we can
still stay away from #3 above). Just wanted to bring this up as app's
ability to know device failure is being considered as part of the
design.


behavior should be determined by the kind of application. Some can live
with less features while for others it is all or nothing. In both cases
a logging feature that can be queried by the app would be useful.

Any of those could be a valid approach I think, but we have to decide on
one. And right now, we have the worst since we return those error codes
which are meant for runtime handling, but they just go into the void.
+1 _sys_device_do_config_level() should at least pass on the error
returned even if one device fails. This as well as the
"resume_all/suspend_all" functions can be called by app in power
management case. It would be useful for the app to know that something
went wrong.

Question still remains whether _sys_device_do_config_level() should
continue with other devices if one fails. IMO it should continue but
should return error if one device had failed. At boot time, kernel can
save the error condition somewhere to be queried by the app.
The thing is that you can have several failures, one per-device object
basically. That's why I was proposing saving the errors in some field in
the device object and queuing them to be retrieved by the application.
Storing status in device object sounds good.

I was considering the possible use case of PM app calling
_sys_device_do_config_level(). In that case a return value of 0 or 1
would help it know some thing went wrong instead of having to query all
devices to find out. But I think this does not impact the main topic of
your RFC and can be addressed separately if necessary.


Brainstorming:

If we want to let the application handle the initialization issues, we
probably need some kind of queue that gets filled by the init system
when init functions return errors, and that the application drains to
see what failed. We might want to queue the associated device objects,
and have an errno field in there, or something like that.
The app would be anyway getting a failure when it tries to use the
device. It most probably cannot rectify any device error on the fly with
more detailed info. Just my thought

A simple status from _sys_device_do_config_level() is probably enough so
the app can decide whether to continue or abort.
This still has to be saved somewhere that can be retrieved by the app.
The kernel does not pass anything to main() currently, and in the
microkernel, there isn't necessarily a main() either.
Yes, passing in main() or task entry points are messy. Storing
somewhere for app to query is better. May be even provide an API to
help in the query if that helps.