Hi Suriyan,
On 01/23/2015 10:46 AM, Suriyan Ramasami wrote:
On Thu, Jan 22, 2015 at 9:51 AM, Kevin Hilman khilman@kernel.org wrote:
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Kevin,
On Wed, Jan 21, 2015 at 4:54 PM, Kevin Hilman khilman@kernel.org wrote:
Hi Surijan,
Suriyan Ramasami suriyan.r@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)
Is it impossible the unsigned BL2(spl/smdk5422-spl.bin) file from hardkernel u-boot with your chaining signed BL2?
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.
- #define CONFIG_SEC_FW_SIZE (15 << 10) /* 15 KB */
somewhere, so that the start offset for U-Boot is calculated correctly.
- 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.
- 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.
Give me some time and I shall iron out my notes and get back to creating a patch for this against mainline U-Boot.
I'm also waiting. Thanks for your try.
Thanks.
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?
It does have some LEDs.
Thanks,
Kevin
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot