[{"id":1770607,"web_url":"http://patchwork.ozlabs.org/comment/1770607/","msgid":"<55b57a24-fb49-5a6b-6881-51c15d52fa3f@rock-chips.com>","list_archive_url":null,"date":"2017-09-19T02:06:20","subject":"Re: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace\n\tassembly-implementation with C-code","submitter":{"id":65124,"url":"http://patchwork.ozlabs.org/api/people/65124/","name":"Andy Yan","email":"andy.yan@rock-chips.com"},"content":"Hi Philipp:\n\n\nOn 2017年09月19日 02:18, Philipp Tomsich wrote:\n> Recent discussions confirmed (what the code always assumed): the\n> Rockchip BROM always enters U-Boot with the stack-pointer valid\n> (i.e. the U-Boot startup code is running off the BROM stack).\n>\n> We can thus replace the back-to-bootrom code (i.e. both the\n> save_boot_params and back_to_bootrom implementations) using C-code\n> based on setjmp/longjmp. The new implementation is already structured\n> to allow an easy drop-in of Andy's changes to enter download-mode when\n> returning to the BROM.\n>\n> This entails one minor tweak to asm/system.h, which only exported\n> the save_boot_params_ret prototype for ARMv7, but not for AArch64.\n>\n> For v2, we force bootrom.o to alway be emitted as A32 (not T32), so we\n> can safely call save_boot_params_ret().\n\n This still have a problem, because the setjmp implementation for \nARM32 platform has humb code when CONFIG_SYS_THUMB_BUILD is\nenabled, this is a default setting for most ARMv7 boards.\n#if CONFIG_IS_ENABLED(SYS_THUMB_BUILD)\n \".align 2\\n\"\n \"adr r0, jmp_target\\n\"\n \"add r0, r0, $1\\n\" // r0 stored the jump target address and with \nbit[0] = 1, this will trigger a thumb switch in longjmp with code \"bx r0\"\n#endif\n\nWhen I force the setjmp code go arm code path, I can back to bootrom \nsuccessfully, But I got a data abort exception in later. it seems it \nhappens when bootrom finished the uboot code\ncopy, when jump to sdram, I need a further debug.\n>\n> It also turned out that I had not caught the RK3188 in my earlier\n> series... and my luck being what it is, the RK3188 needed some extra\n> handholding to adapt to the new regime: instead of passing the context\n> address (for returning to the BROM) from the TPL to the SPL, the SPL\n> now returns to the TPL and the TPL then returns to the BROM.\n>\n> Changes in v2:\n> - [added in v2] chain back_to_bootrom calls for SPL, first returning\n> to the TPL (using the same mechanism) and further calling through\n> to the BROM from the TPL by invoking back_to_bootrom again\n> - adapt the RK3188 spl support file (that I had originally missed)\n>\n> Philipp Tomsich (5):\n> arm: make save_boot_params_ret prototype visible for AArch64\n> rockchip: back-to-bootrom: replace assembly-implementation with C-code\n> rockchip: back-to-bootrom: rk3188: chain from SPL via TPL to the BROM\n> rockchip: back-to-bootrom: allow passing a cmd to the bootrom\n> rockchip: back-to-bootrom: do not compile bootrom.o in thumb mode\n>\n> arch/arm/include/asm/arch-rockchip/bootrom.h | 30 +++++++++---\n> arch/arm/include/asm/system.h | 62 ++++++++++++-------------\n> arch/arm/mach-rockchip/Makefile | 10 +++-\n> arch/arm/mach-rockchip/bootrom.c | 54 +++++++++++++++++++++-\n> arch/arm/mach-rockchip/rk3036-board-spl.c | 2 +-\n> arch/arm/mach-rockchip/rk3188-board-spl.c | 14 +-----\n> arch/arm/mach-rockchip/rk3188-board-tpl.c | 19 ++++----\n> arch/arm/mach-rockchip/rk322x-board-spl.c | 2 +-\n> arch/arm/mach-rockchip/rk3288-board-spl.c | 4 +-\n> arch/arm/mach-rockchip/rk3368-board-tpl.c | 2 +-\n> arch/arm/mach-rockchip/rk3399-board-spl.c | 2 +-\n> arch/arm/mach-rockchip/save_boot_param.S | 69 ----------------------------\n> 12 files changed, 133 insertions(+), 137 deletions(-)\n> delete mode 100644 arch/arm/mach-rockchip/save_boot_param.S\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.denx.de\n\t(client-ip=81.169.180.215; helo=lists.denx.de;\n\tenvelope-from=u-boot-bounces@lists.denx.de;\n\treceiver=)","Received":["from lists.denx.de (dione.denx.de [81.169.180.215])\n\tby ozlabs.org (Postfix) with ESMTP id 3xx5pS55zcz9s3w\n\tfor ;\n\tTue, 19 Sep 2017 12:06:40 +1000 (AEST)","by lists.denx.de (Postfix, from userid 105)\n\tid 7AF6BC21DC1; Tue, 19 Sep 2017 02:06:35 +0000 (UTC)","from lists.denx.de (localhost [IPv6:::1])\n\tby lists.denx.de (Postfix) with ESMTP id 4E219C21C3F;\n\tTue, 19 Sep 2017 02:06:33 +0000 (UTC)","by lists.denx.de (Postfix, from userid 105)\n\tid D5B70C21C3F; Tue, 19 Sep 2017 02:06:31 +0000 (UTC)","from regular1.263xmail.com (regular1.263xmail.com [211.150.99.137])\n\tby lists.denx.de (Postfix) with ESMTPS id 35303C21C34\n\tfor ; Tue, 19 Sep 2017 02:06:30 +0000 (UTC)","from andy.yan?rock-chips.com (unknown [192.168.167.128])\n\tby regular1.263xmail.com (Postfix) with ESMTP id A13E0DB72;\n\tTue, 19 Sep 2017 10:06:25 +0800 (CST)","from [172.16.12.133] (localhost [127.0.0.1])\n\tby smtp.263.net (Postfix) with ESMTPA id 6F5E040D;\n\tTue, 19 Sep 2017 10:06:21 +0800 (CST)","from [172.16.12.133] (unknown [58.22.7.114])\n\tby smtp.263.net (Postfix) whith ESMTP id 21323RLZTK8;\n\tTue, 19 Sep 2017 10:06:24 +0800 (CST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de","X-Spam-Level":"*","X-Spam-Status":"No, score=1.9 required=5.0 tests=RCVD_IN_BL_SPAMCOP_NET,\n\tRCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_WEB autolearn=no autolearn_force=no\n\tversion=3.4.0","X-263anti-spam":"KSV:0;","X-MAIL-GRAY":"0","X-MAIL-DELIVERY":"1","X-KSVirus-check":"0","X-ABS-CHECKED":"4","X-RL-SENDER":"andy.yan@rock-chips.com","X-FST-TO":"b18965@freescale.com","X-SENDER-IP":"58.22.7.114","X-LOGIN-NAME":"andy.yan@rock-chips.com","X-UNIQUE-TAG":"","X-ATTACHMENT-NUM":"0","X-SENDER":"yxj@rock-chips.com","X-DNS-TYPE":"0","To":"Philipp Tomsich ,\n\tu-boot@lists.denx.de","References":"<1505758708-29213-1-git-send-email-philipp.tomsich@theobroma-systems.com>","From":"Andy Yan ","Message-ID":"<55b57a24-fb49-5a6b-6881-51c15d52fa3f@rock-chips.com>","Date":"Tue, 19 Sep 2017 10:06:20 +0800","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<1505758708-29213-1-git-send-email-philipp.tomsich@theobroma-systems.com>","Content-Language":"en-US","Cc":"Stephen Warren ,\n\tKlaus Goger ","Subject":"Re: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace\n\tassembly-implementation with C-code","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.18","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Transfer-Encoding":"base64","Content-Type":"text/plain; charset=\"utf-8\"; Format=\"flowed\"","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" "}},{"id":1770692,"web_url":"http://patchwork.ozlabs.org/comment/1770692/","msgid":"","list_archive_url":null,"date":"2017-09-19T07:19:45","subject":"Re: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace\n\tassembly-implementation with C-code","submitter":{"id":65124,"url":"http://patchwork.ozlabs.org/api/people/65124/","name":"Andy Yan","email":"andy.yan@rock-chips.com"},"content":"Hi Philipp:\n\n\nOn 2017年09月19日 10:06, Andy Yan wrote:\n> Hi Philipp:\n>\n>\n> On 2017年09月19日 02:18, Philipp Tomsich wrote:\n>> Recent discussions confirmed (what the code always assumed): the\n>> Rockchip BROM always enters U-Boot with the stack-pointer valid\n>> (i.e. the U-Boot startup code is running off the BROM stack).\n>>\n>> We can thus replace the back-to-bootrom code (i.e. both the\n>> save_boot_params and back_to_bootrom implementations) using C-code\n>> based on setjmp/longjmp. The new implementation is already structured\n>> to allow an easy drop-in of Andy's changes to enter download-mode when\n>> returning to the BROM.\n>>\n>> This entails one minor tweak to asm/system.h, which only exported\n>> the save_boot_params_ret prototype for ARMv7, but not for AArch64.\n>>\n>> For v2, we force bootrom.o to alway be emitted as A32 (not T32), so we\n>> can safely call save_boot_params_ret().\n>\n> This still have a problem, because the setjmp implementation for \n> ARM32 platform has humb code when CONFIG_SYS_THUMB_BUILD is\n> enabled, this is a default setting for most ARMv7 boards.\n> #if CONFIG_IS_ENABLED(SYS_THUMB_BUILD)\n> \".align 2\\n\"\n> \"adr r0, jmp_target\\n\"\n> \"add r0, r0, $1\\n\" // r0 stored the jump target address and with \n> bit[0] = 1, this will trigger a thumb switch in longjmp with code \"bx r0\"\n> #endif\n>\n> When I force the setjmp code go arm code path, I can back to bootrom \n> successfully, But I got a data abort exception in later. it seems it \n> happens when bootrom finished the uboot code\n> copy, when jump to sdram, I need a further debug.\n\nI found that r9 also need to be preserved, it seems that it hold the \nsdram base.\n>>\n>> It also turned out that I had not caught the RK3188 in my earlier\n>> series... and my luck being what it is, the RK3188 needed some extra\n>> handholding to adapt to the new regime: instead of passing the context\n>> address (for returning to the BROM) from the TPL to the SPL, the SPL\n>> now returns to the TPL and the TPL then returns to the BROM.\n>>\n>> Changes in v2:\n>> - [added in v2] chain back_to_bootrom calls for SPL, first returning\n>> to the TPL (using the same mechanism) and further calling through\n>> to the BROM from the TPL by invoking back_to_bootrom again\n>> - adapt the RK3188 spl support file (that I had originally missed)\n>>\n>> Philipp Tomsich (5):\n>> arm: make save_boot_params_ret prototype visible for AArch64\n>> rockchip: back-to-bootrom: replace assembly-implementation with \n>> C-code\n>> rockchip: back-to-bootrom: rk3188: chain from SPL via TPL to the BROM\n>> rockchip: back-to-bootrom: allow passing a cmd to the bootrom\n>> rockchip: back-to-bootrom: do not compile bootrom.o in thumb mode\n>>\n>> arch/arm/include/asm/arch-rockchip/bootrom.h | 30 +++++++++---\n>> arch/arm/include/asm/system.h | 62 \n>> ++++++++++++-------------\n>> arch/arm/mach-rockchip/Makefile | 10 +++-\n>> arch/arm/mach-rockchip/bootrom.c | 54 \n>> +++++++++++++++++++++-\n>> arch/arm/mach-rockchip/rk3036-board-spl.c | 2 +-\n>> arch/arm/mach-rockchip/rk3188-board-spl.c | 14 +-----\n>> arch/arm/mach-rockchip/rk3188-board-tpl.c | 19 ++++----\n>> arch/arm/mach-rockchip/rk322x-board-spl.c | 2 +-\n>> arch/arm/mach-rockchip/rk3288-board-spl.c | 4 +-\n>> arch/arm/mach-rockchip/rk3368-board-tpl.c | 2 +-\n>> arch/arm/mach-rockchip/rk3399-board-spl.c | 2 +-\n>> arch/arm/mach-rockchip/save_boot_param.S | 69 \n>> ----------------------------\n>> 12 files changed, 133 insertions(+), 137 deletions(-)\n>> delete mode 100644 arch/arm/mach-rockchip/save_boot_param.S\n>>\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.denx.de\n\t(client-ip=81.169.180.215; helo=lists.denx.de;\n\tenvelope-from=u-boot-bounces@lists.denx.de;\n\treceiver=)","Received":["from lists.denx.de (dione.denx.de [81.169.180.215])\n\tby ozlabs.org (Postfix) with ESMTP id 3xxDmZ6p6Bz9sBZ\n\tfor ;\n\tTue, 19 Sep 2017 17:20:29 +1000 (AEST)","by lists.denx.de (Postfix, from userid 105)\n\tid 844D8C21EA8; Tue, 19 Sep 2017 07:20:23 +0000 (UTC)","from lists.denx.de (localhost [IPv6:::1])\n\tby lists.denx.de (Postfix) with ESMTP id E72A0C21D64;\n\tTue, 19 Sep 2017 07:20:20 +0000 (UTC)","by lists.denx.de (Postfix, from userid 105)\n\tid 76471C21D64; Tue, 19 Sep 2017 07:20:20 +0000 (UTC)","from regular2.263xmail.com (regular2.263xmail.com [211.157.152.3])\n\tby lists.denx.de (Postfix) with ESMTPS id 1690AC21D57\n\tfor ; Tue, 19 Sep 2017 07:20:19 +0000 (UTC)","from regular1.263xmail.com (unknown [192.168.165.111])\n\tby regular2.263xmail.com (Postfix) with ESMTP id 7C7A91E927\n\tfor ; Tue, 19 Sep 2017 15:20:15 +0800 (CST)","from andy.yan?rock-chips.com (unknown [192.168.167.131])\n\tby regular1.263xmail.com (Postfix) with ESMTP id 02B829E;\n\tTue, 19 Sep 2017 15:19:51 +0800 (CST)","from [172.16.12.133] (localhost [127.0.0.1])\n\tby smtp.263.net (Postfix) with ESMTPA id 4B2C73B4;\n\tTue, 19 Sep 2017 15:19:46 +0800 (CST)","from [172.16.12.133] (unknown [58.22.7.114])\n\tby smtp.263.net (Postfix) whith ESMTP id 7309AL3M4Z;\n\tTue, 19 Sep 2017 15:19:49 +0800 (CST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de","X-Spam-Level":"*","X-Spam-Status":"No, score=1.9 required=5.0 tests=RCVD_IN_BL_SPAMCOP_NET,\n\tRCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_WEB autolearn=no autolearn_force=no\n\tversion=3.4.0","X-263anti-spam":"KSV:0;","X-MAIL-GRAY":"0","X-MAIL-DELIVERY":"1","X-KSVirus-check":"0","X-ABS-CHECKED":"4","X-RL-SENDER":"andy.yan@rock-chips.com","X-FST-TO":"b18965@freescale.com","X-SENDER-IP":"58.22.7.114","X-LOGIN-NAME":"andy.yan@rock-chips.com","X-UNIQUE-TAG":"","X-ATTACHMENT-NUM":"0","X-SENDER":"yxj@rock-chips.com","X-DNS-TYPE":"0","From":"Andy Yan ","To":"Philipp Tomsich ,\n\tu-boot@lists.denx.de","References":"<1505758708-29213-1-git-send-email-philipp.tomsich@theobroma-systems.com>\n\t<55b57a24-fb49-5a6b-6881-51c15d52fa3f@rock-chips.com>","Message-ID":"","Date":"Tue, 19 Sep 2017 15:19:45 +0800","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<55b57a24-fb49-5a6b-6881-51c15d52fa3f@rock-chips.com>","Content-Language":"en-US","Cc":"Stephen Warren ,\n\tKlaus Goger ","Subject":"Re: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace\n\tassembly-implementation with C-code","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.18","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Transfer-Encoding":"base64","Content-Type":"text/plain; charset=\"utf-8\"; Format=\"flowed\"","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" "}},{"id":1770772,"web_url":"http://patchwork.ozlabs.org/comment/1770772/","msgid":"<93C673C2-A070-474F-A21E-674F178DF1BA@theobroma-systems.com>","list_archive_url":null,"date":"2017-09-19T09:10:29","subject":"Re: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace\n\tassembly-implementation with C-code","submitter":{"id":53488,"url":"http://patchwork.ozlabs.org/api/people/53488/","name":"Philipp Tomsich","email":"philipp.tomsich@theobroma-systems.com"},"content":"Andy,\n\n> On 19 Sep 2017, at 09:19, Andy Yan wrote:\n> \n> Hi Philipp:\n> \n> \n> On 2017年09月19日 10:06, Andy Yan wrote:\n>> Hi Philipp:\n>> \n>> \n>> On 2017年09月19日 02:18, Philipp Tomsich wrote:\n>>> Recent discussions confirmed (what the code always assumed): the\n>>> Rockchip BROM always enters U-Boot with the stack-pointer valid\n>>> (i.e. the U-Boot startup code is running off the BROM stack).\n>>> \n>>> We can thus replace the back-to-bootrom code (i.e. both the\n>>> save_boot_params and back_to_bootrom implementations) using C-code\n>>> based on setjmp/longjmp. The new implementation is already structured\n>>> to allow an easy drop-in of Andy's changes to enter download-mode when\n>>> returning to the BROM.\n>>> \n>>> This entails one minor tweak to asm/system.h, which only exported\n>>> the save_boot_params_ret prototype for ARMv7, but not for AArch64.\n>>> \n>>> For v2, we force bootrom.o to alway be emitted as A32 (not T32), so we\n>>> can safely call save_boot_params_ret().\n>> \n>> This still have a problem, because the setjmp implementation for ARM32 platform has humb code when CONFIG_SYS_THUMB_BUILD is\n>> enabled, this is a default setting for most ARMv7 boards.\n>> #if CONFIG_IS_ENABLED(SYS_THUMB_BUILD)\n>> \".align 2\\n\"\n>> \"adr r0, jmp_target\\n\"\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\"\n>> #endif\n>> \n>> 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\n>> copy, when jump to sdram, I need a further debug.\n> \n> I found that r9 also need to be preserved, it seems that it hold the sdram base.\n\nThanks for testing and debugging: this is invaluable support, as I only have AArch64 boards to test.\n\nThe r9 issue will be easy enough to resolve.\nHowever, it looks like I will need more work on setjmp/longjmp to make this safe both for T32 and A32.\nPlus: 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).\n\nMight be tomorrow or Thursday until I can provide an new version.\n\nRegards,\nPhilipp.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.denx.de\n\t(client-ip=81.169.180.215; helo=lists.denx.de;\n\tenvelope-from=u-boot-bounces@lists.denx.de;\n\treceiver=)","Received":["from lists.denx.de (dione.denx.de [81.169.180.215])\n\tby ozlabs.org (Postfix) with ESMTP id 3xxHCk0fpHz9sMN\n\tfor ;\n\tTue, 19 Sep 2017 19:10:42 +1000 (AEST)","by lists.denx.de (Postfix, from userid 105)\n\tid BFDB7C21E00; Tue, 19 Sep 2017 09:10:37 +0000 (UTC)","from lists.denx.de (localhost [IPv6:::1])\n\tby lists.denx.de (Postfix) with ESMTP id EBAEFC21D70;\n\tTue, 19 Sep 2017 09:10:34 +0000 (UTC)","by lists.denx.de (Postfix, from userid 105)\n\tid 78E30C21D70; Tue, 19 Sep 2017 09:10:33 +0000 (UTC)","from mail.theobroma-systems.com (vegas.theobroma-systems.com\n\t[144.76.126.164])\n\tby lists.denx.de (Postfix) with ESMTPS id 2E647C21D55\n\tfor ; Tue, 19 Sep 2017 09:10:33 +0000 (UTC)","from 89-104-28-141.customer.bnet.at ([89.104.28.141]:56782\n\thelo=[192.168.2.129]) by mail.theobroma-systems.com with esmtpsa\n\t(TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80)\n\t(envelope-from )\n\tid 1duEY2-0006zZ-Bw; Tue, 19 Sep 2017 11:10:30 +0200"],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de","X-Spam-Level":"*","X-Spam-Status":"No, score=1.0 required=5.0 tests=HK_NAME_DR autolearn=no\n\tautolearn_force=no version=3.4.0","From":"\"Dr. Philipp Tomsich\" ","Message-Id":"<93C673C2-A070-474F-A21E-674F178DF1BA@theobroma-systems.com>","Mime-Version":"1.0 (Mac OS X Mail 10.3 \\(3273\\))","Date":"Tue, 19 Sep 2017 11:10:29 +0200","In-Reply-To":"","To":"Andy Yan ","References":"<1505758708-29213-1-git-send-email-philipp.tomsich@theobroma-systems.com>\n\t<55b57a24-fb49-5a6b-6881-51c15d52fa3f@rock-chips.com>\n\t","X-Mailer":"Apple Mail (2.3273)","X-Content-Filtered-By":"Mailman/MimeDel 2.1.18","Cc":"Stephen Warren ,\n\tU-Boot Mailing List ,\n\tKlaus Goger ","Subject":"Re: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace\n\tassembly-implementation with C-code","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.18","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" "}},{"id":1770775,"web_url":"http://patchwork.ozlabs.org/comment/1770775/","msgid":"<10247037.pJkLLH4ko2@diego>","list_archive_url":null,"date":"2017-09-19T09:12:50","subject":"Re: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace\n\tassembly-implementation with C-code","submitter":{"id":10645,"url":"http://patchwork.ozlabs.org/api/people/10645/","name":"Heiko Stuebner","email":"heiko@sntech.de"},"content":"Am Dienstag, 19. September 2017, 11:10:29 CEST schrieb Dr. Philipp Tomsich:\n> Andy,\n> \n> > On 19 Sep 2017, at 09:19, Andy Yan wrote:\n> > \n> > Hi Philipp:\n> > \n> > On 2017年09月19日 10:06, Andy Yan wrote:\n> >> Hi Philipp:\n> >> \n> >> On 2017年09月19日 02:18, Philipp Tomsich wrote:\n> >>> Recent discussions confirmed (what the code always assumed): the\n> >>> Rockchip BROM always enters U-Boot with the stack-pointer valid\n> >>> (i.e. the U-Boot startup code is running off the BROM stack).\n> >>> \n> >>> We can thus replace the back-to-bootrom code (i.e. both the\n> >>> save_boot_params and back_to_bootrom implementations) using C-code\n> >>> based on setjmp/longjmp. The new implementation is already structured\n> >>> to allow an easy drop-in of Andy's changes to enter download-mode when\n> >>> returning to the BROM.\n> >>> \n> >>> This entails one minor tweak to asm/system.h, which only exported\n> >>> the save_boot_params_ret prototype for ARMv7, but not for AArch64.\n> >>> \n> >>> For v2, we force bootrom.o to alway be emitted as A32 (not T32), so we\n> >>> can safely call save_boot_params_ret().\n> >>> \n> >> This still have a problem, because the setjmp implementation for\n> >> ARM32 platform has humb code when CONFIG_SYS_THUMB_BUILD is>> \n> >> enabled, this is a default setting for most ARMv7 boards.\n> >> #if CONFIG_IS_ENABLED(SYS_THUMB_BUILD)\n> >> \".align 2\\n\"\n> >> \"adr r0, jmp_target\\n\"\n> >> \"add r0, r0, $1\\n\" // r0 stored the jump target address and with bit[0]\n> >> = 1, this will trigger a thumb switch in longjmp with code \"bx r0\"\n> >> #endif\n> >> \n> >> When I force the setjmp code go arm code path, I can back to bootrom\n> >> successfully, But I got a data abort exception in later. it seems it\n> >> happens when bootrom finished the uboot code copy, when jump to sdram, I\n> >> need a further debug.\n> > \n> > I found that r9 also need to be preserved, it seems that it hold the sdram\n> > base.\n> Thanks for testing and debugging: this is invaluable support, as I only have\n> AArch64 boards to test.\n> \n> The r9 issue will be easy enough to resolve.\n> However, it looks like I will need more work on setjmp/longjmp to make this\n> safe both for T32 and A32. Plus: I need to figure out why this didn’t show\n> in my disassembly (I don’t remember whether it was a rk3188 or rk3288 board\n> I looked at).\n> \n> Might be tomorrow or Thursday until I can provide an new version.\n\nFrom this conversation, it looks to me that I should wait for that new\nversion for testing on rk3188, as it will likely show the same issues, right?\n\n\nHeiko","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.denx.de\n\t(client-ip=81.169.180.215; helo=lists.denx.de;\n\tenvelope-from=u-boot-bounces@lists.denx.de;\n\treceiver=)","Received":["from lists.denx.de (dione.denx.de [81.169.180.215])\n\tby ozlabs.org (Postfix) with ESMTP id 3xxHGT6KLsz9sBZ\n\tfor ;\n\tTue, 19 Sep 2017 19:13:05 +1000 (AEST)","by lists.denx.de (Postfix, from userid 105)\n\tid 9211BC21EC1; Tue, 19 Sep 2017 09:13:01 +0000 (UTC)","from lists.denx.de (localhost [IPv6:::1])\n\tby lists.denx.de (Postfix) with ESMTP id 36E9BC21D70;\n\tTue, 19 Sep 2017 09:12:59 +0000 (UTC)","by lists.denx.de (Postfix, from userid 105)\n\tid 891CEC21D70; Tue, 19 Sep 2017 09:12:57 +0000 (UTC)","from gloria.sntech.de (gloria.sntech.de [95.129.55.99])\n\tby lists.denx.de (Postfix) with ESMTPS id 49E9FC21D55\n\tfor ; Tue, 19 Sep 2017 09:12:57 +0000 (UTC)","from ip9234ad97.dynamic.kabel-deutschland.de ([146.52.173.151]\n\thelo=diego.localnet) by gloria.sntech.de with esmtpsa\n\t(TLS1.1:DHE_RSA_AES_256_CBC_SHA1:256)\n\t(Exim 4.80) (envelope-from )\n\tid 1duEaJ-0001oS-DX; Tue, 19 Sep 2017 11:12:51 +0200"],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE\n\tautolearn=unavailable autolearn_force=no version=3.4.0","From":"Heiko =?iso-8859-1?q?St=FCbner?= ","To":"\"Dr. Philipp Tomsich\" ","Date":"Tue, 19 Sep 2017 11:12:50 +0200","Message-ID":"<10247037.pJkLLH4ko2@diego>","User-Agent":"KMail/5.2.3 (Linux/4.11.0-1-amd64; KDE/5.28.0; x86_64; ; )","In-Reply-To":"<93C673C2-A070-474F-A21E-674F178DF1BA@theobroma-systems.com>","References":"<1505758708-29213-1-git-send-email-philipp.tomsich@theobroma-systems.com>\n\t\n\t<93C673C2-A070-474F-A21E-674F178DF1BA@theobroma-systems.com>","MIME-Version":"1.0","Cc":"Stephen Warren ,\n\tU-Boot Mailing List ,\n\tKlaus Goger ,\n\tAndy Yan ","Subject":"Re: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace\n\tassembly-implementation with C-code","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.18","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" "}},{"id":1770822,"web_url":"http://patchwork.ozlabs.org/comment/1770822/","msgid":"<291C798E-9B85-4258-96DF-CB27F35B684A@theobroma-systems.com>","list_archive_url":null,"date":"2017-09-19T10:16:02","subject":"Re: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace\n\tassembly-implementation with C-code","submitter":{"id":53488,"url":"http://patchwork.ozlabs.org/api/people/53488/","name":"Philipp Tomsich","email":"philipp.tomsich@theobroma-systems.com"},"content":"> On 19 Sep 2017, at 11:12, Heiko Stübner wrote:\n> \n> Am Dienstag, 19. September 2017, 11:10:29 CEST schrieb Dr. Philipp Tomsich:\n>> Andy,\n>> \n>>> On 19 Sep 2017, at 09:19, Andy Yan wrote:\n>>> \n>>> Hi Philipp:\n>>> \n>>> On 2017年09月19日 10:06, Andy Yan wrote:\n>>>> Hi Philipp:\n>>>> \n>>>> On 2017年09月19日 02:18, Philipp Tomsich wrote:\n>>>>> Recent discussions confirmed (what the code always assumed): the\n>>>>> Rockchip BROM always enters U-Boot with the stack-pointer valid\n>>>>> (i.e. the U-Boot startup code is running off the BROM stack).\n>>>>> \n>>>>> We can thus replace the back-to-bootrom code (i.e. both the\n>>>>> save_boot_params and back_to_bootrom implementations) using C-code\n>>>>> based on setjmp/longjmp. The new implementation is already structured\n>>>>> to allow an easy drop-in of Andy's changes to enter download-mode when\n>>>>> returning to the BROM.\n>>>>> \n>>>>> This entails one minor tweak to asm/system.h, which only exported\n>>>>> the save_boot_params_ret prototype for ARMv7, but not for AArch64.\n>>>>> \n>>>>> For v2, we force bootrom.o to alway be emitted as A32 (not T32), so we\n>>>>> can safely call save_boot_params_ret().\n>>>>> \n>>>> This still have a problem, because the setjmp implementation for\n>>>> ARM32 platform has humb code when CONFIG_SYS_THUMB_BUILD is>> \n>>>> enabled, this is a default setting for most ARMv7 boards.\n>>>> #if CONFIG_IS_ENABLED(SYS_THUMB_BUILD)\n>>>> \".align 2\\n\"\n>>>> \"adr r0, jmp_target\\n\"\n>>>> \"add r0, r0, $1\\n\" // r0 stored the jump target address and with bit[0]\n>>>> = 1, this will trigger a thumb switch in longjmp with code \"bx r0\"\n>>>> #endif\n>>>> \n>>>> When I force the setjmp code go arm code path, I can back to bootrom\n>>>> successfully, But I got a data abort exception in later. it seems it\n>>>> happens when bootrom finished the uboot code copy, when jump to sdram, I\n>>>> need a further debug.\n>>> \n>>> I found that r9 also need to be preserved, it seems that it hold the sdram\n>>> base.\n>> Thanks for testing and debugging: this is invaluable support, as I only have\n>> AArch64 boards to test.\n>> \n>> The r9 issue will be easy enough to resolve.\n>> However, it looks like I will need more work on setjmp/longjmp to make this\n>> safe both for T32 and A32. Plus: I need to figure out why this didn’t show\n>> in my disassembly (I don’t remember whether it was a rk3188 or rk3288 board\n>> I looked at).\n>> \n>> Might be tomorrow or Thursday until I can provide an new version.\n> \n> From this conversation, it looks to me that I should wait for that new\n> version for testing on rk3188, as it will likely show the same issues, right?\n\nYes.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.denx.de\n\t(client-ip=81.169.180.215; helo=lists.denx.de;\n\tenvelope-from=u-boot-bounces@lists.denx.de;\n\treceiver=)","Received":["from lists.denx.de (dione.denx.de [81.169.180.215])\n\tby ozlabs.org (Postfix) with ESMTP id 3xxJfy1JbMz9ryr\n\tfor ;\n\tTue, 19 Sep 2017 20:15:54 +1000 (AEST)","by lists.denx.de (Postfix, from userid 105)\n\tid E3127C21EF4; Tue, 19 Sep 2017 10:15:47 +0000 (UTC)","from lists.denx.de (localhost [IPv6:::1])\n\tby lists.denx.de (Postfix) with ESMTP id C6882C21D70;\n\tTue, 19 Sep 2017 10:15:44 +0000 (UTC)","by lists.denx.de (Postfix, from userid 105)\n\tid 96BDCC21D70; Tue, 19 Sep 2017 10:15:42 +0000 (UTC)","from mail.theobroma-systems.com (vegas.theobroma-systems.com\n\t[144.76.126.164])\n\tby lists.denx.de (Postfix) with ESMTPS id A13F9C21C5C\n\tfor ; Tue, 19 Sep 2017 10:15:40 +0000 (UTC)","from [86.59.122.178] (port=56874 helo=[10.4.9.36])\n\tby mail.theobroma-systems.com with esmtpsa\n\t(TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80)\n\t(envelope-from )\n\tid 1duFZ3-0000bK-1K; Tue, 19 Sep 2017 12:15:37 +0200"],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de","X-Spam-Level":"*","X-Spam-Status":"No, score=1.0 required=5.0 tests=HK_NAME_DR autolearn=no\n\tautolearn_force=no version=3.4.0","From":"\"Dr. Philipp Tomsich\" ","Message-Id":"<291C798E-9B85-4258-96DF-CB27F35B684A@theobroma-systems.com>","Mime-Version":"1.0 (Mac OS X Mail 10.3 \\(3273\\))","Date":"Tue, 19 Sep 2017 12:16:02 +0200","In-Reply-To":"<10247037.pJkLLH4ko2@diego>","To":"=?utf-8?q?Heiko_St=C3=BCbner?= ","References":"<1505758708-29213-1-git-send-email-philipp.tomsich@theobroma-systems.com>\n\t\n\t<93C673C2-A070-474F-A21E-674F178DF1BA@theobroma-systems.com>\n\t<10247037.pJkLLH4ko2@diego>","X-Mailer":"Apple Mail (2.3273)","X-Content-Filtered-By":"Mailman/MimeDel 2.1.18","Cc":"Stephen Warren ,\n\tU-Boot Mailing List ,\n\tKlaus Goger ,\n\tAndy Yan ","Subject":"Re: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace\n\tassembly-implementation with C-code","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.18","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" "}},{"id":1770967,"web_url":"http://patchwork.ozlabs.org/comment/1770967/","msgid":"<2D26637D-39A8-4982-9022-E7D46D521D4A@theobroma-systems.com>","list_archive_url":null,"date":"2017-09-19T12:45:17","subject":"Re: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace\n\tassembly-implementation with C-code","submitter":{"id":53488,"url":"http://patchwork.ozlabs.org/api/people/53488/","name":"Philipp Tomsich","email":"philipp.tomsich@theobroma-systems.com"},"content":"Andy,\n\n> On 19 Sep 2017, at 11:10, Dr. Philipp Tomsich wrote:\n> \n> Andy,\n> \n>> On 19 Sep 2017, at 09:19, Andy Yan wrote:\n>> \n>> Hi Philipp:\n>> \n>> \n>> On 2017年09月19日 10:06, Andy Yan wrote:\n>>> Hi Philipp:\n>>> \n>>> \n>>> On 2017年09月19日 02:18, Philipp Tomsich wrote:\n>>>> Recent discussions confirmed (what the code always assumed): the\n>>>> Rockchip BROM always enters U-Boot with the stack-pointer valid\n>>>> (i.e. the U-Boot startup code is running off the BROM stack).\n>>>> \n>>>> We can thus replace the back-to-bootrom code (i.e. both the\n>>>> save_boot_params and back_to_bootrom implementations) using C-code\n>>>> based on setjmp/longjmp. The new implementation is already structured\n>>>> to allow an easy drop-in of Andy's changes to enter download-mode when\n>>>> returning to the BROM.\n>>>> \n>>>> This entails one minor tweak to asm/system.h, which only exported\n>>>> the save_boot_params_ret prototype for ARMv7, but not for AArch64.\n>>>> \n>>>> For v2, we force bootrom.o to alway be emitted as A32 (not T32), so we\n>>>> can safely call save_boot_params_ret().\n>>> \n>>> This still have a problem, because the setjmp implementation for ARM32 platform has humb code when CONFIG_SYS_THUMB_BUILD is\n>>> enabled, this is a default setting for most ARMv7 boards.\n>>> #if CONFIG_IS_ENABLED(SYS_THUMB_BUILD)\n>>> \".align 2\\n\"\n>>> \"adr r0, jmp_target\\n\"\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\"\n>>> #endif\n>>> \n>>> 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\n>>> copy, when jump to sdram, I need a further debug.\n>> \n>> I found that r9 also need to be preserved, it seems that it hold the sdram base.\n> \n> Thanks for testing and debugging: this is invaluable support, as I only have AArch64 boards to test.\n> \n> The r9 issue will be easy enough to resolve.\n> However, it looks like I will need more work on setjmp/longjmp to make this safe both for T32 and A32.\n> 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).\n\nI had a quick look and things may be quicker to resolve than I thought.\nBefore I create a new version, I was wondering what the requirements on the BROM end are:\nWithout changes to setjmp/longjmp, I can currently preserve \"r4-r11, lr, sp” (i.e \"r1-r3, ip\" will be clobbered).\nIf 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.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.denx.de\n\t(client-ip=81.169.180.215; helo=lists.denx.de;\n\tenvelope-from=u-boot-bounces@lists.denx.de;\n\treceiver=)","Received":["from lists.denx.de (dione.denx.de [81.169.180.215])\n\tby ozlabs.org (Postfix) with ESMTP id 3xxMzf1GDdz9s7F\n\tfor ;\n\tTue, 19 Sep 2017 22:45:32 +1000 (AEST)","by lists.denx.de (Postfix, from userid 105)\n\tid E126AC21F39; Tue, 19 Sep 2017 12:45:26 +0000 (UTC)","from lists.denx.de (localhost [IPv6:::1])\n\tby lists.denx.de (Postfix) with ESMTP id 6200AC21E3D;\n\tTue, 19 Sep 2017 12:45:24 +0000 (UTC)","by lists.denx.de (Postfix, from userid 105)\n\tid 0BB4DC21E3D; Tue, 19 Sep 2017 12:45:22 +0000 (UTC)","from mail.theobroma-systems.com (vegas.theobroma-systems.com\n\t[144.76.126.164])\n\tby lists.denx.de (Postfix) with ESMTPS id AE878C21DA1\n\tfor ; Tue, 19 Sep 2017 12:45:22 +0000 (UTC)","from [86.59.122.178] (port=58200 helo=[10.4.9.36])\n\tby mail.theobroma-systems.com with esmtpsa\n\t(TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80)\n\t(envelope-from )\n\tid 1duHtu-0005C2-LE; Tue, 19 Sep 2017 14:45:18 +0200"],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de","X-Spam-Level":"*","X-Spam-Status":"No, score=1.0 required=5.0 tests=HK_NAME_DR autolearn=no\n\tautolearn_force=no version=3.4.0","From":"\"Dr. Philipp Tomsich\" ","Message-Id":"<2D26637D-39A8-4982-9022-E7D46D521D4A@theobroma-systems.com>","Mime-Version":"1.0 (Mac OS X Mail 10.3 \\(3273\\))","Date":"Tue, 19 Sep 2017 14:45:17 +0200","In-Reply-To":"<93C673C2-A070-474F-A21E-674F178DF1BA@theobroma-systems.com>","To":"Andy Yan ","References":"<1505758708-29213-1-git-send-email-philipp.tomsich@theobroma-systems.com>\n\t<55b57a24-fb49-5a6b-6881-51c15d52fa3f@rock-chips.com>\n\t\n\t<93C673C2-A070-474F-A21E-674F178DF1BA@theobroma-systems.com>","X-Mailer":"Apple Mail (2.3273)","X-Content-Filtered-By":"Mailman/MimeDel 2.1.18","Cc":"U-Boot Mailing List ,\n\tKlaus Goger ,\n\tStephen Warren ","Subject":"Re: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace\n\tassembly-implementation with C-code","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.18","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" "}},{"id":1771496,"web_url":"http://patchwork.ozlabs.org/comment/1771496/","msgid":"","list_archive_url":null,"date":"2017-09-20T01:51:51","subject":"Re: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace\n\tassembly-implementation with C-code","submitter":{"id":65124,"url":"http://patchwork.ozlabs.org/api/people/65124/","name":"Andy Yan","email":"andy.yan@rock-chips.com"},"content":"Hi Philipp:\n\n\nOn 2017年09月19日 20:45, Dr. Philipp Tomsich wrote:\n> Andy,\n>\n>> On 19 Sep 2017, at 11:10, Dr. Philipp Tomsich \n>> > > wrote:\n>>\n>> Andy,\n>>\n>>> On 19 Sep 2017, at 09:19, Andy Yan >> > wrote:\n>>>\n>>> Hi Philipp:\n>>>\n>>>\n>>> On 2017年09月19日 10:06, Andy Yan wrote:\n>>>> Hi Philipp:\n>>>>\n>>>>\n>>>> On 2017年09月19日 02:18, Philipp Tomsich wrote:\n>>>>> Recent discussions confirmed (what the code always assumed): the\n>>>>> Rockchip BROM always enters U-Boot with the stack-pointer valid\n>>>>> (i.e. the U-Boot startup code is running off the BROM stack).\n>>>>>\n>>>>> We can thus replace the back-to-bootrom code (i.e. both the\n>>>>> save_boot_params and back_to_bootrom implementations) using C-code\n>>>>> based on setjmp/longjmp. The new implementation is already structured\n>>>>> to allow an easy drop-in of Andy's changes to enter download-mode when\n>>>>> returning to the BROM.\n>>>>>\n>>>>> This entails one minor tweak to asm/system.h, which only exported\n>>>>> the save_boot_params_ret prototype for ARMv7, but not for AArch64.\n>>>>>\n>>>>> For v2, we force bootrom.o to alway be emitted as A32 (not T32), so we\n>>>>> can safely call save_boot_params_ret().\n>>>>\n>>>> This still have a problem, because the setjmp implementation for \n>>>> ARM32 platform has humb code when CONFIG_SYS_THUMB_BUILD is\n>>>> enabled, this is a default setting for most ARMv7 boards.\n>>>> #if CONFIG_IS_ENABLED(SYS_THUMB_BUILD)\n>>>> \".align 2\\n\"\n>>>> \"adr r0, jmp_target\\n\"\n>>>> \"add r0, r0, $1\\n\" // r0 stored the jump target address and with \n>>>> bit[0] = 1, this will trigger a thumb switch in longjmp with code \n>>>> \"bx r0\"\n>>>> #endif\n>>>>\n>>>> When I force the setjmp code go arm code path, I can back to \n>>>> bootrom successfully, But I got a data abort exception in later. it \n>>>> seems it happens when bootrom finished the uboot code\n>>>> copy, when jump to sdram, I need a further debug.\n>>>\n>>> I found that r9 also need to be preserved, it seems that it hold the \n>>> sdram base.\n>>\n>> Thanks for testing and debugging: this is invaluable support, as I \n>> only have AArch64 boards to test.\n>>\n>> The r9 issue will be easy enough to resolve.\n>> However, it looks like I will need more work on setjmp/longjmp to \n>> make this safe both for T32 and A32.\n>> Plus: I need to figure out why this didn’t show in my disassembly (I \n>> don’t remember whether it was a rk3188 or rk3288 board I looked at).\n>\n> I had a quick look and things may be quicker to resolve than I thought.\n> Before I create a new version, I was wondering what the requirements \n> on the BROM end are:\n> Without changes to setjmp/longjmp, I can currently preserve \"r4-r11, \n> lr, sp” (i.e \"r1-r3, ip\" will be clobbered).\n> If the BROM need any of these additional registers preserved (i.e. \n> r1,r2,r3,ip): let me know and I will change setjmp/longjmp to be more \n> conservative.\n>\n\n The BROM code that call TPL/SPL also write in C like bellow:\n fp = (pFunc)(ptr + 4);\n ret = (*fp)(); // fp point to TPL/SPL first address\n if (ret)\n return;\n ptr = (uint8*)SDRAM_ADDR;\n\nSo the code doesn't touch the register directly, It's the compile stored \nSDRAM_ADDR in r9(I saw it on rk3036 platform).","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.denx.de\n\t(client-ip=81.169.180.215; helo=lists.denx.de;\n\tenvelope-from=u-boot-bounces@lists.denx.de;\n\treceiver=)","Received":["from lists.denx.de (dione.denx.de [81.169.180.215])\n\tby ozlabs.org (Postfix) with ESMTP id 3xxjRF2cTnz9sPt\n\tfor ;\n\tWed, 20 Sep 2017 11:52:09 +1000 (AEST)","by lists.denx.de (Postfix, from userid 105)\n\tid 249B5C21C34; Wed, 20 Sep 2017 01:52:06 +0000 (UTC)","from lists.denx.de (localhost [IPv6:::1])\n\tby lists.denx.de (Postfix) with ESMTP id D70AFC21C35;\n\tWed, 20 Sep 2017 01:52:00 +0000 (UTC)","by lists.denx.de (Postfix, from userid 105)\n\tid 47821C21C35; Wed, 20 Sep 2017 01:51:59 +0000 (UTC)","from regular1.263xmail.com (regular1.263xmail.com [211.150.99.132])\n\tby lists.denx.de (Postfix) with ESMTPS id A5F8CC21C34\n\tfor ; Wed, 20 Sep 2017 01:51:57 +0000 (UTC)","from andy.yan?rock-chips.com (unknown [192.168.167.130])\n\tby regular1.263xmail.com (Postfix) with ESMTP id 68EB29386;\n\tWed, 20 Sep 2017 09:51:53 +0800 (CST)","from [172.16.12.133] (localhost [127.0.0.1])\n\tby smtp.263.net (Postfix) with ESMTPA id 7AD523CC;\n\tWed, 20 Sep 2017 09:51:52 +0800 (CST)","from [172.16.12.133] (unknown [58.22.7.114])\n\tby smtp.263.net (Postfix) whith ESMTP id 20512TO9I55;\n\tWed, 20 Sep 2017 09:51:53 +0800 (CST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=0.6 required=5.0 tests=RCVD_IN_DNSWL_NONE,\n\tRCVD_IN_MSPIKE_H2,RCVD_IN_SORBS_WEB,T_FRT_BELOW2 autolearn=no\n\tautolearn_force=no version=3.4.0","X-263anti-spam":"KSV:0;BIG:0;","X-MAIL-GRAY":"0","X-MAIL-DELIVERY":"1","X-KSVirus-check":"0","X-ADDR-CHECKED4":"1","X-ABS-CHECKED":"1","X-SKE-CHECKED":"1","X-ANTISPAM-LEVEL":"2","X-RL-SENDER":"andy.yan@rock-chips.com","X-FST-TO":"klaus.goger@theobroma-systems.com","X-SENDER-IP":"58.22.7.114","X-LOGIN-NAME":"andy.yan@rock-chips.com","X-UNIQUE-TAG":"","X-ATTACHMENT-NUM":"0","X-SENDER":"yxj@rock-chips.com","X-DNS-TYPE":"0","To":"\"Dr. Philipp Tomsich\" ","References":"<1505758708-29213-1-git-send-email-philipp.tomsich@theobroma-systems.com>\n\t<55b57a24-fb49-5a6b-6881-51c15d52fa3f@rock-chips.com>\n\t\n\t<93C673C2-A070-474F-A21E-674F178DF1BA@theobroma-systems.com>\n\t<2D26637D-39A8-4982-9022-E7D46D521D4A@theobroma-systems.com>","From":"Andy Yan ","Message-ID":"","Date":"Wed, 20 Sep 2017 09:51:51 +0800","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<2D26637D-39A8-4982-9022-E7D46D521D4A@theobroma-systems.com>","Content-Language":"en-US","X-Content-Filtered-By":"Mailman/MimeDel 2.1.18","Cc":"U-Boot Mailing List ,\n\tKlaus Goger ,\n\tStephen Warren ","Subject":"Re: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace\n\tassembly-implementation with C-code","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.18","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Transfer-Encoding":"base64","Content-Type":"text/plain; charset=\"utf-8\"; Format=\"flowed\"","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" "}},{"id":1772534,"web_url":"http://patchwork.ozlabs.org/comment/1772534/","msgid":"<8DE3D47B-2726-4102-827B-B3DEADB680DB@theobroma-systems.com>","list_archive_url":null,"date":"2017-09-21T08:26:19","subject":"Re: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace\n\tassembly-implementation with C-code","submitter":{"id":53488,"url":"http://patchwork.ozlabs.org/api/people/53488/","name":"Philipp Tomsich","email":"philipp.tomsich@theobroma-systems.com"},"content":"Heiko,\n\n> On 19 Sep 2017, at 12:16, Dr. Philipp Tomsich wrote:\n> \n>> \n>> On 19 Sep 2017, at 11:12, Heiko Stübner wrote:\n>> \n>> Am Dienstag, 19. September 2017, 11:10:29 CEST schrieb Dr. Philipp Tomsich:\n>>> Andy,\n>>> \n>>>> On 19 Sep 2017, at 09:19, Andy Yan wrote:\n>>>> \n>>>> Hi Philipp:\n>>>> \n>>>> On 2017年09月19日 10:06, Andy Yan wrote:\n>>>>> Hi Philipp:\n>>>>> \n>>>>> On 2017年09月19日 02:18, Philipp Tomsich wrote:\n>>>>>> Recent discussions confirmed (what the code always assumed): the\n>>>>>> Rockchip BROM always enters U-Boot with the stack-pointer valid\n>>>>>> (i.e. the U-Boot startup code is running off the BROM stack).\n>>>>>> \n>>>>>> We can thus replace the back-to-bootrom code (i.e. both the\n>>>>>> save_boot_params and back_to_bootrom implementations) using C-code\n>>>>>> based on setjmp/longjmp. The new implementation is already structured\n>>>>>> to allow an easy drop-in of Andy's changes to enter download-mode when\n>>>>>> returning to the BROM.\n>>>>>> \n>>>>>> This entails one minor tweak to asm/system.h, which only exported\n>>>>>> the save_boot_params_ret prototype for ARMv7, but not for AArch64.\n>>>>>> \n>>>>>> For v2, we force bootrom.o to alway be emitted as A32 (not T32), so we\n>>>>>> can safely call save_boot_params_ret().\n>>>>>> \n>>>>> This still have a problem, because the setjmp implementation for\n>>>>> ARM32 platform has humb code when CONFIG_SYS_THUMB_BUILD is>> \n>>>>> enabled, this is a default setting for most ARMv7 boards.\n>>>>> #if CONFIG_IS_ENABLED(SYS_THUMB_BUILD)\n>>>>> \".align 2\\n\"\n>>>>> \"adr r0, jmp_target\\n\"\n>>>>> \"add r0, r0, $1\\n\" // r0 stored the jump target address and with bit[0]\n>>>>> = 1, this will trigger a thumb switch in longjmp with code \"bx r0\"\n>>>>> #endif\n>>>>> \n>>>>> When I force the setjmp code go arm code path, I can back to bootrom\n>>>>> successfully, But I got a data abort exception in later. it seems it\n>>>>> happens when bootrom finished the uboot code copy, when jump to sdram, I\n>>>>> need a further debug.\n>>>> \n>>>> I found that r9 also need to be preserved, it seems that it hold the sdram\n>>>> base.\n>>> Thanks for testing and debugging: this is invaluable support, as I only have\n>>> AArch64 boards to test.\n>>> \n>>> The r9 issue will be easy enough to resolve.\n>>> However, it looks like I will need more work on setjmp/longjmp to make this\n>>> safe both for T32 and A32. Plus: I need to figure out why this didn’t show\n>>> in my disassembly (I don’t remember whether it was a rk3188 or rk3288 board\n>>> I looked at).\n>>> \n>>> Might be tomorrow or Thursday until I can provide an new version.\n>> \n>> From this conversation, it looks to me that I should wait for that new\n>> version for testing on rk3188, as it will likely show the same issues, right?\n> \n> Yes.\n\nA new version with a reworked setjmp/longjmp implementation is available at\n\thttps://patchwork.ozlabs.org/project/uboot/list/?series=4327\n\nThis passed testing for Andy (see the Tested-by: credit) on the boards he works\non, but is still pending a test of a RK3188.\n\nRegards,\nPhilipp.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.denx.de\n\t(client-ip=81.169.180.215; helo=lists.denx.de;\n\tenvelope-from=u-boot-bounces@lists.denx.de;\n\treceiver=)","Received":["from lists.denx.de (dione.denx.de [81.169.180.215])\n\tby ozlabs.org (Postfix) with ESMTP id 3xyV7m6ydpz9t3F\n\tfor ;\n\tThu, 21 Sep 2017 18:26:28 +1000 (AEST)","by lists.denx.de (Postfix, from userid 105)\n\tid 853D5C21ED9; Thu, 21 Sep 2017 08:26:26 +0000 (UTC)","from lists.denx.de (localhost [IPv6:::1])\n\tby lists.denx.de (Postfix) with ESMTP id C5E18C21E26;\n\tThu, 21 Sep 2017 08:26:23 +0000 (UTC)","by lists.denx.de (Postfix, from userid 105)\n\tid 139ECC21E85; Thu, 21 Sep 2017 08:26:22 +0000 (UTC)","from mail.theobroma-systems.com (vegas.theobroma-systems.com\n\t[144.76.126.164])\n\tby lists.denx.de (Postfix) with ESMTPS id B88BBC21E26\n\tfor ; Thu, 21 Sep 2017 08:26:21 +0000 (UTC)","from 89-104-28-141.customer.bnet.at ([89.104.28.141]:50980\n\thelo=[192.168.2.129]) by mail.theobroma-systems.com with esmtpsa\n\t(TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80)\n\t(envelope-from )\n\tid 1duwoO-0003hz-8q; Thu, 21 Sep 2017 10:26:20 +0200"],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de","X-Spam-Level":"*","X-Spam-Status":"No, score=1.0 required=5.0 tests=HK_NAME_DR autolearn=no\n\tautolearn_force=no version=3.4.0","From":"\"Dr. Philipp Tomsich\" ","Message-Id":"<8DE3D47B-2726-4102-827B-B3DEADB680DB@theobroma-systems.com>","Mime-Version":"1.0 (Mac OS X Mail 10.3 \\(3273\\))","Date":"Thu, 21 Sep 2017 10:26:19 +0200","In-Reply-To":"<291C798E-9B85-4258-96DF-CB27F35B684A@theobroma-systems.com>","To":"=?utf-8?q?Heiko_St=C3=BCbner?= ","References":"<1505758708-29213-1-git-send-email-philipp.tomsich@theobroma-systems.com>\n\t\n\t<93C673C2-A070-474F-A21E-674F178DF1BA@theobroma-systems.com>\n\t<10247037.pJkLLH4ko2@diego>\n\t<291C798E-9B85-4258-96DF-CB27F35B684A@theobroma-systems.com>","X-Mailer":"Apple Mail (2.3273)","X-Content-Filtered-By":"Mailman/MimeDel 2.1.18","Cc":"U-Boot Mailing List ,\n\tKlaus Goger ,\n\tStephen Warren , Andy Yan ","Subject":"Re: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace\n\tassembly-implementation with C-code","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.18","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" "}},{"id":1772569,"web_url":"http://patchwork.ozlabs.org/comment/1772569/","msgid":"<2813171.BXQzRi5DZL@phil>","list_archive_url":null,"date":"2017-09-21T08:51:44","subject":"Re: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace\n\tassembly-implementation with C-code","submitter":{"id":10645,"url":"http://patchwork.ozlabs.org/api/people/10645/","name":"Heiko Stuebner","email":"heiko@sntech.de"},"content":"Hi Philipp,\n\nAm Donnerstag, 21. September 2017, 10:26:19 CEST schrieb Dr. Philipp Tomsich:\n> > On 19 Sep 2017, at 12:16, Dr. Philipp Tomsich wrote:\n> > \n> >> \n> >> On 19 Sep 2017, at 11:12, Heiko Stübner wrote:\n> >> \n> >> Am Dienstag, 19. September 2017, 11:10:29 CEST schrieb Dr. Philipp Tomsich:\n> >>> Andy,\n> >>> \n> >>>> On 19 Sep 2017, at 09:19, Andy Yan wrote:\n> >>>> \n> >>>> Hi Philipp:\n> >>>> \n> >>>> On 2017年09月19日 10:06, Andy Yan wrote:\n> >>>>> Hi Philipp:\n> >>>>> \n> >>>>> On 2017年09月19日 02:18, Philipp Tomsich wrote:\n> >>>>>> Recent discussions confirmed (what the code always assumed): the\n> >>>>>> Rockchip BROM always enters U-Boot with the stack-pointer valid\n> >>>>>> (i.e. the U-Boot startup code is running off the BROM stack).\n> >>>>>> \n> >>>>>> We can thus replace the back-to-bootrom code (i.e. both the\n> >>>>>> save_boot_params and back_to_bootrom implementations) using C-code\n> >>>>>> based on setjmp/longjmp. The new implementation is already structured\n> >>>>>> to allow an easy drop-in of Andy's changes to enter download-mode when\n> >>>>>> returning to the BROM.\n> >>>>>> \n> >>>>>> This entails one minor tweak to asm/system.h, which only exported\n> >>>>>> the save_boot_params_ret prototype for ARMv7, but not for AArch64.\n> >>>>>> \n> >>>>>> For v2, we force bootrom.o to alway be emitted as A32 (not T32), so we\n> >>>>>> can safely call save_boot_params_ret().\n> >>>>>> \n> >>>>> This still have a problem, because the setjmp implementation for\n> >>>>> ARM32 platform has humb code when CONFIG_SYS_THUMB_BUILD is>> \n> >>>>> enabled, this is a default setting for most ARMv7 boards.\n> >>>>> #if CONFIG_IS_ENABLED(SYS_THUMB_BUILD)\n> >>>>> \".align 2\\n\"\n> >>>>> \"adr r0, jmp_target\\n\"\n> >>>>> \"add r0, r0, $1\\n\" // r0 stored the jump target address and with bit[0]\n> >>>>> = 1, this will trigger a thumb switch in longjmp with code \"bx r0\"\n> >>>>> #endif\n> >>>>> \n> >>>>> When I force the setjmp code go arm code path, I can back to bootrom\n> >>>>> successfully, But I got a data abort exception in later. it seems it\n> >>>>> happens when bootrom finished the uboot code copy, when jump to sdram, I\n> >>>>> need a further debug.\n> >>>> \n> >>>> I found that r9 also need to be preserved, it seems that it hold the sdram\n> >>>> base.\n> >>> Thanks for testing and debugging: this is invaluable support, as I only have\n> >>> AArch64 boards to test.\n> >>> \n> >>> The r9 issue will be easy enough to resolve.\n> >>> However, it looks like I will need more work on setjmp/longjmp to make this\n> >>> safe both for T32 and A32. Plus: I need to figure out why this didn’t show\n> >>> in my disassembly (I don’t remember whether it was a rk3188 or rk3288 board\n> >>> I looked at).\n> >>> \n> >>> Might be tomorrow or Thursday until I can provide an new version.\n> >> \n> >> From this conversation, it looks to me that I should wait for that new\n> >> version for testing on rk3188, as it will likely show the same issues, right?\n> > \n> > Yes.\n> \n> A new version with a reworked setjmp/longjmp implementation is available at\n> \thttps://patchwork.ozlabs.org/project/uboot/list/?series=4327\n> \n> This passed testing for Andy (see the Tested-by: credit) on the boards he works\n> on, but is still pending a test of a RK3188.\n\nTesting that v3 is actually the thing I currently doing, after I found the\nv3 in my inbox :-) . \n\nResults shortly in the v3 series.\n\n\nHeiko","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.denx.de\n\t(client-ip=81.169.180.215; helo=lists.denx.de;\n\tenvelope-from=u-boot-bounces@lists.denx.de;\n\treceiver=)","Received":["from lists.denx.de (dione.denx.de [81.169.180.215])\n\tby ozlabs.org (Postfix) with ESMTP id 3xyVjJ54Xxz9s7g\n\tfor ;\n\tThu, 21 Sep 2017 18:52:03 +1000 (AEST)","by lists.denx.de (Postfix, from userid 105)\n\tid D87CBC21F68; Thu, 21 Sep 2017 08:51:57 +0000 (UTC)","from lists.denx.de (localhost [IPv6:::1])\n\tby lists.denx.de (Postfix) with ESMTP id 85B98C21E23;\n\tThu, 21 Sep 2017 08:51:54 +0000 (UTC)","by lists.denx.de (Postfix, from userid 105)\n\tid 9B444C21E23; Thu, 21 Sep 2017 08:51:52 +0000 (UTC)","from gloria.sntech.de (gloria.sntech.de [95.129.55.99])\n\tby lists.denx.de (Postfix) with ESMTPS id 1919BC21D75\n\tfor ; Thu, 21 Sep 2017 08:51:52 +0000 (UTC)","from ip9234ad97.dynamic.kabel-deutschland.de ([146.52.173.151]\n\thelo=phil.localnet) by gloria.sntech.de with esmtpsa\n\t(TLS1.1:DHE_RSA_AES_256_CBC_SHA1:256)\n\t(Exim 4.80) (envelope-from )\n\tid 1duxCz-0004oE-F4; Thu, 21 Sep 2017 10:51:45 +0200"],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE\n\tautolearn=unavailable autolearn_force=no version=3.4.0","From":"Heiko Stuebner ","To":"\"Dr. Philipp Tomsich\" ","Date":"Thu, 21 Sep 2017 10:51:44 +0200","Message-ID":"<2813171.BXQzRi5DZL@phil>","User-Agent":"KMail/5.2.3 (Linux/4.11.0-1-amd64; KDE/5.28.0; x86_64; ; )","In-Reply-To":"<8DE3D47B-2726-4102-827B-B3DEADB680DB@theobroma-systems.com>","References":"<1505758708-29213-1-git-send-email-philipp.tomsich@theobroma-systems.com>\n\t<291C798E-9B85-4258-96DF-CB27F35B684A@theobroma-systems.com>\n\t<8DE3D47B-2726-4102-827B-B3DEADB680DB@theobroma-systems.com>","MIME-Version":"1.0","Cc":"U-Boot Mailing List ,\n\tKlaus Goger ,\n\tStephen Warren , Andy Yan ","Subject":"Re: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace\n\tassembly-implementation with C-code","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.18","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" "}}]