Re: 23.10.1 amd64 l4linux doesn't build

[Adam Lackorzynski]

Hi Richard,

Error seems still to be the same I'm afraid although no complaint for
missing header (so it's there), so something's different.

Debian installer is here :)
http://ftp.de.debian.org/debian-cd/current/amd64/iso-cd/debian-12.5.0-amd64-netinst.iso


Thanks, Adam

On Thu Apr 11, 2024 at 22:52:01 +, Richard Clark wrote:
> Adam,
> 
> What's the recommended Debian distro to build on?
> Could you point me at an iso image so I can spin up a VM, please?
> 
> 
> Thanks!
> 
> Richard
> 
> ____
> From: Adam Lackorzynski 
> Sent: Thursday, April 11, 2024 3:55 PM
> To: Richard Clark ; 
> l4-hackers@os.inf.tu-dresden.de 
> Subject: Re: 23.10.1 amd64 l4linux doesn't build
> 
> [EXTERNAL]
> 
> Hi Richard,
> 
> On Thu Apr 11, 2024 at 17:51:40 +, Richard Clark wrote:
> > Adam,
> >
> > Thank you for the response!
> >
> > I'm building on a fresh install of linux mint cinnamon.
> > That should be irrelevant as the build should be using its own include 
> > files, not that of the host.
> 
> Ah! Building Linux requires to have libelf-dev installed nowadays, for
> building the objtool tool.
> 
> > Yes, everyone and their sister has a virtual machine nowadays. These are of 
> > limited use, however.
> > There are instances where the user-space runtime directly on top of the l4 
> > kernel (native l4 app) is extremely useful.
> 
> Absolutely.
> 
> > There are also instances where it is helpful to have a full unikernel to 
> > run paravirtualized directly on top of the l4 kernel.
> 
> Yep.
> 
> > And of course, completely untrusted code which is expected to be attacked 
> > and owned gets
> > sandboxed into its own virtual space. I have use for all three cases.
> 
> Sure.
> 
> All that is possible of course. I was just referring to the different
> virtualization options and did not want to exclude the other options
> besides virtualization.
> 
> > I'm (was?) assuming that running a multicore AMD64 linux in a vm is 
> > functional, and am exploring the
> > other two options.
> 
> Good assumption :)
> 
> > I wanted to check the paravirtualzed version first since there seems to be 
> > some
> > instructions for it. It comes packaged alongside the snapshots.
> 
> Yep. The snapshot also has some targets for running uvmm VMs.
> Please check the screencasts at 
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl4re.org%2Fcast-multi-vm-qemu.html=05%7C02%7Crichard.clark%40coheretechnology.com%7C1cff7939aaf24ddb460108dc5a615601%7Ca6ccb3020300496187c25d60f8287e77%7C0%7C0%7C638484621329126751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=umCmEgBwuamLD98dCEnJxPErwVvTV2v2ZqHsWmdV4Bo%3D=0<https://l4re.org/cast-multi-vm-qemu.html>
> 
> 
> Adam
> 
> >
> > Here is about where it seems to go astray:
> >
> > ===
> >   For quick build instructions, please visit:
> > 
> > https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.tudos.org%2FQuickstart=05%7C02%7Crichard.clark%40coheretechnology.com%7C1cff7939aaf24ddb460108dc5a615601%7Ca6ccb3020300496187c25d60f8287e77%7C0%7C0%7C638484621329136974%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=kFjA59XmzO5KfpucO94eHep5BelvFg0PDRD1w2rt9bg%3D=0<http://wiki.tudos.org/Quickstart>
> > 
> > https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fl4linux.org%2Fbuild.shtml=05%7C02%7Crichard.clark%40coheretechnology.com%7C1cff7939aaf24ddb460108dc5a615601%7Ca6ccb3020300496187c25d60f8287e77%7C0%7C0%7C638484621329143922%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=AE%2BAq8rj7jr2zh3sCr1BDcscqJ0C1Fk6zako621JKcA%3D=0<http://l4linux.org/build.shtml>
> > ===
> >   DESCEND objtool
> > :1:10: fatal error: libelf.h: No such file or directory
> > compilation terminated.
> >   CALL
> > /home/webadmin/Fiasco/l4re-snapshot-23.10.1/src/l4linux/scripts/checksyscalls.sh
> >   INSTALL libsubcmd_headers
> >   HOSTLD  scripts/mod/modpost
> >   CC  kernel/bounds.s
> >   CHKSHA1 
> > /home/webadmin/Fiasco/l4re-snapshot-23.10.1/src/l4linux/include/linux/atomic/atomic-arch-fallback.h
> >   UPD include/generated/timeconst.h
> >   CHKSHA1 
> > /home/webadmin/Fiasco/l4re-snapshot-23.10.1/src/l4linux/include/linux/atomic/atomic-instrumented.h
> >   CHKSHA1 
> > /home/webadmin/Fiasco/l4re-snapshot-23.10.1/src/l4linux/include/linux/atomic/a

Re: 23.10.1 amd64 l4linux doesn't build

[Adam Lackorzynski]

Hi Richard,

On Thu Apr 11, 2024 at 17:51:40 +, Richard Clark wrote:
> Adam,
> 
> Thank you for the response!
> 
> I'm building on a fresh install of linux mint cinnamon.
> That should be irrelevant as the build should be using its own include files, 
> not that of the host.

Ah! Building Linux requires to have libelf-dev installed nowadays, for
building the objtool tool.

> Yes, everyone and their sister has a virtual machine nowadays. These are of 
> limited use, however.
> There are instances where the user-space runtime directly on top of the l4 
> kernel (native l4 app) is extremely useful.

Absolutely.

> There are also instances where it is helpful to have a full unikernel to run 
> paravirtualized directly on top of the l4 kernel.

Yep.

> And of course, completely untrusted code which is expected to be attacked and 
> owned gets
> sandboxed into its own virtual space. I have use for all three cases.

Sure.

All that is possible of course. I was just referring to the different
virtualization options and did not want to exclude the other options
besides virtualization.

> I'm (was?) assuming that running a multicore AMD64 linux in a vm is 
> functional, and am exploring the
> other two options.

Good assumption :)

> I wanted to check the paravirtualzed version first since there seems to be 
> some
> instructions for it. It comes packaged alongside the snapshots.

Yep. The snapshot also has some targets for running uvmm VMs.
Please check the screencasts at https://l4re.org/cast-multi-vm-qemu.html


Adam

> 
> Here is about where it seems to go astray:
> 
> ===
>   For quick build instructions, please visit:
> http://wiki.tudos.org/Quickstart
> http://l4linux.org/build.shtml
> ===
>   DESCEND objtool
> :1:10: fatal error: libelf.h: No such file or directory
> compilation terminated.
>   CALL
> /home/webadmin/Fiasco/l4re-snapshot-23.10.1/src/l4linux/scripts/checksyscalls.sh
>   INSTALL libsubcmd_headers
>   HOSTLD  scripts/mod/modpost
>   CC  kernel/bounds.s
>   CHKSHA1 
> /home/webadmin/Fiasco/l4re-snapshot-23.10.1/src/l4linux/include/linux/atomic/atomic-arch-fallback.h
>   UPD include/generated/timeconst.h
>   CHKSHA1 
> /home/webadmin/Fiasco/l4re-snapshot-23.10.1/src/l4linux/include/linux/atomic/atomic-instrumented.h
>   CHKSHA1 
> /home/webadmin/Fiasco/l4re-snapshot-23.10.1/src/l4linux/include/linux/atomic/atomic-long.h
>   CC  
> /home/webadmin/Fiasco/l4re-snapshot-23.10.1/obj/l4linux/amd64/tools/objtool/arch/x86/special.o
>   MKDIR   
> /home/webadmin/Fiasco/l4re-snapshot-23.10.1/obj/l4linux/amd64/tools/objtool/arch/x86/lib/
>   CC  
> /home/webadmin/Fiasco/l4re-snapshot-23.10.1/obj/l4linux/amd64/tools/objtool/weak.o
>   GEN 
> /home/webadmin/Fiasco/l4re-snapshot-23.10.1/obj/l4linux/amd64/tools/objtool/arch/x86/lib/inat-tables.c
> In file included from 
> /home/webadmin/Fiasco/l4re-snapshot-23.10.1/src/l4linux/tools/objtool/include/objtool/objtool.h:13,
>  from 
> /home/webadmin/Fiasco/l4re-snapshot-23.10.1/src/l4linux/tools/objtool/include/objtool/arch.h:11,
>  from 
> /home/webadmin/Fiasco/l4re-snapshot-23.10.1/src/l4linux/tools/objtool/include/objtool/check.h:11,
>  from 
> /home/webadmin/Fiasco/l4re-snapshot-23.10.1/src/l4linux/tools/objtool/include/objtool/special.h:10,
>  from arch/x86/special.c:4:
> /home/webadmin/Fiasco/l4re-snapshot-23.10.1/src/l4linux/tools/objtool/include/objtool/elf.h:37:9:
>  error: unknown type name ‘GElf_Shdr’
>37 | GElf_Shdr sh;
>   | ^
> /home/webadmin/Fiasco/l4re-snapshot-23.10.1/src/l4linux/tools/objtool/include/objtool/elf.h:42:9:
>  error: unknown type name ‘Elf_Data’
>42 | Elf_Data *data;
>   | ^~~~
> /home/webadmin/Fiasco/l4re-snapshot-23.10.1/src/l4linux/tools/objtool/include/objtool/elf.h:54:9:
>  error: unknown type name ‘GElf_Sym’
>54 | GElf_Sym sym;
>   | ^~~~
> /home/webadmin/Fiasco/l4re-snapshot-23.10.1/src/l4linux/tools/objtool/include/objtool/elf.h:82:9:
>  error: unknown type name ‘Elf’
>82 | Elf *elf;
>   | ^~~
> 
> 
> Thanks!
> 
> Richard
> 
> 
> 
> 
> 
> 
> From: Adam Lackorzynski 
> Sent: Thursday, April 11, 2024 1:18 PM
> To: Richard Clark ; 
> l4-hackers@os.inf.tu-dresden.de 
> Subject: Re: 23.10.1 amd64 l4linux doesn't build
> 
> [EXTERNAL]
> 
> Hi Richard,
> 
> which Linux variant are you doing this on, out of curiosity? This is
> typically assembled on stable Debian, so it's good to know the
> difference.
>

Re: 23.10.1 amd64 l4linux doesn't build

[Adam Lackorzynski]

Hi Richard,

which Linux variant are you doing this on, out of curiosity? This is
typically assembled on stable Debian, so it's good to know the
difference.

On another note, regarding virtualization, please focus on uvmm instead
of L4Linux. L4Linux is pure paravirtualization while on today's systems
we obviosly want to exploit the CPUs virtualization support capabilities
which uvmm does nicely.


Best regards, Adam

On Thu Apr 11, 2024 at 14:47:55 +, Richard Clark wrote:
> Hi!
> 
> I'm doing microkernel evaluations for a US gov't contract to find a nice 
> shiny new replacement for
> the dismal little l4 microkernel they've been using and failing with... 
> Fiasco/L4/L4linux seems to
> be a wonderfully full-featured software platform that easily fits the bill. 
> Separation/Capability
> microkernel, fully developed user space, l4-native linux, and even a vmm that 
> runs a sandboxed linux.
> 
> Latest build with snapshot 23.10.1 and l4linux 23.10.1 seems the amd64 
> l4linux is broken with
> issues in libelf.h, gelf.h, and elf.h.  32bit build seems to build ok.
> 
> Still trying to get something up and running. I'll try 32-bit with qemu for 
> now. I do need 64-bit to
> compile and run, so I would appreciate any info on how to fix the build 
> issues.

___
l4-hackers mailing list -- l4-hackers@os.inf.tu-dresden.de
To unsubscribe send an email to l4-hackers-le...@os.inf.tu-dresden.de

Re: L4Re: stack allocation of moderately large arrays

[Adam Lackorzynski]

Hi Paul,

stack size is set to 16 pages per default (64bit archs).
One can change the stack size by placing the following statement in a
program:

#include 

L4RE_ELF_AUX_ELEM_T(l4re_elf_aux_mword_t, _stack_size,
L4RE_ELF_AUX_T_STACK_SIZE, 0x8);


Adam

On Mon Nov 13, 2023 at 18:04:06 +0100, Paul Boddie wrote:
> Hello,
> 
> Having seen a problem recur in programs running in L4Re just now involving 
> arrays of a relatively large size allocated statically in functions - about 
> 10 bytes or so - I was wondering if there are any implicit limitations 
> with this form of allocation in L4Re. Is it possible that programs have a 
> limited stack size and that the stack does not expand?
> 
> Here is an example of the kind of code that causes an unhandled exception:
> 
> uint32_t Spi_gpio::send_units(uint32_t bytes, const uint8_t data[],
>   uint8_t unit_size, uint8_t char_size)
> { 
>   uint32_t chars = bytes / unit_size;
>   int dc[chars];
> 
> And the exception looks like this:
> 
> Unhandled exception: PC=0x1019ca8 PFA=0xfffd075a LdrFlgs=0x0
> 
> The actual cause of the exception is an access to an element in the dc array.
> 
> When I eventually get back to my own experiments with initiating programs in 
> L4Re - not involved with the problem reported here - I intend to look more 
> closely at program stack allocation and expansion strategies, so I suppose 
> this is an appropriate prelude to such work.
> 
> Thanks for any guidance that might be offered, as always!
> 
> Paul

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: L4Re uvmm guest OS

[Adam Lackorzynski]

Hi,

On Tue Aug 22, 2023 at 12:39:23 +0200, Radu Aron wrote:
> Is it possible to have a Windows guest OS running on top of L4Re? If so,
> could you provide some insight into how that could work? It seems like uvmm
> doesn't allow booting from an ISO image, or am I missing something?

As of today this is not possible, aka, nobody has filled in the missing
bits and pieces. Maybe one day...



Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: ARM TrustZone with UVMM

[Adam Lackorzynski]

Hi Michael,

On Mon Jun 05, 2023 at 18:39:25 +0200, Michael Willig wrote:
> I would like to try Fiasco/L4Re for a Mixed-Critical Xilinx UltraScale+
> FPGA-MPSoC (the hardware accelerators on the FPGA should be
> virtualized/isolated for mixed-critical applications) Is there somewhere an
> example (or at least starting point) of an ARM Trustzone configuration of a
> Normal World VM and Secure World VM (with UVMM/Fiasco as hypervisor that
> also takes care of the ARM Trustzone configuration)?

This SoC does not support running VMs on the TZ side. What about just
ignoring the TZ side? Is there any benefit separating workloads between
normal and TZ side?


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: L4Re: Boot module copying and the MIPS Creator CI20

[Adam Lackorzynski]

Hi Paul,

On Sat May 20, 2023 at 00:35:37 +0200, Paul Boddie wrote:
> On Friday, 19 May 2023 19:03:36 CEST Paul Boddie wrote:
> > 
> > I suppose, then, the conclusion is that the CI20 UART code got inadvertently
> > broken when that functionality was reworked. Whether the UART
> > initialisation should be suppressed or whether the UART can be cleanly
> > reinitialised is something to investigate further, I imagine.

Thanks for digging through this.

> Of course I have to follow up to this! The fixes required here involve 
> adjusting the src/kern/mips/bsp/ci20/Modules file to use the following 
> definitions:
> 
> OBJECTS_LIBUART   += uart_16550.o
> CXXFLAGS_uart-libuart += $(call LIBUART_UART, 16550) \
>  -DUART_16550_INIT_FCR=0x10
> 
> If the INIT_FCR setting is not used, the initialisation code clears the 
> trigger level field (defined in the 16550 data sheet) and also the UART 
> enable 
> field (defined in the JZ4780 programming manual, reserved in the 16550 data 
> sheet), disabling the UART.
> 
> For the above value, I merely reproduced the UART enable bit (0x10) set by 
> the 
> Uart_16550 initialisation in the bootstrap code. The trigger level field can 
> be read, yielding a value of 0xc0 which corresponds to (3 << 6) or a level of 
> 60 according to the JZ4780 manual, but the field is documented as being write-
> only, so maybe reading it doesn't make sense. Allowing that field to be 
> cleared does not appear to be harmful.

Thanks, we've changed this.
 
> (I see that the drivers-frst code strongly resembles the library code in the 
> kernel but is slightly older, and I wonder about whether these things could 
> eventually be integrated in a sensible way.)

Frank did work in this area recently to move this closer together.
 
> Alongside these changes, the CI20 still needs instruction emulation for 
> rdhwr, 
> since this instruction is still used by various libraries, even though the 
> bootstrap code avoids it. Meanwhile, I still find that the bootstrap crt0.S 
> file needs patching to fix the memory mapping and to not run with the ERL 
> flag 
> set. Fixing the UART handling in the kernel does not make that issue 
> disappear.

I've also queued a change to disable ERL. Not sure on the other issue
yet.



Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: building x86-32

[Adam Lackorzynski]

On Fri Mar 10, 2023 at 16:56:43 +0100, lieutenant_bea...@web.de wrote:
> ok thanks
> but I still have a Linker-Error:
> 
> ld: i386:x86-64 architecture of input file 
> `/usr/lib/gcc/x86_64-linux-gnu/9/crtbeginS.o' is incompatible with i386 output
> ld: i386:x86-64 architecture of input file 
> `/usr/lib/gcc/x86_64-linux-gnu/9/crtendS.o' is incompatible with i386 output
> 
> I did 'apt-get install lib32gcc-10-dev' previously.
> So maybe a -m32 flag missing somewhere?

The path indicates you're using gcc-9, thus installing lib32gcc-9-dev
would provide the needed files.


Adam

> Gesendet: Donnerstag, 09. März 2023 um 21:36 Uhr
> Von: "Matthias Lange" 
> An: l4-hackers@os.inf.tu-dresden.de
> Cc: lieutenant_bea...@web.de
> Betreff: Re: building x86-32
> Hi,
> 
> On [09-03-2023 18:42], lieutenant_bea...@web.de wrote:
> > Hello,
> >  
> > I try to build a x86-32 image on 20.04.1-Ubuntu x86_64.
> > Doing 'make setup' and select ia32 gives this output:
> > #
> > # configuration written to .kconfig
> > #
> > All build tools checked ok.
> > gcc -fPIC -Wall -pedantic -g -m64 -c
> > /home/b/l4re-snapshot-22.04.0/src/l4/tool/gendep/deptrack.c -o
> > /home/b/l4re-snapshot-22.04.0/obj/l4/x86/tool/gendep/deptrack.64.o
> > gcc -fPIC -Wall -pedantic -g -m64 -c
> > /home/b/l4re-snapshot-22.04.0/src/l4/tool/gendep/syscall.c -o
> > /home/b/l4re-snapshot-22.04.0/obj/l4/x86/tool/gendep/syscall.64.o
> > gcc -m64 -shared -Wl,--no-as-needed
> > -Wl,-soname,/home/b/l4re-snapshot-22.04.0/obj/l4/x86/tool/gendep/64/libgendep.so
> > -ldl -o
> > /home/b/l4re-snapshot-22.04.0/obj/l4/x86/tool/gendep/64/libgendep.so
> > /home/b/l4re-snapshot-22.04.0/obj/l4/x86/tool/gendep/deptrack.64.o
> > /home/b/l4re-snapshot-22.04.0/obj/l4/x86/tool/gendep/syscall.64.o
> >  
> > Notice 'gcc -m64'! And also the object-files are '*.64.o'
> > Is there a fault in the Makefile?
> > Shouldn't it be m32?
> 
> This is correct. The output you mentioned here is from building some host
> tools that are needed by the L4Re build system.
> 
> Best,
> Matthias.
> 
> >  
> > Thanks
> > B.
> 
> > ___
> > l4-hackers mailing list
> > l4-hackers@os.inf.tu-dresden.de
> > https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
> 
> 
> --
> Matthias Lange phone: +49 (0) 351-41 888 614
> Senior Operating Systems Engineer web: 
> https://www.kernkonzept.com[https://www.kernkonzept.com]
> 
> Kernkonzept GmbH
> Buchenstraße 16b
> 01097 Dresden
> 
> Geschäftsführer: Dr.-Ing. Michael Hohmuth
> Registergericht: Amtsgericht Dresden
> Handelsregister: HRB 31129
> 
> You might not be working when I am and that's ok! Please make sure to only
> reply when it suits you. Mails can wait.
> 
> ___
> l4-hackers mailing list
> l4-hackers@os.inf.tu-dresden.de
> https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: NXP LX2160 Uboot Fail

[Adam Lackorzynski]

Hi,

Sorry, the load address was wrong. I just verified the following works
for me:
tftpboot $fdt_addr_r path/to/fsl-lx2160a-rdb.dtb
tftpboot 0x81c0 path/to/bootstrap.uimage
bootm 0x81c0 - $fdt_addr_r



Adam

On Thu Sep 08, 2022 at 07:09:17 +, rib0327 wrote:
> Hi,
> 
> when I load the uimage into this address, I unfortunately get the same error 
> message.
> Is there any other advice?
> Thank you
> 
> Von: l4-hackers  im Auftrag von Adam 
> Lackorzynski 
> Gesendet: Donnerstag, September 1, 2022 12:04 AM
> An: l4-hackers@os.inf.tu-dresden.de 
> Betreff: Re: NXP LX2160 Uboot Fail
> 
> Hi,
> 
> On Wed Aug 31, 2022 at 08:01:05 +, rib0327 wrote:
> > I am currently trying to get the L4Re running on the NXP LX2160 with U-Boot.
> > When I try to load a .uimage I get the following error message:
> > FDT and ATAGS support not compiled in
> 
> I believe this happens because u-boot needs the uimage to be loaded to
> the starting address, i.e. load the uimage to 0x80c0.
> 
> 
> Adam
> 
> ___
> l4-hackers mailing list
> l4-hackers@os.inf.tu-dresden.de
> https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: NXP LX2160 Uboot Fail

[Adam Lackorzynski]

Hi,

On Wed Aug 31, 2022 at 08:01:05 +, rib0327 wrote:
> I am currently trying to get the L4Re running on the NXP LX2160 with U-Boot.
> When I try to load a .uimage I get the following error message:
> FDT and ATAGS support not compiled in

I believe this happens because u-boot needs the uimage to be loaded to
the starting address, i.e. load the uimage to 0x80c0.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Creating tasks and the l4_task_map function

[Adam Lackorzynski]

Hi Paul,

On Sun Aug 21, 2022 at 00:18:57 +0200, Paul Boddie wrote:
> On Monday, 18 April 2022 23:26:03 CEST Adam Lackorzynski wrote:
> > 
> > On Tue Apr 12, 2022 at 01:09:40 +0200, Paul Boddie wrote:
> > > 
> > > This might just sound like me complaining, but I also have some concerns
> > > about being able to verify the behaviour of some of the code. For
> > > example, I recently found that my dataspace implementation was getting
> > > requests from a region mapper/manager with an opcode of 0x1,
> > > which doesn't make any sense to me at all, given that the dataspace
> > > interface code in L4Re implicitly defines opcodes that are all likely to
> > > be very small integers. At first I obviously blamed my own code, but then
> > > I found that in the IPC call implementation found here...
> > > 
> > > pk/l4re-core/l4sys/include/cxx/ipc_iface
> 
> This was obviously...
> 
> pkg/l4re-core/l4sys/include/cxx/ipc_iface
> 
> > > ...if I explicitly cleared the first message register before this
> > > statement...
> > > 
> > >   int send_bytes =
> > > Args::template write_op(mrs->mr, 0, Mr_bytes,
> > > Opt::Opcode, a...);
> > > 
> > > ...then the opcode was produced as expected again.
> > 
> > Which does not fully make sense to me because the message registers seem
> > to be written from 0 on. Anyway, do you have an example maybe?
> 
> I just spent quite some time seeing errors like this...
> 
> ext2svr | L4Re[rm]: mapping for page fault failed with error -39 at 
> 0x1002fbc00 pc=0x10b7804
> ext2svr | L4Re: rom/ext2_server: Unhandled exception: PC=0x10b7804 
> PFA=0x1002fbc00 LdrFlgs=0x0
> 
> -39 being -L4_EBADPROTO (unsupported protocol), of course.
> 
> And then I remembered that there was some curious IPC-related problem I had 
> encountered a while ago. It turns out that it was this again, and since I had 
> obtained a fresh checkout of the L4Re code and had forgotten that this could 
> be a problem, I had revived it! Introducing my workaround eliminated the 
> error.
> 
> Do you have any ideas as to why the first message register gets corrupted?

No, still not. Any chance I could see a small example of this?


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Problem with newest Git-Version (RPi4)

[Adam Lackorzynski]

Hi,

Thanks for the elaborate description. Please use
SRC_C = src/main.c
in the Makefile for the time being.


Adam

On Thu Aug 25, 2022 at 09:40:54 +, rib0327 wrote:
> Hello everyone,
> 
> 
> 
> We have a question regarding the newest Kernel version available on Git 
> (current date: 11.08.2022). We are working on an application and
> 
> have come across a problem.
> 
> In a previous Git version of the Kernel we had no problem building the 
> .uimage file; however, with the newest update we found out that the .uimage 
> file cannot be built.
> 
> 
> 
> Here the working version (older one):
> 
> 
> 
> Buildung local Project exampleApp
> 
> 
>  [ExampleApp_Git] ... Compiling src/main.o
>  [ExampleApp_Git] ==> Linking exampleApp
>  [ExampleApp_Git] ==> exampleApp built
>  [ExampleApp_Git] ==> Installing exampleApp to local build-tree
> 
> 
> Building L4Re uimage with Application exampleApp
> 
> 
> make[1]: Entering directory '/home/dev/L4Re_Git/l4'
> Building entry "exampleApp".
> Merging images:
> mod00: /home/dev/L4Re_Git/build-fiasco//fiasco [436kB]
> mod01: /home/dev/L4Re_Git/build-l4re/bin/arm64_armv8a/l4f/sigma0 
> [36kBBuildung local Project exampleApp
> 
> 
>  [ExampleApp_Git] ... Compiling src/main.o
>  [ExampleApp_Git] ==> Linking exampleApp
>  [ExampleApp_Git] ==> exampleApp built
>  [ExampleApp_Git] ==> Installing exampleApp to local build-tree
> 
> 
> Building L4Re uimage with Application exampleApp
> 
> 
> make[1]: Entering directory '/home/dev/L4Re_Git/l4'
> Building entry "exampleApp".
> Merging images:
> mod00: /home/dev/L4Re_Git/build-fiasco//fiasco [436kB]
> mod01: /home/dev/L4Re_Git/build-l4re/bin/arm64_armv8a/l4f/sigma0 [36kB]
> mod02: /home/dev/L4Re_Git/build-l4re/bin/arm64_armv8a/l4f/moe [226kB]
> mod03: /home/dev/L4Re_Git/build-l4re/bin/arm64_armv8a/l4f/l4re [117kB]
> mod04: /home/dev/L4Re_Git/build-l4re/bin/arm64_armv8a/l4f/exampleApp [174kB]
>  [bootstrap] ... Generating bootstrap.ld
>  [bootstrap] ... Compiling startup.o
>  [bootstrap] ==> Linking bootstrap.elf
>  [bootstrap] ==> Image post-processing bootstrap.elf
>  [bootstrap] ==> bootstrap.elf built
>  ==> Installing bootstrap.elf in image directory
>  ==> Installing bootstrap_exampleApp in image directory
>  ==> Installing bootstrap_exampleApp.elf in image directory
>  [bootstrap] ... Generating bootstrap.raw
>  ==> Installing bootstrap.raw in image directory
>  ==> Installing bootstrap_exampleApp.raw in image directory
>  [bootstrap] ... Generating bootstrap.uimage
> Image Name:   L4 Image #3
> Created:  Thu Aug 11 09:11:24 2022
> Image Type:   AArch64 Linux Kernel Image (uncompressed)
> Data Size:1099688 Bytes = 1073.91 KiB = 1.05 MiB
> Load Address: 0100
> Entry Point:  0100
>  ==> Installing bootstrap.uimage in image directory
>  ==> Installing bootstrap_exampleApp.uimage in image directory
>  Image size(s) in bytes:
>   bootstrap_exampleApp.elf:  1534296
>  bootstrap.raw:  1099688
>   bootstrap.uimage:  1099752
>  Start address: 0x100
>  --> Build-Nr: 3
>  [bootstrap] ==> Installing bootstrap.elf to local build-tree
>  [bootstrap] ==> Installing bootstrap_exampleApp to local build-tree
>  [bootstrap] ==> Installing bootstrap_exampleApp.elf to local build-tree
> make[1]: Leaving directory '/home/dev/L4Re_Git/l4'
> 
> 
> DONE - bootstrap_exampleApp.uimage copied to /tftp/!
> ]
> mod02: /home/dev/L4Re_Git/build-l4re/bin/arm64_armv8a/l4f/moe [226kB]
> mod03: /home/dev/L4Re_Git/build-l4re/bin/arm64_armv8a/l4f/l4re [117kB]
> mod04: /home/dev/L4Re_Git/build-l4re/bin/arm64_armv8a/l4f/exampleApp [174kB]
>  [bootstrap] ... Generating bootstrap.ld
>  [bootstrap] ... Compiling startup.o
>  [bootstrap] ==> Linking bootstrap.elf
>  [bootstrap] ==> Image post-processing bootstrap.elf
>  [bootstrap] ==> bootstrap.elf built
>  ==> Installing bootstrap.elf in image directory
>  ==> Installing bootstrap_exampleApp in image directory
>  ==> Installing bootstrap_exampleApp.elf in image directory
>  [bootstrap] ... Generating bootstrap.raw
>  ==> Installing bootstrap.raw in image directory
>  ==> Installing bootstrap_exampleApp.raw in image directory
>  [bootstrap] ... Generating bootstrap.uimage
> Image Name:   L4 Image #3
> Created:  Thu Aug 11 09:11:24 2022
> Image Type:   AArch64 Linux Kernel Image (uncompressed)
> Data Size:1099688 Bytes = 1073.91 KiB = 1.05 MiB
> Load Address: 0100
> Entry Point:  0100
>  ==> Installing bootstrap.uimage in image directory
>  ==> Installing bootstrap_exampleApp.uimage in image directory
>  Image size(s) in bytes:
>   bootstrap_exampleApp.elf:  1534296
>  bootstrap.raw:  1099688
>   bootstrap.uimage:  1099752
>  Start address: 0x100
>  --> Build-Nr: 3
>  [bootstrap] ==> Installing bootstrap.elf to local build-tree
>  [bootstrap] ==> Installing bootstrap_exampleApp to local build-tree
>  [bootstrap] ==> Installing bootstrap_exampleApp.elf to local build-tree
> make[1]: Leaving directory 

Re: Creating tasks and the l4_task_map function

[Adam Lackorzynski]

Hi Paul,

On Fri Apr 29, 2022 at 00:28:10 +0200, Paul Boddie wrote:
> On Thursday, 28 April 2022 23:21:46 CEST Adam Lackorzynski wrote:
> > 
> > On Mon Apr 25, 2022 at 17:55:45 +0200, Paul Boddie wrote:
> > > 
> > > I didn't really understand this when looking through the existing code. It
> > > seemed that the memory was reserved, and that seemed to involve telling a
> > > region manager/mapper about it, such as in Remote_app_model where the
> > > prog_reserve_utcb_area method appears to attach an invalid dataspace
> > > (obtained from the reserved_area method) to an existing RM.
> > 
> > Generally, the RM API has a reserve_area call which should be used for
> > this.
> 
> Thanks once again for the clarification! I suppose I should ask the more 
> general question of whether the different L4Re mechanisms are documented in a 
> manual or something of that nature. Although the reference documentation 
> covers some of the concepts, along with APIs for use by applications, but not 
> necessarily various framework-level abstractions (like Remote_app_model), it 
> would be informative to be able to read something that discusses the 
> techniques involved in building a system on top of Fiasco.

I'm afraid but for this particular area there's no better documentation
I believe.

> At the moment, I am just trying to persuade a program to run in a new task, 
> which will hopefully only be a matter of properly initialising the details of 
> the program environment. As well as paging in the appropriate segments of the 
> binary in the right places, of course.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Creating tasks and the l4_task_map function

[Adam Lackorzynski]

Hi Paul,

On Mon Apr 25, 2022 at 17:55:45 +0200, Paul Boddie wrote:
> On Monday, 25 April 2022 01:04:44 CEST Adam Lackorzynski wrote:
> > 
> > Thanks for the example.
> 
> Thanks for looking at it! I appreciate the help.
> 
> > I believe I see the issue but first I immediately change to buf_log2size
> > to 12 for the reason of less suprise, and did not change further on the
> > sizes. Then I noticed your way of handling the UTCB involved allocating
> > memory. That's not needed. With the fpage you specify the window of the
> > UTCB memory in the other task, so no need to allocation memory in the
> > launcher task, if it is for reserving the virtual memory.
> 
> I didn't really understand this when looking through the existing code. It 
> seemed that the memory was reserved, and that seemed to involve telling a 
> region manager/mapper about it, such as in Remote_app_model where the 
> prog_reserve_utcb_area method appears to attach an invalid dataspace 
> (obtained 
> from the reserved_area method) to an existing RM.

Generally, the RM API has a reserve_area call which should be used for
this.

> Meanwhile, the l4_factory_create_task function accepts a flexpage as 
> parameter 
> whose details are then provided in the IPC message. As you noted before, 
> Fiasco is meant to handle this flexpage. And it does appear that if I just 
> remove the dataspace allocation and provide the flexpage details, the UTCB 
> gets set up in the new task at the appropriate location.

Yes, a dataspace has nothing to do with this.

> > Then, the issue is that posix_memalign allocates memory which does not
> > have the x-bit set, i.e., is memory that is not executable.
> > Change it to
> >   buf = (char *)mmap(NULL, region_size, PROT_EXEC | PROT_READ | PROT_WRITE,
> > MAP_PRIVATE | MAP_ANON, -1, 0); if (buf == MAP_FAILED)
> >   {
> > printf("Could not reserve memory.\n");
> > return 1;
> >   }
> > and it should work (it did for me).
> 
> This seems like the obvious thing that I couldn't see: that the memory needs 
> to have the appropriate permissions associated with it. Well, it seems a bit 
> more obvious now!
> 
> For the larger region I had in mind, just to keep things simple, mmap is a 
> bit 
> cumbersome because it only supports page-level alignment, so I used the L4Re 
> memory allocator to get a dataspace that I could attach at a suitably aligned 
> address. I imagine that if the parent task were to terminate, having an 
> independently allocated dataspace would be desirable, too.

Yes, of course using a dataspace is also totally fine.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Creating tasks and the l4_task_map function

[Adam Lackorzynski]

On Sat Apr 23, 2022 at 00:40:05 +0200, Paul Boddie wrote:
> On Friday, 22 April 2022 01:16:44 CEST Paul Boddie wrote:
> > 
> > On Thursday, 21 April 2022 22:57:40 CEST Adam Lackorzynski wrote:
> > > 
> > > Maybe it helps to share some code here?
> > 
> > I suppose it might be best to condense this into an example that uses the
> > basic L4Re APIs instead of my own libraries (that wrap those APIs), so as
> > not to confuse things. I'll try and put that together tomorrow.
> 
> So, I finally got to looking at this and making it self-contained, with an 
> archive of the code available here:
> 
> https://www.boddie.org.uk/downloads/tests_l4re.tar.bz2
> 
> This is a package that should work within the L4Re build system containing 
> two 
> source files: a trivial program (exec_payload_l4re.c) and a loader program 
> that attempts to create a new task to load and start the trivial program 
> (exec_l4re.cc). Both programs are statically linked.
> 
> Note that the loader program does not do all the work to start the program, 
> focusing only on being able to resolve the initial page fault. So, although 
> it 
> attempts to set up various capabilities and other resources, it doesn't even 
> initialise the stack or map in other regions that would be needed to actually 
> run the program.
> 
> The log when running the loader program using the supplied configuration will 
> report page faults occurring as follows:
> 
> exec_l4r| page_fault(0x1000ae4, 0x1000ae3) -> 0x1000ae0 (0x4)...
> exec_l4r| -> l4_fpage(0x4, 18, 0x5) @ 100
> exec_l4r| page_fault(0x1000ae5, 0x1000ae3) -> 0x1000ae0 (0x5)...
> exec_l4r| -> l4_fpage(0x4, 18, 0x5) @ 100
> 
> Here, the received fault is decoded and the flexpage for returning is 
> described. When I switch on page fault and IPC logging (P*, I*, IR+) in jdb, 
> I 
> get entries like this:
> 
>  0047 answ [0040] L=0 err=0 (OK) (138,40495)  
>   
> pf:  0043 pfa=01000ae3 ip=01000ae3 (rp) spc=0x13dc5cb8
>   err=15
> ipc: 0047 send rcap->[C:INV] DID=43 L=0 [0040]
>   (0138,00040495) TO=INF
> 
> Here, thread 0047 belongs to the loader program, and 0043 belongs to the 
> trivial payload program.
> 
> It is entirely possible that I am not sufficiently initialising the created 
> task, but it surprises me that the page fault does not get resolved, and I 
> did 
> some old-fashioned debugging with Fiasco to establish that the mapping does 
> occur. One difference between the above and my previous report is that the 
> mapped region is now significantly smaller, since I am now using a binary 
> file 
> installed in the "rom" as a module, not the initially generated ELF binary.
> 
> When looking for other code that might be doing this kind of thing, I 
> remembered L4Linux which seems to use the C APIs. Much of what it is doing is 
> similar to what I have been trying, although it seems to use the "alien" 
> thread mechanism at various points, which I don't fully understand.
> 
> Anyway, I hope that I am making some obvious mistake that just hasn't been 
> obvious to me. Although there were examples in the package that was available 
> via Subversion (and maybe still is available via Git), they covered alien 
> threads and the vCPU support, but I couldn't find anything related to task 
> creation in its own right. Interestingly, I did find this:
> 
> https://github.com/phipse/L4RTEMS/blob/master/l4/pkg/RTEMS_wrapper/server/src/
> wrapper_1.cc
> 
> But it is also using the vCPU feature. However, it does seem to attempt ELF 
> header decoding and related activities, so it might still prove to be a 
> useful 
> reference.
> 
> Thanks once again for listening!

Thanks for the example.

I believe I see the issue but first I immediately change to buf_log2size
to 12 for the reason of less suprise, and did not change further on the
sizes. Then I noticed your way of handling the UTCB involved allocating
memory. That's not needed. With the fpage you specify the window of the
UTCB memory in the other task, so no need to allocation memory in the
launcher task, if it is for reserving the virtual memory.

Then, the issue is that posix_memalign allocates memory which does not
have the x-bit set, i.e., is memory that is not executable.
Change it to
  buf = (char *)mmap(NULL, region_size, PROT_EXEC | PROT_READ | PROT_WRITE, 
MAP_PRIVATE | MAP_ANON, -1, 0);
  if (buf == MAP_FAILED)
  {
printf("Could not reserve memory.\n");
return 1;
  }
and it should work (it did for me).



Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Creating tasks and the l4_task_map function

[Adam Lackorzynski]

Hi Paul,

On Tue Apr 19, 2022 at 01:20:30 +0200, Paul Boddie wrote:
> On Monday, 18 April 2022 23:26:03 CEST you wrote:
> > Hi Paul,
> > 
> > On Tue Apr 12, 2022 at 01:09:40 +0200, Paul Boddie wrote:
> > > 
> > > OK, I did see that function being used, too, but I also found plenty of
> > > other things in my perusal of the different files. Obviously, being able
> > > to extend the UTCB memory is an important consideration.
> > 
> > It is, because, for example, one might not know how many threads a task
> > will have, especially the component that creates the task.
> 
> Right. And so, in the Moe_app_model the size of the UTCB is dependent of the 
> default number of threads. It still seems that I have to provide a UTCB 
> flexpage to l4_factory_create_task, however.

Yes. Both are different levels of APIs. l4_factory_create_task /
L4::Factory::create_task is a kernel API, while Moe_app_model is a
user-level abstraction that is using those APIs.

> > > Right. I see that the factory function actually sends the flexpage in the
> > > IPC call (using l4_factory_create_add_fpage_u), thus mapping it in the
> > > task. I find it hard to follow where this message is actually handled (I
> > > presume that Moe acts as the factory) or what the factory actually does
> > > with the flexpage, but I presume that it ultimately causes it to be
> > > mapped in the new task.
> >
> > It is handled in Fiasco.
> 
> OK. I think I found this in Task::create (src/kern/task.cpp).

Yes, that's there.

> > > However, I wonder about the "chicken and egg" situation in new tasks. It
> > > seems to me that the way things work is that a new task in L4Re is
> > > typically populated with the l4re binary containing the region
> > > mapper/manager (RM). This seems to be initiated here (in launch_loader):
> >
> > Yes, the l4re binary loads the application and then serves as its pager.
> 
> OK. And it seems that the RM provided by this binary is able to indicate the 
> receive window for flexpages when asking for mappings from dataspaces.

Yes, it is.

> [Pagers for other tasks]
> 
> > That's how it works. Moe also has region managers that are used for the
> > l4re binary to be paged. When a page fault is resolved, then there is
> > someone sending memory via a flexpage to the task in question. In our
> > case it's the dataspace manager which sends the memory via an 'map'
> > call. Here it does not matter whether the l4re binary faulted or the
> > application, because in the end the task is the receiver of the flex
> > page, not the particular application (which are runnig in the same
> > task).
> 
> So, the one thing I didn't understand until I started digging around in the 
> Fiasco sources and also implementing my own page fault handler was the scope 
> of the receive window for issued flexpages, but it appears that the whole 
> address space is indicated as the receive window in 
> Thread::handle_page_fault_pager (src/kern/thread-ipc.cpp).

Yes, for page faults this is the case, i.e., the kernel allows the pager
to map into the whole address space to resolve the page fault. There is
not restriction made by the kernel for that, and the page fault handler
has control over the virtual memory space of the task in any case.

> [Mapping memory using l4_task_map]
> 
> > Jdb has facilities to check how the address spaces look like, exactly to
> > debug issue like you describe. You can press 's' to see all the tasks in
> > the system, navigate onto them, and then press 'p' to see the page-table
> > view. Here you can navigate the page tables and verify that the pages at
> > some virtual address is actually pointing to the physical location they
> > should point at. For a particular physical address (page frame number)
> > you can also show the mapping hierarchy via the 'm'.
> 
> The "coherency" problems actually turned out to be me forgetting the 
> appropriate alignment for the mapped flexpages. But I have discovered a few 
> things about jdb in my attempts to troubleshoot my code, including 's' to 
> look 
> at tasks. I found the page table view bewildering, though, rather hoping for 
> a 
> nice summary of mapped pages instead. However, the object space view was very 
> useful in establishing that capabilities were being mapped.

Yeah, the page-table view really shows lots of tables :)
I agree that a list of mapped regions would also be nice to have.

