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). > > 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. Actually, due to the fact we use device tree from the scratch, we don't have any board specific code. Almost everything is probed from the device tree. So we always have only one barebox binary which runs on multiple boards and the .dtb section is patched dynamically. > > 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. Hope this shed some light on the boot process and why we don't have any boards/ directory :) Thanks for your review, Regards, Clément > > 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@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
