Re: Sipeed Lichee RV (Allwinner D1)

On 1/28/22 16:29, Mitchell Horne wrote:
> On 1/19/22 18:05, Jakob Alvermark wrote:
>>
>> On 1/19/22 17:24, Mitchell Horne wrote:
>>>
>>>
>>> On 1/17/22 15:02, Jakob Alvermark wrote:
>>>> Hi,
>>>>
>>>>
>>>> With RISC-V SBCs now coming down in price, I got curios and got 
>>>> myself a Lichee RV (with the dock).
>>>>
>>>> https://linux-sunxi.org/Sipeed_Lichee_RV
>>>>
>>>> The instructions here, https://linux-sunxi.org/Allwinner_Nezha 
>>>> along with some patching got me a working U-boot.
>>>>
>>>> Cross-building and putting together and image for and SD card got 
>>>> me this far:
>>>>
>> <snip>
>>>> Loading kernel...
>>>> /boot/kernel/kernel text=0x609ddc text=0x133abc data=0xf4420 
>>>> data=0xb54+0x1d73e4 syms=[0x8+0xcd188+0x8+0xee5ae]
>>>> Loading configured modules...
>>>> can't find '/etc/hostid'
>>>> can't find '/boot/entropy'
>>>> Using DTB provided by EFI at 0x47ef5000.
>>>> Kernel entry at 0x56a0002e...
>>>> Kernel args: (null)
>>>>
>>>> -----
>>>>
>>>> And here it stops for  ~16 seconds then restarts, that's the 
>>>> watchdog resetting it.
>>>>
>>>> So where do I go from here?
>>>>
>>> Hi Jakob,
>>>
>>> Looks like it bails somewhere in the initial kernel setup, before 
>>> the first output to the console. This is a wide range, so it's 
>>> difficult to say exactly where things are going wrong.
>>>
>>> I will say that generally FreeBSD is not expected to work on the D1; 
>>> as far as I know you are the first to try it. This hardware has some 
>>> quirks requiring special support, which we are entirely lacking. 
>>> Specifically, there is one related to virtual memory management, 
>>> which requires custom (spec-breaking) bits in the page tables to be 
>>> set, to properly specify the attributes of physical and device 
>>> memory. This _may_ have something to do with why it is failing where 
>>> it is. It would take a motivated party to add the support required 
>>> for this SoC, and I'm not aware of anyone currently taking this on. 
>>> This board has caused some headaches in Linux-land for the same 
>>> reasons, but there are more hands to do the work there. I just want 
>>> to set the expectations properly :)
>>>
>>> If you wanted to debug this further, you might rebuild the kernel 
>>> after adding 'options EARLY_PRINTF' to the config file, as this 
>>> should enable a couple early outputs and narrow down the search 
>>> slightly.
>>
>>
>> Hi Mitchell,
>>
>>
>> I did not expect it to work. But it would be nice if it did.
>>
>> I have a long experience with FreeBSD and I have played around with a 
>> couple of different ARM-boards, but I'm not very experienced with 
>> kernel hacking.
>>
>> I built a kernel with EARLY_PRINTF, but it did not give me any more 
>> output...
>>
>> Is there anything else I could try?
>>
>
> Yes, I missed an important detail: the required uart driver is missing 
> from the kernel. Please add 'device uart_snps' to the kernel config as 
> well, and see if this results in any output.


Hi, I tried that, but sadly it did not make any difference.

I looked at what they have done in Linux, and this commit seems to have 
some interesting bits:

https://github.com/smaeul/linux/commit/c1bc61cee73e236c3cd69fe6c998b7f80c654263#diff-4f4bb4eea826b523d76ddb1c539dad5685a0e7fd7cc8f1089a0493efd0e8e5b8


Jakob