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

[Sean Anderson <seanga2@gmail.com>]

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.

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?

There's also the issue that all DMAs should happen from the uncached
memory area, but I think there is some existing infrastructure to
"translate" IO addresses, so this doesn't need to be added to the device
tree.

--Sean