Date   

Re: Question about non-XIP boot

Benjamin Walsh <benjamin.walsh@...>
 

On Mon, Sep 19, 2016 at 11:19:47AM +0800, Tidy Jiang wrote:
Hi All,

I'm reading the boot code for cortex-m, but confused about
something, please help me.

Before jumping to C code:

void _PrepC(void)
{
relocate_vector_table();
enable_floating_point();
_bss_zero();
_data_copy();
_Cstart();
CODE_UNREACHABLE;
}

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

#ifdef CONFIG_XIP
static inline void relocate_vector_table(void) { /* do nothing */ }
#else
static inline void relocate_vector_table(void)
{
/* vector table is already in SRAM, just point to it */
_scs_relocate_vector_table((void *)CONFIG_SRAM_BASE_ADDRESS);
}
#endif

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

In non-XIP mode, from my view, before relocate vector table to RAM,
we should copy the data from flash to RAM. But above code firstly
relocates and then copy data, why ?
In non-XIP mode, the image is supposed to already be in RAM, including
the data, so there is no data to copy from the flash. _data_copy() does
nothing in that case.


RFC: async I/O facility: "zpoll" API

Andy Ross
 

So I've been looking at the requirement for an async I/O framework in
ZEP-540, and this is the API I have so far. An implementation is
prototyped as far as working with a minimal test of a faked device,
I'll get that cleaned up and in gerrit for a review within a day. But
here's the API I'm looking at. Please tear it apart as appropriate;
it's an API we'll be stuck with for a while. Stuff to note:

It works a little like Unix select()/poll(), in that the caller gets
handles to a bunch of "zpoll_event" structures which are 1:1 with
async requests made (e.g. they're a return value from a putative
uart_write_async() call), and can wait on the full set of them, waking
up with any one of them has a completion event to signal.

Driver's are responsible for managing one of these events per
simultaneous outstanding request they want to handle (in mose cases
that number of requests will be one), and calling a straightforward
signal() function when the request is complete (or in an error state).

Because mixing blocking styles is madness (c.f. the historical
disaster of pthreads and file descriptors not being waitable in the
same call and the need for hacks like signalfd), it also accepts basic
semaphores as a waitable object. We might consider some of the other
IPC primitives for the same treatment.

The original request was for a callback mechanism, which I resisted.
But given this mechanism and the existance of the system work queue
(which, to be fair, is a heavyweight feature), that's not hard to
implement. So this supports both styles, but the callback one is
optional for apps with their own main loops that don't want to have a
extra 1kb thread stack sitting around just for event processing.

Semantically, this overlaps in a kind of ugly way with
sem_group_take(), which I see a patch in the queue for. Essentially
zpoll() is a proper superset of that facility. We should probably try
to unify/deprecate such that we can do things in only one way.

Please review. An implementation prototype will arrive promptly.

Andy


========================================================================

typedef void (*zpoll_callback_t)(int result, void *user_data);

enum zpoll_req_type { ZPOLL_REQ_POLL, ZPOLL_REQ_SEM, ZPOLL_REQ_CALLBACK };

struct zpoll_event {
enum zpoll_req_type type : 8;
int signaled : 1; /* Driver/source operation complete */
int active : 1; /* result not yet retrieved/delivered */
int result;
union {
struct {
zpoll_callback_t callback;
void *user_data;
} cb;
struct {
struct zpoll_call *poller;
struct k_sem *semaphore;
} polled;
};
};

/**
* @brief Re/initialize zpoll event
*
* For use by drivers who are initiating a new request. Will return
* an error (-EAGAIN) if the event is still in use, which should
* generally be either propagated back to the user code making the
* request or used to initiate some kind of queuing/allocation of a
* new event. Drivers should *not* pend or busy-wait at request time
* to "wait" for this to become available. These are asynchronous
* requests!
*
* @param evt A potentially-in-use zpoll_event structure
*/
int zpoll_event_init(struct zpoll_event *evt);

