On Thu, Jan 22, 2015 at 9:51 AM, Kevin Hilman <khil...@kernel.org> wrote: > 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. >
Give me some time and I shall iron out my notes and get back to creating a patch for this against mainline U-Boot. >>> 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
