Linux-RISC-V Archive on lore.kernel.org
 help / color / Atom feed
From: Damien Le Moal <Damien.LeMoal@wdc.com>
To: Sean Anderson <seanga2@gmail.com>, Anup Patel <anup@brainfault.org>
Cc: "linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	Anup Patel <Anup.Patel@wdc.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <paul.walmsley@sifive.com>
Subject: Re: [PATCH 00/10] Kendryte k210 SoC boards support
Date: Mon, 2 Mar 2020 05:43:21 +0000
Message-ID: <BYAPR04MB58163B8F6A485DD131241F18E7E70@BYAPR04MB5816.namprd04.prod.outlook.com> (raw)
In-Reply-To: <ec249e00-26a2-b882-92bf-33462b15975f@gmail.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


  reply index

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-12 10:34 Damien Le Moal
2020-02-12 10:34 ` [PATCH 01/10] riscv: Fix gitignore Damien Le Moal
2020-02-20  0:15   ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 02/10] riscv: Force flat memory model with no-mmu Damien Le Moal
2020-02-14 20:18   ` Sean Anderson
2020-02-15  2:15     ` Damien Le Moal
2020-02-15  2:26       ` Sean Anderson
2020-02-15  2:40         ` Damien Le Moal
2020-03-02  3:48   ` Anup Patel
2020-03-04 18:38   ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 03/10] riscv: Unaligned load/store handling for M_MODE Damien Le Moal
2020-03-02  3:57   ` Anup Patel
2020-03-04 19:28   ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 04/10] riscv: Add BUILTIN_DTB support Damien Le Moal
2020-03-02  3:58   ` Anup Patel
2020-03-04 19:28   ` Palmer Dabbelt
2020-03-05  4:58     ` Anup Patel
2020-03-05  5:14       ` Damien Le Moal
2020-03-05  5:37         ` Anup Patel
2020-03-05  6:13           ` Damien Le Moal
2020-03-08  6:10             ` Anup Patel
2020-03-05  8:18         ` Atish Patra
2020-03-07  0:02           ` Sean Anderson
2020-03-07  1:51             ` Atish Patra
2020-03-07  2:08               ` Sean Anderson
2020-03-06 23:56         ` Sean Anderson
2020-02-12 10:34 ` [PATCH 05/10] riscv: Add SOC early init support Damien Le Moal
2020-03-04 19:28   ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 06/10] riscv: Add Kendryte K210 SoC support Damien Le Moal
2020-02-14 20:31   ` Sean Anderson
2020-03-04 19:38   ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 07/10] riscv: Select required drivers for Kendryte SOC Damien Le Moal
2020-03-02  3:59   ` Anup Patel
2020-03-04 19:44   ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 08/10] riscv: Add Kendryte K210 device tree Damien Le Moal
2020-02-14 20:51   ` Sean Anderson
2020-02-15  2:34     ` Damien Le Moal
2020-02-15  2:48       ` Sean Anderson
2020-02-15  3:00         ` Damien Le Moal
2020-02-18 14:12           ` Carlos Eduardo de Paula
2020-02-18 14:18             ` Sean Anderson
2020-02-18 14:30               ` Carlos Eduardo de Paula
2020-02-18 17:48                 ` Sean Anderson
2020-02-18 19:26                   ` Carlos Eduardo de Paula
2020-02-19  9:06                     ` Wladimir J. van der Laan
2020-02-19 22:28                       ` Sean Anderson
2020-02-20 10:48                         ` Wladimir J. van der Laan
2020-02-22 19:07                       ` Wladimir J. van der Laan
2020-04-01 17:55                         ` Drew Fustini
2020-04-02  2:24                           ` Damien Le Moal
2020-02-19  8:50                   ` Wladimir J. van der Laan
2020-02-27 19:43       ` Sean Anderson
2020-03-02  4:06   ` Anup Patel
2020-03-02  4:15     ` Damien Le Moal
2020-03-02  4:22       ` Anup Patel
2020-03-02  4:51         ` Damien Le Moal
2020-03-02  5:05           ` Anup Patel
2020-03-02  5:08             ` Damien Le Moal
2020-03-07  0:18               ` Sean Anderson
2020-03-07  4:11                 ` Anup Patel
2020-03-04 19:44   ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 09/10] riscv: Kendryte K210 default config Damien Le Moal
2020-03-02  4:07   ` Anup Patel
2020-03-04 19:44   ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 10/10] riscv: create a loader.bin for the kendryte kflash.py tool Damien Le Moal
2020-03-02  4:08   ` Anup Patel
2020-03-04 19:44   ` Palmer Dabbelt
2020-02-14 15:05 ` [PATCH 00/10] Kendryte k210 SoC boards support Carlos Eduardo de Paula
2020-02-15  2:02   ` Damien Le Moal
2020-02-17 13:28     ` Carlos Eduardo de Paula
2020-02-26 21:31       ` Carlos Eduardo de Paula
2020-02-27  2:18         ` Damien Le Moal
2020-02-28 20:32 ` Sean Anderson
2020-03-02  3:01   ` Damien Le Moal
2020-03-02  3:53     ` Sean Anderson
2020-03-02  4:11       ` Damien Le Moal
2020-03-02  4:18         ` Sean Anderson
2020-03-02  4:54           ` Damien Le Moal
2020-03-02  4:56             ` Sean Anderson
2020-03-02  5:03               ` Damien Le Moal
2020-03-02  4:17       ` Anup Patel
2020-03-02  4:21         ` Sean Anderson
2020-03-02  4:48         ` Damien Le Moal
2020-03-02  4:51           ` Damien Le Moal
2020-03-02  5:02           ` Sean Anderson
2020-03-02  5:11             ` Damien Le Moal
2020-03-02  5:25               ` Sean Anderson
2020-03-02  5:43                 ` Damien Le Moal [this message]
2020-03-04 19:44 ` Palmer Dabbelt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BYAPR04MB58163B8F6A485DD131241F18E7E70@BYAPR04MB5816.namprd04.prod.outlook.com \
    --to=damien.lemoal@wdc.com \
    --cc=Anup.Patel@wdc.com \
    --cc=anup@brainfault.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=seanga2@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-RISC-V Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-riscv/0 linux-riscv/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-riscv linux-riscv/ https://lore.kernel.org/linux-riscv \
		linux-riscv@lists.infradead.org
	public-inbox-index linux-riscv

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-riscv


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git