#ifdef ZPOLL_CALLBACKS
/**
* @brief Re/initialize zpoll event for a user-specified callback
*
* As for zpoll_event_init(), but assigns the callback fields where provided.
*
* @param evt A potentitally-in-use zpoll_event structure
* @param cb A user-provided callback function
* @param user_data A user-provided opaque pointer to be passed as the
* user_data argument to the callback
*/
int zpoll_event_init_cb(struct zpoll_event *evt, zpoll_callback_t cb, void *user_data);
#endif

/**
* @brief Static initializer for a semaphore zpoll_event
*
* Constructs a zpoll_event stucture suitable for passing to zpoll().
*
* @param sem A pointer to a valid k_sem_t.
*/
#define ZPOLL_EVENT_SEMAPHORE(sem) \
{ \
.request_type = ZPOLL_REQ_SEM, \
.signaled = 0, \
.semaphore = (sem), \
}

/**
* @brief Executes the user-provided handler for a complete event
*
* Called by driver code when the request abstracted by this zpoll
* event is complete, either by waking up a pending zpoll() call or
* scheduling a work thread to issue the user-provided callback.
*
* @param evt A zpoll_event structure whose action is complete
* @param result The integer result code of the asynchronous call
*/
void zpoll_signal(struct zpoll_event *evt, int result);

void _zpoll_sem_signal(struct k_sem *sem);

/**
* @brief Wait for the completion of any of a number of events
*
* Will pend until any of the zpoll_event structures receives a
* zpoll_signal() call from another context (or, for semaphores, a
* "give" event), or until a the specified timeout occurs.
*
* For convenience, will return one known-complete event pointer. But
* note that completion notifications are "level triggered" (they stay
* complete and will synchronously wake up future zpoll calls until
* their results are retrieved), and that there may be more whose
* state can be tested with zpoll_get_result(). In general most
* applications will simply loop on zpoll() getting one event at a
* time.
*
* @param events An array of zpoll_event structures
* @param nevents The size of the events array
* @param timeout_ticks How long to wait before returning, or
* TICKS_UNLIMITED to wait forever.
*
* @return One complete event, or NULL if the timeout expired.
*/
struct zpoll_event* zpoll(struct zpoll_event **events, int nevents,
int timeout_ticks);

/**
* @brief Retrieve the result code of a complete zpoll_event and mark
* it available
*
* Returns the integer result code of the operation encapsulated by
* the zpoll_event. For driver-managed events, this also marks the
* zpoll_event available for future asynchronous I/O calls and so
* *must* be called to free the resource for future I/O.
*
* Will return -EAGAIN if the event is not yet complete.
*
* @return The result code of the asynchronous operation
*/
int zpoll_get_result(struct zpoll_event *e);


Re: RFC: Extension to External Interrupt API

Iván Briano <ivan.briano at intel.com...>
 

On Mon, 19 Sep 2016 19:07:12 +0000, Boie, Andrew P wrote:
On Fri, 2016-09-16 at 04:52 +0000, Vinayak Kariappa Chettimada wrote:
Hi,

Welcome your valuable comments on the proposed extension to External
Interrupt API.

*irq_enable_keep*
https://gerrit.zephyrproject.org/r/#/c/4676/1
https://gerrit.zephyrproject.org/r/#/c/4677/1
Originally Vinayak sent a patch to change ARM's irq_enable() not to
unpend any pending interrupts when enabling the channel. It was -1 as
we didn't want to change the semantics of the kernel API to preserve
compatibility.

However, on further inspection of other arches, this behavior seems to
be peculiar to ARM.

On x86, for example, enabling an IRQ in the IOAPIC or MVIC just clears
the IOAPIC_INT_MASK (bit 16) in the appropriate IOREDTBL entry. It
doesn't clear pending interrupts on that line. Indeed, if it did, the
rate-limiting in the IPM console driver wouldn't work.

On ARC, similarly it puts the IRQ line into the _ARC_V2_IRQ_SELECT
register, and then writes to the _ARC_V2_IRQ_ENABLE register to
enable/disable it. I don't see anything in the datasheet that un-pends
any pending interrupts.

