Do you want to be paid for contributing to the seL4 microkernel and its ecosystem, and getting your code used in critical systems on a large scale? As part of a kick-ass team, while living in Sydney, one of the world’s most liveable cities?
The seL4 team at DATA61 (formerly NICTA) is hiring OS engineers, see https://ssrg.nicta.com.au/jobs/OS-engineers2015
We’re also hiring: - proof engineers: https://ssrg.nicta.com.au/jobs/proof-engineers2015 - researchers/postdocs: https://ssrg.nicta.com.au/jobs/OS-researchers2015
Gernot
Hello again,
i have an issue with different U-Boot versions, and i have no clue what's the problem. Maybe someone's got an idea?
Working on Xilinx' ARM Platform i use U-Boot version u-boot-xlnx-xilinx-v14.6.01, and it's all good with that one and lower versions. But, using u-boot-xlnx-xilinx-v14.7 or higher results in serious CPU errors:
uboot> fatload mmc 0 0x00ffffc0 bootstrap.uimage reading bootstrap.uimage 6139968 bytes read in 528 ms (11.1 MiB/s) uboot> go 0x01000000 ## Starting application at 0x01000000 ... undefined instruction pc : [<01000004>] lr : [<3ff74bc0>] sp : 3fb51e08 ip : 00002802 fp : 00000000 r10: 3fb572d8 r9 : 00000002 r8 : 3fb51f40 r7 : 3ffaff50 r6 : 01000000 r5 : 3fb572dc r4 : 00000002 r3 : 01000000 r2 : 3fb572dc r1 : 3fb572dc r0 : 00000001 Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
Unfortunately, the DIFF between v14.6 and v14.7 is 60'000 lines...
Is there any chance to fix that?
Have nice day,
ba_f
Hi,
sorry, wrong mailing list. Try
http://lists.denx.de/mailman/listinfo/u-boot
Matthias.
On 10/07/2015 06:59 PM, ba_f wrote:
Hello again,
i have an issue with different U-Boot versions, and i have no clue what's the problem. Maybe someone's got an idea?
Working on Xilinx' ARM Platform i use U-Boot version u-boot-xlnx-xilinx-v14.6.01, and it's all good with that one and lower versions. But, using u-boot-xlnx-xilinx-v14.7 or higher results in serious CPU errors:
uboot> fatload mmc 0 0x00ffffc0 bootstrap.uimage reading bootstrap.uimage 6139968 bytes read in 528 ms (11.1 MiB/s) uboot> go 0x01000000 ## Starting application at 0x01000000 ... undefined instruction pc : [<01000004>] lr : [<3ff74bc0>] sp : 3fb51e08 ip : 00002802 fp : 00000000 r10: 3fb572d8 r9 : 00000002 r8 : 3fb51f40 r7 : 3ffaff50 r6 : 01000000 r5 : 3fb572dc r4 : 00000002 r3 : 01000000 r2 : 3fb572dc r1 : 3fb572dc r0 : 00000001 Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
Unfortunately, the DIFF between v14.6 and v14.7 is 60'000 lines...
Is there any chance to fix that?
Have nice day,
ba_f
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
On Wed Oct 07, 2015 at 18:59:17 +0200, ba_f wrote:
i have an issue with different U-Boot versions, and i have no clue what's the problem. Maybe someone's got an idea?
Working on Xilinx' ARM Platform i use U-Boot version u-boot-xlnx-xilinx-v14.6.01, and it's all good with that one and lower versions. But, using u-boot-xlnx-xilinx-v14.7 or higher results in serious CPU errors:
uboot> fatload mmc 0 0x00ffffc0 bootstrap.uimage reading bootstrap.uimage 6139968 bytes read in 528 ms (11.1 MiB/s) uboot> go 0x01000000 ## Starting application at 0x01000000 ... undefined instruction pc : [<01000004>] lr : [<3ff74bc0>] sp : 3fb51e08 ip : 00002802 fp : 00000000 r10: 3fb572d8 r9 : 00000002 r8 : 3fb51f40 r7 : 3ffaff50 r6 : 01000000 r5 : 3fb572dc r4 : 00000002 r3 : 01000000 r2 : 3fb572dc r1 : 3fb572dc r0 : 00000001 Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
Unfortunately, the DIFF between v14.6 and v14.7 is 60'000 lines...
Is there any chance to fix that?
The pc where it traps is (shall be) a NOP and definitely not an undefined instruction. You could check after the fatload whether the contents in memory (via md in u-boot) and in the binary are the same at that location (0x01000004).
Adam
Am 2015-10-12 00:01, schrieb Adam Lackorzynski:
On Wed Oct 07, 2015 at 18:59:17 +0200, ba_f wrote:
i have an issue with different U-Boot versions, and i have no clue what's the problem. Maybe someone's got an idea?
Working on Xilinx' ARM Platform i use U-Boot version u-boot-xlnx-xilinx-v14.6.01, and it's all good with that one and lower versions. But, using u-boot-xlnx-xilinx-v14.7 or higher results in serious CPU errors:
uboot> fatload mmc 0 0x00ffffc0 bootstrap.uimage reading bootstrap.uimage 6139968 bytes read in 528 ms (11.1 MiB/s) uboot> go 0x01000000 ## Starting application at 0x01000000 ... undefined instruction pc : [<01000004>] lr : [<3ff74bc0>] sp : 3fb51e08 ip : 00002802 fp : 00000000 r10: 3fb572d8 r9 : 00000002 r8 : 3fb51f40 r7 : 3ffaff50 r6 : 01000000 r5 : 3fb572dc r4 : 00000002 r3 : 01000000 r2 : 3fb572dc r1 : 3fb572dc r0 : 00000001 Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
Unfortunately, the DIFF between v14.6 and v14.7 is 60'000 lines...
Is there any chance to fix that?
The pc where it traps is (shall be) a NOP and definitely not an undefined instruction. You could check after the fatload whether the contents in memory (via md in u-boot) and in the binary are the same at that location (0x01000004).
Adam
The newer u-boot got dcache support for certain ARMs. So, i have to do 'u-boot> dcache off' to make it run successful.
Bye, ba_f
On Tue Oct 13, 2015 at 16:52:16 +0200, ba_f wrote:
Am 2015-10-12 00:01, schrieb Adam Lackorzynski:
On Wed Oct 07, 2015 at 18:59:17 +0200, ba_f wrote:
i have an issue with different U-Boot versions, and i have no clue what's the problem. Maybe someone's got an idea?
Working on Xilinx' ARM Platform i use U-Boot version u-boot-xlnx-xilinx-v14.6.01, and it's all good with that one and lower versions. But, using u-boot-xlnx-xilinx-v14.7 or higher results in serious CPU errors:
uboot> fatload mmc 0 0x00ffffc0 bootstrap.uimage reading bootstrap.uimage 6139968 bytes read in 528 ms (11.1 MiB/s) uboot> go 0x01000000 ## Starting application at 0x01000000 ... undefined instruction pc : [<01000004>] lr : [<3ff74bc0>] sp : 3fb51e08 ip : 00002802 fp : 00000000 r10: 3fb572d8 r9 : 00000002 r8 : 3fb51f40 r7 : 3ffaff50 r6 : 01000000 r5 : 3fb572dc r4 : 00000002 r3 : 01000000 r2 : 3fb572dc r1 : 3fb572dc r0 : 00000001 Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
Unfortunately, the DIFF between v14.6 and v14.7 is 60'000 lines...
Is there any chance to fix that?
The pc where it traps is (shall be) a NOP and definitely not an undefined instruction. You could check after the fatload whether the contents in memory (via md in u-boot) and in the binary are the same at that location (0x01000004).
Adam
The newer u-boot got dcache support for certain ARMs. So, i have to do 'u-boot> dcache off' to make it run successful.
Interesting, and thanks for the info. Given that it seems to reject the second instruction in bootstrap it looks like the icache is stale. Could you try an 'icache flush' and see if that works too?
Adam
Am 2015-10-16 00:22, schrieb Adam Lackorzynski:
On Tue Oct 13, 2015 at 16:52:16 +0200, ba_f wrote:
Am 2015-10-12 00:01, schrieb Adam Lackorzynski:
On Wed Oct 07, 2015 at 18:59:17 +0200, ba_f wrote:
i have an issue with different U-Boot versions, and i have no clue what's the problem. Maybe someone's got an idea?
Working on Xilinx' ARM Platform i use U-Boot version u-boot-xlnx-xilinx-v14.6.01, and it's all good with that one and lower versions. But, using u-boot-xlnx-xilinx-v14.7 or higher results in serious CPU errors:
uboot> fatload mmc 0 0x00ffffc0 bootstrap.uimage reading bootstrap.uimage 6139968 bytes read in 528 ms (11.1 MiB/s) uboot> go 0x01000000 ## Starting application at 0x01000000 ... undefined instruction pc : [<01000004>] lr : [<3ff74bc0>] sp : 3fb51e08 ip : 00002802 fp : 00000000 r10: 3fb572d8 r9 : 00000002 r8 : 3fb51f40 r7 : 3ffaff50 r6 : 01000000 r5 : 3fb572dc r4 : 00000002 r3 : 01000000 r2 : 3fb572dc r1 : 3fb572dc r0 : 00000001 Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
Unfortunately, the DIFF between v14.6 and v14.7 is 60'000 lines...
Is there any chance to fix that?
The pc where it traps is (shall be) a NOP and definitely not an undefined instruction. You could check after the fatload whether the contents in memory (via md in u-boot) and in the binary are the same at that location (0x01000004).
Adam
The newer u-boot got dcache support for certain ARMs. So, i have to do 'u-boot> dcache off' to make it run successful.
Interesting, and thanks for the info. Given that it seems to reject the second instruction in bootstrap it looks like the icache is stale. Could you try an 'icache flush' and see if that works too?
Adam
No, it crashes with only 'icache flush'. Still need 'dcache off'.
Greets,
ba_f
Hello,
is there any milestone date for a new L4Linux?
I need a driver from Linux Kernel 3.19 (or higher).
What would be best practice for this? Porting 3.19 to l4linux isn't that trivial, is it? Or can i backport the driver to current l4linux?
thanks,
ba_f
On Tue Oct 27, 2015 at 18:24:58 +0100, ba_f wrote:
is there any milestone date for a new L4Linux?
It's getting closer but there are also plenty other things to do.
I need a driver from Linux Kernel 3.19 (or higher).
What would be best practice for this? Porting 3.19 to l4linux isn't that trivial, is it? Or can i backport the driver to current l4linux?
Depends on the driver, can be simple, could be impossible.
Adam
Am 2015-11-02 00:28, schrieb Adam Lackorzynski:
On Tue Oct 27, 2015 at 18:24:58 +0100, ba_f wrote:
is there any milestone date for a new L4Linux?
It's getting closer but there are also plenty other things to do.
I need a driver from Linux Kernel 3.19 (or higher).
What would be best practice for this? Porting 3.19 to l4linux isn't that trivial, is it? Or can i backport the driver to current l4linux?
Depends on the driver, can be simple, could be impossible.
Adam
Alrighty then,
i guess i can back-port the stuff needed.
Now, about Drivers:
I want to write a L4Linux Driver that communicates with another L4-Task (l4re-App). Can i just call all the L4-IPC stuff from within the driver? Is there something special to take care of?
Thanks,
ba_f
On Mon Nov 02, 2015 at 18:20:55 +0100, ba_f wrote:
Am 2015-11-02 00:28, schrieb Adam Lackorzynski:
On Tue Oct 27, 2015 at 18:24:58 +0100, ba_f wrote:
is there any milestone date for a new L4Linux?
It's getting closer but there are also plenty other things to do.
I need a driver from Linux Kernel 3.19 (or higher).
What would be best practice for this? Porting 3.19 to l4linux isn't that trivial, is it? Or can i backport the driver to current l4linux?
Depends on the driver, can be simple, could be impossible.
Adam
Alrighty then,
i guess i can back-port the stuff needed.
Now, about Drivers:
I want to write a L4Linux Driver that communicates with another L4-Task (l4re-App). Can i just call all the L4-IPC stuff from within the driver?
You can but...
Is there something special to take care of?
... take care that you use the L4XV_FN* wrappers and also do not block long when doing calls because that will block L4Linux's vCPU. Best use some asynchronous way of communication but at least make sure any calls are replied soonish/immediately.
Adam
Am 2015-11-03 00:08, schrieb Adam Lackorzynski:
On Mon Nov 02, 2015 at 18:20:55 +0100, ba_f wrote:
Alrighty then,
i guess i can back-port the stuff needed.
Now, about Drivers:
I want to write a L4Linux Driver that communicates with another L4-Task (l4re-App). Can i just call all the L4-IPC stuff from within the driver?
You can but...
Is there something special to take care of?
... take care that you use the L4XV_FN* wrappers and also do not block long when doing calls because that will block L4Linux's vCPU. Best use some asynchronous way of communication but at least make sure any calls are replied soonish/immediately.
Adam
Hey Adam & Folks,
unfortunately, my Server does some crypto stuff and thus is pretty slow.
Right now, my L4re-App (Client) is doing a IOStream::call() which i assume is not appropriate in L4Linux, since it's waiting long. So, L4Linux gets blocked with Istream::receive() and IRQ::receive(), right?
If this is true, i don't really see a clean way of an asynchronous communication, is there?
Thanks,
ba_f
Hi,
On Tue Nov 03, 2015 at 15:30:37 +0100, ba_f wrote:
Am 2015-11-03 00:08, schrieb Adam Lackorzynski:
On Mon Nov 02, 2015 at 18:20:55 +0100, ba_f wrote:
Alrighty then,
i guess i can back-port the stuff needed.
Now, about Drivers:
I want to write a L4Linux Driver that communicates with another L4-Task (l4re-App). Can i just call all the L4-IPC stuff from within the driver?
You can but...
Is there something special to take care of?
... take care that you use the L4XV_FN* wrappers and also do not block long when doing calls because that will block L4Linux's vCPU. Best use some asynchronous way of communication but at least make sure any calls are replied soonish/immediately.
Adam
Hey Adam & Folks,
unfortunately, my Server does some crypto stuff and thus is pretty slow.
Right now, my L4re-App (Client) is doing a IOStream::call() which i assume is not appropriate in L4Linux, since it's waiting long.
How long is long here? Couple of ms, or longer?
So, L4Linux gets blocked with Istream::receive() and IRQ::receive(), right?
Receiving from an IRQ is actually pretty asynchronous, and you should get IRQs the normal (L4)Linux way (do you?). A receive() operation is indeed blocking.
If this is true, i don't really see a clean way of an asynchronous communication, is there?
There are some options but all are more complicated than just doing l4_ipc_call. Some common and good way is to use shared memory and notifications to exchange data. When you do crypto, are you shuffling data around and maybe already have some shared memory? Alternatively, your server could have some submit+fetch interface, with polling or even a notification via an interrupt. Although this last one scores better on the hacky-scale it should be faster to implement :)
Adam
Hello,
Am 2015-11-04 00:22, schrieb Adam Lackorzynski:
Hi,
On Tue Nov 03, 2015 at 15:30:37 +0100, ba_f wrote:
Am 2015-11-03 00:08, schrieb Adam Lackorzynski:
On Mon Nov 02, 2015 at 18:20:55 +0100, ba_f wrote:
Is there something special to take care of?
... take care that you use the L4XV_FN* wrappers and also do not block long when doing calls because that will block L4Linux's vCPU. Best use some asynchronous way of communication but at least make sure any calls are replied soonish/immediately.
Can you be a bit more precise on this, please. What's the problem with L4Linux's vCPU blocking long? Does it crash, or is it just that all L4Linux threads get blocked as well?
A colleague of mine suggested that all L4Linux threads are automatically pushed into its own tasks, anyway, and such would not be affected by one blocking thread. Is this true?
unfortunately, my Server does some crypto stuff and thus is pretty slow.
How long is long here? Couple of ms, or longer?
Some operations definitely take seconds.
So, L4Linux gets blocked with Istream::receive() and IRQ::receive(), right?
Receiving from an IRQ is actually pretty asynchronous, and you should get IRQs the normal (L4)Linux way (do you?).
What do you mean by this? Using on-chip interrupt controller? Or some kind of internal microkernel IRQ?
If it is microkernel IRQ, i haven't figured out, yet, how to implement this without blocking. Is it possible? Are there examples?
A receive() operation is indeed blocking.
If this is true, i don't really see a clean way of an asynchronous communication, is there?
There are some options but all are more complicated than just doing l4_ipc_call. Some common and good way is to use shared memory and notifications to exchange data. When you do crypto, are you shuffling data around and maybe already have some shared memory? Alternatively, your server could have some submit+fetch interface, with polling or even a notification via an interrupt. Although this last one scores better on the hacky-scale it should be faster to implement :)
Yes, i already have shared memory. Until now, I push its capability over an IPC::call().
Cheers, ba_f
On Mon Nov 16, 2015 at 17:22:05 +0100, ba_f wrote:
Am 2015-11-04 00:22, schrieb Adam Lackorzynski:
Hi,
On Tue Nov 03, 2015 at 15:30:37 +0100, ba_f wrote:
Am 2015-11-03 00:08, schrieb Adam Lackorzynski:
On Mon Nov 02, 2015 at 18:20:55 +0100, ba_f wrote:
Is there something special to take care of?
... take care that you use the L4XV_FN* wrappers and also do not block long when doing calls because that will block L4Linux's vCPU. Best use some asynchronous way of communication but at least make sure any calls are replied soonish/immediately.
Can you be a bit more precise on this, please. What's the problem with L4Linux's vCPU blocking long? Does it crash, or is it just that all L4Linux threads get blocked as well?
It won't crash but VMs don't like to be stalled. A few seconds won't be a problem generally but during that time everything inside the VM is blocked. After some time (many dozen seconds) checking mechanisms will kick telling that something is wrong because no scheduling is happening.
A colleague of mine suggested that all L4Linux threads are automatically pushed into its own tasks, anyway, and such would not be affected by one blocking thread. Is this true?
No because in L4Linux there's only one thread (per host CPU) that handles everything like running the Linux kernel code as well as user process threads.
unfortunately, my Server does some crypto stuff and thus is pretty slow.
How long is long here? Couple of ms, or longer?
Some operations definitely take seconds.
So, L4Linux gets blocked with Istream::receive() and IRQ::receive(), right?
Receiving from an IRQ is actually pretty asynchronous, and you should get IRQs the normal (L4)Linux way (do you?).
What do you mean by this? Using on-chip interrupt controller? Or some kind of internal microkernel IRQ?
In L4Linux, there's a l4x_register_irq(l4_cap_idx_t) function where you get a Linux-internal irq number for an irq-cap. That returned irq number is then used for request_irq (and friends) to implement a common interrupt handler in a Linux driver. There are a couple of users of that in L4Linux.
If it is microkernel IRQ, i haven't figured out, yet, how to implement this without blocking. Is it possible? Are there examples?
A receive() operation is indeed blocking.
If this is true, i don't really see a clean way of an asynchronous communication, is there?
There are some options but all are more complicated than just doing l4_ipc_call. Some common and good way is to use shared memory and notifications to exchange data. When you do crypto, are you shuffling data around and maybe already have some shared memory? Alternatively, your server could have some submit+fetch interface, with polling or even a notification via an interrupt. Although this last one scores better on the hacky-scale it should be faster to implement :)
Yes, i already have shared memory. Until now, I push its capability over an IPC::call().
That's ok.
Adam
hello Adam, I also have a question about the Interrupt mechanism in l4linux. I want to move some interrupts to specified cpu core. When I try to write to "/proc/irq/*/smp_affinity" with cpu bitmask, it will call the function l4lx_irq_dev_set_affinity(), which attachs the irq to corresponding vcpu thread. After that, I find the irq is still staying on previous cpu core through linux proc system. So I doubt whether linux proc filesystem's view is synchronized with the interrupt settings of the L4 kernel, or it can not be achieved in l4linux? (I use genode for the runtime environment of fiasco.oc) Thank you!
At 2015-11-20 07:20:56, "Adam Lackorzynski" adam@os.inf.tu-dresden.de wrote:
On Mon Nov 16, 2015 at 17:22:05 +0100, ba_f wrote:
Am 2015-11-04 00:22, schrieb Adam Lackorzynski:
Hi,
On Tue Nov 03, 2015 at 15:30:37 +0100, ba_f wrote:
Am 2015-11-03 00:08, schrieb Adam Lackorzynski:
On Mon Nov 02, 2015 at 18:20:55 +0100, ba_f wrote:
Is there something special to take care of?
... take care that you use the L4XV_FN* wrappers and also do not block long when doing calls because that will block L4Linux's vCPU. Best use some asynchronous way of communication but at least make sure any calls are replied soonish/immediately.
Can you be a bit more precise on this, please. What's the problem with L4Linux's vCPU blocking long? Does it crash, or is it just that all L4Linux threads get blocked as well?
It won't crash but VMs don't like to be stalled. A few seconds won't be a problem generally but during that time everything inside the VM is blocked. After some time (many dozen seconds) checking mechanisms will kick telling that something is wrong because no scheduling is happening.
A colleague of mine suggested that all L4Linux threads are automatically pushed into its own tasks, anyway, and such would not be affected by one blocking thread. Is this true?
No because in L4Linux there's only one thread (per host CPU) that handles everything like running the Linux kernel code as well as user process threads.
unfortunately, my Server does some crypto stuff and thus is pretty slow.
How long is long here? Couple of ms, or longer?
Some operations definitely take seconds.
So, L4Linux gets blocked with Istream::receive() and IRQ::receive(), right?
Receiving from an IRQ is actually pretty asynchronous, and you should get IRQs the normal (L4)Linux way (do you?).
What do you mean by this? Using on-chip interrupt controller? Or some kind of internal microkernel IRQ?
In L4Linux, there's a l4x_register_irq(l4_cap_idx_t) function where you get a Linux-internal irq number for an irq-cap. That returned irq number is then used for request_irq (and friends) to implement a common interrupt handler in a Linux driver. There are a couple of users of that in L4Linux.
If it is microkernel IRQ, i haven't figured out, yet, how to implement this without blocking. Is it possible? Are there examples?
A receive() operation is indeed blocking.
If this is true, i don't really see a clean way of an asynchronous communication, is there?
There are some options but all are more complicated than just doing l4_ipc_call. Some common and good way is to use shared memory and notifications to exchange data. When you do crypto, are you shuffling data around and maybe already have some shared memory? Alternatively, your server could have some submit+fetch interface, with polling or even a notification via an interrupt. Although this last one scores better on the hacky-scale it should be faster to implement :)
Yes, i already have shared memory. Until now, I push its capability over an IPC::call().
That's ok.
Adam
Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Hi,
On Sun Nov 22, 2015 at 22:10:33 +0800, li94575 wrote:
hello Adam, I also have a question about the Interrupt mechanism in l4linux. I want to move some interrupts to specified cpu core. When I try to write to "/proc/irq/*/smp_affinity" with cpu bitmask, it will call the function l4lx_irq_dev_set_affinity(), which attachs the irq to corresponding vcpu thread. After that, I find the irq is still staying on previous cpu core through linux proc system. So I doubt whether linux proc filesystem's view is synchronized with the interrupt settings of the L4 kernel, or it can not be achieved in l4linux? (I use genode for the runtime environment of fiasco.oc)
The l4lx_irq_dev_set_affinity function is called by Linux interrupt handling code, i.e. I think all the book keeping shall be done by the Linux code, including the output of /proc/interrupts. You should check in the jdb to which thread the interrupt is attached. You can see this in the object list, use shift-Q to see it. With CONFIG_L4_DEBUG_REGISTER_NAMES=y enabled in L4Linux, you'll have proper descriptions of the objects, so you'll find the interrupt you're looking for: irqXX with XX being the same number as in /proc/interrupts. Then, look for the T= value of that particular interrupt, it points to the thread the interrupt is attached to. Pressing TAB brings you to the thread in the list. Is it the right one?
Adam
Hi,
are there any Makefiles for building a L4Linux Kernel Module? Or can i just cross-compile for my ARCH, although the driver uses L4-IPC?
Thanks, ba_f
On Mon Jan 04, 2016 at 16:08:55 +0100, ba_f wrote:
are there any Makefiles for building a L4Linux Kernel Module? Or can i just cross-compile for my ARCH, although the driver uses L4-IPC?
There's no difference, so the standard way of building a module should just work (make -C ... M=...).
Adam
Am 2016-01-04 23:37, schrieb Adam Lackorzynski:
On Mon Jan 04, 2016 at 16:08:55 +0100, ba_f wrote:
are there any Makefiles for building a L4Linux Kernel Module? Or can i just cross-compile for my ARCH, although the driver uses L4-IPC?
There's no difference, so the standard way of building a module should just work (make -C ... M=...).
Adam
Hi there,
running in an Error.
$ make -C obj/l4linux/arm-mp M=$PWD ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- modules
make: Entering directory 'obj/l4linux/arm-mp' CC [M] hello.o In file included from src/l4linux/include/asm-generic/int-ll64.h:10:0, from src/l4linux/arch/arm/include/asm/types.h:4, from src/l4linux/include/uapi/linux/types.h:4, from src/l4linux/include/linux/types.h:5, from src/l4linux/include/linux/list.h:4, from src/l4linux/include/linux/module.h:9, from hello.c:11: src/l4linux/include/uapi/asm-generic/int-ll64.h:11:29: fatal error: asm/bitsperlong.h: No such file or directory #include <asm/bitsperlong.h>
The missing header has been generated in 'obj/l4linux/arm-mp/arch/l4/include/generated/asm/bitsperlong.h' but isn't found.
Can i set an include path for Kbuild? Or does this file has to be copied to a proper location?
Thanks,
ba_f
On Wed Jan 06, 2016 at 16:59:11 +0100, ba_f wrote:
Am 2016-01-04 23:37, schrieb Adam Lackorzynski:
On Mon Jan 04, 2016 at 16:08:55 +0100, ba_f wrote:
are there any Makefiles for building a L4Linux Kernel Module? Or can i just cross-compile for my ARCH, although the driver uses L4-IPC?
There's no difference, so the standard way of building a module should just work (make -C ... M=...).
Adam
Hi there,
running in an Error.
$ make -C obj/l4linux/arm-mp M=$PWD ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- modules
make: Entering directory 'obj/l4linux/arm-mp' CC [M] hello.o In file included from src/l4linux/include/asm-generic/int-ll64.h:10:0, from src/l4linux/arch/arm/include/asm/types.h:4, from src/l4linux/include/uapi/linux/types.h:4, from src/l4linux/include/linux/types.h:5, from src/l4linux/include/linux/list.h:4, from src/l4linux/include/linux/module.h:9, from hello.c:11: src/l4linux/include/uapi/asm-generic/int-ll64.h:11:29: fatal error: asm/bitsperlong.h: No such file or directory #include <asm/bitsperlong.h>
The missing header has been generated in 'obj/l4linux/arm-mp/arch/l4/include/generated/asm/bitsperlong.h' but isn't found.
Can i set an include path for Kbuild? Or does this file has to be copied to a proper location?
The ARCH=arm is wrong. L4ARCH=arm is better but you can also just omit it.
Adam
All right, thanks Adam.
Unfortunately, there's still a problem.
I managed to build and run(!) a simple 'hello.ko'. But, i fail with more complex modules. Building works, but when loading my module with 'insmod' i get faults: Page fault (non-resolved): pfa=9 pc=1011cec Non-resolvable page fault at 9, ip 1011cec.
I'm sure the fault is not caused by my code because there is the same issue with legacy drivers. But, i guess something is wrong with the build process. e.g. let's take CONFIG_TCG_TPM in 'src/l4linux/driver/char/tpm'. This one does build and run successfully when setting CONFIG_TCG_TPM=m in 'obj/l4linux/.config' and than building complete l4linux. But it does not build when going to 'src/l4linux/driver/char/tpm' and 'make -C $L4re/obj/l4linux/arm-mp M=$PWD CROSS_COMPILE=arm-linux-gnueabihf- L4ARCH=arm CONFIG_TCG_TPM=m modules V=1'.
It gets me this output:
make: Entering directory '/home/ba_f/l4re-snapshot-2015123115/obj/l4linux/arm-mp' make -C /home/ba_f/l4re-snapshot-2015123115/src/l4linux O=/home/ba_f/l4re-snapshot-2015123115/obj/l4linux/arm-mp/. modules make -C /home/ba_f/l4re-snapshot-2015123115/obj/l4linux/arm-mp KBUILD_SRC=skins/classic/home/ba_f/l4re-snapshot-2015123115/src/l4linux \ -f /home/ba_f/l4re-snapshot-2015123115/src/l4linux/Makefile modules test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \ echo >&2; \ echo >&2 " ERROR: Kernel configuration is invalid."; \ echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\ echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it."; \ echo >&2 ; \ /bin/false) mkdir -p /home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm/.tmp_versions ; rm -f /home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm/.tmp_versions/* make -f /home/ba_f/l4re-snapshot-2015123115/src/l4linux/scripts/Makefile.build obj=/home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm arm-linux-gnueabihf-gcc -Wp,-MD,/home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm/.tpm-interface.o.d -nostdinc -isystem /opt/gcc-linaro-arm-linux-gnueabihf-4.8-2014.03_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/include -I/home/ba_f/l4re-snapshot-2015123115/src/l4linux/arch/l4/include -Iarch/l4/include/generated/uapi -Iarch/l4/include/generated -I/home/ba_f/l4re-snapshot-2015123115/src/l4linux/include -Iinclude -I/home/ba_f/l4re-snapshot-2015123115/src/l4linux/arch/l4/include/uapi -Iarch/l4/include/generated/uapi -I/home/ba_f/l4re-snapshot-2015123115/src/l4linux/include/uapi -Iinclude/generated/uapi -include /home/ba_f/l4re-snapshot-2015123115/src/l4linux/include/linux/kconfig.h -I/home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm -D__KERNEL__ -I/home/ba_f/l4re-snapshot-2015123115/src/l4linux/arch/l4/include/asm/l4-arch -Iarch/l4/include/asm/l4-arch -I/home/ba_f/l4re-snapshot-2015123115/src/l4linux/arch/arm/include/generated -Iarch/arm/include/generated -I/home/ba_f/l4re-snapshot-2015123115/src/l4linux/arch/arm/include/generated/uapi -Iarch/arm/include/generated/uapi -I/home/ba_f/l4re-snapshot-2015123115/src/l4linux/arch/l4/include/asm/mach-arm/generic
-I/home/ba_f/l4re-snapshot-2015123115/src/l4linux/arch/l4/include/asm/plat-arm/generic -I/home/ba_f/l4re-snapshot-2015123115/src/l4linux/arch/arm/include -I/home/ba_f/l4re-snapshot-2015123115/src/l4linux/arch/l4/include/asm/arch-arm -Iarch/l4/include/asm/arch-arm -I/home/ba_f/l4re-snapshot-2015123115/src/l4linux/arch/l4/include/asm/orig-arch -Iarch/l4/include/asm/orig-arch -I/home/ba_f/l4re-snapshot-2015123115/src/l4linux/arch/l4/include -Iarch/l4/include -I/home/ba_f/l4re-snapshot-2015123115/src/l4linux/arch/arm/include/uapi -I/home/ba_f/l4re-snapshot-2015123115/obj/l4/arm-ca/include/arm/l4f -I/home/ba_f/l4re-snapshot-2015123115/obj/l4/arm-ca/include/arm -I/home/ba_f/l4re-snapshot-2015123115/obj/l4/arm-ca/include/l4f -I/home/ba_f/l4re-snapshot-2015123115/obj/l4/arm-ca/include -I/home/ba_f/l4re-snapshot-2015123115/obj/l4/arm-ca/include/contrib/libstdc++-v3
-I/home/ba_f/l4re-snapshot-2015123115/obj/l4/arm-ca/include/contrib/libio-io -DL4API_l4f -DL4SYS_USE_UTCB_WRAP=1 -DTEXT_OFFSET=0x02000000 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -pipe -msoft-float -DARCH_arm -fno-ipa-sra -mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp -funwind-tables -marm -D__LINUX_ARM_ARCH__=6 -march=armv6k -mtune=arm1136j-s -msoft-float -Uarm -fno-dwarf2-cfi-asm -fno-delete-null-pointer-checks -O2 --param=allow-store-data-races=0 -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -fno-var-tracking-assignments -g -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -DCC_HAVE_ASM_GOTO -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(tpm_interface)" -D"KBUILD_MODNAME=KBUILD_STR(tpm)" -c -o /home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm/tpm-interface.o /home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm/tpm-interface.c /home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm/tpm-interface.c:679:5: error: redefinition of ‘tpm_pcr_read’ int tpm_pcr_read(u32 chip_num, int pcr_idx, u8 *res_buf) ^ In file included from /home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm/tpm.h:28:0, from /home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm/tpm-interface.c:33: /home/ba_f/l4re-snapshot-2015123115/src/l4linux/include/linux/tpm.h:54:19: note: previous definition of ‘tpm_pcr_read’ was here static inline int tpm_pcr_read(u32 chip_num, int pcr_idx, u8 *res_buf) { ^ /home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm/tpm-interface.c:714:5: error: redefinition of ‘tpm_pcr_extend’ int tpm_pcr_extend(u32 chip_num, int pcr_idx, const u8 *hash) ^ In file included from /home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm/tpm.h:28:0, from /home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm/tpm-interface.c:33: /home/ba_f/l4re-snapshot-2015123115/src/l4linux/include/linux/tpm.h:57:19: note: previous definition of ‘tpm_pcr_extend’ was here static inline int tpm_pcr_extend(u32 chip_num, int pcr_idx, const u8 *hash) { ^ /home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm/tpm-interface.c:804:5: error: redefinition of ‘tpm_send’ int tpm_send(u32 chip_num, void *cmd, size_t buflen) ^ In file included from /home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm/tpm.h:28:0, from /home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm/tpm-interface.c:33: /home/ba_f/l4re-snapshot-2015123115/src/l4linux/include/linux/tpm.h:60:19: note: previous definition of ‘tpm_send’ was here static inline int tpm_send(u32 chip_num, void *cmd, size_t buflen) { ^ /home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm/tpm-interface.c:980:5: error: redefinition of ‘tpm_get_random’ int tpm_get_random(u32 chip_num, u8 *out, size_t max) ^ In file included from /home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm/tpm.h:28:0, from /home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm/tpm-interface.c:33: /home/ba_f/l4re-snapshot-2015123115/src/l4linux/include/linux/tpm.h:63:19: note: previous definition of ‘tpm_get_random’ was here static inline int tpm_get_random(u32 chip_num, u8 *data, size_t max) { ^ /home/ba_f/l4re-snapshot-2015123115/src/l4linux/scripts/Makefile.build:258: recipe for target '/home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm/tpm-interface.o' failed make[3]: *** [/home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm/tpm-interface.o] Error 1 /home/ba_f/l4re-snapshot-2015123115/src/l4linux/Makefile:1380: recipe for target '_module_/home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm' failed make[2]: *** [_module_/home/ba_f/l4re-snapshot-2015123115/src/l4linux/drivers/char/tpm] Error 2 Makefile:146: recipe for target 'sub-make' failed make[1]: *** [sub-make] Error 2 Makefile:24: recipe for target '__sub-make' failed make: *** [__sub-make] Error 2 make: Leaving directory '/home/ba_f/l4re-snapshot-2015123115/obj/l4linux/arm-mp'
Sorry, for all the shit. Hopefully, you see the problem quick. Guess your more familiar with the build process.
Greets, ba_f
Am 2016-01-06 23:10, schrieb Adam Lackorzynski:
On Wed Jan 06, 2016 at 16:59:11 +0100, ba_f wrote:
Am 2016-01-04 23:37, schrieb Adam Lackorzynski:
On Mon Jan 04, 2016 at 16:08:55 +0100, ba_f wrote:
are there any Makefiles for building a L4Linux Kernel Module? Or can i just cross-compile for my ARCH, although the driver uses L4-IPC?
There's no difference, so the standard way of building a module should just work (make -C ... M=...).
Adam
Hi there,
running in an Error.
$ make -C obj/l4linux/arm-mp M=$PWD ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- modules
make: Entering directory 'obj/l4linux/arm-mp' CC [M] hello.o In file included from src/l4linux/include/asm-generic/int-ll64.h:10:0, from src/l4linux/arch/arm/include/asm/types.h:4, from src/l4linux/include/uapi/linux/types.h:4, from src/l4linux/include/linux/types.h:5, from src/l4linux/include/linux/list.h:4, from src/l4linux/include/linux/module.h:9, from hello.c:11: src/l4linux/include/uapi/asm-generic/int-ll64.h:11:29: fatal error: asm/bitsperlong.h: No such file or directory #include <asm/bitsperlong.h>
The missing header has been generated in 'obj/l4linux/arm-mp/arch/l4/include/generated/asm/bitsperlong.h' but isn't found.
Can i set an include path for Kbuild? Or does this file has to be copied to a proper location?
The ARCH=arm is wrong. L4ARCH=arm is better but you can also just omit it.
Adam
On Mon Jan 11, 2016 at 22:44:54 +0100, ba_f wrote:
Unfortunately, there's still a problem.
I managed to build and run(!) a simple 'hello.ko'. But, i fail with more complex modules. Building works, but when loading my module with 'insmod' i get faults: Page fault (non-resolved): pfa=9 pc=1011cec Non-resolvable page fault at 9, ip 1011cec.
Hard to say something from this output. Would need more info.
I'm sure the fault is not caused by my code because there is the same issue with legacy drivers.
Which ones?
But, i guess something is wrong with the build process. e.g. let's take CONFIG_TCG_TPM in 'src/l4linux/driver/char/tpm'. This one does build and run successfully when setting CONFIG_TCG_TPM=m in 'obj/l4linux/.config' and than building complete l4linux. But it does not build when going to 'src/l4linux/driver/char/tpm' and 'make -C $L4re/obj/l4linux/arm-mp M=$PWD CROSS_COMPILE=arm-linux-gnueabihf- L4ARCH=arm CONFIG_TCG_TPM=m modules V=1'.
That doesn't work even with a standard Linux tree, in the same way. I think you cannot just put CONFIG_FOO=m on the command line, I guess the redefinition errors come from that. For CONFIG_TCG_TPM you probably need to configure it into .config which will also enable all the requirements needed by CONFIG_TCG_TPM.
Adam
Hello Hackers,
I have a custom board with Zynq processor. Unfortunately, it uses UART0 which produces only garbage. (A lot of white spaces or tabs and single freak characters, if this is any help.)
My ZedBoard uses UART1 and Fiasco runs successfully on it.
I'm sure Zynq is proper configured on the new board, because the U-Boot output is displayed correctly. But the Fiasco output then looks like a wrong baud-rate, or something. With both boards i open console with: picocom /dev/ttyACM0 -b 115200
As far as i can see, Zynq TRM doesn't specify any difference between UART0 & UART1, beside the addresses. But, this one is set right in Fiasco.
OnetSwitch use UART0, and its U-Boot works great. https://github.com/MeshSr/u-boot-meshsr.git
At least i don't see any difference between ZedBoard U-Boot and Onetswitch U-Boot, except for the Uart address.
Thanks, ba_f
Am 14.10.2015 um 00:39 schrieb ba_f:
Hello Hackers,
I have a custom board with Zynq processor. Unfortunately, it uses UART0 which produces only garbage. (A lot of white spaces or tabs and single freak characters, if this is any help.)
My ZedBoard uses UART1 and Fiasco runs successfully on it.
I'm sure Zynq is proper configured on the new board, because the U-Boot output is displayed correctly. But the Fiasco output then looks like a wrong baud-rate, or something. With both boards i open console with: picocom /dev/ttyACM0 -b 115200
Looks like a wrong calculated divisor in the baudrate divider register. You should check the actual UART clock source and change the value in uart_cadence.cc accordingly: _regs-write<unsigned>(BAUDGEN, 50000000 / r / (div + 1));
Martin
Am 2015-10-14 16:27, schrieb Martin Schröder:
Am 14.10.2015 um 00:39 schrieb ba_f:
Hello Hackers,
I have a custom board with Zynq processor. Unfortunately, it uses UART0 which produces only garbage. (A lot of white spaces or tabs and single freak characters, if this is any help.)
My ZedBoard uses UART1 and Fiasco runs successfully on it.
I'm sure Zynq is proper configured on the new board, because the U-Boot output is displayed correctly. But the Fiasco output then looks like a wrong baud-rate, or something. With both boards i open console with: picocom /dev/ttyACM0 -b 115200
Looks like a wrong calculated divisor in the baudrate divider register. You should check the actual UART clock source and change the value in uart_cadence.cc accordingly: _regs-write<unsigned>(BAUDGEN, 50000000 / r / (div + 1));
Martin
Yes, u're right. The clock was changed in the new project.
Thank You,
ba_f
l4-hackers@os.inf.tu-dresden.de
-
Adam Lackorzynski -
ba_f -
Gernot Heiser -
li94575 -
Martin Schröder -
Matthias Lange