Suriyan Ramasami <suriya...@gmail.com> writes: > Hello Kevin, > > On Wed, Jan 21, 2015 at 4:54 PM, Kevin Hilman <khil...@kernel.org> wrote: >> Hi Surijan, >> >> Suriyan Ramasami <suriya...@gmail.com> writes: >> >>> Hello Sjoerd Simons, >>> A signed BL2 which allows unsigned BL2 chain load is already >>> available for experimentation. Refer this link: >>> http://forum.odroid.com/viewtopic.php?f=98&t=6147#p58984 >>> The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which >>> allows the same. >>> >>> The layout of SD card is as follows: >>> >>> BL1 (1 to 30) 15K >>> BL2 (31 to 62) 16K >>> indicator block (63 to 64) 1K >>> uboot (65 to 2112) 1M >>> tzsw (2113 to 2624) 256K >>> unsigned BL2 (2625 to 2656) 16K >>> >>> A non zero in the first byte of the indicator block instructs the >>> signed BL2 to load the unsigned BL2 @ offset 2625. >> >> I took the binaries from your .zip file above and put them on the SD >> card for my odroid-xu3 at the offsets above. I'm using BL1 and TZSW >> from the u-boot-hardkernel release[1] and using u-boot-dtb.bin from >> my own mainline u-boot build which inclues the odroid-xu3 patches. >> >> If I leave the indicator block zero'd, everything works fine, and it >> boots my version of mainline u-boot without any problems. >> >> If I then write a non-zero value to the first byte of the indicator >> block and write your unsigned BL2 at the appropriate offset, it no >> longer boots. Is the unsigned BL2 supposed to boot u-boot at offset 65 >> when it's finished as well? >> > > The unsigned SPL from mainline used will be spl/u-boot-spl.bin (raw > jump to offset 0 in that file will be pure code without headers)
OK. > Changes are needed in spl_boot.c to make it next load u-boot-dtb.bin. > > I shall try to list most of the changes here: > 1.arch/arm/cpu/armv7/exynos/spl_boot.c: > The Odroid-XU3's IROM function pointers does not have any code > (AFAICT). I checked the locations that are listed in the array table > and found all 0's there. > We need to replace function copy_uboot_to_ram() with something > similar from HK's file, so that it uses exynos_smc() calls to load the > bits from SD card, or we could enable MMC code in SPL (haven't tried > it) and use those functions instead. > For quick results,I just forced an SD card read. > > 2. #define CONFIG_SEC_FW_SIZE (15 << 10) /* 15 KB */ > somewhere, so that the start offset for U-Boot is calculated correctly. > > 3. for chain loading we define CONFIG_SPL_TEXT_BASE to be, say > 0x63E00000 so that when its executed the static global pointers are > accessed correctly - static struct spl_machine_param machine_param in > file smdk5420_spl.c. > > 4. mem_ctrl_init() hangs in while (val != FOUTBPLL); > One workaround is to use HKs version of this function which again > uses some smc calls. > > With all these changes, SPL chainloading works. Do you have a patch against mainline u-boot for all these changes? I'd be happy to test. >> How are you debugging your SPL images? >> >> I tried adding CONFIG_SPL_SERIAL_SUPPORT so I could printf from SPL, but >> that doesn't compile because it seems that libfdt support is needed. >> > > I didn't enable SERIAL SUPPORT for debugging. I did study the HK SPL > code vs mainline SPL code quite a bit and worked from there. > I can try to see if there is an easy way to enable serial printfs. Are there any GPIO LEDs to blink? Thanks, Kevin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