I think at this point we could consider ARM's behavior of clearing
pending interrupts on irq_enable() a bug and we should change it,
making irq_enable_keep() unnecessary. Does this sound good to everyone?
Sounds reasonable to me.


Re: RFC: Extension to External Interrupt API

Boie, Andrew P
 

On Fri, 2016-09-16 at 04:52 +0000, Vinayak Kariappa Chettimada wrote:
Hi,

Welcome your valuable comments on the proposed extension to External
Interrupt API.

*irq_enable_keep*
https://gerrit.zephyrproject.org/r/#/c/4676/1
https://gerrit.zephyrproject.org/r/#/c/4677/1
Originally Vinayak sent a patch to change ARM's irq_enable() not to
unpend any pending interrupts when enabling the channel. It was -1 as
we didn't want to change the semantics of the kernel API to preserve
compatibility.

However, on further inspection of other arches, this behavior seems to
be peculiar to ARM.

On x86, for example, enabling an IRQ in the IOAPIC or MVIC just clears
the IOAPIC_INT_MASK (bit 16) in the appropriate IOREDTBL entry. It
doesn't clear pending interrupts on that line. Indeed, if it did, the
rate-limiting in the IPM console driver wouldn't work.

On ARC, similarly it puts the IRQ line into the _ARC_V2_IRQ_SELECT
register, and then writes to the _ARC_V2_IRQ_ENABLE register to
enable/disable it. I don't see anything in the datasheet that un-pends
any pending interrupts.

I think at this point we could consider ARM's behavior of clearing
pending interrupts on irq_enable() a bug and we should change it,
making irq_enable_keep() unnecessary. Does this sound good to everyone?

Andrew


Re: Galileo Gen 1 GPIO

Fábio Iaione <fabio.iaione at gmail.com...>
 

Hi Tomasz,
Unfortunately our laboratoty of the University has only Galileo Gen1 boards for classes.
I am studying the zephyr a few months ago because the site says that works with Gen1/Gen2 and now I have a big problem. I have no experience in writing drivers. It is the only option?
Thank you very much.


Re: zoap architecture question...

Vinicius Costa Gomes
 

Hi,

Marcus Shawcroft <marcus.shawcroft(a)gmail.com> writes:

Hi!

Neither the sample/zoap-server application nor the zoap implementation
itself appear to handle the generation of RST messages in response to
message format errors in an initial CON message (or did I miss
something?). Is the intention that the logic to generate such RST
messages will live within the zoap layer or is it intended to be
handled by the layer above?
The plan is that the error handling would live in the layer above. So
yeah, the zoap-server sample right now is lacking in the invalid
messages handling department.

What I see that could be done in the zoap layer is to add a few helper
functions for building the most common types of messages, including
RESET.

But I am waiting for some real usage before adding this.


Cheers
/Marcus
Cheers,
--
Vinicius


Re: Exception debugging with qemu_x86/gdb

Boie, Andrew P
 

On Sat, 2016-09-17 at 23:53 +0300, Paul Sokolovsky wrote:
I would naively think that QEMU's GDB stub would override any
relevant guest exception handling, but that apparently not happen.

I'm not sure how we could get QEMU's stubs in Zephyr's IDT to be honest.

It may be the case that we could do some work on the Zephyr x86
exception handling stubs to be more GDB friendly. I don't know off the
top of my head what it would take to get 'backtrace' to work the way
you describe. We might just need to massage the stack a bit and issue a
debugger 'break' in the error handler.

Currently, for x86 exceptions with CONFIG_EXCEPTION_DEBUG turned on we install a bunch of handler stubs, you can see the code in arch/x86/core/fatal.c. That is what prints out the message. It then calls _SysFatalErrorHandler which either aborts the thread or spins forever.

Faulting segment:address = 0x00000008:0x001782da
This is where your code is generating an exception. I'd set a
breakpoint there.


Andrew


