mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: "Clément Leger" <cleger@kalray.eu>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Barebox List <barebox@lists.infradead.org>
Subject: Re: [PATCH 1/5] k1c: Initial Kalray Coolidge (k1c) architecture support
Date: Thu, 16 Jan 2020 13:24:41 +0100 (CET)	[thread overview]
Message-ID: <1878342639.12568406.1579177481299.JavaMail.zimbra@kalray.eu> (raw)
In-Reply-To: <20200116105534.6wfpjkmrgeixaehy@pengutronix.de>


----- On 16 Jan, 2020, at 11:55, Sascha Hauer s.hauer@pengutronix.de wrote:

> On Thu, Jan 16, 2020 at 11:49:31AM +0100, Clément Leger wrote:
>> Hi Sasha
>> 
>> ----- On 16 Jan, 2020, at 10:26, Sascha Hauer s.hauer@pengutronix.de wrote:
>> 
>> > On Wed, Jan 15, 2020 at 11:26:46AM +0100, Clement Leger wrote:
>> >> +config MALLOC_BASE
>> >> +	hex
>> >> +	default 0x100000000
>> >> +
>> >> +config MALLOC_SIZE
>> >> +	hex
>> >> +	default 0x800000
>> >> +	prompt "malloc area size"
>> >> +endmenu
>> > 
>> >> diff --git a/arch/k1c/lib/board.c b/arch/k1c/lib/board.c
>> >> new file mode 100644
>> >> index 000000000..d17a32614
>> >> --- /dev/null
>> >> +++ b/arch/k1c/lib/board.c
>> >> @@ -0,0 +1,20 @@
>> >> +// SPDX-License-Identifier: GPL-2.0-only
>> >> +/*
>> >> + * Copyright (C) 2019 Kalray Inc.
>> >> + */
>> >> +
>> >> +#include <common.h>
>> >> +#include <malloc.h>
>> >> +#include <memory.h>
>> >> +#include <asm-generic/memory_layout.h>
>> >> +
>> >> +
>> >> +void __noreturn k1c_start_barebox(void)
>> >> +{
>> >> +	mem_malloc_init((void *)CONFIG_MALLOC_BASE,
>> >> +			(void *)(CONFIG_MALLOC_BASE + MALLOC_SIZE - 1));
>> > 
>> > You could extract valid memory from the device tree instead and pick
>> > some memory for malloc there. See of_find_mem() how this can be done.
>> 
>> I think we are going to bite our tail here since of_unflatten_dtb does
>> some xzalloc to unflatten the DTB so we need to initialize the malloc
>> allocator before accessing DTB.
> 
> of_find_mem() doesn't use of_unflatten_dtb(), it uses libfdt to parse
> the device tree.

Oh indeed. I looked at it and I see potential problems:
- Stack address/size will still need to be hardcoded because it needs to
  be setup before executing C code.
- We have multiple memory nodes in our device tree (SMEM and DDR) so we will
  probably have to do some quirks to finally find the DDR memory node.
- MALLOC_SIZE will still needs to be there

I'm afraid we will end up with some mixed up approach were one mecanism is 
dynamic (malloc) and the other is not (stack). Moreover, the "dynamic" memory
detection will be potentially tainted with some if (mem_addr > 0x100000000).

One other option would be to add a compatible field in the memory node.
This way, the search could be easier but I will still have to hardcode the
stack address.

Tell me if you see another mecanism

> 
> Sascha
> 
> --
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2020-01-16 12:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-15 10:26 [PATCH 0/5] Add support for Kalray k1c core Clement Leger
2020-01-15 10:26 ` [PATCH 1/5] k1c: Initial Kalray Coolidge (k1c) architecture support Clement Leger
2020-01-16  9:26   ` Sascha Hauer
2020-01-16 10:49     ` Clément Leger
2020-01-16 10:55       ` Sascha Hauer
2020-01-16 12:24         ` Clément Leger [this message]
2020-01-16 13:11           ` Sascha Hauer
2020-01-16 13:26             ` Clément Leger
2020-01-16 13:34               ` Sascha Hauer
2020-01-15 10:26 ` [PATCH 2/5] k1c: Add processor definitions Clement Leger
2020-01-15 10:26 ` [PATCH 3/5] k1c: Add support for device tree Clement Leger
2020-01-15 10:26 ` [PATCH 4/5] clocksource: k1c: Add k1c clocksource support Clement Leger
2020-01-15 10:26 ` [PATCH 5/5] watchdog: k1c: Add k1c watchdog support Clement Leger
2020-01-20 15:10   ` Ahmad Fatoum
2020-01-20 16:08     ` Clément Leger
2020-01-16  8:25 ` [PATCH 0/5] Add support for Kalray k1c core Sascha Hauer
2020-01-16  8:53   ` Clément Leger
2020-01-16  9:22     ` Sascha Hauer
2020-01-16  9:37       ` Clément Leger
2020-01-16  9:46         ` Sascha Hauer
2020-01-16  9:49 ` Roland Hieber
2020-01-16  9:53   ` Clément Leger

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=1878342639.12568406.1579177481299.JavaMail.zimbra@kalray.eu \
    --to=cleger@kalray.eu \
    --cc=barebox@lists.infradead.org \
    --cc=s.hauer@pengutronix.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