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 0x40000000 to 0xc0000000) 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 0xffff000040000000 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)?
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 0x40000000 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.
Bytes transferred = 1223880 (12acc8 hex) ## Booting kernel from Legacy Image at 40080000 ... Image Name: L4 Image #428 Image Type: AArch64 Linux Kernel Image (uncompressed) Data Size: 1223816 Bytes = 1.2 MiB Load Address: 41000000 Entry Point: 41000000 Verifying Checksum ... OK Loading Kernel Image ... OK
Starting kernel ...
L4 Bootstrapper Build: #428 Thu Jan 14 22:44:58 CET 2021, 7.5.0 RAM: 0000000040000000 - 00000000ffff0000: 3145664kB Total RAM: 3071MB Scanning fiasco Scanning sigma0 Scanning moe Moving up to 5 modules behind 41100000 moving module 02 { 410dd000-4112ac87 } -> { 411cb000-41218c87 } [318600] moving module 01 { 410c4000-410dcea7 } -> { 411b2000-411caea7 } [102056] moving module 00 { 41077000-410c34cf } -> { 41165000-411b14cf } [312528] moving module 04 { 4103f000-41076bbf } -> { 4112d000-41164bbf } [228288] moving module 03 { 41012000-4103ee4f } -> { 41100000-4112ce4f } [183888] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 40003000 Regions of list 'regions' [ 40000000, 400000ef] { f0} Root mbi_rt [ 40001000, 40058fff] { 58000} Kern fiasco [ 400f0000, 40108a5b] { 18a5c} Sigma0 sigma0 [ 40118a60, 4011c2ef] { 3890} Sigma0 sigma0 [ 40130000, 4017d4cf] { 4d4d0} Root moe [ 4018d4d0, 40198d67] { b898} Root moe [ 41000000, 41011193] { 11194} Boot bootstrap [ 41100000, 41164fff] { 65000} Root Module found kernel options (via ELF) at 40004000 Sigma0 config ip:401002bc sp:00000000 Roottask config ip:401413ec sp:00000000 Starting kernel fiasco at 40001818 Hello from Startup::stage2 Number of IRQs available at this GIC: 160 Detecting PSCI ... Detected PSCI v1.1 PSCI: CPU_SUSPEND format extended, supports OS-initiated mode PSCI: TOS: Not present or not required. SERIAL ESC: allocated IRQ 7 for serial uart Not using serial hack in slow timer handler. Welcome to L4/Fiasco.OC! L4/Fiasco.OC microkernel on arm Rev: cffbd484-dirty compiled with gcc 7.5.0 for Samsung S5P6818 [] Build: #212 Thu Jan 14 22:44:36 CET 2021
Calibrating timer loop…
If anyone could maybe guide me into the right direction I’d be more than happy! Thank you very much!
Best regards Andreas
Hi Andreas,
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.
- 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 0x40000000 to 0xc0000000) 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 0xffff000040000000 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)?
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.
- The Timer - or the lack thereof
When we were experimenting with the RAM size we found that when setting to to 3GB starting from 0x40000000 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.
Thanks and regards, Matthias.
PS: If you like you can head over to our github at github.com/kernkonzept and we can continue discussing this in its own issue.
Bytes transferred = 1223880 (12acc8 hex) ## Booting kernel from Legacy Image at 40080000 ... Image Name: L4 Image #428 Image Type: AArch64 Linux Kernel Image (uncompressed) Data Size: 1223816 Bytes = 1.2 MiB Load Address: 41000000 Entry Point: 41000000 Verifying Checksum ... OK Loading Kernel Image ... OK
Starting kernel ...
L4 Bootstrapper Build: #428 Thu Jan 14 22:44:58 CET 2021, 7.5.0 RAM: 0000000040000000 - 00000000ffff0000: 3145664kB Total RAM: 3071MB Scanning fiasco Scanning sigma0 Scanning moe Moving up to 5 modules behind 41100000 moving module 02 { 410dd000-4112ac87 } -> { 411cb000-41218c87 } [318600] moving module 01 { 410c4000-410dcea7 } -> { 411b2000-411caea7 } [102056] moving module 00 { 41077000-410c34cf } -> { 41165000-411b14cf } [312528] moving module 04 { 4103f000-41076bbf } -> { 4112d000-41164bbf } [228288] moving module 03 { 41012000-4103ee4f } -> { 41100000-4112ce4f } [183888] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 40003000 Regions of list 'regions' [ 40000000, 400000ef] { f0} Root mbi_rt [ 40001000, 40058fff] { 58000} Kern fiasco [ 400f0000, 40108a5b] { 18a5c} Sigma0 sigma0 [ 40118a60, 4011c2ef] { 3890} Sigma0 sigma0 [ 40130000, 4017d4cf] { 4d4d0} Root moe [ 4018d4d0, 40198d67] { b898} Root moe [ 41000000, 41011193] { 11194} Boot bootstrap [ 41100000, 41164fff] { 65000} Root Module found kernel options (via ELF) at 40004000 Sigma0 config ip:401002bc sp:00000000 Roottask config ip:401413ec sp:00000000 Starting kernel fiasco at 40001818 Hello from Startup::stage2 Number of IRQs available at this GIC: 160 Detecting PSCI ... Detected PSCI v1.1 PSCI: CPU_SUSPEND format extended, supports OS-initiated mode PSCI: TOS: Not present or not required. SERIAL ESC: allocated IRQ 7 for serial uart Not using serial hack in slow timer handler. Welcome to L4/Fiasco.OC! L4/Fiasco.OC microkernel on arm Rev: cffbd484-dirty compiled with gcc 7.5.0 for Samsung S5P6818 [] Build: #212 Thu Jan 14 22:44:36 CET 2021
Calibrating timer loop…
If anyone could maybe guide me into the right direction I’d be more than happy! Thank you very much!
Best regards Andreas _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
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.
- 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 0x40000000 to 0xc0000000) 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 0xffff000040000000 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)?
0xffff000040000000 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.
- The Timer - or the lack thereof
When we were experimenting with the RAM size we found that when setting to to 3GB starting from 0x40000000 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
Hi Matthias, hi Adam,
I can't find anything in the TRM regarding such hardware features in the region where the code exits. It exits right when scanning for the ram size in scan_ram_size at *(unsigned long *)(base_addr + offset) == 0x12345678) with the address as 0x80000000, which is exactly in the middle of the RAM, very strange. Setting the PLATFORM_RAM_SIZE_MB to 1024 and removing the method setup_memory_map from our Platform_arm_s5p6818 class boots as well. I'm starting to think that the culprit is inside the bootloader that is just a 'hacked' version of a 'hacked' version of u-boot 2016.01 I forked at https://github.com/reschandreas/NanoPC-T3Plus/tree/master/U-Boot , could that assumption be correct?
Regarding the timer, my teammate implemented a new driver and it looks like the timer is counting. However, we're now suspecting that our interrupt controller is not correctly initialized although we're doing it exactly like other Platforms with the GIC-400 and we have checked the base addresses several times.
Sadly the only running Linux version we could find is one really old one from friendlyarm where we couldn't extract meaningful information.
Andreas
On 15.01.21 01:27, Adam Lackorzynski wrote:
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.
- 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 0x40000000 to 0xc0000000) 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 0xffff000040000000 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)?
0xffff000040000000 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.
- The Timer - or the lack thereof
When we were experimenting with the RAM size we found that when setting to to 3GB starting from 0x40000000 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
Hi Andreas,
just regarding the supported Linux versions - the following web page lists Ubuntu 16.04 as supported version and has also a link to a Google Drive share for the source:
http://wiki.friendlyarm.com/wiki/index.php/NanoPC-T3_Plus
Running Linux kernel 4.4 should give quite some info about the platform ... hope this helps ...
Cheers
Andreas
On 1/16/21 4:33 AM, Andreas Resch wrote:
Hi Matthias, hi Adam,
I can't find anything in the TRM regarding such hardware features in the region where the code exits. It exits right when scanning for the ram size in scan_ram_size at *(unsigned long *)(base_addr + offset) == 0x12345678) with the address as 0x80000000, which is exactly in the middle of the RAM, very strange. Setting the PLATFORM_RAM_SIZE_MB to 1024 and removing the method setup_memory_map from our Platform_arm_s5p6818 class boots as well. I'm starting to think that the culprit is inside the bootloader that is just a 'hacked' version of a 'hacked' version of u-boot 2016.01 I forked at https://github.com/reschandreas/NanoPC-T3Plus/tree/master/U-Boot , could that assumption be correct?
Regarding the timer, my teammate implemented a new driver and it looks like the timer is counting. However, we're now suspecting that our interrupt controller is not correctly initialized although we're doing it exactly like other Platforms with the GIC-400 and we have checked the base addresses several times.
Sadly the only running Linux version we could find is one really old one from friendlyarm where we couldn't extract meaningful information.
Andreas
On 15.01.21 01:27, Adam Lackorzynski wrote:
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.
- 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 0x40000000 to 0xc0000000) 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 0xffff000040000000 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)?
0xffff000040000000 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.
- The Timer - or the lack thereof
When we were experimenting with the RAM size we found that when setting to to 3GB starting from 0x40000000 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
Hey everyone,
thanks for the help, we finally got the board to successfully run the hello world application. As suggested we booted the provided Ubuntu image and in /proc/interrupts we found that the Timer used is associated with the IRQ number 56. Which is strange because the TRM states that the same Timer should be the IRQ number 24. We applied the new number and got out of the Calibrating timer loop, and after fixing some issues with our new timer driver we finally got it to work.
Regarding the RAM, we're still not quite sure why setting the RAM size to 2 GB fails, we settled to only specify one GB and call it a day, for now.
Thanks again everybody!
Andreas
On 16.01.21 13:33, Andreas Resch wrote:
Hi Matthias, hi Adam,
I can't find anything in the TRM regarding such hardware features in the region where the code exits. It exits right when scanning for the ram size in scan_ram_size at *(unsigned long *)(base_addr + offset) == 0x12345678) with the address as 0x80000000, which is exactly in the middle of the RAM, very strange. Setting the PLATFORM_RAM_SIZE_MB to 1024 and removing the method setup_memory_map from our Platform_arm_s5p6818 class boots as well. I'm starting to think that the culprit is inside the bootloader that is just a 'hacked' version of a 'hacked' version of u-boot 2016.01 I forked at https://github.com/reschandreas/NanoPC-T3Plus/tree/master/U-Boot , could that assumption be correct?
Regarding the timer, my teammate implemented a new driver and it looks like the timer is counting. However, we're now suspecting that our interrupt controller is not correctly initialized although we're doing it exactly like other Platforms with the GIC-400 and we have checked the base addresses several times.
Sadly the only running Linux version we could find is one really old one from friendlyarm where we couldn't extract meaningful information.
Andreas
On 15.01.21 01:27, Adam Lackorzynski wrote:
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.
- 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 0x40000000 to 0xc0000000) 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 0xffff000040000000 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)?
0xffff000040000000 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.
- The Timer - or the lack thereof
When we were experimenting with the RAM size we found that when setting to to 3GB starting from 0x40000000 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
Hi Andreas,
great that you got it running.
On [25-01-2021 10:49], Andreas Resch wrote:
Hey everyone,
thanks for the help, we finally got the board to successfully run the hello world application. As suggested we booted the provided Ubuntu image and in /proc/interrupts we found that the Timer used is associated with the IRQ number 56. Which is strange because the TRM states that the same Timer should be the IRQ number 24. We applied the new number and got out of the Calibrating timer loop, and after fixing some issues with our new timer driver we finally got it to work.
This can be easily explained. The timer interrupt is a GIC SPI (shared peripheral interrupt) interrupt. They start from 32 upwards (24 + 32 = 56). Number 0 - 31 are PPIs (per processor interrupts). You can spot this in the FDT for your platform if you look out for the GIC_SPI macro in the interrupt cell.
Regarding the RAM, we're still not quite sure why setting the RAM size to 2 GB fails, we settled to only specify one GB and call it a day, for now.
Most certainly parts of the RAM are reserved for the trusted firmware. The raw device tree might not help you here but you can grab the one the platform was booted with from /sys/firmware and disassemble it. This one should tell you the memory nodes that can safely be used by the OS.
Cheers, Matthias.
Thanks again everybody!
Andreas
On 16.01.21 13:33, Andreas Resch wrote:
Hi Matthias, hi Adam,
I can't find anything in the TRM regarding such hardware features in the region where the code exits. It exits right when scanning for the ram size in scan_ram_size at *(unsigned long *)(base_addr + offset) == 0x12345678) with the address as 0x80000000, which is exactly in the middle of the RAM, very strange. Setting the PLATFORM_RAM_SIZE_MB to 1024 and removing the method setup_memory_map from our Platform_arm_s5p6818 class boots as well. I'm starting to think that the culprit is inside the bootloader that is just a 'hacked' version of a 'hacked' version of u-boot 2016.01 I forked at https://github.com/reschandreas/NanoPC-T3Plus/tree/master/U-Boot , could that assumption be correct?
Regarding the timer, my teammate implemented a new driver and it looks like the timer is counting. However, we're now suspecting that our interrupt controller is not correctly initialized although we're doing it exactly like other Platforms with the GIC-400 and we have checked the base addresses several times.
Sadly the only running Linux version we could find is one really old one from friendlyarm where we couldn't extract meaningful information.
Andreas
On 15.01.21 01:27, Adam Lackorzynski wrote:
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.
- 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 0x40000000 to 0xc0000000) 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 0xffff000040000000 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)?
0xffff000040000000 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.
- The Timer - or the lack thereof
When we were experimenting with the RAM size we found that when setting to to 3GB starting from 0x40000000 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
l4-hackers@os.inf.tu-dresden.de
-
Adam Lackorzynski -
Andreas Resch -
Andreas Steinmetzler -
Matthias Lange