Re: RFC: Extension to External Interrupt API

Boie, Andrew P
 

On Sat, 2016-09-17 at 04:13 +0000, Vinayak Kariappa Chettimada wrote:
Everything is so wrong or missing for ARM, NVIC should truely be an
interrupt_controller driver in Zephyr.
Historical note: originally, any given arch had just one interrupt
controller implementation written (APIC for x86, NVIC for ARM, etc) so
it was not separated out and was tightly coupled with the arch/*/core
code. Adding a layer of abstraction here has been done iteratively but
could still use more work. 

May be that is how I should implement for ARM then, may be
inconsistent based on NVIC as I see it is so now in the
drivers/interrupt_controller for others!. This will make a subsystem
like a BLE controller a portability nightmare, unless there is an
interrupt controller driver model, is there one?  irq.h is the
closest i could find.
irq.h is the external interrupt interface for applications.

On x86, we have an abstraction layer for interrupt controllers (which
is still x86-specific). See include/arch/x86/irq_controller.h. This
interface is private to the kernel, only arch/x86/core code uses it.

If we expect to support additional interrupt controllers on ARM, it may
be worthwhile to implement a similar interface for ARM.

I am trying to generalise. I need a bottom-half, a routine that is
scheduled by the top half to be executed later, at a safer time.
irq_offload in Zephyr sense, but I really want is Tasklets.
I suspect there are simpler approaches, I would really look into having
your ISR pend a fiber to do the bottom half work. In another mail Andy
gave some more detail.

Andrew


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 2
[ZEP-648] New CoAP Implementation
https://jira.zephyrproject.org/browse/ZEP-648

[ZEP-346] Provide a HTTP library within Zephyr
https://jira.zephyrproject.org/browse/ZEP-346


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 2
[ZEP-789] (Fixed) IPv4
https://jira.zephyrproject.org/browse/ZEP-789

[ZEP-790] (Fixed) ICMPv4
https://jira.zephyrproject.org/browse/ZEP-790


Re: RFC: Extension to External Interrupt API

Andy Ross
 

Vinayak Kariappa Chettimada wrote:
I am implementing a "work" (tasklet in Linux terms), a "work", being
a function/routine, is invoked as a direct call i.e. if the caller
is in the same priority as the ISR and the software interrupt (my
"work" group) that would have been offloaded to (if were at another
priority) is enabled. Hence, the need for irq_is_enabled().

In theory, each h/w interrupt can have separate/own bottom-half
"work" group (ISR). Why, to have priority levels for the
bottom-halves.
Yeah, this got some water-cooler attention last week. So it seems
what you're really asking for is an interrupt bottom half framework
for zephyr. So you can have your fiber scheduled alongside the
hardware interrupts when needed.

And (Ben needs to jump in here, I'm no expert) it seems like we have
most of what is needed already in the fiber scheduler. All that I can
see we'd need is:

1. Map the available hardware interrupt priorities to the top N fiber
priorities.

2. Mask off equal and lower interrupt priorities during the execution
of a fiber at those levels. This may be tricky to specify on all
architectures, and may involve some of them running "bottom half"
fibers with interrupts disabled. It might plausibly break some
assumptions in existing code that has an "in an ISR" notion (the
definition of "ISR" gets fuzzy).

3. Arrange to have the exit code for every ISR call _Swap() to
reschedule instead of returning directly to the interrupted task.
This would have some code size cost (maybe a tiny stub to wrap the
user-defined ISRs), though not huge.

But at that point, you don't need to muck with architecture-specific
interrupts to get what you want. You just wake up your work fiber(s)
from your existing ISRs with whatever IPC mechanism you want (give a
semaphore, write a command to a fifo, whatever) and they get scheduled
at the IRQ-scale priority you want.

What did I miss?

Andy


Re: [RFC]PWM API Update

Andy Ross
 

Liu, Baohong wrote:
get_cycles_per_usec(void); /* we can find better name:) */
Senseless nitpick: this unit choice will hit precision issues.
Many/most PWM implementations in the wild work on clocks in the low
MHz, so this is only going to return a few bits of frequency
precision. I'd suggest cycles_per_sec() (works as long as the clock
isn't GHz scale) or cycle_time_ps() (starts to lose precision above a
few GHz, also not everyone knows what a picosecond is) or something
equivalent.

