Re: L4Linux stop at "Calibrating delay loop ..."
At 2016-10-04 05:48:21, "Adam Lackorzynski" wrote:
>
>On Fri Sep 30, 2016 at 22:06:47 +0800, li94575 wrote:
>> At 2016-09-23 05:31:52, "Adam Lackorzynski"
>> wrote:
>> >
>> >On Thu Sep 22, 2016 at 22:32:28 +0800, li94575 wrote:
>> >> Hi, adam
>> >> >On Mon Sep 19, 2016 at 22:55:52 +0800, li94575 wrote:
>> >> >> I compiled the l4re-snapshot-2014092821 with the default
>> >> >> modules.list, and everything seems goes
>> >> >> well. However, L4Linux would stop at "Calibrating delay loop ...",
>> >> >> because the value of jiffies did not change.
>> >> >> Timer thread has not generate soft interrupt? If I entered jdb via ESC
>> >> >> at this time, and quit via "g", then
>> >> >> l4linux can run again. It makes me confused so much.
>> >> >> Any help or suggestion will be very welcome.
>> >> >
>> >> >This behavior typically indicates that there's an issue with Fiasco's
>> >> >timer interrupt or with the user-level one in L4Linux.
>> >> >For a start you could add e.g. a printk(".\n") in timer_thread in
>> >> >arch/l4/kernel/timer.c to see if it really does something.
>> >> >Does 'hello' work?
>> >> >Although it's a bit of work you could also compare the code of your
>> >> >snapshot and a recent one if there's any significant change (i.e. fix)
>> >> >that might be relevant. Check arch/l4/kernel/timer.c
>> >> >and src/kern/arm/timer-arm-generic.cpp and
>> >> >src/kern/arm/generic_timer.cpp in the Fiasco kernel.
>> >>
>> >> 'Hello' can work well, which prints "Hello World!" circularly. I add
>> >> printk(".\n") in timer_thread in arch/l4/kernel/timer.c, and found
>> >> timer_thread stop at l4_ipc_reply_and_wait(u, t, &l, to)
>> >> afterinitializing the variable ¡®increment¡¯.
>> >
>> >printk and any other Linux functionaliy cannot be used in this function
>> >because the timer_thread isn't run in a Linux context. It's run in an L4
>> >thread next to Linux. (Sorry for my mistake of writing printk above, I
>> >actually really meant to write LOG_printf.)
>> >
>> >> However, if I use
>> >> LOG_printf() for printing, the phenomenon is different, that
>> >> timer_thread trigers a soft interrupt once. I have checked
>> >> src/kern/arm/timer-arm-generic.cpp and src/kern/arm/generic_timer.cpp
>> >> in the Fiasco kernel, there is less likely to be a problem with them.
>> >
>> >So there's still a problem somewhere. Do you think you could try with a
>> >more recent L4Re version? I remember vaguely that I might have already
>> >seen this behavior but this would be long ago.
>> >
>> I have to admit that there may be a problem with the configuration of
>> the generic timer, but I donot know where the problem. Before this,
>> the generic timer can run well with fiasco.oc-r56+genode+l4linux3.9, I
>> do not make any changes and move the bsp codefor this newer fiasco
>> version.I replace generic timer with Aptimer, then l4linux can run
>> well. So, If I want to assign anAptimer for each CPU, is there any
>> ready-made case for reference?
>
>Do you have others timers for each CPU? Maybe better (as easier), use
>one timer and distribute the timer tick to other CPUs: There's a
>timer_tick-broadcast and it is used in 3 BSPs. Does this help?
>
Yes , that solved my problem. Thank you so much!___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: L4Linux stop at "Calibrating delay loop ..."
On Fri Sep 30, 2016 at 22:06:47 +0800, li94575 wrote:
> At 2016-09-23 05:31:52, "Adam Lackorzynski" wrote:
> >
> >On Thu Sep 22, 2016 at 22:32:28 +0800, li94575 wrote:
> >> Hi, adam
> >> >On Mon Sep 19, 2016 at 22:55:52 +0800, li94575 wrote:
> >> >> I compiled the l4re-snapshot-2014092821 with the default
> >> >> modules.list, and everything seems goes
> >> >> well. However, L4Linux would stop at "Calibrating delay loop ...",
> >> >> because the value of jiffies did not change.
> >> >> Timer thread has not generate soft interrupt? If I entered jdb via ESC
> >> >> at this time, and quit via "g", then
> >> >> l4linux can run again. It makes me confused so much.
> >> >> Any help or suggestion will be very welcome.
> >> >
> >> >This behavior typically indicates that there's an issue with Fiasco's
> >> >timer interrupt or with the user-level one in L4Linux.
> >> >For a start you could add e.g. a printk(".\n") in timer_thread in
> >> >arch/l4/kernel/timer.c to see if it really does something.
> >> >Does 'hello' work?
> >> >Although it's a bit of work you could also compare the code of your
> >> >snapshot and a recent one if there's any significant change (i.e. fix)
> >> >that might be relevant. Check arch/l4/kernel/timer.c
> >> >and src/kern/arm/timer-arm-generic.cpp and
> >> >src/kern/arm/generic_timer.cpp in the Fiasco kernel.
> >>
> >> 'Hello' can work well, which prints "Hello World!" circularly. I add
> >> printk(".\n") in timer_thread in arch/l4/kernel/timer.c, and found
> >> timer_thread stop at l4_ipc_reply_and_wait(u, t, &l, to)
> >> afterinitializing the variable ¡®increment¡¯.
> >
> >printk and any other Linux functionaliy cannot be used in this function
> >because the timer_thread isn't run in a Linux context. It's run in an L4
> >thread next to Linux. (Sorry for my mistake of writing printk above, I
> >actually really meant to write LOG_printf.)
> >
> >> However, if I use
> >> LOG_printf() for printing, the phenomenon is different, that
> >> timer_thread trigers a soft interrupt once. I have checked
> >> src/kern/arm/timer-arm-generic.cpp and src/kern/arm/generic_timer.cpp
> >> in the Fiasco kernel, there is less likely to be a problem with them.
> >
> >So there's still a problem somewhere. Do you think you could try with a
> >more recent L4Re version? I remember vaguely that I might have already
> >seen this behavior but this would be long ago.
> >
> I have to admit that there may be a problem with the configuration of
> the generic timer, but I donot know where the problem. Before this,
> the generic timer can run well with fiasco.oc-r56+genode+l4linux3.9, I
> do not make any changes and move the bsp codefor this newer fiasco
> version.I replace generic timer with Aptimer, then l4linux can run
> well. So, If I want to assign anAptimer for each CPU, is there any
> ready-made case for reference?
Do you have others timers for each CPU? Maybe better (as easier), use
one timer and distribute the timer tick to other CPUs: There's a
timer_tick-broadcast and it is used in 3 BSPs. Does this help?
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
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: L4Linux stop at "Calibrating delay loop ..."
At 2016-09-23 05:31:52, "Adam Lackorzynski" wrote:
>
>On Thu Sep 22, 2016 at 22:32:28 +0800, li94575 wrote:
>> Hi, adam
>> >On Mon Sep 19, 2016 at 22:55:52 +0800, li94575 wrote:
>> >> I compiled the l4re-snapshot-2014092821 with the default
>> >> modules.list, and everything seems goes
>> >> well. However, L4Linux would stop at "Calibrating delay loop ...",
>> >> because the value of jiffies did not change.
>> >> Timer thread has not generate soft interrupt? If I entered jdb via ESC at
>> >> this time, and quit via "g", then
>> >> l4linux can run again. It makes me confused so much.
>> >> Any help or suggestion will be very welcome.
>> >
>> >This behavior typically indicates that there's an issue with Fiasco's
>> >timer interrupt or with the user-level one in L4Linux.
>> >For a start you could add e.g. a printk(".\n") in timer_thread in
>> >arch/l4/kernel/timer.c to see if it really does something.
>> >Does 'hello' work?
>> >Although it's a bit of work you could also compare the code of your
>> >snapshot and a recent one if there's any significant change (i.e. fix)
>> >that might be relevant. Check arch/l4/kernel/timer.c
>> >and src/kern/arm/timer-arm-generic.cpp and
>> >src/kern/arm/generic_timer.cpp in the Fiasco kernel.
>>
>> 'Hello' can work well, which prints "Hello World!" circularly. I add
>> printk(".\n") in timer_thread in arch/l4/kernel/timer.c, and found
>> timer_thread stop at l4_ipc_reply_and_wait(u, t, &l, to)
>> afterinitializing the variable ¡®increment¡¯.
>
>printk and any other Linux functionaliy cannot be used in this function
>because the timer_thread isn't run in a Linux context. It's run in an L4
>thread next to Linux. (Sorry for my mistake of writing printk above, I
>actually really meant to write LOG_printf.)
>
>> However, if I use
>> LOG_printf() for printing, the phenomenon is different, that
>> timer_thread trigers a soft interrupt once. I have checked
>> src/kern/arm/timer-arm-generic.cpp and src/kern/arm/generic_timer.cpp
>> in the Fiasco kernel, there is less likely to be a problem with them.
>
>So there's still a problem somewhere. Do you think you could try with a
>more recent L4Re version? I remember vaguely that I might have already
>seen this behavior but this would be long ago.
>
I have to admit that there may be a problem with the configuration of the
generic timer, but I donot know where the problem. Before this, the generic
timer can run well with fiasco.oc-r56+genode+l4linux3.9, I do not make any
changes and move the bsp codefor this newer fiasco version.I replace generic
timer with Aptimer, then l4linux can run well. So, If I want to assign
anAptimer for each CPU, is there any ready-made case for reference?___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: L4Linux stop at "Calibrating delay loop ..."
On Thu Sep 22, 2016 at 22:32:28 +0800, li94575 wrote:
> Hi, adam
> >On Mon Sep 19, 2016 at 22:55:52 +0800, li94575 wrote:
> >> I compiled the l4re-snapshot-2014092821 with the default modules.list,
> >> and everything seems goes
> >> well. However, L4Linux would stop at "Calibrating delay loop ...", because
> >> the value of jiffies did not change.
> >> Timer thread has not generate soft interrupt? If I entered jdb via ESC at
> >> this time, and quit via "g", then
> >> l4linux can run again. It makes me confused so much.
> >> Any help or suggestion will be very welcome.
> >
> >This behavior typically indicates that there's an issue with Fiasco's
> >timer interrupt or with the user-level one in L4Linux.
> >For a start you could add e.g. a printk(".\n") in timer_thread in
> >arch/l4/kernel/timer.c to see if it really does something.
> >Does 'hello' work?
> >Although it's a bit of work you could also compare the code of your
> >snapshot and a recent one if there's any significant change (i.e. fix)
> >that might be relevant. Check arch/l4/kernel/timer.c
> >and src/kern/arm/timer-arm-generic.cpp and
> >src/kern/arm/generic_timer.cpp in the Fiasco kernel.
>
> 'Hello' can work well, which prints "Hello World!" circularly. I add
> printk(".\n") in timer_thread in arch/l4/kernel/timer.c, and found
> timer_thread stop at l4_ipc_reply_and_wait(u, t, &l, to)
> afterinitializing the variable ¡®increment¡¯.
printk and any other Linux functionaliy cannot be used in this function
because the timer_thread isn't run in a Linux context. It's run in an L4
thread next to Linux. (Sorry for my mistake of writing printk above, I
actually really meant to write LOG_printf.)
> However, if I use
> LOG_printf() for printing, the phenomenon is different, that
> timer_thread trigers a soft interrupt once. I have checked
> src/kern/arm/timer-arm-generic.cpp and src/kern/arm/generic_timer.cpp
> in the Fiasco kernel, there is less likely to be a problem with them.
So there's still a problem somewhere. Do you think you could try with a
more recent L4Re version? I remember vaguely that I might have already
seen this behavior but this would be long ago.
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
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: L4Linux stop at "Calibrating delay loop ..."
Hi
We had a similar problem working with Fiasco.OC and GendodeOS on
ODROID-X2 (Exynos4412) platform. In this case after the review of
GenodeOS and Fiasco.OC, we identified a small problem in the TrustZone
implementation, where interrupts remain disabled.
Perhaps this is not the same problem but it can help.
https://github.com/ssumpf/foc/issues/13
Best regards
On 09/22/2016 10:32 AM, li94575 wrote:
Hi, adam
>On Mon Sep 19, 2016 at 22:55:52 +0800, li94575 wrote:
>> I compiled the l4re-snapshot-2014092821 with the default modules.list,
and everything seems goes
>> well. However, L4Linux would stop at "Calibrating delay loop ...", because
the value of jiffies did not change.
>> Timer thread has not generate soft interrupt? If I entered jdb via ESC at this time,
and quit via "g", then
>> l4linux can run again. It makes me confused so much.
>> Any help or suggestion will be very welcome.
>
>This behavior typically indicates that there's an issue with Fiasco's
>timer interrupt or with the user-level one in L4Linux.
>For a start you could add e.g. a printk(".\n") in timer_thread in
>arch/l4/kernel/timer.c to see if it really does something.
>Does 'hello' work?
>Although it's a bit of work you could also compare the code of your
>snapshot and a recent one if there's any significant change (i.e. fix)
>that might be relevant. Check arch/l4/kernel/timer.c
>and src/kern/arm/timer-arm-generic.cpp and
>src/kern/arm/generic_timer.cpp in the Fiasco kernel.
'Hello' can work well, which prints "Hello World!" circularly. I add
printk(".\n") in timer_thread in
arch/l4/kernel/timer.c, and found timer_thread stop at
l4_ipc_reply_and_wait(u, t, &l, to) after
initializing the variable ‘increment’. However, if I use LOG_printf()
for printing, the phenomenon
is different, that timer_thread trigers a soft interrupt once. I have
checked src/kern/arm/timer-arm-generic.cpp
and src/kern/arm/generic_timer.cpp in the Fiasco kernel, there is less
likely to be a problem with them.
___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
--
MsC. Reinier Millo Sánchez
Centro de Estudios de Informática
Universidad Central "Marta Abreu" de Las Villas
Carretera a Camajuaní Km 5 1/2
Santa Clara, Villa Clara, Cuba
CP 54830
"antes de discutir ... respira;
antes de hablar ... escucha;
antes de escribir ... piensa;
antes de herir ... siente;
antes de rendirte ... intenta;
antes de morir ... vive"
<>___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: L4Linux stop at "Calibrating delay loop ..."
Hi, adam
>On Mon Sep 19, 2016 at 22:55:52 +0800, li94575 wrote:
>> I compiled the l4re-snapshot-2014092821 with the default modules.list,
>> and everything seems goes
>> well. However, L4Linux would stop at "Calibrating delay loop ...", because
>> the value of jiffies did not change.
>> Timer thread has not generate soft interrupt? If I entered jdb via ESC at
>> this time, and quit via "g", then
>> l4linux can run again. It makes me confused so much.
>> Any help or suggestion will be very welcome.
>
>This behavior typically indicates that there's an issue with Fiasco's
>timer interrupt or with the user-level one in L4Linux.
>For a start you could add e.g. a printk(".\n") in timer_thread in
>arch/l4/kernel/timer.c to see if it really does something.
>Does 'hello' work?
>Although it's a bit of work you could also compare the code of your
>snapshot and a recent one if there's any significant change (i.e. fix)
>that might be relevant. Check arch/l4/kernel/timer.c
>and src/kern/arm/timer-arm-generic.cpp and
>src/kern/arm/generic_timer.cpp in the Fiasco kernel.'Hello' can work well,
>which prints "Hello World!" circularly. I add printk(".\n") in timer_thread
>inarch/l4/kernel/timer.c, and found timer_thread stop at
>l4_ipc_reply_and_wait(u, t, &l, to) afterinitializing the variable
>‘increment’. However, if I use LOG_printf() for printing, the phenomenon is
>different, that timer_thread trigers a soft interrupt once. I have checked
>src/kern/arm/timer-arm-generic.cpp and src/kern/arm/generic_timer.cpp in the
>Fiasco kernel, there is less likely to be a problem with them.___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: L4Linux stop at "Calibrating delay loop ..."
Hi,
On Mon Sep 19, 2016 at 22:55:52 +0800, li94575 wrote:
> I compiled the l4re-snapshot-2014092821 with the default modules.list,
> and everything seems goes
> well. However, L4Linux would stop at "Calibrating delay loop ...", because
> the value of jiffies did not change.
> Timer thread has not generate soft interrupt? If I entered jdb via ESC at
> this time, and quit via "g", then
> l4linux can run again. It makes me confused so much.
> Any help or suggestion will be very welcome.
This behavior typically indicates that there's an issue with Fiasco's
timer interrupt or with the user-level one in L4Linux.
For a start you could add e.g. a printk(".\n") in timer_thread in
arch/l4/kernel/timer.c to see if it really does something.
Does 'hello' work?
Although it's a bit of work you could also compare the code of your
snapshot and a recent one if there's any significant change (i.e. fix)
that might be relevant. Check arch/l4/kernel/timer.c
and src/kern/arm/timer-arm-generic.cpp and
src/kern/arm/generic_timer.cpp in the Fiasco kernel.
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
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
L4Linux stop at "Calibrating delay loop ..."
Hi，l4hackers
I compiled the l4re-snapshot-2014092821 with the default modules.list, and
everything seems goes
well. However, L4Linux would stop at "Calibrating delay loop ...", because the
value of jiffies did not change.
Timer thread has not generate soft interrupt? If I entered jdb via ESC at this
time, and quit via "g", then
l4linux can run again. It makes me confused so much.
Any help or suggestion will be very welcome.
The log is showing below:
L4 Bootstrapper
Build: #12 2016年 09月 19日 星期一 18:58:15 CST, 4.8.3 20140320 (prerelease)
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 10 modules behind 110
moving module 02 { 1968000-19a163f } -> { 1a58000-1a9163f } [235072]
moving module 01 { 195e000-196738b } -> { 1a4e000-1a5738b } [37772]
moving module 00 { 18f8000-195d9db } -> { 19e8000-1a4d9db } [416220]
moving module 09 { 15f8000-18f7fff } -> { 16e8000-19e7fff } [3145728]
moving module 08 { 11d6000-15f7497 } -> { 12c6000-16e7497 } [4330648]
moving module 07 { 11d5000-11d50bc } -> { 12c5000-12c50bc } [189]
moving module 06 { 107e000-11d446f } -> { 116e000-12c446f } [1401968]
moving module 05 { 107d000-107d19b } -> { 116d000-116d19b } [412]
moving module 04 { 102a000-107cc1f } -> { 111a000-116cc1f } [338976]
moving module 03 { 101-1029473 } -> { 110-1119473 } [103540]
Loading fiasco
Loading sigma0
Loading moe
find kernel info page...
found kernel info page at 0x2000
Regions of list 'regions'
[ 1000, 1aff] { b00} Kern fiasco
[ 2000, 72fff] {71000} Kern fiasco
[73000, 7315f] { 160} Root mbi_rt
[9, 96edf] { 6ee0} Sigma0 sigma0
[98000, 9e177] { 6178} Sigma0 sigma0
[ 14,171d8f] {31d90} Root moe
[ 178000,1934ab] {1b4ac} Root moe
[ 100, 100f58b] { f58c} Boot bootstrap
[ 110, 19e7fff] { 8e8000} Root Module
API Version: (87) experimental
Sigma0 configip:00090100 sp:
Roottask config ip:00140260 sp:
Starting kernel fiasco at 12e0
Hello from Startup::stage2
Per_cpu_data_alloc: (orig: 0xf0061720-0xf00620e8)
Number of IRQs available at this GIC: 128
FPU0: Arch: Unkn(2), Part: VFPv3(30), r: 5, v: 7, i: 41, t: hard, p: dbl/sngl
ARM generic timer: freq=100 interval=1000 cnt=-262144
SERIAL ESC: allocated IRQ 89 for serial uart
Not using serial hack in slow timer handler.
Welcome to Fiasco.OC (arm)!
L4/Fiasco.OC arm microkernel (C) 1998-2013 TU Dresden
Rev: 8fd26ca-dirty compiled with gcc 4.8.3 for []
Build: #3 Mon Sep 19 18:55:38 CST 2016
Per_cpu_data_alloc: (orig: 0xf0061720-0xf00620e8)
Allocate 2504 bytes (2KB) for CPU[4] local storage (offset=118a8e0,
0xf11ec000-0xf11ec9c8)
cpu1: powered-up
Per_cpu_data_alloc: (orig: 0xf0061720-0xf00620e8)
cpu2: powered-up
Allocate 2504 bytes (2KB) for CPU[1] local storage (offset=118c8e0,
0xf11ee000-0xf11ee9c8)
cpu3: powered-up
FPU1: Arch: Unkn(2), Part: VFPv3(30), r: 5, v: 7, i: 41, t: hard, p: dbl/sngl
Calibrating timer loop... Per_cpu_data_alloc: (orig: 0xf0061720-0xf00620e8)
done.
Allocate 2504 bytes (2KB) for CPU[2] local storage (offset=118f8e0,
0xf11f1000-0xf11f19c8)
Cache config: ON
MDB: use page size: 30
FPU2: Arch: Unkn(2), Part: VFPv3(30), r: 5, v: 7, i: 41, t: hard, p: dbl/sngl
ID_PFR[01]: 1131 00011011Per_cpu_data_alloc: (orig: 0xf0061720-0xf00620e8)
MDB: use page size: 21
Allocate 2504 bytes (2KB) for CPU[3] local storage (offset=11968e0,
0xf11f8000-0xf11f89c8)
ID_[DA]FR0: 02010555
Cache config: ON
MDB: use page size: 12
FPU3: Arch: Unkn(2), Part: VFPv3(30), r: 5, v: 7, i: 41, t: hard, p: dbl/sngl
ID_PFR[01]: 1131 00011011SID_MMFR[04]: 10101105 4000 0124 02102211
Cache config: ON
ID_[DA]FR0: 02010555
ID_PFR[01]: 1131 00011011ID_MMFR[04]: 10101105 4000 0124 02102211
ICPU[2]: goes to idle loop
ID_[DA]FR0: 02010555
GID_MMFR[04]: 10101105 4000 0124 02102211
CPU[1]: goes to idle loop
CPU[3]: goes to idle loop
MA0: Hello!
KIP @ 2000
allocated 4KB for maintenance structures
SIGMA0: Dump of all resource maps
RAM:
[0:0;fff]
[4:73000;73fff]
[0:74000;8]
[0:97000;97fff]
[0:9f000;13]
[4:14;171fff]
[0:172000;177fff]
[4:178000;193fff]
[0:194000;10f]
[4:110;19e7fff]
[0:19e8000;3eff]
[0:4000;7fff]
IOMEM:--
[0:8000;]
MOE: Hello world
MOE: found 2070816 KByte free memory
MOE: found RAM from 73000 to 8000
MOE: allocated 2047 KByte for the page array @0x194000
MOE: virtual user address space [0-bfff]
MOE: rom name space cap -> [C:501000]
BOOTFS: [110-1119474] [C:503000] l4re
BOOTFS: [111a000-116cc20] [C:504000] ned
BOOTFS: [116d000-116d19c] [C:505000] l4lx.cfg
BOOTFS:
