On Thu, Jan 16, 2020 at 10:37:26AM +0100, Clément Leger wrote: > > > ----- On 16 Jan, 2020, at 10:22, Sascha Hauer s.hauer@xxxxxxxxxxxxxx wrote: > > > On Thu, Jan 16, 2020 at 09:53:41AM +0100, Clément Leger wrote: > >> Hi Sasha > >> > >> ----- On 16 Jan, 2020, at 09:25, Sascha Hauer s.hauer@xxxxxxxxxxxxxx wrote: > >> > >> > 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? > >> > >> Indeed, you are right, currently, with this setup the processor boots > >> at address 0x0. > >> Currently, this is used since the JTAG loader can only start an elf > >> at address 0 (temporary limitation). The FSBL (First Stage boot loader) > >> can however load the elf file at any address. > >> > >> I have a patch to locate all the barebox code in SDRAM which is used > >> by the FSBL (see below) to load barebox in SDRAM. > >> > >> I can probably contribute this version if you prefer. Moreover, this will > >> be the final usage so better get it ok right now. > >> > >> For your information about SoC memory map, the SDRAM is located at > >> 0x100000000 and span on 64G, Additionally, 4G are mirrored at > >> 0x80000000 for 32 bits compatibility. > >> > >> > > >> > 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? > >> > >> This is done using ROM code which runs before barebox. Boot flow is the > >> following: > >> - Processor boots in NOR SPI (XIP) > >> - Execute ROM FSBL (First Stage Bootloader) which initialize needed > >> peripherals (DDR, PCIe, etc) > >> - Load SSBL (second stage bootloader) which is barebox ELF file in our case. > >> - .dtb ELF section is patched by this bootloader using the device tree > >> flashed into the board SPI NOR. > >> - Then jumps to barebox. > >> > >> So the version I sent you is a bit different since it allow to have a > >> builtin DTB. I wanted to be more standard with existing architecture. > >> > >> In our version, we have an empty .dtb section (which is of fixed size 24K). > >> And the tools to load elf files (either the FSBL or JTAG tools) are > >> flashing the right dtb (either from flash for FSBL or by board detection > >> with JTAG) into the .dtb section. > >> > >> Tell me if you want me to stay the "standard" way with builtin DTB or if > >> I can go with our way (fixed size .dtb section patched dynamically). > > > > Well, patching the barebox binary with a device tree is not very > > standard at all ;) > > > > How about just passing the dtb as a pointer to barebox? You are probably > > passing the device tree to linux as well, right? Maybe you can reuse > > your Kernel calling convention for barebox? That way it wouldn't matter > > if a started image is barebox or linux, it's both the same. > > Agreed, moreover, this is already done in our Linux port :) > > So to sumarize, I should keep the buitlin DTB mecanism + dtb passing > via registers. Is it ok ? I don't think we need builtin DTB at all. 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@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