Andy


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4837 : rfc: net: yaip: Add nbuf APIs to read/write across multiple fragments
- https://gerrit.zephyrproject.org/r/4836 : lib/http: Add test-case for HTTP header fields
- https://gerrit.zephyrproject.org/r/4823 : net: Make sure that local port selected by Zephyr gets used by uIP.
- https://gerrit.zephyrproject.org/r/4829 : net: yaip: Added a define for unused bytes length in ICMPv6 header
- https://gerrit.zephyrproject.org/r/4833 : net: tests: Add tests for route management API
- https://gerrit.zephyrproject.org/r/4831 : net: yaip: Add more debugging prints to neighbor cache
- https://gerrit.zephyrproject.org/r/4830 : net: yaip: Fix reachable timer accessing NULL pointer
- https://gerrit.zephyrproject.org/r/4828 : net: yaip: Add function to return neighbor by the index
- https://gerrit.zephyrproject.org/r/4832 : net: yaip: Generic route handling
- https://gerrit.zephyrproject.org/r/4827 : net: yaip: Fix function prototype documentation in neighbor header
- https://gerrit.zephyrproject.org/r/4825 : tinycrypt: Add test case for the ECC DH algorithm
- https://gerrit.zephyrproject.org/r/4824 : tinycrypt: Add test case for the ECC DSA algorithm

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4794 : Bluetooth: A2DP: Initialization of A2DP
- https://gerrit.zephyrproject.org/r/3922 : lib: Add HTTP support for Zephyr
- https://gerrit.zephyrproject.org/r/4780 : unified: Fix semaphore group tests
- https://gerrit.zephyrproject.org/r/4810 : unified: Add _is_next_thread_current()
- https://gerrit.zephyrproject.org/r/4785 : unified: Add timeslice support
- https://gerrit.zephyrproject.org/r/4781 : unified: Enable semaphore group use in test_mail
- https://gerrit.zephyrproject.org/r/4779 : unified: Add support for semaphore groups
- https://gerrit.zephyrproject.org/r/4321 : Bluetooth: BR/EDR: Refactor distribution of security procedure status
- https://gerrit.zephyrproject.org/r/3527 : console: shell: Shell enhancement - Support multiple modules
- https://gerrit.zephyrproject.org/r/4487 : Bluetooth: SDP: Server: Support service record registration
- https://gerrit.zephyrproject.org/r/4704 : power_mgmt: Update sample and drivers according to new pm device API
- https://gerrit.zephyrproject.org/r/4463 : power_mgmt: Update Power Management device driver API
- https://gerrit.zephyrproject.org/r/4705 : power_mgmt: Mark old device pm API functions as deprecated
- https://gerrit.zephyrproject.org/r/4808 : Bluetooth: L2CAP: Limit user I/O actions timeout in GAP context
- https://gerrit.zephyrproject.org/r/4795 : Bluetooth: L2CAP: Refactor handling connection response
- https://gerrit.zephyrproject.org/r/4796 : Bluetooth: L2CAP: Handle security procedure non successful path
- https://gerrit.zephyrproject.org/r/4822 : arduino 101: fix PHYS_LOAD_ADDR for arduino_101

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4834 : Bluetooth: init: Add CONFIG_BLUETOOTH_RFCOMM to prj_20.conf
- https://gerrit.zephyrproject.org/r/3895 : tests/kernel/test_multilib: Test for proper multilib selection.
- https://gerrit.zephyrproject.org/r/4447 : Bluetooth: AVDTP: Module Initialization
- https://gerrit.zephyrproject.org/r/4809 : Bluetooth: Controller: Clean up naming in the HCI driver


zoap architecture question...

Marcus Shawcroft <marcus.shawcroft@...>
 

