From: Sean Anderson <seanga2@gmail.com>
To: Damien Le Moal <Damien.LeMoal@wdc.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 00:25:04 -0500 [thread overview]
Message-ID: <ec249e00-26a2-b882-92bf-33462b15975f@gmail.com> (raw)
In-Reply-To: <BYAPR04MB58168C0C89145F91AE8E964FE7E70@BYAPR04MB5816.namprd04.prod.outlook.com>
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.
>>
>> 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
>>
>>
>
>
next prev parent reply other threads:[~2020-03-02 5:25 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-12 10:34 [PATCH 00/10] Kendryte k210 SoC boards support 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 [this message]
2020-03-02 5:43 ` Damien Le Moal
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=ec249e00-26a2-b882-92bf-33462b15975f@gmail.com \
--to=seanga2@gmail.com \
--cc=Anup.Patel@wdc.com \
--cc=Damien.LeMoal@wdc.com \
--cc=anup@brainfault.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.