Re: Boot problems with Fiasco.OC on the NanoPC-T3 Plus

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

_______________________________________________
l4-hackers mailing list
[email protected]
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers