Re: [PATCH 00/10] Kendryte k210 SoC boards support

[Damien Le Moal <Damien.LeMoal@wdc.com>]

On 2020/03/02 14:25, Sean Anderson wrote:
> On 3/2/20 12:11 AM, Damien Le Moal wrote:
>> On 2020/03/02 14:02, Sean Anderson wrote:
>>> On 3/1/20 11:48 PM, Damien Le Moal wrote:
>>>> On 2020/03/02 13:17, Anup Patel wrote:
>>>>> On Mon, Mar 2, 2020 at 9:23 AM Sean Anderson <seanga2@gmail.com> wrote:
>>>>>>
>>>>>> On 3/1/20 10:01 PM, Damien Le Moal wrote:
>>>>>>> On 2020/02/29 5:32, Sean Anderson wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> When booting from U-Boot I get an OOM. Perhaps this is related to the
>>>>>>>> second cpu not coming up?
>>>>>>>
>>>>>>> Unlikely. It looks like your user space needs 2MB per shell (order 9
>>>>>>> allocation). Since you have only 5.5MB free, that may explain the allocation
>>>>>>> failure (if init is forking another shell especially).
>>>>>>
>>>>>> This should be before init comes up; when comparing this to your syslog
>>>>>> output there are several more messages before init gets started.
>>>>>>
>>>>>>> For the second core not coming up, an IPI needs to be sent to the non-boot core
>>>>>>> to wake it up. A Kendryte thing. U-boot should probably do it before jumping to
>>>>>>> the kernel. I thought I had that in the kernel though. Will check again.
>>>>>>
>>>>>> I think it's a RISC-V thing. I should have U-Boot set up to start linux
>>>>>> on both cores, but something may be misconfigured on that end.
>>>>>
>>>>> You have to booti or bootm on U-Boot M-mode to make all CPUs jump to
>>>>> Linux NOMMU.
>>>>>
>>>>> Based on you log, it seems the second CPU is still spinning in U-Boot
>>>>> M-mode and when Linux NOMMU tries to touch memory where second
>>>>> CPU is spinning everything gets corrupted.
>>>>
>>>> Yes, I understand. But in the case of the K210, that last 2MB segment is really
>>>> special as by default it is not usable as regular SRAM. I think it may be better
>>>> to reflect that in the device tree. The K210 soc_early_init() call back can
>>>> probe for that special entry too to see if it has to be turned on for use as
>>>> regular memory or not (i.e. if a kpu driver will use it).
>>>>
>>>> Since booting Linux with 6MB of memory will be even more challenging than with
>>>> 8, I agree that we may never see the case of a kpu driver being used. But I
>>>> personally like making that special case clear in the device tree. No strong
>>>> objection to your simplification though. So if you really object, I will go with it.
>>>
>>> The way I have it set up is like this
>>>
>>>
>>> 	sram0: memory@80000000 {
>>> 		device_type = "memory";
>>> 		compatible = "kendryte,k210-sram";
>>> 		reg = <0x80000000 0x400000>;
>>> 		clocks = <&sysclk K210_CLK_SRAM0>;
>>> 	};
>>>
>>> 	sram1: memory@80400000 {
>>> 		device_type = "memory";
>>> 		reg = <0x80400000 0x200000>;
>>> 		compatible = "kendryte,k210-sram";
>>> 		clocks = <&sysclk K210_CLK_SRAM1>;
>>> 	};
>>>
>>> 	airam: memory@80600000 {
>>> 		device_type = "memory";
>>> 		reg = <0x80600000 0x200000>;
>>> 		compatible = "kendryte,k210-airam";
>>> 		clocks = <&sysclk K210_CLK_AI>;
>>> 	};
>>>
>>> 	reserved-memory {
>>> 		#address-cells = <1>;
>>> 		#size-cells = <1>;
>>> 		ranges;
>>>
>>> 		ai_reserved: ai@80600000 {
>>> 			reg = <0x80600000 0x200000>;
>>> 			reusable;
>>> 		};
>>> 	};>
>>> And then the kpu has 'memory-region = <&ai_reserved>;'. This way the
>>> memory is documented as being used by the kpu, but also free when the
>>> KPU is not in use.
>>
>> I tried to use your syntax above initially but (if I remember correctly), the
>> "reserved-memory" entry prevents the initial ram setup to add the kpu segment,
>> so you can never see it as regular memory. So I dropped that and that memory is
>> usable with the v1 of the series I sent. The soc_early_init() enables it by
>> turning on pll1.
> 
> This seems like it could be fixed by writing a dummy driver for the KPU
> which does nothing but release the memory region.
> 
>>
>>>
>>> However, I have been unable to get the AI ram to work; any time I
>>> access it the CPU hangs. I have tried all combinations of
>>>
>>> * Enabling/disabling the AI clock
>>> * Enabling/disabling PLL1 (the AI clock's parent) but not the AI clock
>>> * Asserting/deasserting the KPU reset
>>>
>>> but I have not been able to get it working. Have you had any luck?
>>
>> See k210_soc_early_init() in drivers/soc/kendryte/k210-sysctl.c. That works.
>> You did already point out the clock initialization that is not enough and
>> working only because most of the values are the default. Maybe U-boot is
>> changing some of them resulting in the worng clock frequencies being set in the
>> kernel ?
> 
> My current clock setup when booted looks like
> 
> => clk dump 
>  Rate               Id        Usecnt      Name
> ----------------------------------------------------
>  26000000             0         2        |-- osc
>  780000000            1         1        |   |-- pll0
>  390000000            0         2        |   |   `-- pll0_half
>  390000000           42         6        |   |       |-- aclk
>  390000000            5         1        |   |       |   |-- sram0
>  390000000            6         1        |   |       |   |-- sram1
>  195000000           10         0        |   |       |   |-- rom
>  390000000           13         0        |   |       |   |-- dvp
>  195000000            7         2        |   |       |   |-- apb0
>  195000000           15         0        |   |       |   |   |-- gpio
>  195000000           29         0        |   |       |   |   |-- uart1
>  195000000           30         0        |   |       |   |   |-- uart2
>  195000000           31         0        |   |       |   |   |-- uart3
>  195000000           33         1        |   |       |   |   |-- fpioa
>  195000000           39         0        |   |       |   |   `-- sha
>  195000000            8         1        |   |       |   |-- apb1
>  195000000           32         0        |   |       |   |   |-- aes
>  195000000           40         0        |   |       |   |   `-- otp
>  195000000            9         1        |   |       |   |-- apb2
>  390000000            4         2        |   |       |   |-- cpu
>  390000000           11         0        |   |       |   |-- dma
>  390000000           14         0        |   |       |   `-- fft
>  97500000            19         0        |   |       |-- spi3
>  390000000           34         0        |   |       |-- timer0
>  390000000           35         0        |   |       |-- timer1
>  390000000           36         0        |   |       |-- timer2
>  390000000           16         0        |   |       |-- spi0
>  390000000           17         1        |   |       |-- spi1
>  390000000           18         0        |   |       |-- spi2
>  390000000           26         0        |   |       |-- i2c0
>  390000000           27         0        |   |       |-- i2c1
>  390000000           28         0        |   |       `-- i2c2
>  299000000            2         1        |   |-- pll1
>  299000000           12         1        |   |   `-- ai
>  0                    3         0        |   |-- pll2
>  0                    0         0        |   |   `-- pll2_half
>  0                   20         0        |   |       |-- i2s0
>  0                   21         0        |   |       |-- i2s1
>  0                   22         0        |   |       |-- i2s2
>  0                   23         0        |   |       |-- i2s0_m
>  0                   24         0        |   |       |-- i2s1_m
>  0                   25         0        |   |       `-- i2s2_m
>  13000000             0         0        |   |-- in0_half
>  13000000            37         0        |   |   |-- wdt0
>  13000000            38         0        |   |   `-- wdt1
>  26000000            41         0        |   `-- rtc
> 
> Perhaps I need PLL1 enabled but *not* AI. Alternatively, I have PLL1 set
> to the default rate of 299 MHz. It could be a clock domain problem.

I kind of remember reading that if you enable the AI clock, then the SRAM is not
usable as regular SRAM anymore and becomes reserved for the KPU. You need to
enable pll1 only for using it as regular mem. However, you mentioned that you
tried that already... Not sure what is going on.


-- 
Damien Le Moal
Western Digital Research