Hi!

Neither the sample/zoap-server application nor the zoap implementation
itself appear to handle the generation of RST messages in response to
message format errors in an initial CON message (or did I miss
something?). Is the intention that the logic to generate such RST
messages will live within the zoap layer or is it intended to be
handled by the layer above?

Cheers
/Marcus


Re: Galileo Gen 1 GPIO

Tomasz Bursztyka
 

Hi Fábio,

Unfortunately, we do not support Galileo v1 pinmuxing, thus: the whole
board is basically unusable at this stage.
You won't be able to get very far unless you provide the cypress chip
driver.

Can you use another board? We support quite a few (see boards directory
in zephyr's tree)

Br,

Tomasz

Dear Sirs,
I am using Galileo Gen 1 (Cypress I/O expander) and I can not change the GPIO levels.
What GPIO driver should I set in menuconfig tool (DesignWare, PCAL9535, MMIO, Intel SCH)?
What driver name and pin numbers should I use in functions API (gpio_pin_configure, gpio_pin_write, ....)?
Thank you very much.


Question about non-XIP boot

Tidy(ChunHua) Jiang <tidyjiang@...>
 

Hi All,

I'm reading the boot code for cortex-m, but confused about something,
please help me.

Before jumping to C code:

void _PrepC(void)
{
relocate_vector_table();
enable_floating_point();
_bss_zero();
_data_copy();
_Cstart();
CODE_UNREACHABLE;
}

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

#ifdef CONFIG_XIP
static inline void relocate_vector_table(void) { /* do nothing */ }
#else
static inline void relocate_vector_table(void)
{
/* vector table is already in SRAM, just point to it */
_scs_relocate_vector_table((void *)CONFIG_SRAM_BASE_ADDRESS);
}
#endif

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

In non-XIP mode, from my view, before relocate vector table to RAM, we
should copy the data from flash to RAM. But above code firstly relocates
and then copy data, why ?

Thx & Rgds.


Re: A possible case of TCP server no-response, was: Re: bufs lost in TCP connection establishment

Paul Sokolovsky
 

Hello,

On Thu, 15 Sep 2016 02:51:49 -0000
"Flavio Santes" <flavio.santes(a)intel.com> wrote:

One particularly naughty conditions I experienced is that while my
usual testcase usually proceeded beyond connect() call, sometimes I
got time "strips" when connect() call just hanged (I don't use
[]

This is a hardware-agnostic issue, see:
https://jira.zephyrproject.org/browse/ZEP-428. The issue description
is not really useful, although comments will help. BTW, we apply the
same workaround: restart the server :)
Thanks, I read it, but not sure it's the same issue as I described
above - indeed, there're many different issues. I checked into Z source,
and found that it actually tries to make a random local port number (if
user passed one as 0). But Wireshark still shows that after a restart,
1025 is what gets actually sent on wire, and the situation got pretty
unpleasant when I moved from local servers to knocking on AWS IoT ones,
which, well, I can't restart.

So, digging further, turned that Zephyr networking layer and uIP live
their own separate lives wrt to local port numbering.
https://gerrit.zephyrproject.org/r/#/c/4823/ makes them talk together,
though on uIP's terms (using global variables). As patch description
says, I'm open to suggestions to redo it via adding function arguments.



Thanks,
Paul


On Wed, 7 Sep 2016 15:26:23 +0000
Rohit Grover <Rohit.Grover(a)arm.com&gt; wrote:
Regards,
Flavio


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 1
[ZEP-555] correct libgcc not getting linked for CONFIG_FLOAT=y on ARM
https://jira.zephyrproject.org/browse/ZEP-555


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4822 : arduino 101: fix PHYS_LOAD_ADDR for arduino_101
- https://gerrit.zephyrproject.org/r/4821 : drivers: gpio: reuse gpio Kconfigs for sensor subsystem

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4705 : power_mgmt: Mark old device pm API functions as deprecated
- https://gerrit.zephyrproject.org/r/4704 : power_mgmt: Update sample and drivers according to new pm device API
- https://gerrit.zephyrproject.org/r/4463 : power_mgmt: Update Power Management device driver API
- https://gerrit.zephyrproject.org/r/4450 : tests: Add gcov support
- https://gerrit.zephyrproject.org/r/4357 : tests: Add a sample for testing natively
- https://gerrit.zephyrproject.org/r/4354 : ztest: Add documentation
- https://gerrit.zephyrproject.org/r/4356 : tests: convert tests/net/buf to the new framework
- https://gerrit.zephyrproject.org/r/4355 : ztest: Add simple integration and unit tests
- https://gerrit.zephyrproject.org/r/4118 : tests: Add a generic testing framework
- https://gerrit.zephyrproject.org/r/4353 : ztest: Add native building support

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4622 : eth: Add full-duplex configuration to ENC28J60
- https://gerrit.zephyrproject.org/r/4621 : eth: Initial release to tx semaphore for the ENC28J60 driver.
- https://gerrit.zephyrproject.org/r/4620 : eth: Adjust ENC28J60 MAC configuration.
- https://gerrit.zephyrproject.org/r/4803 : Merge bluetooth branch into master


Exception debugging with qemu_x86/gdb

Paul Sokolovsky
 

Hello,

I have a crash ("CPU exception 13") somewhere in networking code. My
next step would be to run the app (BOARD=qemu_x86) under GDB, wait for
crash, type "backtrace". I follow
https://www.zephyrproject.org/doc/reference/kbuild/kbuild_project.html#application-debugging
, but when exception occurs, I don't end up in GDB, Zephyr's own
exception handler keeps running, e.g.:

***** CPU exception 13
***** Exception code: 0x00004074
Current thread ID = 0x00177f60
Faulting segment:address = 0x00000008:0x001782da
eax: 0x0000ff0e, ebx: 0x00178350, ecx: 0x00177f60, edx: 0x00177f60
esi: 0x00000000, edi: 0x00178400, ebp: 000169398, esp: 0x0017830c
eflags: 0x00004046
Fatal essential fiber error! Spinning...

I tried to look for Kconfig options, but the only relevant I found was
CONFIG_EXCEPTION_DEBUG, setting it to "n" from default "y" doesn't
help. Well, another option is CONFIG_GDB_SERVER, but that embeds
actual GDB debug stub into the *application*. But we use QEMU's debug
stub on the meta-level, so CONFIG_GDB_SERVER shouldn't be needed (and
enabling it just garbles console, as it tries to communicate via
serial).

