[PATCH v8 00/21] riscv: Add Sipeed Maix support

[Sean Anderson]

On 4/22/20 9:51 PM, Rick Chen wrote:
> Hi Sean
> 
>> Hi Sean
>>
>>> This patch series adds support for Sipeed Maix boards and the Kendryte
>>> K210 CPU. Currently, only the Maix Bit V2.0 is supported, however other
>>> models are similar.
>>>
>>> Known Bugs/Limitations:
>>> - Accessing the AI ram hangs, limiting available ram to 6M
>>> - Trying to boot an image with bootm fails with
>>>   ERROR: Failed to allocate 0x7d60 bytes below 0x80000000.
>>>
>>> To flash u-boot to a maix bit, run
>>> kflash -tp /dev/<your tty here> -B bit_mic u-boot-dtb.bin
>>>
>>> Boot output should look like the following:
>>>
>>> U-Boot 2020.04-rc2-00087-g2221cc09c1-dirty (Feb 28 2020 - 13:53:09 -0500)
>>>
>>> DRAM:  8 MiB
>>> In:    serial at 38000000
>>> Out:   serial at 38000000
>>> Err:   serial at 38000000
>>> =>
>>>
>>> Changes for v8:
>>> - Removed dependency on the patch "clk: Add functions to register CCF clock
>>>   structs". Hopefully this will make reviewing easier.
>>
>> I have applied this patch series to u-boot-riscv/master except [PATCH
>> v8 14/21] riscv: Clean up IPI initialization code.
>> Because it will cause some warnings as below:
>>
>> arch/riscv/lib/andes_plic.c: In function 'riscv_init_ipi':
>> arch/riscv/lib/andes_plic.c:84:12: warning: initialization makes
>> integer from pointer without a cast [-Wint-conversion]
>>   int ret = syscon_get_first_range(RISCV_SYSCON_PLIC);
>>             ^~~~~~~~~~~~~~~~~~~~~~
>> arch/riscv/lib/andes_plic.c:86:13: warning: passing argument 1 of
>> 'IS_ERR' makes pointer from integer without a cast [-Wint-conversion]
>>   if (IS_ERR(ret))
>>              ^~~
>> In file included from arch/riscv/lib/andes_plic.c:20:0:
>> include/linux/err.h:34:20: note: expected 'const void *' but argument
>> is of type 'int'
>>  static inline long IS_ERR(const void *ptr)
>>                     ^~~~~~
>> arch/riscv/lib/andes_plic.c:87:18: warning: passing argument 1 of
>> 'PTR_ERR' makes pointer from integer without a cast [-Wint-conversion]
>>    return PTR_ERR(ret);
>>                   ^~~
>> In file included from arch/riscv/lib/andes_plic.c:20:0:
>> include/linux/err.h:29:20: note: expected 'const void *' but argument
>> is of type 'int'
>>  static inline long PTR_ERR(const void *ptr)
>>                     ^~~~~~~
>> arch/riscv/lib/andes_plic.c:88:16: warning: assignment makes pointer
>> from integer without a cast [-Wint-conversion]
>>   gd->arch.plic = ret;
>>
> 
> after running CI yesterday, it failed in many cases:
> https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/678023975
> 
> and I trace at least two cases belong to your patch
> 49.59
> https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/678024035
> 
> arning, treated as error:
> /home/travis/build/rickchen36/u-boot-riscv/doc/board/sipeed/maix.rst:173:Error
> in "code-block" directive:
> 1 argument(s) required, 0 supplied.
> .. code-block::
>     &sysclk {
>         assigned-clocks = <&sysclk K210_CLK_PLL0>;
>         assigned-clock-rates = <800000000>;
>     };
> doc/Makefile:69: recipe for target 'htmldocs' failed
> make[1]: *** [htmldocs] Error 1

I used to have

.. code-block:: dts

but it warned that "dts" was not a valid language, so I dropped it.

> 49.66
> https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/678024042
> 
> ./tools/patman/patman --test && ./tools/buildman/buildman -t &&
> ./tools/dtoc/dtoc -t && make testconfig; fi; fi
> cp: cannot create regular file
> '/home/travis/build/rickchen36/sandbox/': Not a directory
> cp: cannot create regular file
> '/home/travis/build/rickchen36/sandbox/': Not a directory
> WARNING: no status info for 'sipeed_maix_bitm'
> WARNING: no maintainers for 'sipeed_maix_bitm'

I'm not sure what the issue here is. Which specific files are lacking a
MAINTAINERS entry?

> 
> So I will drop your patchs and run CI again today.
> And hope you can fix them in next version and pass CI verification.



> 
> Thanks,
> Rick
> 

These "errors" seem rather minor. I will fix the PLIC ones in the next
revision, but I don't think the sort found in this email are
particularly erroneous.

--Sean