From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dr. Philipp Tomsich Date: Tue, 19 Sep 2017 14:45:17 +0200 Subject: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace assembly-implementation with C-code In-Reply-To: <93C673C2-A070-474F-A21E-674F178DF1BA@theobroma-systems.com> References: <1505758708-29213-1-git-send-email-philipp.tomsich@theobroma-systems.com> <55b57a24-fb49-5a6b-6881-51c15d52fa3f@rock-chips.com> <93C673C2-A070-474F-A21E-674F178DF1BA@theobroma-systems.com> Message-ID: <2D26637D-39A8-4982-9022-E7D46D521D4A@theobroma-systems.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de Andy, > On 19 Sep 2017, at 11:10, Dr. Philipp Tomsich wrote: > > Andy, > >> On 19 Sep 2017, at 09:19, Andy Yan wrote: >> >> Hi Philipp: >> >> >> On 2017年09月19日 10:06, Andy Yan wrote: >>> Hi Philipp: >>> >>> >>> On 2017年09月19日 02:18, Philipp Tomsich wrote: >>>> Recent discussions confirmed (what the code always assumed): the >>>> Rockchip BROM always enters U-Boot with the stack-pointer valid >>>> (i.e. the U-Boot startup code is running off the BROM stack). >>>> >>>> We can thus replace the back-to-bootrom code (i.e. both the >>>> save_boot_params and back_to_bootrom implementations) using C-code >>>> based on setjmp/longjmp. The new implementation is already structured >>>> to allow an easy drop-in of Andy's changes to enter download-mode when >>>> returning to the BROM. >>>> >>>> This entails one minor tweak to asm/system.h, which only exported >>>> the save_boot_params_ret prototype for ARMv7, but not for AArch64. >>>> >>>> For v2, we force bootrom.o to alway be emitted as A32 (not T32), so we >>>> can safely call save_boot_params_ret(). >>> >>> This still have a problem, because the setjmp implementation for ARM32 platform has humb code when CONFIG_SYS_THUMB_BUILD is >>> enabled, this is a default setting for most ARMv7 boards. >>> #if CONFIG_IS_ENABLED(SYS_THUMB_BUILD) >>> ".align 2\n" >>> "adr r0, jmp_target\n" >>> "add r0, r0, $1\n" // r0 stored the jump target address and with bit[0] = 1, this will trigger a thumb switch in longjmp with code "bx r0" >>> #endif >>> >>> When I force the setjmp code go arm code path, I can back to bootrom successfully, But I got a data abort exception in later. it seems it happens when bootrom finished the uboot code >>> copy, when jump to sdram, I need a further debug. >> >> I found that r9 also need to be preserved, it seems that it hold the sdram base. > > Thanks for testing and debugging: this is invaluable support, as I only have AArch64 boards to test. > > The r9 issue will be easy enough to resolve. > However, it looks like I will need more work on setjmp/longjmp to make this safe both for T32 and A32. > Plus: I need to figure out why this didn’t show in my disassembly (I don’t remember whether it was a rk3188 or rk3288 board I looked at). I had a quick look and things may be quicker to resolve than I thought. Before I create a new version, I was wondering what the requirements on the BROM end are: Without changes to setjmp/longjmp, I can currently preserve "r4-r11, lr, sp” (i.e "r1-r3, ip" will be clobbered). If the BROM need any of these additional registers preserved (i.e. r1,r2,r3,ip): let me know and I will change setjmp/longjmp to be more conservative.