mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Clement Leger <cleger@kalray.eu>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 0/5] Add support for Kalray k1c core
Date: Thu, 16 Jan 2020 09:25:47 +0100	[thread overview]
Message-ID: <20200116082547.l6ba2wcsrne7mozb@pengutronix.de> (raw)
In-Reply-To: <20200115102650.11739-1-cleger@kalray.eu>

Hi Clement,

On Wed, Jan 15, 2020 at 11:26:45AM +0100, Clement Leger wrote:
> Kalray k1c core is embedded in Kalray Coolidge SoC. This core has the
> following features:
>  - 32/64 bits
>  - 6-issue VLIW architecture
>  - 64 x 64bits general purpose registers
>  - SIMD instructions
>  - little-endian
> 
> This port is a 64 bits one and allows to boot up to a barebox prompt on a k200
> board. k1c support for clocksource and watchdog is also part of this port.
> 
> In order to build a usable toolchain, build scripts are provided at the
> following address: https://github.com/kalray/build-scripts.
> 
> Kalray uses FOSS which is available at https://github.com/kalray
> 
> Clement Leger (5):
>   k1c: Initial Kalray Coolidge (k1c) architecture support
>   k1c: Add processor definitions
>   k1c: Add support for device tree
>   clocksource: k1c: Add k1c clocksource support
>   watchdog: k1c: Add k1c watchdog support

From a first look this is all pretty straight forward, looks good ;)

barebox is entered at 0x0. According to the linker script and the device
tree you have 4MiB of SRAM there, right?

I don't see any SDRAM setup code in this series, nevertheless it is
used. How is SDRAM setup done? Is it done in ROM or is it some board
specific binary that runs before barebox?

Generally it seems that the board code is not very well separated from
the SoC code. Ideally barebox startup is like:

- The entry point is board specific
- in this board specific code everything is done that is needed for a
  properly running SoC with SDRAM enabled. This may require some helper
  functions to be shared between boards
- the entry code jumps to the generic code, passing a pointer to
  the device tree and if necessary SDRAM base/size

With this setup we can build barebox images for multiple boards (or
multiple configurations of boards) in one go. As a developer you can
test on multiple boards without having to recompile. For a compile
tester it reduces the number of configurations to build (faster
results). For an integrator it reduces the number of barebox receipts to
keep track of.  Overall it's worth implementing such a scheme.

It would be great to get there with the Kalray SoC as well, that's why I
asked about the SDRAM setup above. If there is board specific code
running before barebox, it should be possible to pass information to
barebox on which board we are actually running. With this information we
could reduce the need for board specifics in barebox.

I hope my questions go into the right direction, maybe just tell me a
little bit more about the SoC startup.

Regards,
 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

  parent reply	other threads:[~2020-01-16  8:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-15 10:26 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
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 ` Sascha Hauer [this message]
2020-01-16  8:53   ` [PATCH 0/5] Add support for Kalray k1c core 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=20200116082547.l6ba2wcsrne7mozb@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=cleger@kalray.eu \
    /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