U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marek.vasut@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer
Date: Fri, 15 Jun 2018 14:00:31 +0200	[thread overview]
Message-ID: <85111443-91db-70ab-3cea-9ed326982d1b@gmail.com> (raw)
In-Reply-To: <3a3b322d-c04d-063e-392b-7967a9b8959c@gmail.com>

On 06/15/2018 01:43 PM, Marek Vasut wrote:
> On 06/15/2018 12:37 PM, Ulrich Hecht wrote:
>> On Fri, Jun 15, 2018 at 12:09 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
>>>> +             arm_smccc_smc(ARM_SMCCC_RENESAS_MEMCONF,
>>>> +                           0, 0, 0, 0, 0, 0, 0, &res);
>>>
>>> Will this call work on platforms without patched ATF ?
>>> (I think not, don't you need to handle return value?)
>>
>> I have not actually tested that, but if I understand the ATF code
>> correctly, unimplemented calls return
>> SMC_UNK (0xffffffff), which should be handled by the default case (NOP) below.
> 
> Which means the board has a memory size of 0 and fails to boot ?
> 
>>>> +             switch (res.a0) {
>>>> +             case 1:
>>>> +                     base[0] = 0x048000000ULL;
>>>> +                     size[0] = 0x038000000ULL;
>>>> +                     base[1] = 0x500000000ULL;
>>>> +                     size[1] = 0x040000000ULL;
>>>> +                     base[2] = 0x600000000ULL;
>>>> +                     size[2] = 0x040000000ULL;
>>>> +                     base[3] = 0x700000000ULL;
>>>> +                     size[3] = 0x040000000ULL;
>>>> +                     fdt_fixup_memory_banks(blob, base, size, 4);
>>>> +                     break;
>>>> +             case 2:
>>>> +                     base[0] = 0x048000000ULL;
>>>> +                     size[0] = 0x078000000ULL;
>>>> +                     base[1] = 0x500000000ULL;
>>>> +                     size[1] = 0x080000000ULL;
>>>> +                     fdt_fixup_memory_banks(blob, base, size, 2);
>>>> +                     break;
>>>> +             case 3:
>>>> +                     base[0] = 0x048000000ULL;
>>>> +                     size[0] = 0x078000000ULL;
>>>> +                     base[1] = 0x500000000ULL;
>>>> +                     size[1] = 0x080000000ULL;
>>>> +                     base[2] = 0x600000000ULL;
>>>> +                     size[2] = 0x080000000ULL;
>>>> +                     base[3] = 0x700000000ULL;
>>>> +                     size[3] = 0x080000000ULL;
>>>> +                     fdt_fixup_memory_banks(blob, base, size, 4);
>>>> +                     break;
>>>
>>> Obvious design question is -- since you're adding new SMC call anyway,
>>> can't the call just return the memory layout table itself, so that it
>>> won't be duplicated both in U-Boot and ATF ?
>>
>> My gut feeling was to go with the smallest interface possible.
> 
> But this doesn't scale. The API here uses some ad-hoc constants to
> identify memory layout tables which have to be encoded both in ATF and
> U-Boot, both of which must be kept in sync.
> 
> The ATF already has those memory layout tables, it's only a matter of
> passing them to U-Boot. If you do just that, the ad-hoc constants and
> encoding of tables into U-Boot goes away and in fact simplifies the design.
> 
> Yet, I have to wonder if ATF doesn't already contain some sort of
> standard SMC call to get memory topology. It surprises me that it wouldn't.

In fact, Laurent (CCed) was solving some similar issue with lossy decomp
and I think this involved some passing of memory layout information from
ATF to U-Boot too, or am I mistaken ?

-- 
Best regards,
Marek Vasut

  reply	other threads:[~2018-06-15 12:00 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-15  9:40 [U-Boot] [RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer Ulrich Hecht
2018-06-15  9:40 ` [U-Boot] [RFC ATF] Add SMCCC_RENESAS_MEMCONF SMC call Ulrich Hecht
2018-06-15 10:09 ` [U-Boot] [RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer Marek Vasut
2018-06-15 10:37   ` Ulrich Hecht
2018-06-15 11:43     ` Marek Vasut
2018-06-15 12:00       ` Marek Vasut [this message]
2018-06-15 23:21         ` Laurent Pinchart
2018-06-15 23:42           ` Marek Vasut
2018-06-16 15:44             ` Laurent Pinchart
2018-06-17  0:08               ` Marek Vasut
2018-06-19  2:15                 ` Laurent Pinchart
2018-06-19  5:43                   ` Magnus Damm
2018-06-19  5:56                     ` Laurent Pinchart
2018-06-19  6:58                   ` Geert Uytterhoeven
2018-06-19  7:11                     ` Laurent Pinchart
2018-06-19  7:17                       ` Geert Uytterhoeven
2018-06-20  4:55                       ` Marek Vasut
2018-06-28 17:24                         ` Eugeniu Rosca

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=85111443-91db-70ab-3cea-9ed326982d1b@gmail.com \
    --to=marek.vasut@gmail.com \
    --cc=u-boot@lists.denx.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox