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 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. > > 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. > > 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 [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
