From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Date: Thu, 22 Jan 2015 09:51:12 -0800 Subject: [U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address In-Reply-To: (Suriyan Ramasami's message of "Wed, 21 Jan 2015 21:54:19 -0800") References: <1421746560.6818.37.camel@collabora.co.uk> <1421772007.6818.42.camel@collabora.co.uk> <7h1tmn8wk2.fsf@deeprootsystems.com> Message-ID: <7hegqm7lgv.fsf@deeprootsystems.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Suriyan Ramasami writes: > Hello Kevin, > > On Wed, Jan 21, 2015 at 4:54 PM, Kevin Hilman wrote: >> Hi Surijan, >> >> Suriyan Ramasami 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