So, I would naively think that QEMU's GDB stub would override any
relevant guest exception handling, but that apparently not happen. What
am I missing? I tried to look for other related options to QEMU
(besides -s -S), but don't see nothing relevant. The only doc I found
is http://wiki.qemu.org/Documentation/Debugging which is pretty short
at best.


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 36
[ZEP-906] [unified] Add scheduler time slicing support
https://jira.zephyrproject.org/browse/ZEP-906

[ZEP-909] Adapt tickless idle + power management for ARM
https://jira.zephyrproject.org/browse/ZEP-909

[ZEP-908] Add task offload to fiber support
https://jira.zephyrproject.org/browse/ZEP-908

[ZEP-910] Adapt tickless idle for x86
https://jira.zephyrproject.org/browse/ZEP-910

[ZEP-907] Test memory pool support (with mailboxes)
https://jira.zephyrproject.org/browse/ZEP-907

[ZEP-911] Refine thread priorities & locking
https://jira.zephyrproject.org/browse/ZEP-911

[ZEP-924] Revise documentation for Interrupts
https://jira.zephyrproject.org/browse/ZEP-924

[ZEP-923] Revise documentation for Timing
https://jira.zephyrproject.org/browse/ZEP-923

[ZEP-927] Enhancements to memory maps
https://jira.zephyrproject.org/browse/ZEP-927

[ZEP-925] Enhancements to message queues
https://jira.zephyrproject.org/browse/ZEP-925

