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.
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
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
