Hi, On 13 June 2017 at 04:31, Dr. Philipp Tomsich <philipp.toms...@theobroma-systems.com> wrote: > >> On 13 Jun 2017, at 11:47, Marek Vasut <ma...@denx.de> wrote: >> >> On 06/13/2017 11:44 AM, Dr. Philipp Tomsich wrote: >>> Marek, >>> >>>> On 13 Jun 2017, at 10:42, Marek Vasut <ma...@denx.de >>>> <mailto:ma...@denx.de>> wrote: >>>> >>>> On 06/13/2017 03:51 AM, Kever Yang wrote: >>>>> Hi Marek, >>>> >>>> Hi, >>>> >>>>> On 06/07/2017 02:28 PM, Marek Vasut wrote: >>>>>> On 06/07/2017 04:28 AM, Kever Yang wrote: >>>>>>> Hi Andre, Steve, Marek, >>>>>>> >>>>>>> Could you help to check how to make it work with this patch on >>>>>>> sunxi, bcm and socfpga platform? >>>>>> The socfpga expects the hook at that exact position (0x40 I think) , so >>>>>> if you moved it somewhere, you broke socfpga. >>>>> >>>>> I know this break socfpga, and that's why I cc you for help, could you >>>>> help the take a look if we can have a solution on socfpga to "make it >>>>> work with this patch"? >>>> >>>> Can you generate the same u-boot binary with this patch ? If so, then it >>>> will work on socfpga. SoCFPGA expects that small piece of stuff at >>>> offset 0x40 , so if you move this boot0 hook, it will break. HTH >>> >>> So the SoCFPGA-implementation relies on the boot0 hook to always start >>> at 0x40? Then this needs fixing anyway… or it will break once someone >>> else touches the armv7 startup code. >> >> I think it's not just the SoCFPGA. > > What I am saying is that the boot0-hook is intended to add a header > before the actual U-Boot code (as Andre had originally stated in his > commit message and as various comments around the boot0 hook > also suggest): > > arm/arm64: implement a boot header capability > > Some SPL loaders (like Allwinner's boot0, and Broadcom's boot0) > require a header before the actual U-Boot binary to both check its > validity and to find other data to load. Sometimes this header may > only be a few bytes of information, and sometimes this might simply > be space that needs to be reserved for a post-processing tool. > > However, the actual start of the boot0-hook in the U-Boot today is right > after the vector-table (which is 0x40 long), which has a few interesting > consequences for various architectures: > - sunxi: doesn’t matter > - socfpga: boot0 hook relies on something being in front of it, as it uses > a ".balign 64, …” to advance to 0x40 > - rockchip: comes too late to allow inserting the word-sized field at the > very start (and to move the vectors back by a word). > > Now having looked at the implementation in > arch/arm/mach-socfpga/include/mach/boot0.h > it is clear why Kever’s change breaks this code: .balign will not forward > to 0x40 (after all, 0x0 is also 64-byte aligned). > > Once the boot0 hook is at the beginning of the binary (as always intended), > this will need to become a .space or .fill directive. > >>> That said, I read your comment to mean that the following changes would >>> work for SoCFPGA: >>> 1.arch/arm/lib/vectors.S: >>> #if CONFIG_IS_ENABLED(BOOT0_HOOK) >>> … pull in the boot0 hook, which needs to contain the vectors >>> #else >>> b reset >>> … remaining vectors … >>> #endif >>> 2.boot0.h (for socfpga): >>> b reset >>> … remaining vectors … >>> /* now at 0x40 */ >>> … whatever currently lives in the boot0.h for socfpga ... >>> >>> Ok? >> >> I'm not sure I understand what you're trying to say. IIRC the SoCFPGA >> bootrom checks the content at 0x40-0x48 in SRAM and then jumps to 0x50 >> if the content is valid. Otherwise it reloads the content from >> SD/SPI/NAND… > > Thanks for the background info. With this, it should be possible to create > a new version of the patch that also correctly handles socfpga.
Sounds like this is figured out, great! - Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