[ZEP-929] Verify the preempt-thread-only and coop-thread-only configurations
https://jira.zephyrproject.org/browse/ZEP-929

[ZEP-926] Enhancements to memory pools
https://jira.zephyrproject.org/browse/ZEP-926

[ZEP-931] Finalize kernel file naming & locations
https://jira.zephyrproject.org/browse/ZEP-931

[ZEP-930] Cutover to unified kernel
https://jira.zephyrproject.org/browse/ZEP-930

[ZEP-912] Finish renaming kernel object types
https://jira.zephyrproject.org/browse/ZEP-912

[ZEP-937] Adapt networking to unified kernel
https://jira.zephyrproject.org/browse/ZEP-937

[ZEP-936] Adapt drivers to unified kernel
https://jira.zephyrproject.org/browse/ZEP-936

[ZEP-934] NIOS_II port
https://jira.zephyrproject.org/browse/ZEP-934

[ZEP-935] Kernel logger support (validation)
https://jira.zephyrproject.org/browse/ZEP-935

[ZEP-933] ARC port
https://jira.zephyrproject.org/browse/ZEP-933

[ZEP-916] Eliminate kernel object API anomalies
https://jira.zephyrproject.org/browse/ZEP-916

[ZEP-918] Add ring buffer support
https://jira.zephyrproject.org/browse/ZEP-918

[ZEP-917] Add abort handler support
https://jira.zephyrproject.org/browse/ZEP-917

[ZEP-914] Improving locking algorithms in kernel objects
https://jira.zephyrproject.org/browse/ZEP-914

[ZEP-921] Miscellaneous documentation work
https://jira.zephyrproject.org/browse/ZEP-921

[ZEP-919] Purge obsolete microkernel & nanokernel code
https://jira.zephyrproject.org/browse/ZEP-919

[ZEP-922] Revise documentation for Kernel Event Logger
https://jira.zephyrproject.org/browse/ZEP-922

[ZEP-928] Enhancements to event handling
https://jira.zephyrproject.org/browse/ZEP-928

[ZEP-932] Adapt kernel sample & test projects
https://jira.zephyrproject.org/browse/ZEP-932

[ZEP-913] Place thread stacks in their own linker section
https://jira.zephyrproject.org/browse/ZEP-913

[ZEP-920] Investigate malloc/free support
https://jira.zephyrproject.org/browse/ZEP-920

[ZEP-915] O(1) pend queue support
https://jira.zephyrproject.org/browse/ZEP-915

[ZEP-903] Create APIs for app to create and mount FS
https://jira.zephyrproject.org/browse/ZEP-903

[ZEP-904] Look into supporting additional file systems under Zephyr FS API
https://jira.zephyrproject.org/browse/ZEP-904

[ZEP-902] Reduce the use of Kconfig for FS to minimum
https://jira.zephyrproject.org/browse/ZEP-902

[ZEP-905] hello_world compilation for arduino_due target fails when using CROSS_COMPILE
https://jira.zephyrproject.org/browse/ZEP-905


UPDATED JIRA items within last 24 hours: 4
[ZEP-812] Compression Format for IPv6 over 802.15.4
https://jira.zephyrproject.org/browse/ZEP-812

[ZEP-809] IPv6 over 802.15.4
https://jira.zephyrproject.org/browse/ZEP-809

[ZEP-875] 6LoWPAN - Context based compression support
https://jira.zephyrproject.org/browse/ZEP-875

[ZEP-796] DHCPv4
https://jira.zephyrproject.org/browse/ZEP-796


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 3
[ZEP-584] (Fixed) warn user if SDK is out of date
https://jira.zephyrproject.org/browse/ZEP-584

[ZEP-758] (Fixed) Rename Quark SE Devboard to its official name: Quark SE C1000
https://jira.zephyrproject.org/browse/ZEP-758

[ZEP-898] (Fixed) Remove 1MB limit in file system
https://jira.zephyrproject.org/browse/ZEP-898

6541 - 6560 of 8046