public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] Fix board init code to use a valid C runtime environment
Date: Wed, 11 Nov 2015 00:04:53 +0100	[thread overview]
Message-ID: <20151111000453.0949228b@lilith> (raw)
In-Reply-To: <CAPnjgZ3A8aKJGfyg849yQYT7ioh1Cw+vWmLNZDsgvoGzSe1nTQ@mail.gmail.com>

Hello Simon,

On Tue, 10 Nov 2015 13:04:50 -0700, Simon Glass <sjg@chromium.org>
wrote:

> I'm hoping we don't have to bring back this assembler.

What we need in ASM is just the part that actually alters the stack
(i.e., changes the SP of the architecture) so that no C function has to
do it.

> Do we really need to put everything in separate functions?

We need the (non-C) allocation code to be told the size to allocate
and to pass the base address of the allocated space, so that makes two
calls per allocated space, and there's GD  and malloc, so four calls.

Now, I created one function per call, but there are ways to use less
than four functions.

I could have specified the allocations sizes directly in crt0.S, but I
agree that all we can do in C should be done in C, so I kept the size
calculations in C functions.

We could also reduce the score to one function for GD and one for
malloc as follows: instead of calling one ulong(*)(void) to get the
size and one void(*)(void*) to initialize the allocated space, we could
call one ulong(*)(void*) twice, first with the void* equal to NULL (and
the function then returns the size it needs allocated) and second with
the void* equal to the base address of the allocated space (and the
function can then initialize it).

We could even reduce this to one single ulong(int chunk_id, void*)
where chunk_id would be either CHUNK_GD or CHUNK_MALLOC), and the
function would return the right size or do the right initializations
for the chunk considered. Plus, if a new type of chunk should be
allocated in addition to GD and the malloc arena, this could be handled
by adding a new chunk_id and adding cases in the alloc function for
size computation and chunk initialization.

> Perhaps you could add a bit more detail in the commit message as to
> what problem this solves?

Will do in v3.

> Regards,
> Simon

Amicalement,
-- 
Albert.

      reply	other threads:[~2015-11-10 23:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-10  0:20 [U-Boot] [PATCH] Fix board init code to use a valid C runtime environment Albert ARIBAUD
2015-11-10  1:14 ` Thomas Chou
2015-11-10  6:06   ` Albert ARIBAUD
2015-11-10  3:54 ` Bin Meng
2015-11-10  7:14   ` [U-Boot] [PATCH] Fix board init code to use a valid C runtime environment (LONG, sorry) Albert ARIBAUD
2015-11-10 20:04 ` [U-Boot] [PATCH] Fix board init code to use a valid C runtime environment Simon Glass
2015-11-10 23:04   ` Albert ARIBAUD [this message]

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=20151111000453.0949228b@lilith \
    --to=albert.u.boot@aribaud.net \
    --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