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