> I did manage to get l4_task_map to work between two fully initialised tasks 
> created by Ned as follows:
> 
> l4_fpage_t payload_fpage = l4_fpage((l4_addr_t) buf,
> l4util_log2(L4_PAGESIZE * NUM_PAGES),
> L4_FPAGE_RW);
> 
> l4_task_map(recipient, L4RE_THIS_TASK_CAP, payload_fpage, 0x300);
> 
> This permitted the recipient task to access the memory in the appropriately 
> aligned buf region, this being mapped into the region starting at 0x300 
> in 
> the recipient.
> 
> I also managed to achieve the same thing using 

Re: Unresolved page faults when running l4linux-mag

[Adam Lackorzynski]

Hi,

sorry, this should be fixed now in the latest snapshot.


Adam

On Mon Mar 21, 2022 at 00:13:12 +0800, Haohui Mai wrote:
> Sorry I forgot to mention that I'm on Ubuntu 20.04 and trying to run
> the x86_64 port of L4Linux.
> 
> ~Haohui
> 
> On Sun, Mar 20, 2022 at 10:38 PM Haohui Mai  wrote:
> >
> > Hello,
> >
> > I'm trying to run the l4linux-mag example in the L4Re snapshot. It
> > seems it will result in an unresolved page fault using the current
> > snapshot (22.01.0):
> >
> > Loading: rom/ramdisk-amd64.rd
> > INITRD: Size of RAMdisk is 4096KiB
> > RAMdisk from 01816000 to 01c16000 [4096KiB]
> > l4lx_thread_create: Created thread 429 (timer0) (u:b3001c00,
> > v:, sp:01557f28)
> > WARNING: Unknown rdmsr: c100 at 0x212a20
> > WARNING: Unknown wrmsr: c100 at 0x212a33
> > WARNING: Unknown rdmsr: c100 at 0x212a4f
> > WARNING: Unknown wrmsr: c100 at 0x212a70
> > Non-resolvable page fault at 3612f82, ip 302265.
> > Page fault (non-resolved): pfa=3612f82 pc=302265
> > Non-resolvable page fault at 3612f82, ip 302265.
> > Page fault (non-resolved): pfa=3612f82 pc=302265
> > qemu-system-x86_64: terminating on signal 2
> >
> > Changing the console from ttyS0 to ttyLv0 will go a little bit
> > further, but still result in a page fault:
> >
> > BUG: unable to handle page fault for address: 03612f80
> > #PF: user write access in kernel mode
> > #PF: error_code(0x0006) - not-present page
> > PGD 0 P4D 0
> > Oops: 0006 [#1] SMP
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0-l4-ge2ad9258b98e #2
> > RIP: 0028:cache_alloc_refill+0x365/0x610
> > Code: 54 24 24 31 db 85 d2 74 2e 49 8b 44 24 50 48 85 c0 74 11 89 df
> > 41 0f af 7c 24 14 49 03 7d 28 ff d0 0f 1f 00 49 8b 55 20 89 d8 <88> 1c
> > 02 83 c3 01 41 39 5c 24 24 77 d2 45 85 f6 0f 85 fd 01 00 00
> > RSP: 319f9f00:1006bca0 EFLAGS: 0246 ORIG_RAX: 00f0
> > RAX:  RBX:  RCX: 6db6db6db6db6db7
> > RDX: 03612f80 RSI: 0001 RDI: 00e57840
> > RBP: 003c R08: 000194ff R09: 0002
> > R10: 000194f8 R11: 0006 R12: 1001fc00
> > R13: 088bd3f0 R14: 0400 R15: 0dc0
> > FS:  () GS:() knlGS:
> > CS:  0028 DS: 0023 ES: 0023 CR0: 
> > CR2:  CR3:  CR4: 
> > Call Trace:
> >  ? idr_alloc_cyclic+0x52/0xb0
> >  kmem_cache_alloc+0xc7/0xe0
> >  __kernfs_new_node.constprop.0+0x59/0x1a0
> >  ? vsnprintf+0x3e6/0x5b0
> >  ? kernfs_link_sibling+0x8d/0xd0
> >  ? kernfs_next_descendant_post+0x7d/0x90
> >  ? kernfs_activate+0x5a/0x80
> >  ? kernfs_add_one+0xdd/0x130
> >  kernfs_new_node+0x1b/0x40
> >  __kernfs_create_file+0x20/0xb0
> >  sysfs_add_file_mode_ns+0x96/0x180
> >  sysfs_create_file_ns+0x5d/0x90
> >  bus_create_file+0x3f/0x60
> >  bus_register+0x180/0x240
> >  subsys_system_register+0x16/0x40
> >  ? ntp_init+0x21/0x21
> >  init_clocksource_sysfs+0xe/0x1f
> >  do_one_initcall+0x44/0x190
> >  kernel_init_freeable+0x161/0x1ab
> >  ? rest_init+0xb0/0xb0
> >  kernel_init+0x11/0x100
> >
> > Any ideas to debug this? Your help is appreciated.
> >
> > Thanks,
> > Haohui

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Creating tasks and the l4_task_map function

[Adam Lackorzynski]

Hi Paul,

On Tue Apr 12, 2022 at 01:09:40 +0200, Paul Boddie wrote:
> On Monday, 11 April 2022 01:02:37 CEST Adam Lackorzynski wrote:
> > Hi Paul,
> > 
> > On Sun Apr 10, 2022 at 18:58:10 +0200, Paul Boddie wrote:
> > > I finally got round to experimenting with L4Re again, but in attempting to
> > > investigate task creation, I seem to have some difficulties understanding
> > > the mechanism by which tasks are typically created and how the
> > > l4_task_map function might be used in the process.
> > > 
> > > After looking at lots of different files in the L4Re distribution, my
> > > understanding of the basic mechanism is as follows:
> > > 
> > > 1. Some memory is reserved for the UTCB of a new task, perhaps using the
> > > l4re_ma_alloc_align function (or equivalent) to obtain a dataspace.
> > 
> > No, for UTCBs there's a dedicated call l4_task_add_ku_mem in case one
> > needs more UTCB memory than has been initially created with
> > l4_factory_create_task().
> 
> OK, I did see that function being used, too, but I also found plenty of other 
> things in my perusal of the different files. Obviously, being able to extend 
> the UTCB memory is an important consideration.

It is, because, for example, one might not know how many threads a task
will have, especially the component that creates the task.

> > > 2. A task is created using l4_factory_create_task, indicating the UTCB
> > > flexpage, with this being defined as...
> > > 
> > >   l4_factory_create_task(l4re_env()->factory, new_task,
> > >   
> > >   l4_fpage(utcb_start, utcb_log2size, L4_FPAGE_RW))
> > 
> > Yes. Here the flexpage defines where memory usable for UTCBs shall be
> > created.
> 
> Right. I see that the factory function actually sends the flexpage in the IPC 
> call (using l4_factory_create_add_fpage_u), thus mapping it in the task. I 
> find it hard to follow where this message is actually handled (I presume that 
> Moe acts as the factory) or what the factory actually does with the flexpage, 
> but I presume that it ultimately causes it to be mapped in the new task.

It is handled in Fiasco.

> [Thread creation and initiation]
> 
> > > The expectation is that the thread will immediately fault because there is
> > > no memory mapped at the instruction pointer location. However, it seems
> > > to me that it should be possible to use l4_task_map to make a memory
> > > region available within the task's address space, although I don't ever
> > > see this function used in L4Re for anything.
> > > 
> > > (The C++ API makes it difficult to perform ad-hoc searches for such
> > > low-level primitives, in my view, so perhaps I am missing use of the
> > > equivalent methods.)
> > 
> > Indeed. L4::Task::map is used, for example to map some initial
> > capabilities, and typically not memory.
> 
> Yes, I see a lot of these map operations operating on capabilities. For 
> example:
> 
> pkg/l4re-core/libloader/include/remote_app_model
> 
> However, I wonder about the "chicken and egg" situation in new tasks. It 
> seems 
> to me that the way things work is that a new task in L4Re is typically 
> populated with the l4re binary containing the region mapper/manager (RM). 
> This 
> seems to be initiated here (in launch_loader):

Yes, the l4re binary loads the application and then serves as its pager.

> pkg/l4re-core/ned/server/src/lua_exec.cc
> 
> This RM is then able to handle the page fault when an attempt is made to load 
> and run a new program. But one cannot rely on the RM when it isn't already 
> installed in a task, so there must be a way of mapping it into the new task 
> so 
> that it can be present. I assumed that using l4_task_map might be one way of 
> doing so.
> 
> Otherwise, I thought that perhaps an existing task could provide a kind of RM 
> to act as the new task's pager in the bootstrapping phase, so that page 
> faults 
> would be directed towards the existing task's RM and mappings established to 
> get the new task's RM up and running. However, in that case, since the usual 
> IPC traffic between RM and dataspaces does not involve sending flexpages to 
> the new task (and thus implicitly mapping them in the task, as I understand 
> it), it seems that the existing task's RM would also need to explicitly map 
> flexpages in the new task, again using something like l4_task_map.

That's how it works. Moe also has region managers that are used for the
l4re binary to be paged. When a page fault is resolved, then there is
someone sending memory via a flexpage to the task in question. In our
ca

Re: Creating tasks and the l4_task_map function

[Adam Lackorzynski]

Hi Paul,

On Sun Apr 10, 2022 at 18:58:10 +0200, Paul Boddie wrote:
> I finally got round to experimenting with L4Re again, but in attempting to 
> investigate task creation, I seem to have some difficulties understanding the 
> mechanism by which tasks are typically created and how the l4_task_map 
> function might be used in the process.
> 
> After looking at lots of different files in the L4Re distribution, my 
> understanding of the basic mechanism is as follows:
> 
> 1. Some memory is reserved for the UTCB of a new task, perhaps using the 
> l4re_ma_alloc_align function (or equivalent) to obtain a dataspace.

No, for UTCBs there's a dedicated call l4_task_add_ku_mem in case one
needs more UTCB memory than has been initially created with
l4_factory_create_task().

> 2. A task is created using l4_factory_create_task, indicating the UTCB 
> flexpage, with this being defined as...
> 
>   l4_factory_create_task(l4re_env()->factory, new_task,
>   l4_fpage(utcb_start, utcb_log2size, L4_FPAGE_RW))

Yes. Here the flexpage defines where memory usable for UTCBs shall be
created.
 
> 3. A thread is created using l4_factory_create_thread.
> 
>   l4_factory_create_thread(l4re_env()->factory, new_thread)
> 
> 4. The thread attributes are set using the l4_thread_control API.
> 
> 5. The l4_thread_ex_regs function is used to set the instruction pointer 
> (program counter) and stack pointer of the thread.
> 
> 6. The l4_scheduler_run_thread function is used to initiate the thread.

All yes.
 
> The expectation is that the thread will immediately fault because there is no 
> memory mapped at the instruction pointer location. However, it seems to me 
> that it should be possible to use l4_task_map to make a memory region 
> available within the task's address space, although I don't ever see this 
> function used in L4Re for anything.
> 
> (The C++ API makes it difficult to perform ad-hoc searches for such low-level 
> primitives, in my view, so perhaps I am missing use of the equivalent 
> methods.)

Indeed. L4::Task::map is used, for example to map some initial
capabilities, and typically not memory.
 
> Tentatively, I would imagine that something like this might work:
> 
>   l4_task_map(new_task, L4RE_THIS_TASK_CAP,
>   l4_fpage(program_start, program_log2size, L4_FPAGE_RX),
>   task_program_start)
> 
> Here, the program payload would be loaded into the creating task at 
> program_start, but the new task would be receiving the payload at 
> task_program_start, with the configured instruction pointer location 
> occurring 
> within the receive window (after task_program_start, in other words).

Yes, this would work.

> There are, of course, many other considerations around creating tasks, which 
> I 
> have noted from looking at the different packages (libloader, l4re_kernel, 
> moe, ned), and I am aware that a few other things need to be done to start a 
> task such as...
> 
> * Defining capability selectors and mapping appropriate capabilities to the 
> new task.
> 
> * Creating a stack for the task and populating it with arguments and 
> environment information.
> 
> * Defining a suitable pager and exception handler, with this usually being 
> provided by the l4re binary, as I understand it.

Yes, this all needs to be done.
 
> Also, when actually dealing with program loading generally, I realise that 
> the 
> ELF binary needs to be interpreted and the appropriate regions associated 
> with 
> different parts of memory, this typically being handled by the region mapper/
> manager in L4Re. And there is also the matter of dynamic library loading.

Yes, indeed.
 
> But here, I am just attempting to establish the basic mechanism when a task 
> starts up. Unfortunately, the only discussion I found was this (after some 
> initial discussion about a related topic):
> 
> http://os.inf.tu-dresden.de/pipermail/l4-hackers/2014/015366.html
> 
> There are various examples in Subversion (maybe somewhere in the Git 
> repositories, too) that create tasks or threads, but I don't find them 
> particularly helpful, apparently being oriented towards very specific 
> applications. A previous example was referenced in the above thread for the 
> older L4Env system (or maybe an even earlier system):
> 
> http://os.inf.tu-dresden.de/pipermail/l4-hackers/2000/000384.html
> 
> As for why I would be wondering about such things - a question inevitably 
> asked in the first thread referenced above - I firstly want to be able to 
> understand the mechanism involved, but I also want to be able to integrate 
> work I have been doing on file paging into task creation.

I think you described it very well with your steps listed above. Also,
l4util has a l4util_create_thread() function that lists all the steps
needed to create a thread in an existing task.
 
> Although I can probably do this by customising the "app model" normally used 
> by the different loaders, it seems that I would need to construct an 
> 

Re: Unable to boot hello example.

[Adam Lackorzynski]

Hi,

On Fri Feb 04, 2022 at 04:34:44 -0500, Ashwin Krishnakumar wrote:
> Hello all,
> I have created this issue in the manifest repo.
> Issue : https://github.com/kernkonzept/manifest/issues/12
> 
> I am writing it again.

Thanks Ashwin. Please bear with us while we work through it.

> I am trying to boot an AMD64 and ARM64 machine using fiasco. The Fiasco and
> L4 build works fine. We are able to generate the final elf also
> successfully. However the QEMU is unable to boot the machine. IT just
> freezes at startup with the comment "ROM booting".
> 
>1. Fiasco building successfully
> 
> [image: image.png]
> 
> 
>1. L4 runtime built successfully
> 
> [image: Screen Shot 2022-02-04 at 4 18 24 AM]
> 
> 
>1. Able to give a boot command. However the system requires a video
>card. So I moved to my Linux laptop and observed that the system boots
>beyond this error, but is not printing hello world.

You mean that you built this on a server, and as running it remotely on
this server did not work you moved to the laptop?

> [image: Screen Shot 2022-02-04 at 4 25 57 AM]
> 
> 
> In my local laptop it just says booting from ROM and freezes.
> 
> Is there an alternate instruction for booting examples for ARM64 and AMD64 ?

The snapshot you're using has a configuration facility via "make setup".
Did you run this? There's also a README.md file with info. What was your
entry point?


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: l4re + rpi4 + mmc + vm + net

[Adam Lackorzynski]

On Sun Sep 19, 2021 at 09:51:07 +0200, Matthieu Fatrez wrote:
> Sorry, answer to myself. I miss the BLK_DEV_RAM=y param in kernel
> compilation to have access to /dev/ram0.

Yep, that's right.

> Looking now for the mmc access.

I'm afraid but it won't work with the single device tree node.
First the node is in state "disabled" such that both uvmm and Linux
won't consider it. Then the node refers to other resources which it
needs to work, in particular pinctrl and clocks which also need to be
available. There are two ways of approaching this, either start with the
full device tree for the platform, or add all required resources to the
device tree. In any case all required resources have to be added to the
io configs as well.
I would generally recommend to start with the full device tree as uvmm
will disable all devices which it does not find a corresponding resource
in the io config. For actually figuring out what is required (except
"all") it might be useful to check the particular driver (here mmc)
what it actually requires to work, i.e., where it bails out in its
init/probe function.



HTH,
Adam

> Le sam. 18 sept. 2021 à 16:53, Matthieu Fatrez  a
> écrit :
> 
> > Hello l4-hackers,
> >
> > I try to run a vm with l4re on a RPI4b with this files bellow, but I don't
> > know how to find the root device to finalize the boot process.
> >
> > I haven't played on the network part yet, but if you have any advice on
> > the subject as well, I'm a taker.
> >
> > Help needed please. Thanks.
> >
> > vm_hw.vbus
> >
> > --8<
> > Io.add_vbusses
> > {
> >   vm_hw = Io.Vi.System_bus(function()
> > MMC = wrap(Io.system_bus().mmc);
> >   end);
> > }
> >
> > --8<
> >
> > io.cfg
> >
> > --8<
> > local Res = Io.Res
> > local Hw = Io.Hw
> > local add_children = Io.Dt.add_children
> >
> > add_children(Io.system_bus(), function()
> > mmc = Hw.Device(function()
> > compatible = { "brcm,bcm2835-mmc" };
> > Resource.reg0 = Res.mmio(0xfe30, 0xfe3000FF);
> > Resource.irq0 = Res.irq(0x7e + 32);
> > Property.flags = Io.Hw_device_DF_dma_supported;
> > end)
> > end)
> >
> > --8<
> >
> > mmc.dts
> >
> > --8<
> > /dts-v1/;
> > /include/ "virt-arm_virt-64.dts"
> >
> > / {
> >   mmc@fe30 {
> > compatible = "brcm,bcm2835-mmc", "brcm,bcm2835-sdhci";
> > reg = <0xfe30 0x100>;
> > interrupts = <0x0 0x7e 0x4>;
> > clocks = <0x3 0x1c>;
> > dmas = <0xa 0xb>;
> > dma-names = "rx-tx";
> > brcm,overclock-50 = <0x0>;
> > status = "disabled";
> > pinctrl-names = "default";
> > pinctrl-0 = <0x19>;
> > bus-width = <0x4>;
> > phandle = <0x2d>;
> >   };
> > };
> >
> > --8<
> >
> > mfa.cfg
> >
> > --8<
> > local L4 = require "L4";
> > local l = L4.default_loader;
> >
> > vbus_l4linux = l:new_channel();
> >
> > -- Start io & flash memory
> > l:start({
> > caps = {
> > sigma0 = L4.cast(L4.Proto.Factory,
> > L4.Env.sigma0):create(L4.Proto.Sigma0),
> > icu = L4.Env.icu,
> > vm_hw = vbus_l4linux:svr()
> > },
> > log = {"IO", "y"}
> > }, "rom/io rom/io.cfg rom/vm_hw.vbus -vv");
> >
> > l:startv({
> > caps = {
> > ram = L4.Env.user_factory:create(
> >   L4.Proto.Dataspace, 256 * 1024 * 1024,
> >   L4.Mem_alloc_flags.Continuous |
> >   L4.Mem_alloc_flags.Pinned |
> >   L4.Mem_alloc_flags.Super_pages,
> >   21):m("rws");
> > vbus = vbus_l4linux;
> > },
> > log = L4.Env.log:m("rws")
> > }, "rom/uvmm", "-v",
> > "--kernel", "rom/Image.gz",
> > "--ramdisk", "rom/ramdisk-armv8-64.rd",
> > "--dtb", "rom/mmc.dtb",
> > "--cmdline", "console=hvc0 ramdisk_size=1 root=/dev/mmcblkp3
> > rw");
> >
> > --8<
> >
> > in modules.list
> >
> > --8<
> > entry mfa
> > roottask moe rom/mfa.cfg
> > module l4re
> > module hello
> > module uvmm
> > module ned
> > module mfa.cfg
> > module uvmm
> > module cons
> > module dtb/virt-arm_virt-64.dtb
> > module mmc.dtb
> > module[shell] echo $SRC_BASE_ABS/pkg/uvmm/configs/vmm.lua
> > module ramdisk-armv8-64.rd
> > 

Re: Basic support for HiKey960 & SMP question

[Adam Lackorzynski]

Hi Martin,

On Fri Sep 17, 2021 at 13:05:38 +, Martin Decky wrote:
> Dear L4 hackers,
> 
> I have implemented a basic support for the HiKey960 board (based on the
> Kirin 960 SoC) [1] in Fiasco.OC and L4Re. If you are interested, please feel
> free to examine the code at GitHub [2]. I would be more than happy for a
> code review and suggestions towards potential upstream merging.
> 
> The code is based on the latest L4Re base 21.07.0 snapshot. I have wanted to
> rebase the implementation on the latest revisions of the respective GitHub
> repositories, but unfortunately the current upstream Fiasco does not work
> for me properly even in QEMU.
> 
> The implementation is very basic (fixed physical memory layout, UART support
> only, etc.), but seems to be working fine on the default examples.
> Unfortunately, I am struggling for some time with making the additional CPU
> cores work. I would greatly appreciate your assistance in this matter.
> 
> In a nutshell, the additional 3 little cores (A53) are woken up correctly
> using the PSCI call (I am not tackling the 4 big A73 cores yet), but the
> Fiasco code livelocks in the loop around the STXR instruction in
> src/kern/arm/64/tramp-mp.S [3]. The STXR instruction always reports that the
> exclusive access to the _tramp_mp_spinlock failed despite no other accesses
> to the spinlock happened (confirmed using a JTAG debugger).
> 
> I have checked all the usual culprits like proper virtual memory mapping
> attributes. I don't see any significant difference between the
> initialization code of Fiasco and the initialization code of other kernels
> that support HiKey960. I am also aware of the recent Adam's fix to the
> _tramp_mp_spinlock code [4], but not even that fixes the livelock issue on
> HiKey 960.
> 
> Does anyone have any idea what might be root cause of the livelock here?
> Thanks in advance for any input.

I'm not sure about the QEMU part (works fine for me) but on the HiKey my
guess would be that the cache on those cores is not enabled? Could you
check this?


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: l4re + l4linux on aarch64 - raspi4

[Adam Lackorzynski]

Hi,

On Thu Sep 09, 2021 at 16:01:18 +0200, Matthieu Fatrez wrote:
> Thanks Adam. I will try to use uvmm. 
> 
> Do you plan to have the 64bit/rpi4 ready? And when if planned. 

It is so far that VMs run, e.g., the VM examples will also run on the
rpi4.


Adam

> > Le 9 sept. 2021 à 08:40, Adam Lackorzynski  a 
> > écrit :
> > 
> > Hi Matthieu,
> > 
> >> On Mon Sep 06, 2021 at 22:35:25 +0200, Matthieu Fatrez wrote:
> >> I tried to use l4re hypervisor on raspberry pi 4. Prebuild image works but
> >> not for my needs.
> >> In fact, I want to use l4re running on raspberry pi 4 (aarch64) with 1 or
> >> more tasks (such hello, ...) and 1 linux 64 bits vm like debian, fedora or
> >> opensuse.
> >> 
> >> When I try to compile :
> >> - x86_64 (native) : fiasco, l4re, l4linux no problem,
> >> - rpi3, 32bit (cross compile) : fiasco, l4re, l4linux no problem
> >> - rpi4 64bit (cross compile) : fiasco l4re OK but nothing for l4linux :-(
> >> 
> >> In this last case, obj/l4linux directory is empty. Nothing created. Normal?
> >> 
> >> Do you have some advices for me please?
> > 
> > Yes, I did not yet add L4Linux to the 64bit/rpi4 builds although it is
> > actually also available for arm64.
> > 
> > Anyway, what you saw in the prebuilt images running Linux is based on
> > "real" virtualizationn using Arm's virtualization extensions rather than
> > L4Linux which is using a different approach. I believe you should be
> > looking into this, based on uvmm's capabilities to run unmodified Linux.
> > 
> > 
> > Adam
> > 
> > ___
> > l4-hackers mailing list
> > l4-hackers@os.inf.tu-dresden.de
> > https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
> 
> ___
> l4-hackers mailing list
> l4-hackers@os.inf.tu-dresden.de
> https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Adam
-- 
Adam a...@os.inf.tu-dresden.de
  Lackorzynski http://os.inf.tu-dresden.de/~adam/

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: l4re + l4linux on aarch64 - raspi4

[Adam Lackorzynski]

Hi Matthieu,

On Mon Sep 06, 2021 at 22:35:25 +0200, Matthieu Fatrez wrote:
> I tried to use l4re hypervisor on raspberry pi 4. Prebuild image works but
> not for my needs.
> In fact, I want to use l4re running on raspberry pi 4 (aarch64) with 1 or
> more tasks (such hello, ...) and 1 linux 64 bits vm like debian, fedora or
> opensuse.
> 
> When I try to compile :
> - x86_64 (native) : fiasco, l4re, l4linux no problem,
> - rpi3, 32bit (cross compile) : fiasco, l4re, l4linux no problem
> - rpi4 64bit (cross compile) : fiasco l4re OK but nothing for l4linux :-(
> 
> In this last case, obj/l4linux directory is empty. Nothing created. Normal?
> 
> Do you have some advices for me please?

Yes, I did not yet add L4Linux to the 64bit/rpi4 builds although it is
actually also available for arm64.

Anyway, what you saw in the prebuilt images running Linux is based on
"real" virtualizationn using Arm's virtualization extensions rather than
L4Linux which is using a different approach. I believe you should be
looking into this, based on uvmm's capabilities to run unmodified Linux.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: L4Re on Raspi 3

[Adam Lackorzynski]

Hi Paul,

On Sat Jun 19, 2021 at 02:00:18 +0200, Paul Boddie wrote:
> On Monday, 14 June 2021 22:21:50 CEST Adam Lackorzynski wrote:
> > 
> > On Mon Jun 14, 2021 at 13:15:22 +0200, Yanneck Geiger wrote:
> > > Hello, unfortunately I can't get L4Re running on the Raspberry Pi 3 / 3+
> > > using the provided Guider (https://l4re.org/rpi.html). I did the 64-Bit
> > > setup accordingly with the provided U-Boot and the ready-to-use images.
> > > U-Boot itself seems to work fine and I can set the IPs ...
> 
> First of all, apologies for interrupting this thread, but I either forgot 
> about or overlooked the above guide to L4Re on the Raspberry Pi, so I decided 
> to return to an attempt I made two years ago to get things working on the Pi 
> Zero. Although reviving the old thread might be an option, maybe some of my 
> new experiences might be informative here.
> 
> In any case, thanks for bringing the above document to my attention! :-)
> 
> > > Unfortunately I don't know the address to load the .elf file so I'm using
> > > the following commands: "tftpboot bootstrap_hello_rpi3.elf" and "bootelf".
> > > After entering "bootelf" the output on serial spews garbage and after a
> > > few seconds the same garbage is "printed" in an interval of around 1
> > > second. Am I doing anything wrong or am I missing something?
> > 
> > That actually does not sound too bad, the periodic output that comes
> > once a second is probably "Hello World!" being printed, i.e., it worked
> > principally. When there is garbage maybe the Baud rate of the UART is
> > wrong. We're using 115200 Baud, is there anything different in your
> > setup?
> 
> The short version of a much longer story whose details might be pertinent to 
> the above is that care must be taken with the UART configuration on these 
> boards. Although the Pi 3 and 3+ are mentioned above, while I am using the Pi 
> Zero, I did initially think that I might set up Fiasco to use the existing 
> definition for the Pi Zero W. Unfortunately, the UART defined for the Pi Zero 
> W is the 16550, whereas the Pi Zero may be more similar to the original Pi 
> (or 
> Pi 1) and use the PL001.

Ok, thanks, bootstrap is currently not handling this, I'll try to add
it.
 
> (See src/fiasco/src/kern/arm/bsp/rpi/Kconfig for the board configuration 
> options.)
> 
> For me, the effect of using the wrong UART involved the initial bootstrap 
> messages being shown normally followed by subsequent messages appearing very, 
> very slowly - one or two characters per second - and with a certain amount of 
> corruption. Once I had realised my mistake, the problem went away and the 
> output was as expected.

The previous' problem was actually a wrong speed seeting that confuses
the UART. It also happens in Linux if wrong.
 
> Rewinding to the beginning, reviewing the whole process, and reflecting on my 
> earlier experiences, what I discovered this time round was that the Debian 
> toolchains for ARM cross-compilation are definitely unsuitable for the Pi 
> Zero 
> and early generation Pi models (with the BCM2835). Although the CPU options 
> can be given to the toolchains, the Debian toolchains provide built-in 
> function implementations that are compiled for ARMv7. Thus, booting a payload 
> compiled with these toolchains will eventually reach code that will not work 
> on these early SoCs, whereas models using the later SoCs will be fine.

Yes, common problem.

> (Here, the use of U-Boot is helpful because a register dump is produced that 
> indicates where the problem lies. In the first instance, the compiler was 
> generating ARMv7 code because I had not set up the appropriate configuration 
> options in L4Re. Subsequently, the unsuitable built-in or bundled code was 
> encountered and identified. I don't know why U-Boot wasn't this helpful 
> before, though.)
> 
> So, I found that building an ARMv6 toolchain using Buildroot 2020.11, with 
> C++ 
> support enabled, was sufficient, specifically these options:
> 
> Target options  --->
> Target Architecture (ARM (little endian))
> Target Binary Format (ELF)
> Target Architecture Variant (arm1176jzf-s)
> Target ABI (EABIhf)
> Floating point strategy (VFPv2)
> ARM instruction set (ARM)
> 
> Toolchain  --->
> Enable C++ support
> 
> I had to get my head around the build systems of L4Re, Fiasco and this 
> snapshot to then set everything up appropriately. This seemed to involve 
> defining the following files:
> 
> src/fiasco/src/templates/globalconfig.out.arm-rpiz
> 
> 
> CONFIG_ARM=y
> CONFIG_PF_RP

Re: L4Re on Raspi 3

[Adam Lackorzynski]

Hi Yanneck,

On Mon Jun 14, 2021 at 13:15:22 +0200, Yanneck Geiger wrote:
> Hello, unfortunately I can't get L4Re running on the Raspberry Pi 3 / 3+
> using the provided Guider (https://l4re.org/rpi.html). I did the 64-Bit
> setup accordingly with the provided U-Boot and the ready-to-use images.
> U-Boot itself seems to work fine and I can set the IPs ...
> Unfortunately I don't know the address to load the .elf file so I'm using
> the following commands: "tftpboot bootstrap_hello_rpi3.elf" and "bootelf".
> After entering "bootelf" the output on serial spews garbage and after a few
> seconds the same garbage is "printed" in an interval of around 1 second.
> Am I doing anything wrong or am I missing something?

That actually does not sound too bad, the periodic output that comes
once a second is probably "Hello World!" being printed, i.e., it worked
principally. When there is garbage maybe the Baud rate of the UART is
wrong. We're using 115200 Baud, is there anything different in your
setup?


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Resource sharing

[Adam Lackorzynski]

Hi,

On Sun Apr 04, 2021 at 12:51:25 +0200, John Galt wrote:
> Is it possible to share resources between two VMs running Linux?
> After defining the io_bus and the io configuration, just one VM is getting
> access to the resource while the other displays:
> ERROR: binding irq 34, result is -1 (operation not permitted)
>  "VMM: FATAL: Device creation for virtual device failed".
> Terminate called after throwing an instance of 'N2L413Runtime_errorE'
> what: Operation not permitted: cannot bind to IRQ

That looks like you're trying to share the same hardware interrupt with
multiple VMs. I'm not sure how this can work? Shall both VMs get the
same hardware interrupt in parallel, i.e. the hardware interrupt should
fire twice? What's the model you're thinking of here?


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Build tutorial for the Zynq Ultrascale+

[Adam Lackorzynski]

Hi,

Please use -m 2048 for QEMU as the virtual platform is using 2GB.

Adam

On Thu Apr 01, 2021 at 22:02:28 +, Jorge Miguel Perez Utrera wrote:
> Hi,
> 
> I am trying to build the first tutorial, but cross-compiling for the Zynq 
> Ultrascale+. However, when I run "make E=hello qemu" I get the next output:
> 
> Image size(s) in bytes:
> bootstrap_hello.elf:  1275456
>   Start address: 0x100
>   --> Build-Nr: 5
> QEMU-cmd: qemu-system-aarch64 -kernel 
> /home/jperezu/build-arm/images/bootstrap.elf -serial stdio -M xlnx-zcu102 
> -cpu cortex-a53 -m 1024 -display none
> 
> L4 Bootstrapper
>   Build: #5 Thu Apr  1 23:34:21 CEST 2021, 10.2.0
>   Scanning up to 2048 MB RAM, starting at offset 32MB
>   Memory size is 2048MB ( - 7fff)
>   RAM:  - 7fff: 2097152kB
>   Total RAM: 2048MB
>   Scanning fiasco
>   Scanning sigma0
>   Scanning moe
>   Moving up to 5 modules behind 110
>   moving module 04 { 10ad000-10d99bf } -> { 1199000-11c59bf } [182720]
>   moving module 03 { 108f000-10aca0f } -> { 117b000-1198a0f } [121360]
>   moving module 02 { 105b000-108e54f } -> { 1147000-117a54f } [210256]
>   moving module 01 { 1055000-105abef } -> { 1141000-1146bef } [23536]
>   moving module 00 { 1014000-1054cef } -> { 110-1140cef } [265456]
>   Loading fiasco
>   Loading sigma0
>   Loading moe
>   find kernel info page...
>   found kernel info page (via ELF) at 3000
> Regions of list 'regions'
> [ 1000, 4afff] {4a000} Kern   fiasco
> [4b000, 4b0ef] {   f0} Root   mbi_rt
> [   10,10a46f] { a470} Sigma0 sigma0
> [   14,170e43] {30e44} Root   moe
> [   171e48,17eed7] { d090} Root   moe
> [  100,   1012d63] {12d64} Boot   bootstrap
> [  10131ef,   10135af] {  3c1} Boot   modinfo
> [  117b000,   11c59bf] {4a9c0} Root   Module
>   found kernel options (via ELF) at 4000
>   Sigma0 configip:00100474 sp:
>   Roottask config  ip:00141694 sp:
>   Starting kernel fiasco at 16b0
> Hello from Startup::stage2
> Number of IRQs available at this GIC: 192
> 
> Assertion failed at /home/jperezu/fiasco/src/kern/irq_mgr_multi_chip.cpp:67: 
> mask
> 
> Does anyone know what could be the problem?
> 
> I am using CROSS_COMPILE:=aarch64-linux-gnu- to build and  ARM64 
> architecture, ARMv8a CPU variant, Xilinx Zynq Ultrascale+, and CPU Arm 
> Cortex-A53  in the configuration.
> 
> 
> Thank you for your help.
> 
> 
> Sincerely,
> 
> Jorge

> ___
> l4-hackers mailing list
> l4-hackers@os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Boot problems with Fiasco.OC on the NanoPC-T3 Plus

[Adam Lackorzynski]

On Thu Jan 14, 2021 at 23:54:38 +0100, Matthias Lange wrote:
> On [14-01-2021 23:24], Andreas Resch wrote:
> > Hello everyone,
> > 
> > as part of a practical course at my university my group has to bring 
> > Fiasco.OC and L4re to the NanoPC-T3 Plus which is powered by the S5P6818 
> > from Samsung/Nexell.
> > We’re currently stuck on multiple fronts, and as a sort of last resort I’m 
> > asking here for help, I hope you don’t mind.
> > 
> > 1. Problem - The RAM
> > We implemented a working uart driver for our board and when using all 
> > (seemingly) correct values for the RAM region (as stated in the TRM is 
> > located from 0x4000 to 0xc000) our SBC only boots up to the message 
> > “Hello from Startup::stage2” and then hangs in the function 
> > Kmem_alloc::Kmem_alloc() , we believe because the value of Map_base is with 
> > 0x4000 far too big but haven’t found a way to fix this issue 
> > whilst keeping the correct RAM region. Does someone have an idea why 
> > setting the incorrect RAM region results in more progress in the boot 
> > process (as stated in the following paragraph)?

0x4000 is a virtual address, and is the start of the memory
mapping in Fiasco. This looks like the memory is already used in the
platform, as Matthias already suspected.

> The reason most likely is that the kernel touches a memory region that is
> reserved or used by someone else (e.g. by ARM Trusted Firmware). The TRM
> usually only tells you the hardware features. You might get a better insight
> by looking into the device tree (e.g. from Linux) for your platform. Look out
> for the "memory" node.

But use the one on the target as the bootloader (probably) fills out those 
fields.

> > 2. The Timer - or the lack thereof
> > When we were experimenting with the RAM size we found that when setting to 
> > to 3GB starting from 0x4000 we achieve slightly more output. Right up 
> > to ARM generic timer, which seems to not work on this particular board, we 
> > decided to implement our own timer driver, now we are stuck at Panic: Trace 
> > buffer size unaligned which, upon investigation, was an output from the 
> > JDB; by disabling the debugger we could again get more output, seen below. 
> > The clock doesn’t seem to start counting and I currently have no idea how 
> > to implement my own clock driver, I was hoping the generic clock would 
> > suffice.
> 
> Here I would also recommend looking into the device tree for figuring out the
> available timers on the platform. Then you could either sneak into the Linux
> driver or use the TRM to implement your own driver.

TBH, I wouldn't believe the generic timer would not work.
General hint, look at the running OS on the box, i.e., Linux, such as
dmesg, /proc etc, it tells many things about the platform.



Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Fiasco.OC won't boot on Aaeon FWS2360 ...

[Adam Lackorzynski]

Hi Andreas,

On Mon Dec 14, 2020 at 15:35:08 -0800, Andreas Steinmetzler wrote:
> in some experiments I'm trying to run Fiasco/L4re on a Aaeon FWS2360
> (https://www.aaeon.com/en/p/desktop-network-appliance-fws-2360) with an
> Intel Atom C3558. Unfortunately Fiasco gets stuck on boot when trying to
> start the different cores of the processor (I'm using the latest published
> l4re-snapshot-20.10.0). For this test I'm using the "hello world" ISO build
> with this command
> 
>     make E=hello grub2iso MODULE_SEARCH_PATH="${PWD}/../build-fiasco-amd64"
> 
> The ISO image boots fine on another amd64 system.  After adding some
> printf()'s to the file kernel_thread-ia32.cpp it looks to me that things get
> stuck with this call:
> 
>   // Send IPI-Sequency to startup the APs
>   Apic::mp_startup(Cpu::boot_cpu(), Apic::APIC_IPI_OTHERS, tramp_page);
> 
> as it does not return anymore ... any hint how to debug this or drill down
> to get more information and the AtomC3558 system to boot?

The first thing I'd check is whether it runs on a single core only at
least (i.e. commenting out the mp_startup call)?
Then it's probably good diving into mp_startup to see at which point
therein it is hanging. Then we'll see whether this tells us something.


Thanks, Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Raspberry Pi SD access

[Adam Lackorzynski]

Hi Mohamed,

on the rpi4 there's a global offset used in Linux's device tree (check
for ranges statement in bcm2711.dtsi). The address of the sdhc/mmc
controller rather is 0xfe30. Also use 0x7e + 32 for the IRQ to
consider it's an SPI.



Adam

On Wed Oct 07, 2020 at 20:28:44 +0200, Mohamed Nasr wrote:
> I am trying to access SD card of Raspberry Pi 4 But the IO fail with
> IO  | new iomem region: p=007e00 v=40 s=40
> (bmb=0x24370)
> IO  | map mem: p=007e30 v=70 s=1000: failed(-12)
> VMM: FATAL: Insufficient memory
> 
> Can you help me on what I am missing?
> 
> My configurations are:
> 
> --- io.cfg --
> local Res = Io.Res
> local Hw = Io.Hw
> local add_children = Io.Dt.add_children
> 
> add_children(Io.system_bus(), function()
> mmc = Hw.Device(function()
> compatible = { "brcm,bcm2835-mmc" };
> Resource.reg0 = Res.mmio(0x7e30, 0x7e3000FF);
> Resource.irq0 = Res.irq(0x7e);
> Property.flags = Io.Hw_device_DF_dma_supported;
> end)
> end)
> 
>  vm_hw.vbus ---
> Io.add_vbusses
> {
>   vm_hw = Io.Vi.System_bus(function()
> MMC = wrap(Io.system_bus().mmc);
>   end);
> }
> 
>  rpi_mmc.ned -
> local L4 = require("L4");
> local l = L4.default_loader;
> 
> vbus_l4linux = l:new_channel();
> 
> -- Start io & flash memory
> l:start({
> caps = {
> sigma0 = L4.cast(L4.Proto.Factory,
> L4.Env.sigma0):create(L4.Proto.Sigma0),
> icu = L4.Env.icu,
> vm_hw = vbus_l4linux:svr()
> },
> log = {"IO", "y"}
> }, "rom/io rom/io.cfg rom/vm_hw.vbus -vv");
> 
> l:startv({
> caps = {
> ram = L4.Env.user_factory:create(L4.Proto.Dataspace, 256 * 1024 *
> 1024, 7, 21):m("rws");
> vbus = vbus_l4linux;
> },
> log = L4.Env.log:m("rws")
> }, "rom/uvmm", "-v", "-krom/image.bin",
> "-rrom/ramdisk-arm64.rd",
> "-drom/virt-arm_virt-64-2.dtb",
> "-cconsole=hvc0 ramdisk_size=1 root=/dev/ram0 rw");
> 
> --- modules.list -
> entry rpi-mmc
> kernel fiasco -serial_esc
> roottask moe rom/rpi-mmc.ned
> module uvmm
> module l4re
> module ned
> module virt-arm_virt-64-mod.dtb
> module ramdisk-arm64.rd
> module rpi-mmc.ned
> module image.bin
> module io
> module io.cfg
> module vm_hw.vbus
> 
> - I added mmc to device tree -
> mmc@7e30 {
>compatible = "brcm,bcm2835-mmc", "brcm,bcm2835-sdhci";
>reg = <0x7e30 0x100>;
>interrupts = <0x0 0x7e 0x4>;
>clocks = <0x3 0x1c>;
>dmas = <0xa 0xb>;
>dma-names = "rx-tx";
>brcm,overclock-50 = <0x0>;
>status = "disabled";
>pinctrl-names = "default";
>pinctrl-0 = <0x19>;
>bus-width = <0x4>;
>phandle = <0x2d>;
> };
> 
> 
> I tested Linux kernel with uvmm module and without IO module and it was
> working perfectly. I compiled it with the following options on:
> 
>  CONFIG_VIRTIO=y
>  CONFIG_VIRTIO_PCI=y
>  CONFIG_VIRTIO_BLK=y
>  CONFIG_BLK_MQ_VIRTIO=y
>  CONFIG_VIRTIO_CONSOLE=y
>  CONFIG_VIRTIO_INPUT=y
>  CONFIG_VIRTIO_NET=y
> 
> -
> boot log messages are:
> 
> L4 Bootstrapper
>   Build: #104 Wed Oct  7 20:14:57 EET 2020, 7.5.0
>   Raspberry Pi Model 4B, Rev 1.1, 4096MB, SoC BCM2711 [c03111]
>   Warranty intact, OTP reading allowed, OTP programming allowed,
> Overvoltage allowed
>   RAM:  - 3b3f: 970752kB
>   RAM: 4000 - fbff: 3080192kB
>   Total RAM: 3956MB
>   Scanning fiasco
>   Scanning sigma0
>   Scanning moe
>   Moving up to 14 modules behind 110
>   moving module 13 { 254-25400bb } -> { 262c000-262c0bb } [188]
>   moving module 12 { 253f000-253f555 } -> { 262b000-262b555 } [1366]
>   moving module 11 { 230c000-253e187 } -> { 23f8000-262a187 } [2302344]
>   moving module 10 { 15b3000-230b9ff } -> { 169f000-23f79ff } [13994496]
>   moving module 09 { 15b2000-15b22ea } -> { 169e000-169e2ea } [747]
>   moving module 08 { 1232000-15b1fff } -> { 131e000-169dfff } [3670016]
>   moving module 07 { 1231000-123176c } -> { 131d000-131d76c } [1901]
>   moving module 06 { 11be000-123041f } -> { 12aa000-131c41f } [468000]
>   moving module 05 { 11a-11bd14f } -> { 128c000-12a914f } [119120]
>   moving module 04 { 119f000-119fdbf } -> { 128b000-128bdbf } [3520]
>   moving module 03 { 10eb000-119e957 } -> { 11d7000-128a957 } [735576]
>   moving module 02 { 10ad000-10eaf0f } -> { 1199000-11d6f0f } [253712]
>   moving module 01 { 10a3000-10ac947 } -> { 118f000-1198947 } [39240]
>   moving module 00 { 1014000-10a24c7 } -> { 110-118e4c7 } [582856]
>   Loading fiasco
>   Loading sigma0
>   Loading moe
>   find kernel info page...
>   found kernel info page (via ELF) at 3000
> Regions of list 'regions'
> [0,   fff] { 

Re: L4Linux with hardware access on amd64 PC ...

[Adam Lackorzynski]

Hi,

On Mon Aug 17, 2020 at 22:35:11 -0700, Andreas Steinmetzler wrote:
> Hi,
> 
> I'm experimenting with the TuD Snapshot release 2020.07.1 and can compile
> and run Fiasco, L4re and L4Linux in their basic configurations (amd64
> architecture) using the default l4lx.cfg file of the distribution.
> 
> As this is not all that useful, I was looking in getting the system use the
> available hardware. Based on snippets I found on the internet and the
> example config files, I created the following cfg and devs files, but now
> L4Linux immediately runs into an unhandled exception (full boot log at the
> end of this eMail).
> 
> Was wondering if someone from the mailing list can share a set of config
> files which would allow to get L4Linux up and using at least some of the
> basic hardware like network and disks on a typical PC board. In my current
> experiments I'm using the following config files (see below).
> 
> Any help or pointers are appreciated!

An error like this should not happen, irrespective of any config.
I've uploaded 2020.08.0 and checked that the amd64 L4Linux configs in
the L4Linux-mag setup works and sees PCI devices.
Could you work from that config?



Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: uvmm support for AMD-V

[Adam Lackorzynski]

Hi,

On Wed Jul 15, 2020 at 20:49:14 -0700, Andreas Steinmetzler wrote:
> I followed the tutorials on github to get a basic L4re environment compiled
> and running (Hello World) on a embedded x86 board (more specifically APU2
> https://www.pcengines.ch/apu2.htm). Everything worked fine - really nice
> tutorial.
> 
> Next, I was using the single Linux VM guide to move on getting to more
> interesting stuff and uvmm stopped with the following error message
> 
>     "VMM: FATAL: Unsupported HW virtualization type.: Invalid request"
> 
> While reading more of the documentation I looks to me that uvmm is not
> supporting AMD-V (last sentence in
> https://github.com/kernkonzept/uvmm/blob/master/doc/uvmm.dox).
> 
> Wondering if there is a fundamental shortcoming of the AMD-V extensions or
> is it just missing because nobody worked on it?

There's nothing fundamental, it's just as you guessed, someone would
need to work on it.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Alignment checking on ARM

[Adam Lackorzynski]

Hi,

this setting is only relevant for bootstrap. The kernel has its own
(configurable) alignment checking setting.
For bootstrap it is merely a historic precaution thing and with today's
compilers / CPUs it should be removed, at least for v6+.


Adam

On Mon Nov 25, 2019 at 15:03:37 +, Al Grant wrote:
> I'm building L4 on ARM using GCC 7.4.0 on Cortex-A15. ARCH-arm/head.cc enables
> alignment checking (sets SCTLR.A=1), but we then see an alignment check fault 
> in
> init_kip_f.cc. With the default compiler options, the GCC cross tools will 
> assume
> alignment checking is _not_ enabled and will generate code that may use 
> unaligned
> access.
> 
> We can override this by compiling with -mno-unaligned-access. But it would be
> good to know what is intended. If the intention is to be able to run 
> "mainstream"
> open-source code in userspace, i.e. build code using the standard Linux ABI,
> we ought to allow that, and not enable alignment checks in SCTLR. Some code
> will not be fixed by compiling -mno-unaligned-access (because it casts 
> arbitrary
> unaligned pointers to word-sized types etc.)
> 
> So my question is, what is the intention?
> 
>   (1) fault unaligned access in kernel and userspace
> 
>   (2) fault unaligned access in kernel but allow in userspace
> 
>   (3) allow unaligned access in kernel and userspace
> 
> I'm assuming it can't be (3) as the bootstrap code explicitly enables 
> alignment checking.
> (2) would be a good compromise, it would enable alignment checks which would 
> pick
> up some possible faults in the kernel, but it would improve portability of 
> ordinary
> open-source packages in userspace.
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Kernel Helpers segmentation fault

[Adam Lackorzynski]

Hi,

the case for cmpxchg64 is currently not handled, that's why it faults.
Could you make me available the go program or at least the code around
the call to __kuser_cmpxchg64?


Adam

On Wed Nov 13, 2019 at 08:45:22 +0530, Sateesh K wrote:
> Hi,
>   My setup is as follows:
>   l4linux 4.19.0-l4
>   Fiasco.OC
>   Raspberry Pi 3 Model B
> 
>   I am running a helloworld.go program which is causing the following stack
> trace.
> 
> (gdb) bt full
> #0  0x0f60 in ?? ()
> No symbol table info available.
> #1  0x0001143c in kernelCAS64 ()
> at /usr/local/go/src/sync/atomic/asm_linux_arm.s:112
> No locals.
> #2  0x0001103c in sync/atomic.loadUint64 (addr=0x10442080, val=48)
> at /usr/local/go/src/sync/atomic/64bit_arm.go:10
> No locals.
> #3  0x00071f44 in internal/poll.(*fdMutex).rwlock (mu=0x10442080,
> read=false,
> ~r1=160) at /usr/local/go/src/internal/poll/fd_mutex.go:130
> mutexBit.lo = 4
> mutexMask.hi = 2147481600
> mutexMask.lo = 0
> mutexSema = 0x1044208c
> mutexWait.hi = 2048
> mutexWait.lo = 0
> #4  0x00072314 in internal/poll.(*FD).writeLock (fd=0x10442080, ~r0=...)
> at /usr/local/go/src/internal/poll/fd_mutex.go:237
> No locals.
> #5  0x00072a94 in internal/poll.(*FD).Write (fd=0x10442080, p=..., ~r1=0,
> ~r2=...) at /usr/local/go/src/internal/poll/fd_unix.go:243
> n = -1212420096
> nn = 118
> --Type  for more, q to quit, c to continue without paging--c
> #6  0x00073958 in os.(*File).write (b=..., err=..., f=0x1040c0f0, n=2729821
> 44) at /usr/local/go/src/os/file_unix.go:243
> No locals.
> #7  0x00072ffc in os.(*File).Write (b=..., err=..., f=0x1040c0f0, n=0) at
> /usr/local/go/src/os/file.go:144
> err.data = 0x12c0e8  ""
> err.itab = 0x8b7a8  "\004"
> ~r2.data = 0x10456014 ""
> ~r2.itab = 0x0
> #8  0x0008b7fc in fmt.Fprintln (a=..., err=..., n=233960, w=...) at
> /usr/local/go/src/fmt/print.go:255
> p = 0x10456080
> #9  0x0008b888 in fmt.Println (a=..., err=..., n=0) at
> /usr/local/go/src/fmt/print.go:264
> No locals.
> #10 0x000916c0 in main.main () at /home/pi/hello.go:6
> No locals.
> 
>  On further analysis, I find that segmentation fault is at
> 
> __kuser_cmpxchg64.
> 
> I have enabled CONFIG_KUSER_HELPERS=y when building the linux kernel.
> 
> Any hint please on how to proceed.
> 

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Fiasco.OC-UX on MIPS?

[Adam Lackorzynski]

Hi Paul,

On Fri Aug 30, 2019 at 13:43:10 +0200, Paul Boddie wrote:
> On Thursday 29. August 2019 12.31.49 Paul Boddie wrote:
> > On Wednesday 28. August 2019 16.47.31 Sarah Hoffmann wrote:
> > > On 8/28/19 4:07 PM, Paul Boddie wrote:
> > > > make O=mybuild qemu E=hello QEMU_OPTIONS='-nographic -M malta'
> > > 
> > > You must also add the CPU type for Mips QEMU. For Mips 32 R2 this would
> > > be:
> > >   -M malta -cpu P5600
> > > 
> > > (Unrelated, I usually also set: -nographic -monitor none -serial stdio
> > > That gives you the output directly on the console, no extra windows.)
> > 
> > This is very useful to know. I will give it a try and report back on the
> > outcome.
> 
> Well, the short story is that I got it to work, so many thanks are due for 
> the 
> help. Of course, had I looked at the Makeconf.boot.example file, I would have 
> learned about the necessary -cpu option, but that was not the only obstacle 
> here.
> 
> (The -serial stdio option is apparently the default, but with qemu having so 
> many options and switches, I imagine that it is worth specifying in case 
> defaults change or option combinations have side-effects.)
> 
> What I found was that the bootstrap code was not completing. I added the -S 
> option to qemu to stop the CPU at start-up time, and I used the -s option to 
> set up remote debugging. Then, I ran gdb in another terminal, using the 
> following commands in the gdb session:
> 
> target remote localhost:1234
> set architecture mips:isa32r2
> hbreak *0x802d
> c
> 
> Using the si command to step through the code, it appeared that execution 
> failed at the point where a load was first made relative to the gp register. 
> Using the info registers command, I could see that the initialisation of this 
> register was not done properly. And looking at the registers at the start of 
> bootstrap routine execution, I could see that t9 was being used to initialise 
> gp but had not been set up.
> 
> If this sounds familiar it is because there were similar issues with other 
> assembly language routines that I ended up patching to run L4Re on the 
> different Ingenic devices I have been using. However, I never needed to patch 
> this code. An explanation for this might be that on the actual hardware, U-
> Boot is involved and it might well initialise t9 when jumping to the 
> bootstrap 
> code. Here, the CPU firmware does not set up t9.
> 
> Previously, it was noted that other compilers had been used to develop L4Re 
> for MIPS platforms, and I suspect that there must be a difference in the 
> behaviour of the .cpload macro between the assemblers employed by these 
> compilers. With my Debian-provided GCC toolchains, .cpload doesn't seem to be 
> setting up t9, and it may be that it will only do so if there is a frame 
> declared, which is not the case in the code affected by this problem (in the 
> different places in L4Re).
> 
> (I would have to remind myself about what the .cp* macros actually do because 
> I don't remember at this point in time.)
> 
> So maybe the approach for initialising t9 could be reviewed so that it is not 
> toolchain-specific. Here, as before, I ended up doing something like this:
> 
> _start:
> lui $25, %hi(_realstart)
> ori $25, $25, %lo(_realstart)
> _realstart:
> ...

Thanks for the update!
Indeed it seems to work for me without any adjustments both with mips32
on malta and with mips64 on the boston platform (both with a
pretty recent QEMU). I probably using the "wrong" compiler. I'll try to
follow up here once sid's cross compilers are installable again.



Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Full virtualization on Raspberry PI 4

[Adam Lackorzynski]

On Thu Aug 29, 2019 at 23:06:40 +0200, clim atisefr wrote:
> I know the Raspberry PI 3 does not support the full virtualization and only
> para-virtualization is supported.
> It seems that the Raspberry PI 4 with the Broadcom 2711 (Quad-core
> Cortex-A72 ARM v8 64-bit SoC @ 1.5 GHz) may support it.
> Is there any development to support this platform with L4RE ? or any hint
> to start it ?

There's activity for rpi4, for the obvious reasons you mention. However,
u-boot with network booting or USB still doesn't seem to be there but
would be nice to have to avoid SD card shuffling. Eventually it will
happen...


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Fiasco.OC-UX on MIPS?

[Adam Lackorzynski]

Hi Paul,

UX is an interesting way of virtualizing a kernel and gives interesting
insights into both Fiasco and Linux. I guess with some work it would be
well possible to make this work on MIPS.
But, before going on this endeavor what about QEMU? It should be much
quicker and simpler to run it through QEMU,


Adam

On Mon Aug 12, 2019 at 00:35:10 +0200, Paul Boddie wrote:
> Having been using the MIPS-based CI20 single-board computer a bit more 
> recently, I wondered if it might be possible to get the user mode Fiasco 
> kernel working on MIPS. As I understand it, the UX variant of Fiasco only 
> works on IA32 (x86, 32-bit), and although MIPS isn't particularly popular, it 
> would at least be useful to me.
> 
> However, having looked at the code, it seems like quite a bit of work to 
> unpick the IA32-related aspects from the UX-specific code. There appears to 
> be 
> a fair amount of descriptor table usage, for instance, and despite reading 
> the 
> thesis about it [1], I don't feel I have a decent-enough overview of what 
> would really need doing to port the UX variant to another architecture.
> 
> So far, I've reviewed the MIPS code which employs a Proc abstraction and has 
> a 
> number of functions in the Mips namespace which could be replaced to maintain 
> a "virtual" processor in the user mode kernel. It seems that the existing UX 
> variant employs an Emulation abstraction for things like the processor 
> status, 
> and perhaps the Proc abstraction could take over these responsibilities. 
> Quite 
> how many privileged CPU registers would need maintaining probably depends on 
> how much other code would still be using them.
> 
> This brings me to an awkward difference between IA32 and MIPS: that of the 
> page fault handling and memory management. MIPS has no inherent notion of 
> page 
> table structures that are held by the CPU and consulted by it when addressing 
> errors occur. Instead, an exception handler is invoked to populate various 
> privileged registers and to perform privileged instructions. However, it 
> seems 
> to me that Fiasco needs to maintain a page directory, anyway, and that the 
> user mode kernel is not likely to be attempting the actual memory management 
> operations, either.
> 
> Consequently, it is tempting to think that the existing UX code might also be 
> usable on MIPS. This would actually involve replacing a dedicated page 
> directory implementation that appears to be present for MIPS with the one 
> that 
> other architectures appear to use. One detail that might need preserving is 
> the code path dealing with TLB lookups (as a consequence of addressing 
> errors), but it may be the case that page faults are dealt with more directly 
> when signals arrive - perhaps what the UX code does now - and that the TLB 
> exception vectors will remain unused.
> 
> When considering some of these issues, I did wonder about the role of certain 
> architecture-specific aspects of the MIPS implementation. The existing UX 
> code 
> seems to deal with "vectors" and seems rather connected to interrupt 
> descriptor tables (or their emulation). On MIPS, exception vectors are 
> typically resident in kernel memory and have specific addresses.
> 
> It seems to me that the handling of exceptions (caused by signals) would 
> direct execution via these vectors and thus preserve the existing exception.S 
> implementation, albeit relocated to user memory. I guess the alternative 
> would 
> involve rewriting such things and using emulated processor features directly 
> instead of trapping and handling privileged instructions. (I did also wonder 
> to what extent the assembly language could also be migrated to C++ even for 
> the native MIPS implementation.)
> 
> That brings me to a discussion about the purpose of the user mode kernel 
> variant. As I understand it, one of the aims is to preserve architecture-
> specific code so as to give that code some possible testing and general 
> exercise: it might actually help in the development of the kernel more 
> generally. Is this a reasonable understanding? Initially, I thought that UX 
> would actually be architecture-neutral (in terms of mechanisms; obviously the 
> code would be native), but it appears that a stated aim is to be able to run 
> existing binaries unchanged. Would an architecture-neutral UX variant make 
> any 
> sense?
> 
> I suppose I could go on and on, here, but as far as I can tell there are 
> quite 
> a few things that would need deciding in order to have a realistic chance of 
> ever getting this working, amongst others that I will have forgotten or not 
> considered...
> 
>  * Redefining the memory layout for kernel and task processes (so as to work
>within the host system constraints)
> 
>  * Separating generic and native functionality for various central
>abstractions
> 
>  * Replacing the memory management with a mechanism similar to that employed
>by the existing UX code
> 
>  * Defining a 

Re: Enable L4Linux network access on Raspberry Pi-b.

[Adam Lackorzynski]

0x0>;  
>   
>   
>   
> usbether@1 {  
>   
> compatible = "usb424,ec00";   
>   
> reg = <0x1>;  
>   
> phandle = <0x6e>; 
>   
> };
>   
> };
>   
> };   
>  
> 
> Is this sufficient to do IO config as following rpi_devices.io?
> Within rpi_devices.io, I defined a named vBUS as l4lx.   How does L4linux 
> client know this "l4lx" vBUS is for me?  Should I need configure it within 
> L4linux somewhere?

No, this is configured in the ned script.
Please look at l4/conf/examples/l4lx-gfx.cfg and
l4/conf/examples/l4lx-x86.io for an example how those vbus names in the
io config are linked to the 'vbus' cap of L4Linux.

Might be that the USB controller needs access to some more MMIO/IRQs,
you'll see this when running it I guess.


Adam

> 
> 
> local Res = Io.Res
>   
> local Hw = Io.Hw  
>   
> local hw = Io.system_bus()
>   
>   
>   
> -- create a virtual bus for client with its name as 'l4lx'
>   
> -- Give it access to NIC device   
>   
> -- 'l4lx is name of vbus  
>   
> Io.add_vbus("l4lx", Io.Vi.System_bus  
>   
> { 
>   
>   -- add device which matches the compatibility ID (CID)  
>   
>   -- usb_net_smsc9514 for rpi-3b  
>   
>   -- 'usb424,ec00'
>   
>   -- NIC = wrap(hw:match("usb424,ec00")); 
>   
>   NIC = wrap(hw.NIC); 
>   
> })
>   
>   
>   
> Io.hw_add_devices(function()  
>   
>   
>   
>   -- create a new named NIC device
>   
>   NIC = Hw.Device(function()  
>   
> Property.hid = "smsc9514";
>   
> compatible = {"usb424,ec00"}; 
>   
> -- Resource.regs = Res.mmio(0x4e00, 0x4e000fff);  
>   
> -- Resource.irq = Res.irq(41);
>   
>   end);   
>   
>   
>   
> end)  
>   
> ~
>
> 
> Much Appreciated!
> Lei Zhou
> 
> 
> From: Lei Zhou
> Sent: Thursday, June 20, 2019 6:43 PM
> To: Adam Lackorzynski; l4-hackers@os.inf.tu-dresden.de
> Subject: Enable L4Linux network access on Raspberry Pi-b.
> 
> Hi Adam & Hackers,
> 
> Has anybody enabled network access for L4linux Raspberry pi3? I read 
> through all the history on related topics and understand the process to get 
> it working.  I summarized the steps as below and major problem for me is how 
> to convert device tree for L4linux and compose corresponding rpi_deices.io 
> configuration.   Please see my specific question inlined in those steps.
> Thanks in advance for your feedback.
> 
> 1.  configure and Compile l4linux to support flattened device tree support.  
> Also enables
>CONFIG_USB_LAN78XX=y  &&
>CONFIG_USB_USBNET=y
>CONFIG_USB_NET_SMSC95XX=y
>CONFIG_L4_SERVER = y
>CONFIG_USE_OF = y
> 2. Adapt 
> h

Re: How to enable Guest Linux VM on Raspberry PI3?

[Adam Lackorzynski]

Hi,

but this also indicates that you did not configure L4Linux for ARMv6 or
v7, as with those there would not be a swp instruction in the code
I believe. For the rpi3 v7 should be selected.

Adam

On Thu Jun 13, 2019 at 20:58:58 +, Lei Zhou wrote:
> Never mind and figured out the problem by googling.   Need enable 
> "CONFIG_SWP_EMULATE"  --- Emulate SWP/SWPB instructions when configuring the 
> L4Linux.
> 
> Linux VM is up running on Rpi 3 and will enable other use cases further on 
> Rpi 3.
> 
> Thanks,
> Lei. 
> 
> 
> 
> From: Lei Zhou
> Sent: Thursday, June 13, 2019 12:24 PM
> To: Adam Lackorzynski; l4-hackers@os.inf.tu-dresden.de
> Subject: RE: How to enable Guest Linux VM on Raspberry PI3?
> 
> Thanks Adam, much appreciated!by enabling the FPU fixes the exception.
> 
> After I rebuilt the Fiasco and Rpi *.uimage,  the logging moves further until 
> the following error:
> 
> =
> Starting binary at 0x3000268, argc=7 argv=0xafff4f8c *argv=0xb1007ff4 
> argv0=romz
> External resolver is at 0xa8000b48
> ==> L4Linux starting... <
> Linux version 4.19.0-l4-svn63 (lezhou@CI070004358) (gcc version 7.4.1 
> 201819
> Binary name: rom/vmlinuz
>This is an AEABI build.
> Linux kernel command line (6 args): mem=64M 
> console=ttyLv0l4x_rd=rom/ramdisk-ar1
> CPU mapping (l:p)[1]: 0:0
> Image: 0300 - 0360 [6144 KiB].
> Areas: Text: 0300 - 03305000 [3092kB]
>RO-Data:  03305000 - 033a8000 [652kB]
>Data: 033e2000 - 034130f4 [196kB]
>Init: 033be000 - 033e2000 [144kB]
>BSS:  034130f4 - 0349a000 [539kB]
> Device scan:
> Device scan done.
> l4lx_thread_create: Created thread 41a (cpu0) (u:b3000e00, v:b3000c00, 
> sp:033e3)
> main thread will be 41a
> L4x: section-with-init(-data): Virt: 0x300 to 0x3499fff [4712 KiB]
> L4x: section-with-init-text: Virt: 0x300 to 0x3499fff [4712 KiB]
> L4x:data: Virt: 0x300 to 0x3499fff [4712 KiB]
> L4x: Main thread running, waiting...
> L4x: Memory size: 64MB
> L4x: Setting superpages for main memory
> L4x: Adjusted memory start: 0300
> L4x: Main memory: Virt: 0x360 to 0x75f [65536 KiB]
> L4x: vmalloc area: 0760 - 0f60
> L4x:text: Virt: 0x300 to 0x3499fff [4712 KiB]
> Loading: rom/ramdisk-arm.rd
> INITRD: Size of RAMdisk is 1449KiB
> RAMdisk from 2000 to 0016c400 [1449KiB]
> l4lx_thread_create: Created thread 41f (timer0) (u:b3000a00, v:, 
> sp:034)
> 'swp(b)' instruction at 03051d28 and faulting.
> Linux built for the wrong ARM version?
> 'swp(b)' instruction at 031b3604 and faulting.
> Linux built for the wrong ARM version?
> 'swp(b)' instruction at 031b3604 and faulting.
> .
> 
> Any comments?
> 
> Thanks again,
> Lei
> 
> 
> From: l4-hackers [l4-hackers-boun...@os.inf.tu-dresden.de] on behalf of Adam 
> Lackorzynski [a...@os.inf.tu-dresden.de]
> Sent: Thursday, June 13, 2019 11:43 AM
> To: l4-hackers@os.inf.tu-dresden.de
> Subject: Re: How to enable Guest Linux VM on Raspberry PI3?
> 
> Hi,
> 
> you're hitting a floating point intruction. Do you have FPU support
> enabled in Fiasco?
> 
> Adam
> 
> On Thu Jun 13, 2019 at 00:35:26 +, Lei Zhou wrote:
> > I put in some printf(...)  into ../pkg/ned/src/lua.cc for debugging.
> >
> > the exception seems throwing out from following function:
> > lua.cc ---> int lua() >
> > =
> >   for (int i = 0; libs[i].func; ++i)
> > {
> >   printf("Ned says: Hi World! %s 021\n", libs[i].name);
> >   luaL_requiref(L, libs[i].name, libs[i].func, 1);
> >   lua_pop(L, 1);
> > }
> >
> >   printf("Ned says: Hi World! leizhou 01\n");
> > ===
> >
> > When it's loading "package" library by invoking this function, it raises 
> > this exception.
> >
> > LUAMOD_API int luaopen_package (lua_State *L) {
> >   createclibstable(L);
> >   luaL_newlib(L, pk_funcs);  /* create 'package' table */
> >   createsearcherstable(L);
> >   /* set field 'path' */
> >   setpath(L, "path", LUA_PATHVARVERSION, LUA_PATH_VAR, LUA_PATH_DEFAULT);
> >   /* set field 'cpath' */
> >   setpath(L, "cpath", LUA_CPATHVARVERSION, LUA_CPATH_VAR, 
> > LUA_CPATH_DEFAULT);
> >   /* store config information */
> >   lua_pushliteral(L, LUA_DIRSEP "\n&q

Re: Want to run L4Re on Raspberry PI.

[Adam Lackorzynski]

Hi,

On Thu Jun 13, 2019 at 19:36:33 +0200, Paul Boddie wrote:
> On Thursday 13. June 2019 17.48.59 Adam Lackorzynski wrote:
> > On Wed Jun 12, 2019 at 00:34:02 +0200, Paul Boddie wrote:
> > > 
> > > Perhaps take a look at the following:
> > > 
> > > http://www.boddie.org.uk/downloads/armv6_hello.elf
> > > http://www.boddie.org.uk/downloads/armv6zk_hello.elf
> > 
> > I see a couple of floating point instructions and it would be
> > interesting to know whether one of those triggers it. Sorry for not
> > saying this earlier, but could you place a version with debugging
> > symbols (of bootstrap) online, i.e. one where I could see where
> > move_modules is.
> 
> To do this, I ran the following command:
> 
> make O=mybuild E=hello uimage BOOTSTRAP_NO_STRIP=1
> 
> I had been looking in the general build configuration, but the "Strip 
> binaries 
> on install" (BID_STRIP_PROGS) option evidently only applies to bundled 
> programs, not the bootstrap payload itself.
> 
> The above binaries have now been replaced with ones that include symbol 
> information. Previously, I had been looking at the dump for boot_modules.o 
> and 
> didn't notice anything particularly unusual, but I must admit that I don't 
> know the more exotic ARM instructions.

I do not see anything particular special either. The floating point
instructions are in the libc/*printf, so are not affected here.
I could only continue with a binary search style of looking where it
breaks, with "while(1);" as printfs do seems to change too much as you
already found out.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Want to run L4Re on Raspberry PI.

[Adam Lackorzynski]

On Wed Jun 12, 2019 at 00:34:02 +0200, Paul Boddie wrote:
> On Tuesday 11. June 2019 23.32.43 Adam Lackorzynski wrote:
> > On Tue Jun 11, 2019 at 02:00:00 +0200, Paul Boddie wrote:
> > > Unfortunately, nothing more is shown and there is no register dump. Maybe
> > > I have to compile in some kind of exception handler or something.
> > 
> > No, it's built-in. So my suggestion would be to narrow it down by
> > putting some more printfs etc. in the code so see where it diverts.
> > But understandably this is pretty cumbersome with the SD card.
> 
> Indeed, but it was more cumbersome blitting patterns to the display on the 
> Ben 
> NanoNote to trace progress through the bootstrap code and kernel. :-)
> 
> Previously, I did generate debugging statements, and initially it seemed that 
> the code didn't get beyond calc_modules_size, seemingly failing to loop over 
> more than one module. However, splitting up the following statement...
> 
> s += l4_round_size(mbi->module(i).size(), p2align);
> 
> ...and inserting other debugging statements did seem to persuade the code to 
> proceed until move_module was called. Thus, output like this can be generated:
> 
> Counting 5 modules...
> Module 0...
> Size: 648904...
> Module 1...
> Size: 41840...
> Module 2...
> Size: 218336...
> Module 3...
> Size: 87208...
> Module 4...
> Size: 132812...
> Total: 1142784
> 
> In fact, this is from my most recent attempt at instrumenting the code in 
> this 
> way.
> 
> > Could you put the hello.elf online so that I could have a look to check
> > for the assumption with the wrong instruction?
> 
> Perhaps take a look at the following:
> 
> http://www.boddie.org.uk/downloads/armv6_hello.elf
> http://www.boddie.org.uk/downloads/armv6zk_hello.elf

I see a couple of floating point instructions and it would be
interesting to know whether one of those triggers it. Sorry for not
saying this earlier, but could you place a version with debugging
symbols (of bootstrap) online, i.e. one where I could see where
move_modules is.

Thanks, Adam
 
> I rebuilt the toolchain using the raspberrypi0_defconfig instead of manually 
> selecting Raspberry Pi Zero in the configuration menu, just to make sure that 
> there wasn't some important difference.
> 
> Then, I rebuilt Fiasco and L4Re. The ARMv6 and ARMv6zK payloads were 
> generated 
> from separate ARMv6 and ARMv6zK builds of L4Re.
> 
> The result is unchanged from before, meaning that either the generated code 
> has no influence on the result - it does differ slightly, but mostly involves 
> the usual reordering done when such settings are altered - or "bad" 
> instructions are somehow being generated anyway.
> 
> Thanks for taking an interest in this! I imagine that I am probably doing 
> something wrong, but hopefully my mistakes can be used to teach others what 
> to 
> do.
> 

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: How to enable Guest Linux VM on Raspberry PI3?

[Adam Lackorzynski]

Hi,

you're hitting a floating point intruction. Do you have FPU support
enabled in Fiasco?

Adam

On Thu Jun 13, 2019 at 00:35:26 +, Lei Zhou wrote:
> I put in some printf(...)  into ../pkg/ned/src/lua.cc for debugging.
> 
> the exception seems throwing out from following function:
> lua.cc ---> int lua() >
> =
>   for (int i = 0; libs[i].func; ++i)  
>   
> { 
>   
>   printf("Ned says: Hi World! %s 021\n", libs[i].name);   
>   
>   luaL_requiref(L, libs[i].name, libs[i].func, 1);
>   
>   lua_pop(L, 1);  
>   
> } 
>   
>   
>   
>   printf("Ned says: Hi World! leizhou 01\n"); 
> ===
> 
> When it's loading "package" library by invoking this function, it raises this 
> exception.
> 
> LUAMOD_API int luaopen_package (lua_State *L) {   
>   
>   createclibstable(L);
>   
>   luaL_newlib(L, pk_funcs);  /* create 'package' table */ 
>   
>   createsearcherstable(L);
>   
>   /* set field 'path' */  
>   
>   setpath(L, "path", LUA_PATHVARVERSION, LUA_PATH_VAR, LUA_PATH_DEFAULT); 
>   
>   /* set field 'cpath' */ 
>   
>   setpath(L, "cpath", LUA_CPATHVARVERSION, LUA_CPATH_VAR, LUA_CPATH_DEFAULT); 
>   
>   /* store config information */  
>   
>   lua_pushliteral(L, LUA_DIRSEP "\n" LUA_PATH_SEP "\n" LUA_PATH_MARK "\n" 
>   
>  LUA_EXEC_DIR "\n" LUA_IGMARK "\n");  
>   
>   lua_setfield(L, -2, "config");  
>   
>   /* set field 'loaded' */
>   
>   luaL_getsubtable(L, LUA_REGISTRYINDEX, "_LOADED");  
>   
>   lua_setfield(L, -2, "loaded");  
>   
>   /* set field 'preload' */   
>   
>   luaL_getsubtable(L, LUA_REGISTRYINDEX, "_PRELOAD"); 
>   
>   lua_setfield(L, -2, "preload"); 
>   
>   lua_pushglobaltable(L); 
>   
>   lua_pushvalue(L, -2);  /* set 'package' as upvalue for next lib */  
>   
>   luaL_setfuncs(L, ll_funcs, 1);  /* open lib into global table */    
>   
>   lua_pop(L, 1);  /* pop global table */  
>   
>   return 1;  /* return 'package' table */ 
>   
> }   
> 
> Any hints would be greatly appreciated!
> Lei
> 
> 
> 
> From: Lei Zhou
> Sent: Tuesday, June 11, 2019 7:10 PM
> To: Adam Lackorzynski; l4-hackers@os.inf.tu-dresden.de
> Subject: RE: How to enable Guest Linux VM on Raspberry PI3?
> 
> Hi Adam,
> 
> I built Fiasco/L4Re and L4Linux vmlinuz, my own ramdisk-armv7.cpio.gz.
> 
> This is my l4linux.cfg content:
> ==
> -- vim:set ft=lua:
> 
> local L4 = require("L4");
> 
> L4.default_loader:start({ log = L4.Env.log:m("rws"), },
> "rom/vmlinuz mem=64M console=ttyLv0 " ..
> "l4x_rd=rom/ramdisk-armv7.cpio.gz" ..  L4.Info.arch() 
> .. ".rd "
> .. "root=1:0 ramdisk_size=4000 init=/bin/sh");
> =
> This is my module.list:
> 
> entry L4Linux-rpi3
> roottask moe rom/l4linux.cfg
> module l4linux.cfg
> module l4re
> module ned
> module vmlinuz
> module ramdisk-armv7.cpio.gz
> ===
> 
> I made final bootstrap_L4Linux-rpi3.uimage.
> 
> =
> 
> After Rpi3 booted up, it stopped at NED exception and hangs!  And log is 
> pasted as below

Re: Want to run L4Re on Raspberry PI.

[Adam Lackorzynski]

On Tue Jun 11, 2019 at 02:00:00 +0200, Paul Boddie wrote:
> On Tuesday 11. June 2019 00.18.43 Paul Boddie wrote:
> > On Tuesday 11. June 2019 00.08.59 Adam Lackorzynski wrote:
> > > If it just reboots in the middle of a rather normal C function, then
> > > it's likely some instruction that has been generated there and not
> > > understood by the CPU. Could you maybe use u-boot as it shows a register
> > > dump when something like this happens, allowing to know where it
> > > branched away.
> > 
> > I think that introducing U-Boot may save me some time in the end, so I'll
> > look into that. The Raspberry Pi stuff is rather alien to me, but I had
> > hoped that there was an established recipe for getting things up and
> > running.
> 
> Well, with config.txt updated with...
> 
> kernel=u-boot.bin
> 
> ...I get a prompt on the UART and can tell U-Boot to load and start the 
> payload, according to some instructions I found online:
> 
> https://ltekieli.com/buildroot-with-raspberry-pi-u-boot/
> 
> Here is the conversation:
> 
> 
> 
> U-Boot> mmc dev 0
> switch to partitions #0, OK
> mmc0 is current device
> U-Boot> fatload mmc 0:1 ${kernel_addr_r} hello.raw
> 1209560 bytes read in 91 ms (12.7 MiB/s)
> U-Boot> bootz ${kernel_addr_r}
> Kernel image @ 0x08 [ 0x100 - 0x11274d8 ]

Interesting way of doing it, i.e. good that our bootstrap image also
looks like a Linux image.
I'd typically do something like this using the uimage:
fatload mmc 0:1 0x0c0 hello.uimage
bootm 0x0c0

But in the end it should not make a difference.

> Starting kernel ...
> 
> 
> L4 Bootstrapper
>   Build: #8 Mon Jun 10 19:44:17 CEST 2019, 7.4.0
>   Scanning up to 512 MB RAM, starting at offset 32MB
>   Memory size is 512MB ( - 1fff)
>   RAM:  - 1fff: 524288kB
>   Total RAM: 512MB
>   Scanning fiasco
>   Scanning sigma0
>   Scanning moe
>   Moving up to 5 modules behind 110
> 
> 
> 
> Unfortunately, nothing more is shown and there is no register dump. Maybe I 
> have to compile in some kind of exception handler or something.

No, it's built-in. So my suggestion would be to narrow it down by
putting some more printfs etc. in the code so see where it diverts.
But understandably this is pretty cumbersome with the SD card.
Could you put the hello.elf online so that I could have a look to check
for the assumption with the wrong instruction?




Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Want to run L4Re on Raspberry PI.

[Adam Lackorzynski]

On Mon Jun 10, 2019 at 20:16:55 +0200, Paul Boddie wrote:
> On Wednesday 29. May 2019 18.27.03 Paul Boddie wrote:
> > 
> > P.S. I have a selfish interest in following this as I could imagine also
> > trying out L4Re on the Raspberry Pi at some point. I guess that the
> > framebuffer isn't currently supported though.
> 
> Well, I got round to trying this, but it hasn't been entirely successful.
> 
> First of all, I made a toolchain using Buildroot 2019.02.2 and what are 
> effectively the raspberrypi0_defconfig settings. The generated gcc is version 
> 7.4.0, ld is version 2.29.1.
> 
> Note that I am using the Zero, not the Zero-W, model. This doesn't appear to 
> have any real toolchain implications, as far as I can tell from looking at 
> the 
> configurations.
> 
> Some pertinent settings:
> 
> BR2_GCC_TARGET_ABI="aapcs-linux"
> BR2_GCC_TARGET_CPU="arm1176jzf-s"
> BR2_GCC_TARGET_FPU="vfp"
> BR2_GCC_TARGET_FLOAT_ABI="hard"
> BR2_GCC_TARGET_MODE="arm"
> BR2_ARM_CPU_HAS_FPU=y
> BR2_ARM_CPU_HAS_VFPV2=y
> BR2_ARM_CPU_HAS_ARM=y
> BR2_ARM_CPU_HAS_THUMB=y
> BR2_ARM_CPU_ARMV6=y
> BR2_arm1176jzf_s=y
> BR2_ARM_EABIHF=y
> BR2_ARM_FPU_VFPV2=y
> 
> Then, I built Fiasco with the Raspberry Pi Zero W selected:
> 
> CONFIG_PF_BCM283X=y
> CONFIG_BSP_NAME="bcm283x"
> CONFIG_CAN_ARM_CPU_1176=y
> CONFIG_ARM_V6=y
> CONFIG_ARM_V6PLUS=y
> CONFIG_PF_BCM283X_RPIZW=y   
> CONFIG_ABI_VF=y 
> CONFIG_ARM_1176=y
> CONFIG_FPU=y 
> CONFIG_LAZY_FPU=y
> CONFIG_ARM_1176_CACHE_ALIAS_FIX=y
> CONFIG_ARM_CPU_ERRATA=y
> 
> In this configuration, I also selected things that appeared useful, such as 
> FPU support and the fixes/errata, which might not have been appropriate.
> 
> Finally, I built L4Re with the Raspberry Pi Model B selected as platform:
> 
> CONFIG_CPU_ARM_ARMV6ZK=y
> CONFIG_CPU="armv6zk"
> CONFIG_PLATFORM_TYPE="rpi_b"
> CONFIG_CPU_ARMV6KPLUS=y
> CONFIG_CPU_ARMV6PLUS=y
> CONFIG_PLATFORM_TYPE_rpi_b=y
> 
> Having built the "hello" example, deploying the bootstrap_hello.raw file to 
> the microSD card as hello.raw, alongside the extra files that the Raspberry 
> Pi's proprietary bootloader uses, with a config.txt file that indicates the 
> kernel...
> 
> kernel=hello.raw
> 
> ...I see the payload starting over the UART connection, but it appears that 
> the board keeps restarting, meaning that I just see the following over and 
> over again:
> 
> L4 Bootstrapper
>   Build: #8 Mon Jun 10 19:44:17 CEST 2019, 7.4.0
>   Scanning up to 512 MB RAM, starting at offset 32MB
>   Memory size is 512MB ( - 1fff)
>   RAM:  - 1fff: 524288kB
>   Total RAM: 512MB
>   Scanning fiasco
>   Scanning sigma0
>   Scanning moe
>   Moving up to 5 modules behind 110
> 
> Instrumenting the boot_modules.cc file in the bootstrap package, I see that 
> the Boot_modules::move_modules is not completed. Generally, modules appear to 
> be identified, but some other operation is causing a problem that appears to 
> cause the board to reset.
> 
> I have also tried building Fiasco for first generation Raspberry Pi devices 
> along with the FPU support and other special options. And I have tried 
> building for the Pi Zero-W without these extra options. The result seems to 
> be 
> the same, so I suspect that the kernel plays no role here, particularly since 
> the problem appears to lie in the bootstrap code.
> 
> I wonder if others who have looked at Raspberry Pi hardware might be able to 
> share their experiences. It is rather frustrating to have to piece together 
> the details of building and deploying for hardware ostensibly supported by 
> L4Re.

If it just reboots in the middle of a rather normal C function, then
it's likely some instruction that has been generated there and not
understood by the CPU. Could you maybe use u-boot as it shows a register
dump when something like this happens, allowing to know where it
branched away. 


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: L4Re, BUILD_ARCH, cross-building for ARM on MIPS

[Adam Lackorzynski]

Hi Paul,

On Mon Jun 10, 2019 at 16:50:57 +0200, Paul Boddie wrote:
> In attempting to investigate building L4Re/Fiasco.OC for the Raspberry Pi 
> Zero, I encountered an unusual problem: unusual because, I suppose, most 
> people do not try and cross-build on architectures other than x86(-64).
> 
> When performing the initial L4Re build directory initialisation step...
> 
> make B=mybuild
> 
> ...BUILD_ARCH seems to be set to x86 even on other architectures. This then 
> causes CCXX_FLAGS to be populated with x86-dependent settings such as -m32, 
> and the gcc host compilers for MIPS raise errors upon encountering these 
> unrecognised arguments.
> 
> Here is the offending command in the top-level Makefile (line 376 in my 
> version, r83 in Subversion):
> 
> GENDEP_OUTPUT=$$X.out $(CC) $(CCXX_FLAGS) -c $$X -o $$X.o
> 
> Although it seemed like the config step could be performed after ignoring 
> these errors, I did wonder if there might be some undesirable consequences. 
> In 
> the end, I found that the following invocation was needed:
> 
> make B=mybuild CC=gcc CXX=g++ LD=ld BUILD_ARCH=mips CPU=32r2 CPU_ABI=32
> 
> After that, things seem to work as expected. I imagine that there is a 
> "chicken and egg" situation here: the appropriate settings would be obtained 
> from the configuration, but the command being run sets up the configuration.
> 
> Has anyone else seen this problem before?

That's a good point. You can do "make B=builddir T=arm-rv" to
immediately switch to the target architecture. I'm trying to improve the
handling here as I just stumpled into this in a different setting as
well.


HTH,
Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: How to enable Guest Linux VM on Raspberry PI3?

[Adam Lackorzynski]

On Fri Jun 07, 2019 at 18:27:18 +, Lei Zhou wrote:
> After I brought up L4Re and Fiasco on Raspberry PI3,  would like to enable 
> guest Linux VM on top of it.
> 
> I'm looking at the link https://github.com/kernkonzept/manifest/wiki/LinuxVM 
> and hoping I can do the same thing on Raspberry PI3.   
> 
> The link seems using hardware-assisted virtualization option uvmm based for 
> guest VM. There seems also L4Linux Paravirtualization option.Which 
> option should I use for me to enable guest LInux  VM on Raspberry PI3?

You can only use L4Linux as the Raspberries do not support
hardware-assisted virtualization (because they have the wrong interrupt
controller).


Adam

> In addition,  when I followed the link to try on QEMU first,   encounter some 
> "vbus" capability issue.   I followed the guidance exactly as the link says.  
>  However,   when I started the command to spawning the Linux VM as:
>  $make E=uvmm-basic qemu
> 
> It failed with following log:
> 
> 
> MOE: virtual user address space [0-7f]
> MOE: rom name space cap -> [C:103000]
> MOE: rwfs name space cap -> [C:105000]
>   BOOTFS: [4110-411974b8] [C:107000] uvmm
>   BOOTFS: [41198000-411c4e58] [C:109000] l4re
>   BOOTFS: [411c5000-41246770] [C:10b000] ned
>   BOOTFS: [41247000-412475c4] [C:10d000] virt-arm_virt.dtb
>   BOOTFS: [41248000-41430200] [C:10f000] ramdisk-armv8.cpio.gz
>   BOOTFS: [41431000-41431242] [C:111000] uvmm-basic.ned
>   BOOTFS: [41432000-42618a00] [C:113000] Image.gz
> MOE: cmdline: moe rom/uvmm-basic.ned
> MOE: Starting: rom/ned rom/uvmm-basic.ned
> MOE: loading 'rom/ned'
> Ned says: Hi World!
> Ned: loading file: 'rom/uvmm-basic.ned'
> VMM[vmbus]: 'vbus' capability not found. Hardware access not possible for VM.
> VMM[main]: Hello out there.
> VMM: FATAL: ERROR: ARM GIC virtualization does not work without passing the 
> virtual GICC via the vbus
> VMM[vm]: Device creation for virtual device virtio_uart@2 failed. 
> Disabling device.
> VMM[]: virtio_net@1.l4vmm,virtiocap: capability net is invalid.
> VMM[vm]: Device creation for virtual device virtio_net@1 failed. 
> Disabling device.
> VMM: FATAL: ERROR: ARM GIC virtualization does not work without passing the 
> virtual GICC via the vbus
> VMM[vm]: Device creation for virtual device interrupt-controller failed. 
> Disabling device.
> VMM: FATAL: Parsing timer interrupt: Argument out of range
> qemu-system-aarch64: terminating on signal 2
> Makefile:6: recipe for target 'do-all-make-goals' failed
> make: *** [do-all-make-goals] Interrupt
> =
> 
> Any feedbacks are greatly appreciated!
> Lei Zhou
> 
> ___
> l4-hackers mailing list
> l4-hackers@os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Want to run L4Re on Raspberry PI.

[Adam Lackorzynski]

Hi,

you need to have the mkimage tool available, which is typically
available through the u-boot-tools package (or similar).

For the other error, please disable Virtualization support in the Fiasco
configuration. The raspberry pi does not support hardware-assisted
virtualization.


Adam

On Wed May 29, 2019 at 21:27:35 +, Lei Zhou wrote:
> Another error I'm running into is at last step to generate bootable uimage.
> 
> $make E=hello uimage 
> MODULE_SEARCH_PATH="${PWD}/../../kernel/fiasco/build-ukernel-pi3" 
> PLATFORM_TYPE=rpi_b
> 
> I have two questions:
>1.   What RAM_BASE should I pass in make cmdline? or leave it as is?
>2.  Seems missing mkimage tool in the src tree.  I used repomgr pulling 
> all the source automatically. What did I miss here?
> 
> 
> make[1]: Entering directory '/home/lezhou/workspace/l4re/src/l4'
> === Updating RAM_BASE for platform rpi_b to 0x0 =
>   ... Regenerating RAM_BASE settings
>   [sigma0] ==> Linking sigma0
>   [sigma0] ==> sigma0 built
>   [sigma0] ==> Installing sigma0 to local build-tree
>   [moe] ==> Linking moe
>   [moe] ==> moe built
>   [moe] ==> Installing moe to local build-tree
> /home/lezhou/workspace/l4re/src/l4/pkg/bootstrap/server/src/Make.rules:263: 
> *** mkimage(mkimage) host tool missing, cannot build bootstrap.uimage/itb.  
> Stop.
> ../../../../mk/binary.inc:149: recipe for target 
> '/home/lezhou/workspace/l4re/src/l4/build-pi3/pkg/bootstrap/server/src/OBJ-arm64_armv8a'
>  failed
> make[2]: *** 
> [/home/lezhou/workspace/l4re/src/l4/build-pi3/pkg/bootstrap/server/src/OBJ-arm64_armv8a]
>  Error 2
> Makefile:537: recipe for target 'uimage' failed
> make[1]: *** [uimage] Error 2
> make[1]: Leaving directory '/home/lezhou/workspace/l4re/src/l4'
> Makefile:6: recipe for target 'do-all-make-goals' failed
> make: *** [do-all-make-goals] Error 2
> -
> 
> Thanks,
> Lei
> 
> 
> From: Lei Zhou
> Sent: Wednesday, May 29, 2019 4:39 PM
> To: Paul Boddie; l4-hackers@os.inf.tu-dresden.de
> Subject: RE: Want to run L4Re on Raspberry PI.
> 
> When I cross compiled Fiasco for Raspberry PI3 B,   running into this 
> compiling error as below.
> 
> Here are what I did:
>   1. use Linaro cross compiler
>   2. // cross compiling for Rpi 3b+
>   $make BUILDDIR=build-rpi3-ukernel
>   $make O=build-rpi3-ukernel config// pick aarch64, broadcom 2837, 
> and rpi 3b
>   $make O=build-rpi3-ukernel -j4
> 
> Compiling error:
> 
>   ... Making arm_control-arm-bcm283x.o
>   ... Making irq_handler-arm-bcm283x.o
>   ... Making uart_console.o
>   ... Making vgic.o
>   ==> Linking tcboffset.bin
>   ... Making jdb.o
> In file included from auto/vgic.cc:4:0:
> /home/lezhou/workspace/l4re/src/kernel/fiasco/src/kern/arm/vgic.cpp: In 
> constructor ‘Gic_h_init::Gic_h_init(Cpu_number)’:
> /home/lezhou/workspace/l4re/src/kernel/fiasco/src/kern/arm/vgic.cpp:153:59: 
> error: ‘Gic_h_phys_base’ is not a member of ‘Mem_layout’
>  Gic_h::gic.construct(Kmem::mmio_remap(Mem_layout::Gic_h_phys_base));
>^~~
> /home/lezhou/workspace/l4re/src/kernel/fiasco/src/Makerules.global:118: 
> recipe for target 'vgic.o' failed   <<<== compiling error
> make[2]: *** [vgic.o] Error 1
> make[2]: *** Waiting for unfinished jobs
> make[2]: Leaving directory 
> '/home/lezhou/workspace/l4re/src/kernel/fiasco/build-ukernel-pi3'
> /home/lezhou/workspace/l4re/src/kernel/fiasco/src/Makefile:153: recipe for 
> target 'all' failed
> ==
> 
> Any inputs would be appreciated!
> Lei
> 
> 
> 
> 
> 
> 
> 
> From: l4-hackers [l4-hackers-boun...@os.inf.tu-dresden.de] on behalf of Paul 
> Boddie [p...@boddie.org.uk]
> Sent: Wednesday, May 29, 2019 12:27 PM
> To: l4-hackers@os.inf.tu-dresden.de
> Subject: Re: Want to run L4Re on Raspberry PI.
> 
> On Wednesday 29. May 2019 15.20.01 Matthias Lange wrote:
> >
> > The issue we have with "standard" cross toolchains is the libgcc they are
> > shipping. It is compiled for ARMv7 and contains instructions that are
> > unknown / illegal on ARMv6k. The mean thing is, that our build system tells
> > GCC via "-march=armv6zk" what code to generate but then links the wrong
> > libgcc.
> 
> Some of these compiler configuration issues are awkward. My problem was that
> although there are switches for hard- and soft-float, appropriate libgcc
> variants need to be available, and the Debian toolchains do not provide them
> all. I actually don't remember if there is a need for completely separate
> compilers, but 

Re: Want to run L4Re on Raspberry PI.

[Adam Lackorzynski]

On Tue May 28, 2019 at 21:21:41 +, Lei Zhou wrote:
> Thanks Paul for your prompt response.  I will give it try and see how it 
> goes.Regards,   Lei

One missing piece is probably that u-boot should be put on the rpi to
load the bootstrap.uimage.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Fwd: l4linux running lmbench

[Adam Lackorzynski]

On Wed May 29, 2019 at 17:11:19 +0800, yangzeng wrote:
> Dear Developers:
> 
> I am a newcomer to l4linux, I use the default configuration to run
> l4linux-mag, now I want to run lmbench on l4linux, how should I put
> lmbench into l4linux

I guess you're using a ramdisk right now, so you can add lmbench to
that. The ramdisk probably needs to be bigger than the current one, so
please also enlarge it (append some space with dd and then use
resize2fs).


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: L4Linux with L4Re and Fiasco.OC-UX

[Adam Lackorzynski]

Hi Paul,

On Thu Mar 28, 2019 at 23:28:17 +0100, Paul Boddie wrote:
> I have been looking at trying out L4Linux in UX mode as a first step towards 
> its use on "native" Fiasco, and I seem to be experiencing a problem with 
> launching the Linux kernel itself.
> 
> I have followed the instructions from these pages:
> 
> https://l4linux.org/download.shtml
> https://l4linux.org/build.shtml
> https://l4linux.org/use.shtml
> 
> Specifically, I have an existing build of UX that has been used for some time 
> to develop software. I have updated it to revision 83 and have checked out 
> the 
> l4linux_requirements, which appear to be some packages (rtc and shmc) I 
> already have. I then performed a build once again:
> 
> make O=mybuild
> 
> The L4Linux repository has also been checked out and updated to revision 83. 
> The code has been configured and built using the following invocations:
> 
> make O=mybuild x86_32-ux_defconfig
> make O=mybuild menuconfig # to set the L4Re build directory
> make O=mybuild
> 
> Here, the mybuild directory is distinct from the L4Re mybuild directory.
> 
> For the initial RAM filesystem, I downloaded the ramdisk-x86.rd file, and I 
> run the system as follows:
> 
> make O=mybuild ux E=L4Linux-basic
> 
> After the usual familiar start-up messages, I see this output specific to the 
> configuration being launched:
> 
> 
> Ned: loading file: 'rom/l4lx.cfg'
> libio: Warning: Query of 'vbus' failed!
> PH  0 offs=1000 flags=r-x PH-type=0x1
>   virt=0010 evirt=0053f000
>   phys=0010 ephys=0053f000
>   f_sz=0043f000 memsz=0043f000
> PH  1 offs=0044 flags=rw- PH-type=0x1
>   virt=0053f000 evirt=00a58000
>   phys=0053f000 ephys=00a58000
>   f_sz=0006ce9f memsz=00519000
> PH  2 offs=00371ee0 flags=--- PH-type=0x4
>   virt=00470ee0 evirt=00470f1c
>   phys=00470ee0 ephys=00470f1c
>   f_sz=003c memsz=003c
> Starting binary at 0x10, argc=6 argv=0xafff4f84 *argv=0xb1007ff4 
> argv0=rom/vmlinuz
> External resolver is at 0xa8000bd0
> L4Re: rom/vmlinuz: Unhandled exception: PC=0x46980b PFA=97d47fe0 LdrFlgs=0
> 
> 
> In order to try and identify the problem, I used the following command:
> 
> addr2line -e ~/L4/L4Linux/l4linux/mybuild/vmlinux 0x46980b
> 
> This seems to indicate that the point of failure is at line 2727 in 
> arch/l4/kernel/main.c which is the start of this function:
> 
> int __ref L4_CV main(int argc, char **argv)
> 
> So, I wonder what the problem might be that leads to a crash as the main 
> function is being invoked. Have I missed anything obvious?

Guess not except that doing this on UX could be a bit adventurous
nowadays. Which instruction is sitting at 0x46980b?


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Raspberry Pi 3B and L4Linux

[Adam Lackorzynski]

Hi,

On Wed Mar 27, 2019 at 14:07:42 +0100, Dejan Cotra wrote:
> Im trying to run L4Linux on Raspberry Pi 3B.
> So far I was able to build Fiasco kernel and L4Re for Raspberry Pi 3B.
> I used aarch64-linux-gnu-gcc toolchain.
> 
> Also I was able to create Uboot image for hello config, which I
> successfully run on both qemu and Raspberry Pi 3B.
> 
> So now Im trying to build L4Linux.
> First question would be does L4Linux supparm64 architecture?

Not yet.

> If yes, any hints for configuration?
> 
> If it does not support arm64 architecture does this also mean that I have
> to build Fiasco kernel and L4Re for 32bit arm architecture.

Yes, it does mean that both Fiasco and L4Re have to be 32bit as well.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Setting up ssd and hard disk in l4linux

[Adam Lackorzynski]

Hi,

On Tue Feb 26, 2019 at 10:06:20 +0800, Xinyue Wu wrote:
> I have been trying to mount ssd and hard disk in l4linux. There are some
> similiar questions in previous archives, and I have done the following
> things according to them:
> 
>- configure 'devs' file and 'io' file, add sata to vbus
>- enable PCI support
>- enable vPCI driver
>- enable AHCI driver
> 
> But when I ran l4linux in hardware, I still couldn't find sata in pci bus,
> nor could I found my devices under /dev. Does anyone have some suggestions?
> Or maybe there are something wrong in my device configuration, please let
> me know if so.

With PCI, it works differently. As the IO component is able to iterate
over the PCI bus to find all devices and the resources (MMIO, IRQs, ...)
they use/need, you don't need to specify the resources yourself.

Please have a look at l4/conf/examples/l4lx-x86.io. There is an l4linux
vbus which does what you need, i.e. it defines a virtual PCI bus and
puts all devices of a certain class, including storage, on it.
This configuration is also used in the L4Linux-mag configuration.
With this L4Linux will iterate over its virtual PCI bus and find the
AHCI controller.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: some questions about l4bd.c in l4linux

[Adam Lackorzynski]

Hi,

On Wed Feb 20, 2019 at 09:44:35 +, yadong.li wrote:
>   I am studying how to support emmc storage in L4Re.
>I have read the file l4linux/drivers/block/l4bd.c.
>I have some questions
> 
> 1¡¢  In ¡°l4linux/drivers/block/l4bd.c¡±, I can¡¯t find the function 
> implementation of ¡°l4fdxc_request_write¡± and some with prefix l4fdxc in 
> l4linx or l4£¬
> is there some demos?
> 
> 2¡¢  If it is implemented by ourselves, where is more reasonable to place 
> ¡°l4fdxc_request_write¡± , in l4 or l4linux ?
> 
> 3¡¢  If in l4, Which implementation is more reasonable , lib or server?

Oh. There's actually a library libfdx that implements the L4Re side of
all of this. For some reason it's not available. I'll add it for the
next snapshot run.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Communication between L4Linux tasks and L4re tasks

[Adam Lackorzynski]

Hi,

On Wed Feb 13, 2019 at 15:25:53 +0100, Canberk Demirsoy wrote:
> I have a simple question regarding the communication of L4Linux and L4re. I
> have already read previous entries but could not solve my problem.
> 
> I am able to establish a communication between the tasks in L4re, but what
> I need is communication between a task that is running on L4Linux and a
> task that is running on L4re.
> 
> How can I do this in simplest way? Any suggestions?

In this setting one needs the L4Linux kernel, i.e. the Linux program
uses a driver in the L4Linux kernel which then is able to talk to L4Re
programs, or other L4Linux kernels. The way L4Linux works does not allow
a Linux program to communicate with L4Re programs using L4 mechanisms.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: High 32 bits of SFMASK is reserved

[Adam Lackorzynski]

Hi,

On Tue Sep 18, 2018 at 22:45:41 +0100, Yuxuan Shui wrote:
> In cpu-64.cpp, in function Cpu::setup_sysenter, Fiasco try to set
> IA32_FMASK (called MSR_SFMASK in the code) to ~0ULL. However, only the
> lower 32bit of FMASK should be written to.
> 
> This cause problems on some platforms.

Thanks a lot, will be fixed.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: L4Re Build Failure on i386 (Revision 80)

[Adam Lackorzynski]

On Fri Aug 03, 2018 at 15:49:56 +0200, Paul Boddie wrote:
> On Friday 3. August 2018 15.36.50 Adam Lackorzynski wrote:
> > 
> > On Fri Aug 03, 2018 at 00:26:45 +0200, Paul Boddie wrote:
> > > 
> > > I know that the ldscripts have been changed, but I struggle to see how
> > > the above relates to them or whether they are even involved in this
> > > particular outcome. Might there be something obviously wrong somewhere
> > > in the recent changes?
> > 
> > I also saw this, I currently believe this is due to the latest binutils
> > (2.31). Are you running this one?
> 
> Yes, that's the one:
> 
> binutils 2.31.1-2 on i386
> 
> I guess I could use a more stable distribution version to see if this 
> resolves 
> the problem. I'll give it a try and report back.
> 
> Thanks for following up!

Issue has been fixed by now. Was a mistake in the linkerscript
where earlier ld versions did not complain.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: L4Re Build Failure on i386 (Revision 80)

[Adam Lackorzynski]

Hi Paul,

On Fri Aug 03, 2018 at 00:26:45 +0200, Paul Boddie wrote:
> I thought I'd try and get L4Re and the UX variant of Fiasco.OC working again. 
> Various errors with the actual compiler - not typical compilation errors - 
> have previously occurred, but system updates come along every so often and I 
> saw that new revisions of L4Re/Fiasco.OC have also arrived fairly recently.
> 
> Unfortunately, the L4Re build fails with complaints about the linking 
> process. 
> Here is the verbose build output at the point of failure:
> 
>   [fb-drv] ==> Linking fb-drv
> LD_PRELOAD=libgendep.so 
> LD_LIBRARY_PATH=:/home/paulb/L4/UX/src/l4/mybuild/tool/gendep/32:/home/paulb/L4/UX/src/l4/mybuild/tool/gendep
>  
> GENDEP_TARGET=fb-drv GENDEP_BINARY=ld  GENDEP_BINARY_ALT1=ld 
> /home/paulb/L4/UX/src/l4/tool/bin/l4-bender -t ld -
> Dl4obj=/home/paulb/L4/UX/src/l4/mybuild -Dl4dir=/home/paulb/L4/UX/src/l4 -
> Dgcclibdir="/usr/lib/gcc/i686-linux-gnu/7/ /usr/lib/gcc/i686-linux-
> gnu/7/../../../../i686-linux-gnu/lib/i686-linux-gnu/7/ /usr/lib/gcc/i686-
> linux-gnu/7/../../../../i686-linux-gnu/lib/i386-linux-gnu/ /usr/lib/gcc/i686-
> linux-gnu/7/../../../../i686-linux-gnu/lib/../lib/ /usr/lib/gcc/i686-linux-
> gnu/7/../../../i686-linux-gnu/7/ /usr/lib/gcc/i686-linux-gnu/7/../../../i386-
> linux-gnu/ /usr/lib/gcc/i686-linux-gnu/7/../../../../lib/ /lib/i686-linux-
> gnu/7/ /lib/i386-linux-gnu/ /lib/../lib/ /usr/lib/i686-linux-gnu/7/ 
> /usr/lib/i386-linux-gnu/ /usr/lib/../lib/ /usr/lib/gcc/i686-linux-
> gnu/7/../../../../i686-linux-gnu/lib/ /usr/lib/gcc/i686-linux-gnu/7/../../../ 
> /lib/ /usr/lib/" -Dl4system=x86_gen -Dl4api=l4f -Dlinker="ld -m elf_i386" --
> spec=/home/paulb/L4/UX/src/l4/mk/bid-bender.spec -- -o fb-drv  -MD -MF ./.fb-
> drv.pcs.d -PClibc_support_misc -PClibio-vbus -PCx86emu_int10 -PCx86emu_int10 -
> PCstdlibs -static -gc-sections -Ttext-segment=0x0100   --defsym 
> __L4_KIP_ADDR__=0xa000 --defsym __L4_STACK_ADDR__=0xb000 -L 
> /home/paulb/L4/UX/src/l4/mybuild/lib/x86_gen/l4f -L 
> /home/paulb/L4/UX/src/l4/mybuild/lib/x86_gen -L 
> /home/paulb/L4/UX/src/l4/mybuild/lib  --warn-common -Ttext-segment=0x0100 
> main.o dummy.o splash.o vesa.o  
> ld: section `.note.gnu.property' assigned to non-existent phdr `interp'
> ld: section `.rel.dyn' assigned to non-existent phdr `interp'
> 
> I know that the ldscripts have been changed, but I struggle to see how the 
> above relates to them or whether they are even involved in this particular 
> outcome. Might there be something obviously wrong somewhere in the recent 
> changes?

I also saw this, I currently believe this is due to the latest binutils
(2.31). Are you running this one?



Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Issues about webserver on L4Re

[Adam Lackorzynski]

Hi,

On Thu May 24, 2018 at 14:05:57 +, 李 鼎基 wrote:
> I’ve been trying to find or write a webserver directly on L4Re (*NO* L4Linux 
> involved) based on snapshot “l4re-snapshot-17.12”.
> At first, I noticed that there was already a web server in 
> “l4re-snapshot-17.12/src/l4/pkg/ankh”.
> But it was broken, even if I removed the “broken” file to make, nothing was 
> generated under “/path/to/build/pkg/ankh” except “Makefile”.

Yes, the 'broken' file is there because it is, indeed, broken, i.e. not
compiling.

> Then I intend to write a simple webserver (1st step a socket demo). Although 
> there are socket APIs, I don’t know how to solve the NIC driver issues.
> The same code works well on Linux but failed on L4Re.
> 
> Therefore:
> 
>   1.  Is there any way to revive the “ankh”?
>   2.  If not, is there any way/demo to write a simple webserver directly on 
> L4Re? Or how to solve the NIC driver issues?

You're right that there's the need for a driver. Reviving ankh is quite
a bit of work, and would include fixing/updating DDE first. Maybe
looking into dpdk is a better approach here. Then a TCP/IP stack is
required, for a simple demo lwip should work I guess (it's in the repo).
Overall quite a bit of work.

Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Building programs with MODE=shared in L4Re

[Adam Lackorzynski]

On Sun May 20, 2018 at 00:47:02 +0200, Paul Boddie wrote:
> On Monday 14. May 2018 21.18.04 Adam Lackorzynski wrote:
> > 
> > You can set LD_DEBUG=1 in the environment of your program to make the
> > dynamic loader tell you something. LD_TRACE_LOADED_OBJECTS=1 might also
> > be of help. Add enviroment variable settings after the program's
> > cmdline: ...:start({ ...}, "rom/myprog arg", { LD_DEBUG=1, ... });
> 
> So, with the help of fbterminal (mentioned in my last message), I managed to 
> get some debugging information out of the loader:
> 
> L4Re: rom/ex_hello_shared: Unhandled exception: PC=0x80 PFA=8d7a LdrFlgs=0
> 
> This appears to be generated in 
> pkg/l4re-core/l4re_kernel/server/src/region.cc 
> inside the Region_map::op_exception method. I'm not really sure what I can do 
> with this information, though.
> 
> Alongside ex_hello_shared and the stack of programs supporting the 
> framebuffer 
> environment, I have the following libraries included in the modules.list:
> 
> module lib4re.so
> module lib4re-util.so
> module libc_be_l4refile.so
> module libc_be_l4re.so
> module libc_be_socket_noop.so
> module libc_support_misc.so
> module libdl.so
> module libl4sys-direct.so
> module libl4sys.so
> module libl4util.so
> module libld-l4.so
> module libpthread.so
> module libsupc++.so
> module libuc_c.so
> 
> This being for reference, since my first guess would be that the loader is 
> failing before even considering any of the libraries.

So the "Unhandled exception" message is the first one, or are there
other messages? For me this works, in QEMU. If there would be a lib
missing or similar it would also complain differently.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Input driver configuration and use in L4Re

[Adam Lackorzynski]

On Mon Apr 23, 2018 at 01:28:59 +0200, Paul Boddie wrote:
> Hello again,
> 
> I have been implementing input drivers for the keypad/keyboard provided by 
> the 
> Ben NanoNote and Letux 400 notebook computer, and although I appear to have 
> implemented something that works (tested using specialised example code), 
> using the existing OMAP3 keypad code as a guide (in pkg/drivers/input), I 
> wondered whether it is possible to connect such drivers to other components 
> in 
> a convenient way.
> 
> I see that the input package is the thing that provides the device registry 
> that I use when employing the arm_input_register macro, and in that package 
> is 
> a framework that supposedly exports input drivers as serial I/O devices using 
> the "l4drv" driver. But I can't find anything obvious that uses the connect 
> operation which would need to occur to probe, enable, and attach my driver to 
> this framework.
> 
> Is it possible to integrate my input drivers to things like Mag, which seems 
> to use input events, or to fbterminal or other things? I haven't seen any 
> documentation or code that demonstrates this, but I suppose that I may have 
> missed something somewhere.
> 
> Thanks for any help that is offered!

Mag uses libinput (or may use) for getting input devices. That's more or
less the common approach. The drivers in pkg/drivers/input are a loose
end currently, i.e. they're not used by anyone else. However, I believe
you should be able to hook them into
mag/plugins/input_libinput/input_libinput.cc to get some input working for
mag.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Building programs with MODE=shared in L4Re

[Adam Lackorzynski]

Hi Paul,

On Fri May 11, 2018 at 01:00:11 +0200, Paul Boddie wrote:
> I have been busy writing libraries and programs for L4Re and recently had to 
> think about the size of the payloads I have been deploying. It appears that 
> in 
> the build system, one can use MODE=shared to build dynamically-linked 
> programs, and there is a shared version of the hello example in the examples 
> package.
>
> However, I don't see any recipe for doing this for other programs. My 
> impression is that the dynamic linker must have all the required libraries 
> deployed as modules, and so I wrote a script to generate a list of such 
> modules using readelf. In addition, it appears that libl4sys-direct.so is 
> required (which readelf does not detect).

It's option that available but on default most/all programs are static.
 
> Adding these modules to my conf/modules.list should yield success, but within 
> my constrained debugging environment, I only see that "shared" programs fail 
> to start. I really need to see if they start but then experience some 
> initialisation problem, or whether they actually crash but Mag keeps their 
> viewports around.
> 
> Are there any other things that I need to consider when building and 
> deploying 
> such programs? I searched for guidance on this topic and only found the 
> following:
> 
> http://os.inf.tu-dresden.de/pipermail/l4-hackers/2014/007094.html
> http://os.inf.tu-dresden.de/pipermail/l4-hackers/2016/007830.html
> 
> Both of these discussion threads only provide some details and are obviously 
> not tutorials.
> 
> Thanks for any clues you might be able to provide!

You can set LD_DEBUG=1 in the environment of your program to make the
dynamic loader tell you something. LD_TRACE_LOADED_OBJECTS=1 might also
be of help. Add enviroment variable settings after the program's
cmdline: ...:start({ ...}, "rom/myprog arg", { LD_DEBUG=1, ... });

Adam

> P.S. I guess I could also see if the CI20 produces useful console-level 
> details, perhaps indicating an architecture-related problem. Usually, 
> however, 
> the problem is caused by some simple mistake I have made, so I suspect that 
> there is merely some detail I have forgotten.

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Assertion failure error in kernel vgic interrupt processing

[Adam Lackorzynski]

On Thu May 03, 2018 at 11:18:03 +0800, nico.hacker wrote:
> The previous test is not enough to cause error, this error is not related to 
> peripherals, I have removed almost all peripheral driversIn the 
> previous test, I added a delay operation before the vm2 start, so that vm1 
> completely up and then start vm2, this will greatly reduce the probability of 
> the error. Now I removed this delay, vm1 and vm2 started simultaneously, then 
> the error will occur frequently (about 1/10 probability). The error is 
> generated when kernel processes vtimer interrupts. Under normal 
> circumstances, after processing a vtimer interrupt, the vcpu thread will 
> return to uvmm and then execute prepare_guest_entry(). This operation will 
> eventually enter the kernel through the system call to set the state of vcpu 
> thread, but when the error occurs, I find that the vcpu thread does not 
> execute vcpu_resume, it processes two consecutive vtimer interrupts. As a 
> result, the assertion fails.

Ok, I see. I've never experienced this, however I will try running VMs
aggressivly concurrent and see what happens.

> Is the kernel able to guarantee that the complete process of handling vgic 
> and vtimer interrupts (including the process in uvmm) is not interrupted by a 
> new interrupt?

Yes, this is supposed to be the case.

> Here's my configuration:

You're aware that you seem to give both VMs access to the same UART
device? (Will probably have nothing to do with the assertion.)




Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Assertion failure error in kernel vgic interrupt processing

[Adam Lackorzynski]

On Mon Apr 09, 2018 at 22:26:38 +0800, nico wrote:
> Sorry, the last email did not specify this information. 
> I gave VM1 all the hardware resources, and it used eight cores. VM2 only has
> uart resources (also timer, gic resources), using a single core. I tried to
> give both VM1 and VM2 only the necessary hardware resources( uart, timer, 
> gic),
> and that error won't happen.

Ok, that's interesting. So that means that some of the passed through
hardware is causing this. Would you be able to find out which device is
causing this, by selectively enabling/disabling devices?


Adam

> On 4/9/2018 06:28ï¼ Adam Lackorzynski<a...@os.inf.tu-dresden.de> wroteï¼ 
> 
> Hi Nico,
> 
> On Fri Mar 30, 2018 at 10:15:33 +0800, nico wrote:
> 
> Hi Adam, I'm using an eight-core Cortex-A53 processor. The vm is
> running 64bit Linux. It is recommended to start two or three vms, that
> will be easier to reproduce this problem.
> 
> 
> So, I tried several things but cannot reproduce this issue. I assume
> this are single-core VMs only? Any hardware passed through?
> Just trying to narrow it down...

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Assertion failure error in kernel vgic interrupt processing

[Adam Lackorzynski]

Hi Nico,

On Fri Mar 30, 2018 at 10:15:33 +0800, nico wrote:
> Hi Adam, I'm using an eight-core Cortex-A53 processor. The vm is
> running 64bit Linux. It is recommended to start two or three vms, that
> will be easier to reproduce this problem.

So, I tried several things but cannot reproduce this issue. I assume
this are single-core VMs only? Any hardware passed through?
Just trying to narrow it down...


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Assertion failure error in kernel vgic interrupt processing

[Adam Lackorzynski]

Hi,

On Thu Mar 29, 2018 at 20:48:34 +0800, nico wrote:
> Hi l4 hackers,
> 
> I recently encountered an assertion failure error during the vm linux boot
> process, the kernel error is at src/kern/arm/thread-arm-hyp.cpp. 
> --
>  vcpu_vgic_upcall(unsigned virq)
>  {
>..
>assert (state() & Thread_vcpu_user);
>..
>  }
> --
> The thread reports this error while processing the vgic interrupt. I'm not 
> sure
> where the thread state has been changed. The most suspicious is the function
> vcpu_enter_kernel_mode(), but the function is called in several places. I have
> updated to the latest version (l4re-snapshot-18.03) and the error still
> appears.
> There is also a phenomenon that if multiple VMs are started, the frequency of
> this error will increase a lot. 

Interesting. Could you please be a little bit more verbose, e.g. what
type of CPU/SoC you're using and whether you're on 32 or 64bit?
Would I be able to reproduce this?



Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: I got an issue, when testing command like this :qemu–system–aarch64 -kernel uimage -smp 2...

[Adam Lackorzynski]

On Tue Mar 13, 2018 at 11:40:37 +, Jiang qihong wrote:
> The whole command , qemu–system–aarch64 -kernel uimage -M vexpress -a15 -cpu 
> cortex-a57 -smp 2 -m256 --nographic 
> The issue is that when running into shell, i didn't find  two cpus.
> The parameter "-smp 2",didn't work. 
> Does qemu support arch arm -v8 when using the parameter(-smp)? 

Currently, the code to boot up secondary cores on the QEMU rv/vexpress
platform is missing in Fiasco for arm64, i.e. your observation is right,
that only a single core comes up. This is being worked on.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: How to show call path in backtrace with jdb?

[Adam Lackorzynski]

Hi,

On Tue Mar 13, 2018 at 11:58:57 +0800, Zihan Yang wrote:
> I'm trying to debug L4Linux using jdb in Fiasco. I have added a
> breakpoint in a function(e.g, syscall_exit), and it did hit into jdb
> when I run. However, when I type 'bt' in jdb, it only prints the
> values in the stack, or worse, it sometimes couldn't print the stack.

> I have tried enabling L4_DEBUG_REGISTER_NAMES and CONFIG_FRAME_POINTER
> in L4Linux, and uncheck 'config without frame pointer' and 'generate
> inline code' options in Fiasco, but still it doesn't work.
> 
> QEMU could be an option, but qemu debugs the whole system while I just
> want to focus on the L4Linux itself because I just want to figure out
> the call path of ret_from_fork and how does L4Linux stop the user
> dispatch loop, etc.
> 
> Is there any way to show the the call path in jdb to assist the debugging 
> work?

There's not really such a feature in jdb to assist with that.
I think reading code is the better approach here.
 
> By way, is there any doc describing the call path from fiasco to
> L4Linux, I know it is implemented with sysretq or iretq, but where is
> the entrypoint in L4Linux? For example, when I type 'ls /bin' in
> shell, it would finally go into L4Linux's function 'syscall_exit()',
> but how can I find the call path between them? If I can figure it out,
> maybe I just don't need to debug anymore.

All this entry to Linux and exit from it (to the user process) is
happening in arch/l4/kernel/dispatch.c. There's the entry point
(l4x_vcpu_entry) and that's the path to follow. In there it will branch
to syscall handling, page fault handling, irq handling, or exception
handling, depending on the type of entry.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Is the L4Linux running as a Fiasco.OC server?

[Adam Lackorzynski]

Hi,

On Thu Mar 08, 2018 at 11:00:03 +0800, Zeyu Mi wrote:
> On Thu, Mar 8, 2018 at 8:14 AM, Adam Lackorzynski <a...@os.inf.tu-dresden.de
> > wrote:
> 
> >
> > On Wed Mar 07, 2018 at 15:50:24 +0800, Zeyu Mi wrote:
> > > Sorry for bothering you again...
> > >
> > > I have changed to snapshot-17.09 and the "s" command works normally.
> > >
> > > I also disabled the VCPU thread model in the L4Linux config and it can be
> > > compiled
> > > without any error :)
> > >
> > > However, the L4Linux keeps reporting the following error message if
> > running
> > > in QEMU.
> > >
> > > Non-resolvable page fault at b300b308, ip 6454e6.
> > > Page fault (non-resolved): pfa=b300b308 pc=6454e6
> > > Non-resolvable page fault at b300b308, ip 6454e6.
> > > Die message: Trap: 14
> > > Non-resolvable page fault at b300b308, ip 205390.
> > > Page fault (non-resolved): pfa=b300b308 pc=205390
> > > Non-resolvable page fault at b300b308, ip 205390.
> > > Die message: Trap: 14
> > >
> > > If running on the real hardware (a Skylake machine), it keeps reporting
> > the
> > > following message.
> > >
> > > L4x: Main thread running, waiting...
> > > Die message: Trap: 6
> > > Die message: Trap: 6
> > > Die message: Trap: 6
> > > Die message: Trap: 6
> > > Die message: Trap: 6
> > > Die message: Trap: 6
> >
> > That's strange. What are you running inside L4Linux?
> > What's also interesting is that on QEMU there are page-faults and on
> > hardware trap6.
> > For my setups, all looks fine.
> 
> Hi Adam,
> 
> I switched to snapshot-17.12, and turned off the VCPU thread model.
> While this version works normally on QEMU (with -cpu host option, Skylake
> machine), it triggers
> a general protection (trap 13) on the Skylake machine. The instruction
> triggering such fault is "XRSTORS64".
> It is quite strange to see such phenomenon since the QEMU uses the Skylake
> CPU to run the system, which is
> the same as the real hardware.
> 
> Therefore, I dived into the source code and found that the system chose
> different paths in "copy_kernel_to_xregs_booting"
> funtion. This function has the following code snippet.
> 
> if (state_cpu_has(X86_FEATURE_XSAVES))
> XSTATE_OP(XRSTORS, xstate, lmask, hmask, err);
> else
> XSTATE_OP(XRSTOR, xstate, lmask, hmask, err);
> 
> If running in QEMU, the system chose the else branch. But it chose the if
> branch if running in hardware.
> 
> Do you have any suggestion on fixing that?

Ok, so looks like an issue with recent FPU stuff, I need to get a
Skylake as a testbox.
Please try adding "noxsaves" on the L4Linux command line.



Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Activating the sigma0 thread in the Fiasco kernel

[Adam Lackorzynski]

On Thu Mar 08, 2018 at 00:52:55 +0100, Paul Boddie wrote:
> On Wednesday 7. March 2018 01.22.46 Paul Boddie wrote:
> > 
> > Currently, I have reason to believe that an exception occurs causing the
> > sigma0 thread to terminate, but it's getting late and my debugging
> > efficiency is suffering. I think that when the thread terminates, it has
> > the following cause register flags set:
> > 
> > ExcCode = 0b01101 (= 11, coprocessor unusable)
> > IP2 = 1
> > CE = 0b01
> > 
> > The error exception program counter seems to be given as 0x8021, which
> > doesn't sound consistent with a user mode address, but perhaps the kernel
> > is using that register for something else.
> > 
> > So maybe there's some FPU stuff that I haven't managed to eradicate in the
> > L4Re code.
> 
> None of this appeared to be accurate, probably because I was reading directly 
> from the cause register when I should have been reading the saved version. 
> Anyway, I decided to make the kernel stop upon receiving the first thread-
> halting condition, and this yielded the following details:
> 
> * Stored cause has ExcCode 4 (address error, load/instruction fetch)
> * Stored exception program counter is 0x2092ac
> * Stored bad virtual address is 0xfff2aff4
> 
> In sigma0, I found the following rather interesting, produced using objdump 
> with some comments added by me:
> 
>   209290:   3c02fff3lui v0,0xfff3
>   209294:   24422000addiu   v0,v0,8192// 0xfff32000
>   209298:   afc2011csw  v0,284(s8)
>   20929c:   7c02e83b0x7c02e83b// rdhwr v0, $29 (ULR)
>   2092a0:   afc20118sw  v0,280(s8)
>   2092a4:   8fc20118lw  v0,280(s8)
>   2092a8:   8fc30158lw  v1,344(s8)
>   2092ac:   8c508ff4lw  s0,-28684(v0) // 0xfff2aff4
> 
> Evidently, v0 was not getting updated by the rdhwr instruction, which should 
> be handled as a reserved instruction. Thus, the previous value of v0 was 
> being 
> combined with the offset in the final instruction above, causing a read from 
> a 
> completely invalid address that happens to feature in the saved bad virtual 
> address register.
> 
> So, I had a look at my code and discovered that I had indeed transcribed an 
> operation incorrectly: it was related to implementing the ins instruction for 
> this SoC; I had employed the wrong temporary register and was losing the 
> original instruction details when attempting to get the target register.
> 
> At this point, I think Fiasco now starts up. However, I now need to figure 
> out 
> how to perform the necessary operations to reinitialise the framebuffer and 
> do 
> interesting things like provide feedback on what is actually going on in my 
> example programs. I hope it gets a bit easier from this point, though. :-)

Good!


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Is the L4Linux running as a Fiasco.OC server?

[Adam Lackorzynski]

On Wed Mar 07, 2018 at 15:50:24 +0800, Zeyu Mi wrote:
> Sorry for bothering you again...
> 
> I have changed to snapshot-17.09 and the "s" command works normally.
> 
> I also disabled the VCPU thread model in the L4Linux config and it can be
> compiled
> without any error :)
> 
> However, the L4Linux keeps reporting the following error message if running
> in QEMU.
> 
> Non-resolvable page fault at b300b308, ip 6454e6.
> Page fault (non-resolved): pfa=b300b308 pc=6454e6
> Non-resolvable page fault at b300b308, ip 6454e6.
> Die message: Trap: 14
> Non-resolvable page fault at b300b308, ip 205390.
> Page fault (non-resolved): pfa=b300b308 pc=205390
> Non-resolvable page fault at b300b308, ip 205390.
> Die message: Trap: 14
> 
> If running on the real hardware (a Skylake machine), it keeps reporting the
> following message.
> 
> L4x: Main thread running, waiting...
> Die message: Trap: 6
> Die message: Trap: 6
> Die message: Trap: 6
> Die message: Trap: 6
> Die message: Trap: 6
> Die message: Trap: 6

That's strange. What are you running inside L4Linux?
What's also interesting is that on QEMU there are page-faults and on
hardware trap6.
For my setups, all looks fine.

> > BTW, is it possible to enable the previous thread model and SMP in the
> > L4Linux simultaneously?

Not really as this has some issues, it might work (with hickups).



Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Is the L4Linux running as a Fiasco.OC server?

[Adam Lackorzynski]

Hi,

On Tue Mar 06, 2018 at 10:22:18 +0800, Zeyu Mi wrote:
> On Tue, Mar 6, 2018 at 9:20 AM, Zeyu Mi <yzmiz...@gmail.com> wrote:
> 
> >
> >
> > On Tue, Mar 6, 2018 at 7:50 AM, Adam Lackorzynski <
> > a...@os.inf.tu-dresden.de> wrote:
> >
> >> Hi,
> >>
> > Hi Adam,
> >
> >>
> >> On Mon Mar 05, 2018 at 19:47:19 +0800, Zeyu Mi wrote:
> >> > I am studying the implementation of the Fiasco.OC and the L4Linux.
> >> >
> >> > I have searched on the Internet and many papers and documents record
> >> that
> >> > L4Linux runs as an L4 server and
> >> > any L4Linux user process is a new task, which has a new page table
> >> > different from that of an L4Linux server.
> >> >
> >> > However, the experiment result seems to conflict with those documents.
> >> When
> >> > I started a new program in the
> >> > L4Linux shell and used "lp" command (show present list) in JDB, I
> >> noticed
> >> > that there was one thread having "vcpu" state.
> >> > But the resulted list did not contain any new thread or task which is
> >> > related to the new program.
> >> >
> >> > I am very confused and wondering whether or not the implementation
> >> recorded
> >> > in those papers or documents are wrong or obsolete?
> >>
> >> Your obvservations are all right, however, 'lp' lists all threads in the
> >> system but not tasks (aka address spaces). For listing tasks, use 's',
> >> where you will see all the tasks for the Linux user processes.
> >>
> > I have tried 's' command, but there was alwasy a general protection fault.
> > The following is the error
> > message.
> >
> > KERNEL: Warning: No page-fault handler for 0xf048, error 0x0,
> > pc f000922b
> > General Protection (eip=f0042dc3, err=) -- jdb bug?

Strange. You might want to update your snapshot version although I
cannot remember having seen such an error. Alternatively use shift-Q and
look for tasks.

> > There has been a change in model for L4Linux. With the vcpu model there
> >> is only one thread (the vcpu) which is moving between the tasks for
> >> execution. In the previous thread mode there has been a thread in each
> >> user process. Both variants are still available through the L4Linux
> >> config.
> >>
> > Could you kindly tell me how to enable the previous thread mode?
> >
> 
> Hi Adam,
> I have disabled the vcpu exeuction mode by changing the L4Linux config.
> But there is one warning treated as an error when compiling the L4Linux.
> Following is the detailed error log:
> 
> src/l4linux/arch/l4/kernel/main.c:3853:2: error: implicit declaration of
> function ‘get_cpu_gdt_table’ [-Werror=implicit-function-declaration]
> l4x_load_percpu_gdt_descriptor(get_cpu_gdt_table(_cpu));
> 
> Do you have any suggestion to fix that?

Disable CONFIG_SMP?


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Activating the sigma0 thread in the Fiasco kernel

[Adam Lackorzynski]

On Tue Mar 06, 2018 at 01:14:25 +0100, Paul Boddie wrote:
> On Tuesday 6. March 2018 00.46.29 Adam Lackorzynski wrote:
> > 
> > All what you write sounds good. In any case the eret must restore state
> > including setting the right interrupt state. Are you getting timer
> > interrupts when sigma0 shall run, or is there silence? Is ESC working to
> > get into jdb?
> 
> Thanks for the reply as usual! :-)
> 
> After Proc::cli is called in user_invoke, I don't think any interrupts will 
> be 
> delivered, and if I display the status register, the IE (interrupt enable) 
> bit 
> is indeed not set. So I wouldn't expect any timer interrupts unless something 
> else enables interrupts again, but I can't find any statement where this gets 
> done.
> 
> Here, I think that I *might* have transcribed some operation incorrectly, 
> leaving interrupts disabled when they should be re-enabled. The eret 
> shouldn't 
> itself re-enable interrupts, as far as I remember from messing around with my 
> own boot payloads, since it merely clears the EXL (exception level) bit which 
> prevents interrupts if set (and then jumps to EPC, of course).
> 
> (Thinking about it, EXL isn't even set when I check the status register, but 
> if allowing interrupts in kernel mode, it is customary to clear it, from what 
> I have read, so maybe Fiasco does that.)
> 
> Now, I have transcribed the di instruction to the supposedly-equivalent 
> status 
> register operations that clear IE, and the ei instruction to the operations 
> that set IE, both of these featuring in the Proc::cli and Proc::sti methods. 
> Maybe these instructions should be transcribed to set and clear EXL, however, 
> even though that is not what di and ei do.
> 
> As for jdb and UART interactions, I've had to use more primitive techniques 
> because I can't establish a reliable physical connection to the relevant 
> pins. 
> Fortunately, I can take over the framebuffer and display simple bit patterns 
> (to keep debugging code at a minimum), and this is how I can comment on 
> things 
> like the status register. Yes, it is a slow and tedious way of working, but 
> I've used it successfully before. :-)
> 
> Do you have any idea where this missing re-enabling statement might be, or 
> should I really be manipulating EXL instead of IE?

The asm code sets cp0_status upon exit which includes enabling
interrupts. Are you sure you're not getting any timer interrupts when
supposedly running inside sigma0? (Flipping some pixels in the timer
handler...)



Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Is the L4Linux running as a Fiasco.OC server?

[Adam Lackorzynski]

Hi,

On Mon Mar 05, 2018 at 19:47:19 +0800, Zeyu Mi wrote:
> I am studying the implementation of the Fiasco.OC and the L4Linux.
> 
> I have searched on the Internet and many papers and documents record that
> L4Linux runs as an L4 server and
> any L4Linux user process is a new task, which has a new page table
> different from that of an L4Linux server.
> 
> However, the experiment result seems to conflict with those documents. When
> I started a new program in the
> L4Linux shell and used "lp" command (show present list) in JDB, I noticed
> that there was one thread having "vcpu" state.
> But the resulted list did not contain any new thread or task which is
> related to the new program.
> 
> I am very confused and wondering whether or not the implementation recorded
> in those papers or documents are wrong or obsolete?

Your obvservations are all right, however, 'lp' lists all threads in the
system but not tasks (aka address spaces). For listing tasks, use 's',
where you will see all the tasks for the Linux user processes.
There has been a change in model for L4Linux. With the vcpu model there
is only one thread (the vcpu) which is moving between the tasks for
execution. In the previous thread mode there has been a thread in each
user process. Both variants are still available through the L4Linux
config.



Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Activating the sigma0 thread in the Fiasco kernel

[Adam Lackorzynski]

Hi Paul,

On Sun Mar 04, 2018 at 22:25:12 +0100, Paul Boddie wrote:
> I've been trying to coerce L4Re and Fiasco.OC to work with the Ben NanoNote, 
> which is related to the MIPS Creator CI20 that is (mostly - see earlier 
> discussions) supported by this software. There are a few challenges involved, 
> such as avoiding MIPS32r2 instructions that the NanoNote's SoC doesn't 
> support 
> (JZ4740 in the NanoNote versus JZ4780 in the CI20), and positioning things 
> appropriately to avoid upsetting the installed bootloader.
> 
> Since I last posted anything about this, I've managed to get Fiasco to go 
> about its bootstrapping business, proceeding from the bootstrap package, 
> entering the kernel, running kernel_main, doing various initialisation tasks, 
> enabling interrupts, and ending up in the init_workload method where a sigma0 
> thread and a boot thread are created and activated.
> 
> It is at this point that I seem to have encountered a particularly stubborn 
> problem: how to get the sigma0 thread to activate and return control to 
> init_workload for the boot thread to be activated, then going on to finish 
> what little remains of the bootstrapping process. Strangely, the boot thread 
> has no difficulty in being activated and returning control if I put it first 
> in the sequence, but sigma0 seems to cause something different to happen.
> 
> Now, for this activation, it seems that the real action begins in 
> Context::switch_cpu, where an exchange of stack pointers occurs and a branch 
> is made to the Context::switchin_context method, with the old context 
> presumably being made to resume after the branchpoint. As far as I can tell, 
> both threads manage to set this up correctly. I see that the new context then 
> causes Thread::user_invoke to be called, with execution proceeding via the 
> ret_from_user_invoke routine and ultimately into the user task. Looking at 
> the 
> address to which the CPU will "return" to in user mode, all seems reasonable 
> and consistent with the configuration of sigma0.
> 
> However, one thing that baffles me somewhat is the way that interrupts are 
> disabled in Thread::user_invoke. Given that the CPU ends up in the task in 
> user mode, it would surely need some kind of exception or interrupt for the 
> kernel to be re-entered, yet I don't see any operation that re-enables 
> interrupts anywhere. Maybe this is the cause of my problem, but I don't 
> understand how sigma0 would be different from anything else.
> 
> I have needed to change some CPU-level operations to adapt the code to the 
> earlier microarchitecture revision, but I don't think I've made any obvious 
> mistakes, and I have seemingly figured out how to describe the interrupt 
> system because for a while I couldn't get past the Delay::init invocation in 
> the bootstrap process which relies on interrupts working. (Some comments in 
> the code would have helped me guess what numbers to use in certain 
> invocations.)
> 
> Does anyone have any thoughts or guidance about what I should be looking at?

All what you write sounds good. In any case the eret must restore state
including setting the right interrupt state. Are you getting timer
interrupts when sigma0 shall run, or is there silence? Is ESC working to
get into jdb?


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: L4Linux performance vs hardware virtualization

[Adam Lackorzynski]

On Wed Feb 07, 2018 at 08:02:15 +, Bob Liu wrote:
> L4Linux.org mentioned:
>  "Compared to monolithic Linux, there is a small performance tradeoff because 
> of the µ-kernel architecture. However, the initial L4Linux has been somewhat 
> optimized, and on L4/x86 it has a very acceptable slowdown of less than 4 % 
> for any relevant load.
> "
> Any place can find more detail about the test?
> 
> And I'm very curious the L4Linux performance vs "using hardware 
> virtualization on top of L4", have you made any comparison  before?

To add what Vasily already said, L4Linux has a decent performance but
cannot cope with what hardware features can achieve, esp. for the memory
and CPU virtualization. For I/O there isn't really an architectural
difference, except again if there's hardware support, such as interrupt
injection. For L4Linux there's the (famous) paper from 1997 describing
it in its first variant:
https://os.inf.tu-dresden.de/papers_ps/sosp97.pdf



Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: MIPS Creator CI20 patches (again)

[Adam Lackorzynski]

On Fri Feb 02, 2018 at 16:45:13 +0100, Paul Boddie wrote:
> On Wednesday 10. January 2018 00.48.03 Adam Lackorzynski wrote:
> > 
> > Adding the .global to the asm block makes thread2 a global symbol which
> > I'd like not to have here (contrary to L4UTIL_THREAD_FUNC). Just doing
> > "static void thread2()" gives warnings because there is no
> > implementation. Looks to me that having a function is much better here.
> > I'll have a look into this.
> > 
> > Thanks for investigating this. And also thanks to James for the nice
> > explanation of the issue.
> 
> I added a patch that works around this problem (l4util-mips-thread.diff) to 
> my 
> collection:
> 
> http://www.boddie.org.uk/paul/L4Re-Fiasco.OC.html
> 
> (Yes, it's the easiest/laziest approach!)
> 
> I have also been trying to extend the CI20 (JZ4780) support to the Ben 
> NanoNote (JZ4740), but success is still out of my reach in this regard. 
> Currently, the NanoNote is refusing to use the serial pins, having done so 
> before from Linux (but not currently, which is worrying), but it has made me 
> wonder about a few aspects of the UART configuration.
> 
> There seems to be a "kernel" UART, but the userspace seems to have the 
> configuration details in l4/pkg/bootstrap/server/src/platform for each board. 
> Does the kernel somehow delegate the configuration to the bootstrap component 
> or is there somewhere in the kernel that needs to be changed for the "kernel" 
> UART? It also makes me wonder about how the jdb communications are configured.

It's the other way around. The booting begins with bootstrap, that's
where the first output happens. Bootstrap then passes the UART config on
to Fiasco, i.e. the UART config that is used in bootstrap is also used
by Fiasco. Do you see the initial output of bootstrap?


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Get instruction opcode + operands for page fault

[Adam Lackorzynski]

Hi,

On Fri Feb 02, 2018 at 14:32:08 +0100, Josef Stark wrote:
> when a page fault occurs, does the Instruction Register contain the actual
> instruction that caused the fault or the previous instruction? In the former
> case, how can I access it? I need the opcode + the operands (like
> source/target registers). I already have the memory address that the
> instruction tried to access.
> 
> I'm on ARM A9, so only load/store instructions can cause a page fault.
> 
> I know that I could also look at the address where my IP is pointing to and
> get the instruction from there, but I'm wondering which way would be
> easier/better.

There is no register that contains the opcode of the instruction that
caused a fault. You have to read the instruction yourself if you're
interested in decoding the instruction.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Build problems on i386 (Fiasco-OC.UX)

[Adam Lackorzynski]

On Mon Jan 29, 2018 at 22:36:34 +0100, Paul Boddie wrote:
> More awkward news from Debian on i386! I was looking to build the "Linux 
> Usermode Platform" variant of Fiasco-OC on i386 (well, Pentium 4) and 
> encountered a couple of issues.
> 
> Firstly, "struct ucontext" is mentioned in src/kern/ux/usermode.cpp but has 
> been deprecated in favour of "ucontext_t". There are some User Mode Linux 
> reports about this:
> 
> https://lkml.org/lkml/2017/11/15/159
> https://lkml.org/lkml/2018/1/25/522
> 
> A search-and-replace involving the two terms fixes the compilation error that 
> otherwise occurs.

Thanks.

> Secondly, linking of the kernel fails due to symbol conflicts between the 
> minilibc functionality and glibc:
> 
> /usr/lib/gcc/i686-linux-gnu/6/../../../i386-linux-gnu/libc.a(memcmp.o): In 
> function `memcmp':
> (.text+0x0): multiple definition of `memcmp'
> libc.a(memcmp.o):/home/paulb/L4/UX-75/src/kernel/fiasco/src/lib/minilibc/memcmp.c:7:
>  
> first defined here
> collect2: error: ld returned 1 exit status
> /home/paulb/L4/UX-75/src/kernel/fiasco/src/kern/ux/Makerules.KERNEL:35: 
> recipe 
> for target 'fiasco.debug' failed
> 
> So, not knowing how best to deal with this, I relied on the --allow-multiple-
> definition linker option:
> 
> https://gcc.gnu.org/ml/gcc-help/2009-09/msg00108.html
> 
> I doubt that this is the right way to deal with it. Maybe GCC 6.4 (Debian 
> 6.4.0-12) introduced some behaviour that is not compatible with the way this 
> linking is being done.

With older binutils it works, with the most recent ones not.
Anyway, removing memcmp.c from src/Modules.ux seems to fix it, and it
works on both older and recent environments.


Thanks,
Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Build problems on i386 (L4Re)

[Adam Lackorzynski]

On Mon Jan 29, 2018 at 23:40:15 +0100, Paul Boddie wrote:
> As promised, my other error report...
> 
> With Fiasco-OC built, I concentrated on building L4Re for i386, but this led 
> to me encountering this rather frustrating error:
> 
>   [l4util] ==> Linking to shared libl4util.so
> /home/paulb/L4/UX-75/src/l4/mk/lib.mk:139: recipe for target 'libl4util.so' 
> failed
> make[4]: *** [libl4util.so] Segmentation fault
> make[4]: *** Deleting file 'libl4util.so'
> ../../../../../mk/binary.inc:164: recipe for target 
> '/home/paulb/L4/UX-75/src/l4/mybuild/pkg/l4re-core/l4util/lib/src/OBJ-x86_gen-
> l4f' failed
> 
> This issue is present in repository versions 72 through 76. Again, I'm 
> testing 
> this with GCC 6.4 (Debian 6.4.0-12). I've not seen this at all when cross-
> compiling, either with the Debian or with Buildroot compilers.

This is an segfault of the linker/binutils of Debian unstable as of
today. Maybe it's worth pursuing, maybe it goes away on its own...


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Access ARM Data Fault Address Register (System Control Register) in Fiasco.OC

[Adam Lackorzynski]

Hi,

On Thu Jan 25, 2018 at 16:32:25 +, Stark, Josef wrote:
> Hey,
> 
> in Fiasco.OC we have a function inside 
> src/kernel/foc/l4/pkg/l4sys/include/thread.h
> > L4_INLINE l4_msgtag_t
> > l4_thread_ex_regs_ret(l4_cap_idx_t thread, l4_addr_t *ip, l4_addr_t *sp,
> >                      l4_umword_t *flags) L4_NOTHROW;
> which allows us for a given thread (capability ID) to read its general 
> purpose registers, SP and IP.
> Is there a similar function (if not, how could I achieve it) to access the 
> ARM A9 System
> control registers or, to be more precise, the Data Fault Address Register 
> (DFAR) [1] of
> a thread?
> I tried creating a function similar to the above mentioned, but modified the 
> body to do this:
> > unsigned int v;
> > asm volatile ("mrc p15, 0, %[v], c6, c0, 0" : [v]"=r"(v) :: );
> and then write v back to the caller. But this just made the whole system hang.
> Any ideas? Thanks in advance!

This MRC is a privileged instruction and cannot be called in user-level.
If for whatever reason you need to know DFAR (why?), you need to do the
mrc in the kernel and have an interface to retrieve it from there.
Taking any security considerations aside, add another function to L4::Thread
(Thread_object in the kernel) to get the value, it's an easy option.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: L4/Fiasco kernel debugger (jdb) and step over command

[Adam Lackorzynski]

On Thu Jan 18, 2018 at 08:47:52 +0300, Valery V. Sedletski wrote:
> On 18.01.2018 02:41, Adam Lackorzynski wrote:
> > On Tue Jan 16, 2018 at 01:38:18 +0300, Valery V. Sedletski wrote:
> > > On 29.12.2017 01:27, Adam Lackorzynski wrote:
> > > > On Thu Dec 28, 2017 at 05:59:05 +0300, Valery V. Sedletski wrote:
> > > > > On 28.12.2017 03:22, Adam Lackorzynski wrote:
> > > > > > On Thu Dec 28, 2017 at 02:54:20 +0300, Valery V. Sedletski wrote:
> > > > > > > On 28.12.2017 02:29, Adam Lackorzynski wrote:
> > > > > > > > On Wed Dec 27, 2017 at 18:33:16 +0300, Valery V. Sedletski 
> > > > > > > > wrote:
> > > > > > > > > On 27.12.2017 13:05, Matthias Lange wrote:
> > > > > > > > > > Hi Valery,
> > > > > > > > > > 
> > > > > > > > > > > On 26. Dec 2017, at 17:54, Valery V. Sedletski 
> > > > > > > > > > > <_valer...@mail.ru> wrote:
> > > > > > > > > > > 
> > > > > > > > > > > Hi. I'm trying to debug my program with jdb. (I'm using 
> > > > > > > > > > > the old L4/Fiasco / L4Env, not the current Fiasco.OC / 
> > > > > > > > > > > L4Re). I enabled the permanent single step mode (with the 
> > > > > > > > > > > S+ command) and a permanent show the Thread Control Block 
> > > > > > > > > > > (with the t+ command) option. So, I was able to 
> > > > > > > > > > > single-step with "g" command. Also, I found "jr" (go 
> > > > > > > > > > > until return (ret or iret) is encountered) and "jb" (go 
> > > > > > > > > > > until the next branch instruction, like jmp/call/int) 
> > > > > > > > > > > commands, but they don't seem to work. When I enter them, 
> > > > > > > > > > > I see only a single step to the next instruction. Are 
> > > > > > > > > > > these two commands broken? How do I step over a 
> > > > > > > > > > > "call"/"int" instruction?
> > > > > > > > > > Fiasco/L4Env has been outdated for almost 10 years now and 
> > > > > > > > > > hasn’t been maintained since then. Sorry, but here we are 
> > > > > > > > > > unable to help you with your problem.
> > > > > > > > > Yes, I know that  it's outdated now.
> > > > > > > > > > Are there any reasons you chose Fiasco/L4Env over 
> > > > > > > > > > Fiasco.OC/L4Re?
> > > > > > > > > My program is based on L4Env. I'm porting it to L4Re now. But 
> > > > > > > > > first I need
> > > > > > > > > to fix some bug and then continue porting it to L4Re. I 
> > > > > > > > > think, someone could
> > > > > > > > > remember some problems existed with L4/Fiasco kernel 
> > > > > > > > > debugger. Also,
> > > > > > > > > Fiasco.OC debugger may be very similar, so I expected someone 
> > > > > > > > > could help me.
> > > > > > > > > The problem is that I cannot find any commands similar to 
> > > > > > > > > "step over"
> > > > > > > > > command. There are "jb" (continue to the next branch 
> > > > > > > > > instruction) and "jr"
> > > > > > > > > (continue until next return instruction), but they don't seem 
> > > > > > > > > to work. They
> > > > > > > > > just do a single stepping. Does still anybody remember how 
> > > > > > > > > could I step over
> > > > > > > > > a "call" instruction? Maybe, in Fiasco.OC it's similar? Or, 
> > > > > > > > > in Fiasco, it
> > > > > > > > > was completely broken in the end?
> > > > > > > > Indeed, jdb's functionality is still pretty similar here, 
> > > > > > > > including
> > > > > > > > non-functionalities. Would you have a chance to run your code 
> > > > > > > > within
> &

Re: L4/Fiasco kernel debugger (jdb) and step over command

[Adam Lackorzynski]

On Tue Jan 16, 2018 at 01:38:18 +0300, Valery V. Sedletski wrote:
> On 29.12.2017 01:27, Adam Lackorzynski wrote:
> > On Thu Dec 28, 2017 at 05:59:05 +0300, Valery V. Sedletski wrote:
> > > On 28.12.2017 03:22, Adam Lackorzynski wrote:
> > > > On Thu Dec 28, 2017 at 02:54:20 +0300, Valery V. Sedletski wrote:
> > > > > On 28.12.2017 02:29, Adam Lackorzynski wrote:
> > > > > > On Wed Dec 27, 2017 at 18:33:16 +0300, Valery V. Sedletski wrote:
> > > > > > > On 27.12.2017 13:05, Matthias Lange wrote:
> > > > > > > > Hi Valery,
> > > > > > > > 
> > > > > > > > > On 26. Dec 2017, at 17:54, Valery V. Sedletski 
> > > > > > > > > <_valer...@mail.ru> wrote:
> > > > > > > > > 
> > > > > > > > > Hi. I'm trying to debug my program with jdb. (I'm using the 
> > > > > > > > > old L4/Fiasco / L4Env, not the current Fiasco.OC / L4Re). I 
> > > > > > > > > enabled the permanent single step mode (with the S+ command) 
> > > > > > > > > and a permanent show the Thread Control Block (with the t+ 
> > > > > > > > > command) option. So, I was able to single-step with "g" 
> > > > > > > > > command. Also, I found "jr" (go until return (ret or iret) is 
> > > > > > > > > encountered) and "jb" (go until the next branch instruction, 
> > > > > > > > > like jmp/call/int) commands, but they don't seem to work. 
> > > > > > > > > When I enter them, I see only a single step to the next 
> > > > > > > > > instruction. Are these two commands broken? How do I step 
> > > > > > > > > over a "call"/"int" instruction?
> > > > > > > > Fiasco/L4Env has been outdated for almost 10 years now and 
> > > > > > > > hasn’t been maintained since then. Sorry, but here we are 
> > > > > > > > unable to help you with your problem.
> > > > > > > Yes, I know that  it's outdated now.
> > > > > > > > Are there any reasons you chose Fiasco/L4Env over 
> > > > > > > > Fiasco.OC/L4Re?
> > > > > > > My program is based on L4Env. I'm porting it to L4Re now. But 
> > > > > > > first I need
> > > > > > > to fix some bug and then continue porting it to L4Re. I think, 
> > > > > > > someone could
> > > > > > > remember some problems existed with L4/Fiasco kernel debugger. 
> > > > > > > Also,
> > > > > > > Fiasco.OC debugger may be very similar, so I expected someone 
> > > > > > > could help me.
> > > > > > > The problem is that I cannot find any commands similar to "step 
> > > > > > > over"
> > > > > > > command. There are "jb" (continue to the next branch instruction) 
> > > > > > > and "jr"
> > > > > > > (continue until next return instruction), but they don't seem to 
> > > > > > > work. They
> > > > > > > just do a single stepping. Does still anybody remember how could 
> > > > > > > I step over
> > > > > > > a "call" instruction? Maybe, in Fiasco.OC it's similar? Or, in 
> > > > > > > Fiasco, it
> > > > > > > was completely broken in the end?
> > > > > > Indeed, jdb's functionality is still pretty similar here, including
> > > > > > non-functionalities. Would you have a chance to run your code within
> > > > > > QEMU and attach gdb to QEMU so that you could do your debugging?
> > > > > > 
> > > > > So, it still does not work in jdb until now? Good, so debugging in GDB
> > > > > inside QEMU still should work?
> > > > > Is there any examples how to do GDB debugging (or, it is not specific 
> > > > > to
> > > > > L4/Fiasco or Fiasco.OC?)? I suspect that I need to link a GDB stub 
> > > > > with my
> > > > > program and connect to it with GDB via network somehow? Are there any
> > > > > manuals somewhere?
> > > > What I mean is rather attaching GDB to QEMU and using that to debug the
> > > > whole L4 system. What maybe tric

Re: Question about vm memory initialization

[Adam Lackorzynski]

Hi,

On Wed Jan 10, 2018 at 21:33:51 +0800, nico wrote:
> Yes,  your understanding is correct.  I want  u-boot to load ramdisk to RAM,
> not linux
> kernel.  And vm linux will use that ramdisk, can this be achieved?

Loading a ramdisk alongside of the Linux kernel is a standard feature of
uvmm. For that, add the ramdisk to your entry in the modules.list file.
With that it will be included in your image that is being built.
Then, in your uvmm.ned config file (if you're using that), add/change
the 'rd' entry to rd="rom/yourfile" where "yourfile" is the file you
added in your modules.list entry.

Does this help?
Adam

> On 1/10/2018 16:40ï¼ Matthias Lange<matthias.la...@kernkonzept.com> wroteï¼ 
> 
> Hi Nico,
> 
> On 2018-0110 at 09:11:09 +0800, nico.hacker wrote:
> > Yes, that's it. Do you have any good suggestions?
> äº   2018-01-10 06:36:25,Adam Lackorzynski os=
> "" inf="" tu-dresden="" de="">å  é  : "padding-left:1ex;margin:0px 0px 0px 0.8ex;border-left:#ccc 1px solid">
> Hi nico,
> > 
> > On Tue Jan 09, 2018 at 19:18:20 +0800, nico wrote:
> > 
>  I started uvmm and found that all ram space allocated to vm are cleared.
> > 
> > Yes, sure. We do not want to see any other data in there, possibly
> > coming from another domain and leaking some information.
> > 
> > 
>  But I do not need to do that, because uboot has loaded image file to 
> ram, and vm linux would use that image file. Could you tell me where the uvmm 
> did the cleanup?
>  Regards, Nico
> 
> I am not sure if I have understood your use-case correctly but the steps 
> you
> 
> are performing are like this?
> 
> 1. Power up your board
> 2. u-boot loads a Linux kernel (and possibly ramdisk and device tree)
>  into RAM
> 3. u-boot loads your L4Re image
> 4. L4Re is started with uvmm
> 
> Is my understanding correct?
> 
> Regards,
> Matthias.
> 
> > 
> > Describing this in my own words, you want to load a file via u-boot and
> > use that in your VM?
> > 
> > Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: MIPS Creator CI20 patches (again)

[Adam Lackorzynski]

On Tue Jan 09, 2018 at 23:17:10 +0100, Paul Boddie wrote:
> On Tuesday 9. January 2018 01.02.58 Paul Boddie wrote:
> > 
> > So, I am assuming that the compiler gets confused by the freestanding
> > assembly language definition of the function, and the object goes missing
> > in some way that then leads to the error. Of course, the above introduces
> > other operations that are superfluous, but perhaps not harmful, due to the
> > general boilerplate included in C-level functions.
> > 
> > Anyway, I'll see if I get any response from the other discussion.
> 
> Well, I got a response that effectively describes the cause of the problem:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884821#25
> 
> As I understand it, the assembly language code defines a local object (the 
> default behaviour), but the C compiler regards it as a global object due to 
> the declaration used:
> 
> void __attribute__((visibility("internal"))) thread2(void);
> 
> Consequently, the linker complains about this inconsistency (but also seems 
> to 
> experience an error generating the error message).
> 
> What I see from the mybuild/include/mips/l4/util/thread.h file are two macros 
> for defining and declaring thread functions:
> 
> - L4UTIL_THREAD_FUNC introduces a global object wrapping the actual function
> 
> - L4UTIL_THREAD_STATIC_FUNC introduces a local object wrapping the actual 
> function, declaring it at the C level as a global, internal object
> 
> Since we are dealing with the output of the latter macro, it seems that there 
> are two main alternatives that suppress the error:
> 
> - Add a ".global" directive for the introduced wrapper object in the assembly 
> language (as is done by the former macro), producing a global but internal 
> object
> 
> - Declare the object at the C level as a static object, as in...
> 
>   static void thread2(void);
> 
> Another solution could involve using a C-level wrapper function and including 
> assembly language inside that, if necessary. Maybe someone (Sarah?) could say 
> what the motivations were for doing it in the current way. My hypothesis is 
> that extra instructions get generated for the C functions that are either 
> superfluous or harmful, such as accessing the stack, but I would gladly be 
> corrected.

Adding the .global to the asm block makes thread2 a global symbol which
I'd like not to have here (contrary to L4UTIL_THREAD_FUNC). Just doing
"static void thread2()" gives warnings because there is no
implementation. Looks to me that having a function is much better here.
I'll have a look into this.

Thanks for investigating this. And also thanks to James for the nice
explanation of the issue.



Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Question about vm memory initialization

[Adam Lackorzynski]

Hi nico,

On Tue Jan 09, 2018 at 19:18:20 +0800, nico wrote:
> I started uvmm and found that all ram space allocated to vm are cleared.

Yes, sure. We do not want to see any other data in there, possibly
coming from another domain and leaking some information.

> But I do not need to do that, because uboot has loaded image file to ram, and 
> vm linux would use that image file. Could you tell me where the uvmm did the 
> cleanup? Regards, Nico

Describing this in my own words, you want to load a file via u-boot and
use that in your VM?



Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: MIPS Creator CI20 patches (again)

[Adam Lackorzynski]

On Mon Jan 08, 2018 at 01:14:09 +0100, Paul Boddie wrote:
> On Monday 8. January 2018 00.37.41 Adam Lackorzynski wrote:
> > 
> > Is it ok if you have visibility("hidden") instead of internal?
> 
> No, it would seem that all other visibility types produce the same error. In 
> fact, the only thing that seems to prevent an error is to qualify the 
> function 
> signature as static, as previously noted:

Alright, strange, but thanks for investigating.

> static void thread2(void);
> 
> Trying other visibility types or just omitting the static qualifier from the 
> above causes the same error, the essence of which is this:
> 
> Can't find matching LO16 reloc against `.text' for R_MIPS_GOT16 at 0x1f8
> 
> So, I guess it is some kind of code generation bug in the toolchain, but it 
> did make me wonder what the L4UTIL_THREAD_STATIC_FUNC macro does and why we 
> get this problem now. It seems like it introduces a wrapper function that 
> sets 
> up the appropriate register for position-independent code (reminiscent of the 
> ci20-gcc-cpload.diff file amongst my patches which does the same for various 
> l4re-core components that won't otherwise work when compiled with GCC).
> 
> And maybe this wrapper function confuses the compiler somehow. However, it 
> doesn't confuse the compiler for the vcpu example where it is also used. So, 
> there might be something else going on as well.
> 
> I'm aiming to follow up with the binutils maintainers about this, but I just 
> wondered if any of this sounded problematic or familiar.

No, not familiar. It works with the older tool set, i.e. would be
interesting whether the more recent ones are not ok here or the code
needs to change.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: MIPS Creator CI20 patches (again)

[Adam Lackorzynski]

Hi Paul,

On Sun Jan 07, 2018 at 14:15:13 +0100, Paul Boddie wrote:
> Sorry to follow up on myself again...
> 
> On Thursday 21. December 2017 01.55.51 Paul Boddie wrote:
> > On Wednesday 20. December 2017 16.52.45 Paul Boddie wrote:
> > > However, another problem has emerged when trying to build L4Re. It
> > > appears that something changed between r72 and r73, and now, when I try
> > > and build L4Re, I get a linker error as described in the following
> > > Debian bug report:
> > > 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884821
> > > 
> > > 
> > > mipsel-linux-gnu-ld: main.o: Can't find matching LO16 reloc against
> > > `.text' for R_MIPS_GOT16 at 0x1f8 in section `mipsel-linux-gnu-ld: BFD
> > > (GNU Binutils for Debian) 2.29.1 internal error, aborting at
> > > ../../bfd/bfd.c:866 in _bfd_doprnt
> 
> This specific internal error is a bug in binutils when producing the error 
> message, but the error causing the message is a genuine problem.
> 
> In pkg/examples/sys/utcb-ipc/main.c, expanding the L4UTIL_THREAD_STATIC_FUNC 
> macro by hand, I get the following:
> 
> EXTERN_C_BEGIN
> void __attribute__((visibility("internal"))) thread2(void);
> static void __attribute__((used)) thread2_worker_function(void);
> asm (
>   ".type thread2, function \n"
>   "thread2 : \n .set push; .set noreorder;"
>   L4UTIL_THREAD_START_SETUP_GP
>   "la $t9, thread2_worker_function\n"
>   "  jal $t9 \n"
>   "   nop\n"
>   ".set pop"
> );
> EXTERN_C_END
> static L4_NORETURN void thread2_worker_function(void)
> {
> ...
> }
> 
> It seems that the problem is caused by the declaration of thread2. If I 
> replace that with this...
> 
> static void thread2(void);
> 
> ...the error associated with the output goes away (although I get a warning 
> from the compiler about thread2 not being defined, which happens in the 
> assembly language code, of course). But obviously, this isn't a proper 
> solution.

Is it ok if you have visibility("hidden") instead of internal?


Thanks,
Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: L4/Fiasco kernel debugger (jdb) and step over command

[Adam Lackorzynski]

On Thu Dec 28, 2017 at 05:59:05 +0300, Valery V. Sedletski wrote:
> On 28.12.2017 03:22, Adam Lackorzynski wrote:
> > On Thu Dec 28, 2017 at 02:54:20 +0300, Valery V. Sedletski wrote:
> > > On 28.12.2017 02:29, Adam Lackorzynski wrote:
> > > > On Wed Dec 27, 2017 at 18:33:16 +0300, Valery V. Sedletski wrote:
> > > > > On 27.12.2017 13:05, Matthias Lange wrote:
> > > > > > Hi Valery,
> > > > > > 
> > > > > > > On 26. Dec 2017, at 17:54, Valery V. Sedletski 
> > > > > > > <_valer...@mail.ru> wrote:
> > > > > > > 
> > > > > > > Hi. I'm trying to debug my program with jdb. (I'm using the old 
> > > > > > > L4/Fiasco / L4Env, not the current Fiasco.OC / L4Re). I enabled 
> > > > > > > the permanent single step mode (with the S+ command) and a 
> > > > > > > permanent show the Thread Control Block (with the t+ command) 
> > > > > > > option. So, I was able to single-step with "g" command. Also, I 
> > > > > > > found "jr" (go until return (ret or iret) is encountered) and 
> > > > > > > "jb" (go until the next branch instruction, like jmp/call/int) 
> > > > > > > commands, but they don't seem to work. When I enter them, I see 
> > > > > > > only a single step to the next instruction. Are these two 
> > > > > > > commands broken? How do I step over a "call"/"int" instruction?
> > > > > > Fiasco/L4Env has been outdated for almost 10 years now and hasn’t 
> > > > > > been maintained since then. Sorry, but here we are unable to help 
> > > > > > you with your problem.
> > > > > Yes, I know that  it's outdated now.
> > > > > > Are there any reasons you chose Fiasco/L4Env over Fiasco.OC/L4Re?
> > > > > My program is based on L4Env. I'm porting it to L4Re now. But first I 
> > > > > need
> > > > > to fix some bug and then continue porting it to L4Re. I think, 
> > > > > someone could
> > > > > remember some problems existed with L4/Fiasco kernel debugger. Also,
> > > > > Fiasco.OC debugger may be very similar, so I expected someone could 
> > > > > help me.
> > > > > The problem is that I cannot find any commands similar to "step over"
> > > > > command. There are "jb" (continue to the next branch instruction) and 
> > > > > "jr"
> > > > > (continue until next return instruction), but they don't seem to 
> > > > > work. They
> > > > > just do a single stepping. Does still anybody remember how could I 
> > > > > step over
> > > > > a "call" instruction? Maybe, in Fiasco.OC it's similar? Or, in 
> > > > > Fiasco, it
> > > > > was completely broken in the end?
> > > > Indeed, jdb's functionality is still pretty similar here, including
> > > > non-functionalities. Would you have a chance to run your code within
> > > > QEMU and attach gdb to QEMU so that you could do your debugging?
> > > > 
> > > So, it still does not work in jdb until now? Good, so debugging in GDB
> > > inside QEMU still should work?
> > > Is there any examples how to do GDB debugging (or, it is not specific to
> > > L4/Fiasco or Fiasco.OC?)? I suspect that I need to link a GDB stub with my
> > > program and connect to it with GDB via network somehow? Are there any
> > > manuals somewhere?
> > What I mean is rather attaching GDB to QEMU and using that to debug the
> > whole L4 system. What maybe tricky here is to stop the system at the
> > right point but breakpoints should do it here. QEMU options are
> > -s and -S.
> > 
> > 
> > Adam
> 
> So, I need to add the GDB stub to a microkernel somehow? Is this an option
> somewhere in Fiasco configuration menu?

No. The GDB stub is already there in QEMU, allowing to debug what is
running inside QEMU. Just try it out :)


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: L4/Fiasco kernel debugger (jdb) and step over command

[Adam Lackorzynski]

On Thu Dec 28, 2017 at 02:54:20 +0300, Valery V. Sedletski wrote:
> On 28.12.2017 02:29, Adam Lackorzynski wrote:
> > On Wed Dec 27, 2017 at 18:33:16 +0300, Valery V. Sedletski wrote:
> > > On 27.12.2017 13:05, Matthias Lange wrote:
> > > > Hi Valery,
> > > > 
> > > > > On 26. Dec 2017, at 17:54, Valery V. Sedletski <_valer...@mail.ru> 
> > > > > wrote:
> > > > > 
> > > > > Hi. I'm trying to debug my program with jdb. (I'm using the old 
> > > > > L4/Fiasco / L4Env, not the current Fiasco.OC / L4Re). I enabled the 
> > > > > permanent single step mode (with the S+ command) and a permanent show 
> > > > > the Thread Control Block (with the t+ command) option. So, I was able 
> > > > > to single-step with "g" command. Also, I found "jr" (go until return 
> > > > > (ret or iret) is encountered) and "jb" (go until the next branch 
> > > > > instruction, like jmp/call/int) commands, but they don't seem to 
> > > > > work. When I enter them, I see only a single step to the next 
> > > > > instruction. Are these two commands broken? How do I step over a 
> > > > > "call"/"int" instruction?
> > > > Fiasco/L4Env has been outdated for almost 10 years now and hasn’t been 
> > > > maintained since then. Sorry, but here we are unable to help you with 
> > > > your problem.
> > > Yes, I know that  it's outdated now.
> > > > Are there any reasons you chose Fiasco/L4Env over Fiasco.OC/L4Re?
> > > My program is based on L4Env. I'm porting it to L4Re now. But first I need
> > > to fix some bug and then continue porting it to L4Re. I think, someone 
> > > could
> > > remember some problems existed with L4/Fiasco kernel debugger. Also,
> > > Fiasco.OC debugger may be very similar, so I expected someone could help 
> > > me.
> > > The problem is that I cannot find any commands similar to "step over"
> > > command. There are "jb" (continue to the next branch instruction) and "jr"
> > > (continue until next return instruction), but they don't seem to work. 
> > > They
> > > just do a single stepping. Does still anybody remember how could I step 
> > > over
> > > a "call" instruction? Maybe, in Fiasco.OC it's similar? Or, in Fiasco, it
> > > was completely broken in the end?
> > Indeed, jdb's functionality is still pretty similar here, including
> > non-functionalities. Would you have a chance to run your code within
> > QEMU and attach gdb to QEMU so that you could do your debugging?
> > 
> So, it still does not work in jdb until now? Good, so debugging in GDB
> inside QEMU still should work?
> Is there any examples how to do GDB debugging (or, it is not specific to 
> L4/Fiasco or Fiasco.OC?)? I suspect that I need to link a GDB stub with my
> program and connect to it with GDB via network somehow? Are there any
> manuals somewhere?

What I mean is rather attaching GDB to QEMU and using that to debug the
whole L4 system. What maybe tricky here is to stop the system at the
right point but breakpoints should do it here. QEMU options are
-s and -S.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: L4/Fiasco kernel debugger (jdb) and step over command

[Adam Lackorzynski]

On Wed Dec 27, 2017 at 18:33:16 +0300, Valery V. Sedletski wrote:
> On 27.12.2017 13:05, Matthias Lange wrote:
> > Hi Valery,
> > 
> > > On 26. Dec 2017, at 17:54, Valery V. Sedletski <_valer...@mail.ru> wrote:
> > > 
> > > Hi. I'm trying to debug my program with jdb. (I'm using the old L4/Fiasco 
> > > / L4Env, not the current Fiasco.OC / L4Re). I enabled the permanent 
> > > single step mode (with the S+ command) and a permanent show the Thread 
> > > Control Block (with the t+ command) option. So, I was able to single-step 
> > > with "g" command. Also, I found "jr" (go until return (ret or iret) is 
> > > encountered) and "jb" (go until the next branch instruction, like 
> > > jmp/call/int) commands, but they don't seem to work. When I enter them, I 
> > > see only a single step to the next instruction. Are these two commands 
> > > broken? How do I step over a "call"/"int" instruction?
> > Fiasco/L4Env has been outdated for almost 10 years now and hasn’t been 
> > maintained since then. Sorry, but here we are unable to help you with your 
> > problem.
> Yes, I know that  it's outdated now.
> > Are there any reasons you chose Fiasco/L4Env over Fiasco.OC/L4Re?
> My program is based on L4Env. I'm porting it to L4Re now. But first I need
> to fix some bug and then continue porting it to L4Re. I think, someone could
> remember some problems existed with L4/Fiasco kernel debugger. Also,
> Fiasco.OC debugger may be very similar, so I expected someone could help me.
> The problem is that I cannot find any commands similar to "step over"
> command. There are "jb" (continue to the next branch instruction) and "jr"
> (continue until next return instruction), but they don't seem to work. They
> just do a single stepping. Does still anybody remember how could I step over
> a "call" instruction? Maybe, in Fiasco.OC it's similar? Or, in Fiasco, it
> was completely broken in the end?

Indeed, jdb's functionality is still pretty similar here, including
non-functionalities. Would you have a chance to run your code within
QEMU and attach gdb to QEMU so that you could do your debugging?


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: exception while running L4linux on raspberry pi 2

[Adam Lackorzynski]

Hi,

On Fri Dec 15, 2017 at 15:09:54 +0530, vmc doe wrote:
>  I tried to build l4+l4Re+l4linux for raspberry pi 2.
> The build was successful, but when I tried to run this in qemu I am getting
> the following error.
> Could you pls help me to fix this error?
> I am new to L4 and L4Re and would like to try out some virtualization
> options with L4 Microkernel.
> Could you pls suggest some initial modules or portions where I can start
> with.
> 
> Regards
> vmc
> 
>   BOOTFS: [110-110012e] [C:107000] l4lx.cfg
>   BOOTFS: [1101000-111a4a4] [C:109000] l4re
>   BOOTFS: [111b000-117c718] [C:10b000] ned
>   BOOTFS: [117d000-1576480] [C:10d000] vmlinuz
>   BOOTFS: [1577000-1877000] [C:10f000] ramdisk-arm.rd
> MOE: cmdline: moe rom/l4lx.cfg
> MOE: Starting: rom/ned rom/l4lx.cfg
> MOE: loading 'rom/ned'
> Ned says: Hi World!
> L4Re: unhandled exception: pc=0x1029198 (pfa=205a48)
> L4Re: Global::l4re_aux->ldr_flags=0

Interesting. Is that the default l4lx.cfg? I.e. you're starting L4Linux?
But I think this is earlier. Could you check where in the code the
intruction pointer 0x1029198 is? Use gdb or objdump -ldSC on the 'ned'
binary you find in the build directory.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Trying l4re-snapshot-17.10 on a Wanboard(iMX6Q) hangs at Starting kernel ...

[Adam Lackorzynski]

Hi,

On Fri Dec 15, 2017 at 12:09:43 +, Sathish Kumar Balasubramaniam -ERS, HCL 
Tech wrote:
> Build machine is Debian 8.10 (jessie) 64-Bit
> GCC toolchain is gcc-linaro-4.9.4-2017.01-x86_64_arm-linux-gnueabihf
> I tried to build the l4re-snapshot-17.10 for Freescale iMX6 and the build 
> completed.
> When i loaded the bootstrap.uimage (both hello and L4Linux-basic) boots till 
> the following

That might just be the wrong UART. The default for imx6 is UART2, which
UART is the Wandboard using? You can select the UART by adding
PLATFORM_UART_NR=x (for x with 1 to 5) to the command line when building
the uimage.

> U-Boot 2016.11+fslc+gc44711d (Nov 15 2017 - 16:14:11 +0530)
> 
> CPU:   Freescale i.MX6Q rev1.2 at 792 MHz
> Reset cause: POR
> Board: Wandboard rev C1
> I2C:   ready
> DRAM:  2 GiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> *** Warning - bad CRC, using default environment
> 
> auto-detected panel HDMI
> Display: HDMI (1024x768)
> In:serial
> Out:   serial
> Err:   serial
> Net:   FEC [PRIME]
> Hit any key to stop autoboot:  0
> => ext4load mmc 0 ${loadaddr} /boot/bootstrap.uimage
> 8790080 bytes read in 628 ms (13.3 MiB/s)
> => bootm ${loadaddr}
> ## Booting kernel from Legacy Image at 1200 ...
>Image Name:   L4 Image #2
>Image Type:   ARM Linux Kernel Image (uncompressed)
>Data Size:8790016 Bytes = 8.4 MiB
>Load Address: 1100
>Entry Point:  1100
>Verifying Checksum ... OK
>Loading Kernel Image ... OK
> 
> Starting kernel ...


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Porting Fiasco + L4Re to Raspberry Pi 2

[Adam Lackorzynski]

Hi,

On Fri Nov 24, 2017 at 10:30:31 +0100, Alexander Weidinger wrote:
> I'm using U-Boot in the version v2017.09 by denx to boot the device.
> The binary blobs `bootcode.bin` and `start.elf` are from [0].
> Additionally the `config.txt` in use is as follows:
> 
> > kernel=u-boot.bin
> > enable_uart=1
> > init_uart_baud=115200
> > init_uart_clock=300
> 
> I'm directly using the *.elf file(s) and copy them to `loadaddr`,
> which should be 0x0020.

Thanks for all the info. I can only try to reproduce this to eventually
understand what the problem is.

Thanks, Adam

> [0] https://github.com/raspberrypi/firmware/tree/1.20170811/boot
> 
> On 24.11.2017 01:10, Adam Lackorzynski wrote:
> > Hi,
> > 
> > On Tue Nov 21, 2017 at 16:19:52 +0100, Alexander Weidinger wrote:
> >> Hello Antoine, hello l4-hackers,
> >>
> >> I'm currently trying to replicate the port to RPi2 for Fiasco/Genode,
> >> which works great, until I get stuck in the boot process:
> >>
> >>> L4 Bootstrapper   
> >>>   
> >>>   Build: #7 Di 21. Nov 15:19:58 CET 2017, 5.4.0   
> >>>   
> >>>   Scanning up to 960 MB RAM, starting at offset 32MB  
> >>>   
> >>>   Memory size is 960MB ( - 3bff)  
> >>>   
> >>>   RAM:  - 3bff: 983040kB  
> >>>   
> >>>   Total RAM: 960MB
> >>>   
> >>>   Scanning fiasco 
> >>>   
> >>>   Scanning sigma0 
> >>>   
> >>>   Scanning moe
> >>>   
> >>>   Moving up to 5 modules behind 110   
> >>>   
> >>>   moving module 02 { 10ed000-111e4a3 } -> { 11de000-120f4a3 } [201892]
> >>>   
> >>>   moving module 01 { 10db000-10ec337 } -> { 11cc000-11dd337 } [70456] 
> >>>   
> >>>   moving module 00 { 1053000-10da0e7 } -> { 1144000-11cb0e7 } [553192]
> >>>   
> >>>   moving module 04 { 1031000-105257b } -> { 1122000-114357b } [136572]
> >>>   
> >>>   moving module 03 { 100f000-1030467 } -> { 110-1121467 } [136296]
> >>>   
> >>>   Loading fiasco  
> >>>   
> >>>   Loading sigma0  
> >>>   
> >>>   Loading moe 
> >>>   
> >>>   find kernel info page...
> >>>   
> >>>   found kernel info page (via ELF) at 2000
> >>>   
> >>> Regions of list 'regions' 
> >>>   
> >>> [ 1000,  1a3f] {  a40} Kern   fiasco  
> >>>   
> >>> [ 2000, 96fff] {95000} Kern   fiasco  
> >>>   
> >>> [97000, 970eb] {   ec} Root   mbi_rt  
> >>>   
> >>> [e, ea9e7] { a9e8} Sigma0 sigma0  
> >>>   
> >>> [f, f517b] { 517c} Sigma0 sigma0  
> >>>   
> >>> [   14,17c4eb] {3c4ec} Root   moe 
> >>>   
> >>> [  100,   100e523] { e524} Boot   bootstrap   
> >>>   
> >>> [  110,   1143fff] {44000} Root   Module  
> >>>   
> >>>   found kernel options (via ELF) at 3000  
> >>>   
> >>>   Sigma0 configip:000e0100 sp:
> >>>   
> >>>   Roottask config  ip:00140254 sp:
> >>>   
> >>>   Starting kernel fiasco at 1200  
> >&g

Re: Porting Fiasco + L4Re to Raspberry Pi 2

[Adam Lackorzynski]

Hi,

On Tue Nov 21, 2017 at 16:19:52 +0100, Alexander Weidinger wrote:
> Hello Antoine, hello l4-hackers,
> 
> I'm currently trying to replicate the port to RPi2 for Fiasco/Genode,
> which works great, until I get stuck in the boot process:
> 
> > L4 Bootstrapper 
> > 
> >   Build: #7 Di 21. Nov 15:19:58 CET 2017, 5.4.0 
> > 
> >   Scanning up to 960 MB RAM, starting at offset 32MB
> > 
> >   Memory size is 960MB ( - 3bff)
> > 
> >   RAM:  - 3bff: 983040kB
> > 
> >   Total RAM: 960MB  
> > 
> >   Scanning fiasco   
> > 
> >   Scanning sigma0   
> > 
> >   Scanning moe  
> > 
> >   Moving up to 5 modules behind 110 
> > 
> >   moving module 02 { 10ed000-111e4a3 } -> { 11de000-120f4a3 } [201892]  
> > 
> >   moving module 01 { 10db000-10ec337 } -> { 11cc000-11dd337 } [70456]   
> > 
> >   moving module 00 { 1053000-10da0e7 } -> { 1144000-11cb0e7 } [553192]  
> > 
> >   moving module 04 { 1031000-105257b } -> { 1122000-114357b } [136572]  
> > 
> >   moving module 03 { 100f000-1030467 } -> { 110-1121467 } [136296]  
> > 
> >   Loading fiasco
> > 
> >   Loading sigma0
> > 
> >   Loading moe   
> > 
> >   find kernel info page...  
> > 
> >   found kernel info page (via ELF) at 2000  
> > 
> > Regions of list 'regions'   
> > 
> > [ 1000,  1a3f] {  a40} Kern   fiasco
> > 
> > [ 2000, 96fff] {95000} Kern   fiasco
> > 
> > [97000, 970eb] {   ec} Root   mbi_rt
> > 
> > [e, ea9e7] { a9e8} Sigma0 sigma0
> > 
> > [f, f517b] { 517c} Sigma0 sigma0
> > 
> > [   14,17c4eb] {3c4ec} Root   moe   
> > 
> > [  100,   100e523] { e524} Boot   bootstrap 
> > 
> > [  110,   1143fff] {44000} Root   Module
> > 
> >   found kernel options (via ELF) at 3000
> > 
> >   Sigma0 configip:000e0100 sp:  
> > 
> >   Roottask config  ip:00140254 sp:  
> > 
> >   Starting kernel fiasco at 1200
> > 
> >   Non-HYP kernel detected but running in HYP mode, switching back
> 
> Sometimes (non-reproducible) additionally I get:
> > [...]
> > Hello from Startup::stage2
> 
> Which means stage2 comes up but hangs afterwards.
> And even sometimes I am able to completely boot the device:

Seems some initialization thing to me in your case.
"Unfortunately" works fine for me so far. Are you using u-boot or
are you booting differently?

Adam

> > [...]   
> > 
> > FPU: Initialize 
> > 
> > FPU0: Subarch: 2, Part: 30, Rev: 5, Var: 7, Impl: 41
> > 
> > ARM generic timer: freq=1920 interval=19200 cnt=36679846728534094   
> > 
> > SERIAL ESC: allocated IRQ 57 for serial uart
> > 
> > Not using serial hack in slow timer handler.
> > 
> > Welcome to L4/Fiasco.OC!
> > 
> > L4/Fiasco.OC microkernel on arm 
> > 
> > Rev: r75 compiled with gcc 5.4.0 for Broadcom 2836[]
> > 
> > Build: #2 Tue Nov 21 15:17:05 CET 2017  
> > 
> > 
> > 
> > Calibrating timer loop... done. 
> > 
> > MDB: use page size: 20  
> > 
> > MDB: use page size: 12  
> > 
> > SIGMA0: Hello!  
> >

Re: Booting L4Re with qemu-system-arm: Panic in sigma0

[Adam Lackorzynski]

On Wed Nov 01, 2017 at 11:17:12 +0800, Leslie Zhai wrote:
> still failed:
> 
> QEMU-cmd: qemu-system-arm -kernel
> /data/project/xiangzhai/l4re/l4/build-arm/images/bootstrap.elf -serial stdio
> -M integratorcp -cpu arm926 -m 256
> 
> I am trying to build Fiaso and L4Re with different GNU cross-compiler
> toolchain.

gcc 5 and later tool chains have ARMv6 instructions in their libgcc,
i.e. won't run on ARMv5 anymore. Taking the Codesourcery tool chain is
the right thing if ARMv5 code is required.


Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Patches (was Re: Problem with L4Linux accessing ethernet clocks)

[Adam Lackorzynski]

On Wed Nov 01, 2017 at 01:03:36 +0100, Paul Boddie wrote:
> On Wednesday 1. November 2017 00.38.23 Adam Lackorzynski wrote:
> > 
> 
> [Cache detail querying]
> 
> > I just modified the code to have a fixed value and that worked for me as
> > a quick hack. I don't think the value will ever change for a particular
> > CPU. But it's still a hack and there's a smarter way definitely.
> 
> In a lot of systems, I guess people would use a configuration setting for 
> this 
> kind of thing (U-Boot seems to have a lot of this going on). I'd have to look 
> at the code to see how this instruction got included, though.

It's the MIPS-related cache handling in l4sys.

> > Debian is building pie code per default nowadays, I think that's where
> > it's coming from, and we should handle this.
> > 
> > The MIPS vendor compiler is actually gcc but an older one:
> > https://www.mips.com/develop/tools/codescape-mips-sdk/download-codescape-mi
> > ps-sdk-essentials/
> 
> I'm guessing that there might have been different defaults and therefore 
> corresponding assumptions that don't hold true for vanilla gcc.

Yes, that might actually be, but Debian/Ubuntu is pretty widespread so
it should work too.
 
> [Accessing 1GB]
> 
> > There's a hole, and it also looks like the first 256MB is mirrored at
> > 512MB. However, using all the memory is just a matter actually making it
> > known, I've just tried it and it seems to work. All Ci20's have 1GB,
> > right?
> 
> Yes. My interpretation was also that the first 256MB resides at zero for 
> compatibility with earlier SoCs in the family, and that they "started again" 
> at a higher location (at 512MB, I guess, if you've looked it up!) when their 
> products needed more address space.
> 
> Thanks for taking a look at this! I doubt that the CI20 is so high priority 
> now, but who knows what its corporate parents will do after their separation?

The Ci20 has a somewhat special CPU which needs some special treatment.
For that reason I was mentioning the Ci40 which is better in this
regard.



Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Patches (was Re: Problem with L4Linux accessing ethernet clocks)

[Adam Lackorzynski]

Hi,

On Mon Oct 30, 2017 at 18:38:40 +0100, Paul Boddie wrote:
> > > to do some assembly language programming here just to recover from the
> > > exception. In this case, however, the emulated instruction is very
> > > simple, although I did take the liberty of rearranging the emulation
> > > mechanism slightly.
> > 
> > Yes, it is probably simple but that does not necessarily mean it would
> > need to be done in asm. Exceptions are caught and handled of course, the
> > actual processing can be done in C.
> 
> The instruction being emulated is rdhwr with argument $1 (SYNCI_Step). Other 
> arguments of this instruction were already implemented in 
> src/kernel/fiasco/src/kern/mips/exception.S, and so it was natural to add 
> support for this argument there as well. For example, the existing support 
> covered argument $29 (ULR) which seems to be concerned with accessing 
> task/thread-local storage, if I interpret "TLS" correctly.

Yes, that's about TLS.

> Meanwhile, argument $1 (SYNCI_Step) is concerned with accessing data from a 
> configuration register that would normally only be accessible in kernel mode, 
> with the purpose of this instruction variant being to expose the cache 
> details 
> to user mode. So the only way to actually implement the instruction as 
> intended would be in kernel mode by doing the necessary read from the CONFIG1 
> register.
> 
> A hack that I did consider was to just replace the instruction with code that 
> just loads a constant that is set up according to the SoC parameters. A user 
> space handler could certainly do such work and be invoked by the exception 
> handler, but the resulting functionality would not exactly be equivalent to 
> that provided by the patch because it would not dynamically ask the hardware 
> about itself.

I just modified the code to have a fixed value and that worked for me as
a quick hack. I don't think the value will ever change for a particular
CPU. But it's still a hack and there's a smarter way definitely.

> > > Yes. Various L4Re components do not work when compiled with gcc unless I
> > > introduce these changes. It was suggested that I do not compile such
> > > things as position-independent code, but I don't remember any further
> > > explanation.
> > 
> > Hmm, does that mean that with Debian's gcc (6? 7?) there might be issues?
> 
> Here's my version information:
> 
> mipsel-linux-gnu-gcc (Debian 6.3.0-18) 6.3.0 20170516
> 
> However, I was told that gcc typically compiles position-independent code as 
> the default for mipsel. My guess is that any version would be a problem, and 
> I 
> think it was already noted that development was done with the MIPS vendor 
> compilers, not gcc, so this is why this issue wasn't noticed before.

Debian is building pie code per default nowadays, I think that's where
it's coming from, and we should handle this.

The MIPS vendor compiler is actually gcc but an older one:
https://www.mips.com/develop/tools/codescape-mips-sdk/download-codescape-mips-sdk-essentials/

> [Accessing 1GB]
> 
> > Ok, I see, there's a background. And obviously the available memory can
> > make a big difference.
> 
> If the entire 1GB appears at a different physical address than zero, which is 
> my understanding of the situation, is it possible to set some kind of 
> configuration variable to let Fiasco know about this, while still preserving 
> the addresses used for things like peripherals in the usual zero-based region?

There's a hole, and it also looks like the first 256MB is mirrored at
512MB. However, using all the memory is just a matter actually making it
known, I've just tried it and it seems to work. All Ci20's have 1GB,
right?



Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Patches (was Re: Problem with L4Linux accessing ethernet clocks)

[Adam Lackorzynski]

Hi,

On Mon Oct 23, 2017 at 01:50:47 +0200, Paul Boddie wrote:
> A quick reply as it is rather late...

So often :)

> On Monday 23. October 2017 00.55.53 Adam Lackorzynski wrote:
> > On Mon Oct 16, 2017 at 15:35:22 +0200, Paul Boddie wrote:
> > > On Monday 16. October 2017 00.48.38 Adam Lackorzynski wrote:
> > > > 
> > > > You're talking about the cache instruction issue?
> > > 
> > > Yes (ci20-rdhwr.diff). I was also potentially interested in supporting
> > > other instructions that related SoCs do not support, at least where
> > > those do not
> > 
> > What I don't understand is why this needs to be done in asm. I'd favor
> > something in C.
> 
> I haven't looked at how the floating point emulation is done in the Linux 
> kernel, as another example of this kind of thing, but I imagine that you have 

Linux has FP emulators to support applications with FPU code on
processors that don't have an FPU. It does the obvious, catching the
traps and handling them. Whether it's a good idea to do that in a
microkernel is another thing. Technically it could be done of course but
building the code with softfloat has always been a good alternative.

> to do some assembly language programming here just to recover from the 
> exception. In this case, however, the emulated instruction is very simple, 
> although I did take the liberty of rearranging the emulation mechanism 
> slightly.

Yes, it is probably simple but that does not necessarily mean it would
need to be done in asm. Exceptions are caught and handled of course, the
actual processing can be done in C.

> In fact, someone with more familiarity than me with low-level MIPS 
> programming 
> could probably reproduce my patch with little effort, but I imagine that it 
> isn't of significant interest any more.
> 
> [MIPS systems without floating point support]
> 
> > Fiasco is typically built not using floating point, as most kernels.
> > Which problem are you hinting at?
> 
> I was just wondering about use of floating point. If I can build user space 
> programs that also don't need floating point then I save myself some work, 
> potentially.

Exactly, and it will be faster too.

> [...]
> 
> > > Thinking back, there was some uncertainty about whether it was
> > > appropriate to generate position-independent code when building
> > > Fiasco.OC, where I had introduced initialisation of t9 so that global
> > > offset table lookups functioned correctly (ci20-gcc-cpload.diff).
> > 
> > This diff addresses user-level programs, and are meant to have them
> > being able to be compiled as PIC?
> 
> Yes. Various L4Re components do not work when compiled with gcc unless I 
> introduce these changes. It was suggested that I do not compile such things 
> as 
> position-independent code, but I don't remember any further explanation.

Hmm, does that mean that with Debian's gcc (6? 7?) there might be issues?

> > > I was rebasing my own large patch against an updated upstream repository,
> > > but other matters took priority and I haven't looked at it again. I had
> > > been trying to write a few device drivers for the CI20, specifically for
> > > GPIO, CPM and I2C, with the latter being unreliable and rather annoying.
> > 
> > I don't know but maybe the Ci40 is a better board, having interAptiv
> > cores.
> 
> The CI40 is aimed at a different sector, being IoT-related rather than a 
> desktop-style single-board computer. Indeed, the CI20 has 1GB RAM - far more 
> than the CI40 - but some trickery appears necessary to make more than 256MB 
> visible to Fiasco due to the physical memory map layout, but I haven't looked 
> into this yet. Obviously, Linux can make use of all of the RAM.
> 
> For me, my interest in the CI20 is driven by its choice of SoC which is in 
> the 
> same family as various other products I have access to. I don't think I'll be 
> buying another board for the time being: the CI20 is tangential enough to my 
> core interests as it is.

Ok, I see, there's a background. And obviously the available memory can
make a big difference.



Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Patches (was Re: Problem with L4Linux accessing ethernet clocks)

[Adam Lackorzynski]

On Sat Oct 14, 2017 at 17:09:46 +0200, Paul Boddie wrote:
> On Wednesday 11. October 2017 15.33.58 Manolis Ragkousis wrote:
> > 
> > Finally I have a question, Are you accepting patches for L4 and L4Linux?
> > I could make my git patches more presentable and send them here if you
> > want, to be added to your upstream repo.
> 
> I would be interested to know about this as well. I sent some patches to the 
> list a while back, but nothing was really said about whether there was any 
> interest in incorporating them upstream.

Principally yes but this also depends on time etc., see other mail.
 
> One of the patches made the stated CI20 support actually work, thanks to 
> Sarah's guidance, so it must surely be of interest to more than just me. The 

You're talking about the cache instruction issue?

> other patches attempted to support gcc instead of the vendor compiler, which 
> I 
> would also think would be desirable (especially given the corporate "pass the 
> parcel" game going on with the vendor in question at the moment).

Well, then lets discuss those changes.



Adam

___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers