[{"id":1772593,"web_url":"http://patchwork.ozlabs.org/comment/1772593/","msgid":"<2510496.Zb8RDqHzGq@phil>","list_archive_url":null,"date":"2017-09-21T09:09:49","subject":"Re: [U-Boot] [PATCH v3 0/6] 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 Donnerstag, 21. September 2017, 10:19:23 CEST schrieb Philipp Tomsich:\n> \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 turned out to require a some tweaking to system.h (making sure\n> that the prototype for save_boot_params_ret is visible for A64)and\n> start.S (so binutils knows that this is a possible function entry and\n> it can correctly insert A32-to-Thumb transitions) and taking the axe\n> to setjmp.h (which created quite a few issues with it not expecting\n> A32/T32/Thumb call-sites and some fragility from GCC being smart about\n> the clobber-list of the inline assembly... which led to r9 not being\n> saved or restored).\n\nThis is missing information on dependant series. Using the u-boot-rockchip\nrepository which is at\n782088de7be7 (\"rockchip: imply ADC and SARADC_ROCKCHIP on supported SoCs\")\n\npatches 1-3 apply, but patch 4 fails to apply as I seem to be missing some\ndependencies.\n\nAnd the u-boot mailinglist seems to be configured very strangely, as it\nseems to rip apart patch-series only sending me some parts.\n\nSo far I can at least say, that the u-boot-rockchip repo at the above\ncommit still boots. Could you please point me to mbox versions\nof needed base patches?\n\n\nThanks\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 3xyW6G0Tpjz9t3w\n\tfor ;\n\tThu, 21 Sep 2017 19:10:13 +1000 (AEST)","by lists.denx.de (Postfix, from userid 105)\n\tid AD516C21FAC; Thu, 21 Sep 2017 09:10:03 +0000 (UTC)","from lists.denx.de (localhost [IPv6:::1])\n\tby lists.denx.de (Postfix) with ESMTP id CED86C21E85;\n\tThu, 21 Sep 2017 09:10:00 +0000 (UTC)","by lists.denx.de (Postfix, from userid 105)\n\tid 394B5C21E85; Thu, 21 Sep 2017 09:09:59 +0000 (UTC)","from gloria.sntech.de (gloria.sntech.de [95.129.55.99])\n\tby lists.denx.de (Postfix) with ESMTPS id EE37DC21E26\n\tfor ; Thu, 21 Sep 2017 09:09:58 +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 1duxUT-0004vx-Nq; Thu, 21 Sep 2017 11:09:49 +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":"Philipp Tomsich ","Date":"Thu, 21 Sep 2017 11:09:49 +0200","Message-ID":"<2510496.Zb8RDqHzGq@phil>","User-Agent":"KMail/5.2.3 (Linux/4.11.0-1-amd64; KDE/5.28.0; x86_64; ; )","In-Reply-To":"<1505981969-49480-1-git-send-email-philipp.tomsich@theobroma-systems.com>","References":"<1505981969-49480-1-git-send-email-philipp.tomsich@theobroma-systems.com>","MIME-Version":"1.0","Cc":"Stephen Warren ,\n\tAndre Przywara ,\n\tNisal Menuka , u-boot@lists.denx.de,\n\tKlaus Goger ,\n\tAndy Yan , Stefan Roese ,\n\tJagan Teki ","Subject":"Re: [U-Boot] [PATCH v3 0/6] 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":1772623,"web_url":"http://patchwork.ozlabs.org/comment/1772623/","msgid":"<1575654.3LH0U9PvCD@phil>","list_archive_url":null,"date":"2017-09-21T09:44:26","subject":"Re: [U-Boot] [PATCH v3 0/6] 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 Donnerstag, 21. September 2017, 11:09:49 CEST schrieb Heiko Stuebner:\n> Am Donnerstag, 21. September 2017, 10:19:23 CEST schrieb Philipp Tomsich:\n> > \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 turned out to require a some tweaking to system.h (making sure\n> > that the prototype for save_boot_params_ret is visible for A64)and\n> > start.S (so binutils knows that this is a possible function entry and\n> > it can correctly insert A32-to-Thumb transitions) and taking the axe\n> > to setjmp.h (which created quite a few issues with it not expecting\n> > A32/T32/Thumb call-sites and some fragility from GCC being smart about\n> > the clobber-list of the inline assembly... which led to r9 not being\n> > saved or restored).\n> \n> This is missing information on dependant series. Using the u-boot-rockchip\n> repository which is at\n> 782088de7be7 (\"rockchip: imply ADC and SARADC_ROCKCHIP on supported SoCs\")\n> \n> patches 1-3 apply, but patch 4 fails to apply as I seem to be missing some\n> dependencies.\n> \n> And the u-boot mailinglist seems to be configured very strangely, as it\n> seems to rip apart patch-series only sending me some parts.\n> \n> So far I can at least say, that the u-boot-rockchip repo at the above\n> commit still boots. Could you please point me to mbox versions\n> of needed base patches?\n\nAlso, with patches 1-3 and 5 applied the radxarock board fails to start.\nI see the SPL banner and a \"Returning to boot ROM...\" and then nothing.\n\nI do belive it may have something to do with the TPL's + SPL's stack both\nbeing at the end of SRAM? Having the SPL go back to TPL and then\nback to bootrom was my original intention as well, but didn't work at\nthe time.\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 3xyWt44W86z9s5L\n\tfor ;\n\tThu, 21 Sep 2017 19:44:43 +1000 (AEST)","by lists.denx.de (Postfix, from userid 105)\n\tid 0172FC21F74; Thu, 21 Sep 2017 09:44:36 +0000 (UTC)","from lists.denx.de (localhost [IPv6:::1])\n\tby lists.denx.de (Postfix) with ESMTP id 35903C21E85;\n\tThu, 21 Sep 2017 09:44:34 +0000 (UTC)","by lists.denx.de (Postfix, from userid 105)\n\tid 06014C21E85; Thu, 21 Sep 2017 09:44:32 +0000 (UTC)","from gloria.sntech.de (gloria.sntech.de [95.129.55.99])\n\tby lists.denx.de (Postfix) with ESMTPS id 249DBC21DEB\n\tfor ; Thu, 21 Sep 2017 09:44:31 +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 1duy1y-00057f-Op; Thu, 21 Sep 2017 11:44:26 +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":"Philipp Tomsich ","Date":"Thu, 21 Sep 2017 11:44:26 +0200","Message-ID":"<1575654.3LH0U9PvCD@phil>","User-Agent":"KMail/5.2.3 (Linux/4.11.0-1-amd64; KDE/5.28.0; x86_64; ; )","In-Reply-To":"<2510496.Zb8RDqHzGq@phil>","References":"<1505981969-49480-1-git-send-email-philipp.tomsich@theobroma-systems.com>\n\t<2510496.Zb8RDqHzGq@phil>","MIME-Version":"1.0","Cc":"Stephen Warren ,\n\tAndre Przywara ,\n\tNisal Menuka , u-boot@lists.denx.de,\n\tKlaus Goger ,\n\tAndy Yan , Stefan Roese ,\n\tJagan Teki ","Subject":"Re: [U-Boot] [PATCH v3 0/6] 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":1772657,"web_url":"http://patchwork.ozlabs.org/comment/1772657/","msgid":"<3CDC3C31-933B-4D38-ADE7-F9F9C354505F@theobroma-systems.com>","list_archive_url":null,"date":"2017-09-21T10:25:17","subject":"Re: [U-Boot] [PATCH v3 0/6] 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 21 Sep 2017, at 11:44, Heiko Stuebner wrote:\n> \n> Am Donnerstag, 21. September 2017, 11:09:49 CEST schrieb Heiko Stuebner:\n>> Am Donnerstag, 21. September 2017, 10:19:23 CEST schrieb Philipp Tomsich:\n>>> \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 turned out to require a some tweaking to system.h (making sure\n>>> that the prototype for save_boot_params_ret is visible for A64)and\n>>> start.S (so binutils knows that this is a possible function entry and\n>>> it can correctly insert A32-to-Thumb transitions) and taking the axe\n>>> to setjmp.h (which created quite a few issues with it not expecting\n>>> A32/T32/Thumb call-sites and some fragility from GCC being smart about\n>>> the clobber-list of the inline assembly... which led to r9 not being\n>>> saved or restored).\n>> \n>> This is missing information on dependant series. Using the u-boot-rockchip\n>> repository which is at\n>> 782088de7be7 (\"rockchip: imply ADC and SARADC_ROCKCHIP on supported SoCs\")\n>> \n>> patches 1-3 apply, but patch 4 fails to apply as I seem to be missing some\n>> dependencies.\n>> \n>> And the u-boot mailinglist seems to be configured very strangely, as it\n>> seems to rip apart patch-series only sending me some parts.\n>> \n>> So far I can at least say, that the u-boot-rockchip repo at the above\n>> commit still boots. Could you please point me to mbox versions\n>> of needed base patches?\n> \n> Also, with patches 1-3 and 5 applied the radxarock board fails to start.\n> I see the SPL banner and a \"Returning to boot ROM...\" and then nothing.\n> \n> I do belive it may have something to do with the TPL's + SPL's stack both\n> being at the end of SRAM? Having the SPL go back to TPL and then\n> back to bootrom was my original intention as well, but didn't work at\n> the time.\n\nI didn’t expect the stacks to overlap… so returning from SPL to TPL can’t\nwork. However, the jump_to_spl() is at least partially to blame (we already\nhave a working C-runtime and there’s no point in reentering through the\nreset entry-point).\n\nI need to ponder this a bit, but my gut feeling is that the TPL->SPL transition\ncan be done in a less intrusive way and may allow us to retain the TPL stack.\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 3xyXn34z8mz9s03\n\tfor ;\n\tThu, 21 Sep 2017 20:25:26 +1000 (AEST)","by lists.denx.de (Postfix, from userid 105)\n\tid 258DEC21F6B; Thu, 21 Sep 2017 10:25:18 +0000 (UTC)","from lists.denx.de (localhost [IPv6:::1])\n\tby lists.denx.de (Postfix) with ESMTP id 956E2C21E26;\n\tThu, 21 Sep 2017 10:25:16 +0000 (UTC)","by lists.denx.de (Postfix, from userid 105)\n\tid 4EC61C21E26; Thu, 21 Sep 2017 10:25:15 +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 EF928C21DEB\n\tfor ; Thu, 21 Sep 2017 10:25:14 +0000 (UTC)","from [86.59.122.178] (port=52066 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 1duyfO-0006vj-0E; Thu, 21 Sep 2017 12:25:10 +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":"<3CDC3C31-933B-4D38-ADE7-F9F9C354505F@theobroma-systems.com>","Mime-Version":"1.0 (Mac OS X Mail 10.3 \\(3273\\))","Date":"Thu, 21 Sep 2017 12:25:17 +0200","In-Reply-To":"<1575654.3LH0U9PvCD@phil>","To":"Heiko Stuebner ","References":"<1505981969-49480-1-git-send-email-philipp.tomsich@theobroma-systems.com>\n\t<2510496.Zb8RDqHzGq@phil> <1575654.3LH0U9PvCD@phil>","X-Mailer":"Apple Mail (2.3273)","X-Content-Filtered-By":"Mailman/MimeDel 2.1.18","Cc":"Stephen Warren ,\n\tAndre Przywara ,\n\tNisal Menuka ,\n\tU-Boot Mailing List ,\n\tKlaus Goger ,\n\tAndy Yan , Stefan Roese ,\n\tJagan Teki ","Subject":"Re: [U-Boot] [PATCH v3 0/6] 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":1772658,"web_url":"http://patchwork.ozlabs.org/comment/1772658/","msgid":"<761A9677-8A29-40BF-8539-26C15C90EC48@theobroma-systems.com>","list_archive_url":null,"date":"2017-09-21T10:27:27","subject":"Re: [U-Boot] [PATCH v3 0/6] 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 21 Sep 2017, at 11:09, Heiko Stuebner wrote:\n> \n> Am Donnerstag, 21. September 2017, 10:19:23 CEST schrieb Philipp Tomsich:\n>> \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 turned out to require a some tweaking to system.h (making sure\n>> that the prototype for save_boot_params_ret is visible for A64)and\n>> start.S (so binutils knows that this is a possible function entry and\n>> it can correctly insert A32-to-Thumb transitions) and taking the axe\n>> to setjmp.h (which created quite a few issues with it not expecting\n>> A32/T32/Thumb call-sites and some fragility from GCC being smart about\n>> the clobber-list of the inline assembly... which led to r9 not being\n>> saved or restored).\n> \n> This is missing information on dependant series. Using the u-boot-rockchip\n> repository which is at\n> 782088de7be7 (\"rockchip: imply ADC and SARADC_ROCKCHIP on supported SoCs\")\n> \n> patches 1-3 apply, but patch 4 fails to apply as I seem to be missing some\n> dependencies.\n> \n> And the u-boot mailinglist seems to be configured very strangely, as it\n> seems to rip apart patch-series only sending me some parts.\n> \n> So far I can at least say, that the u-boot-rockchip repo at the above\n> commit still boots. Could you please point me to mbox versions\n> of needed base patches?\n\nI seem to be suffering from “too many trees” syndrome.\nThe next reroll will be a clean one again.\n\nThanks,\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 3xyXqb4ZGrz9s03\n\tfor ;\n\tThu, 21 Sep 2017 20:27:39 +1000 (AEST)","by lists.denx.de (Postfix, from userid 105)\n\tid 45D85C21EFC; Thu, 21 Sep 2017 10:27:28 +0000 (UTC)","from lists.denx.de (localhost [IPv6:::1])\n\tby lists.denx.de (Postfix) with ESMTP id 8801CC21E26;\n\tThu, 21 Sep 2017 10:27:26 +0000 (UTC)","by lists.denx.de (Postfix, from userid 105)\n\tid 5672BC21E26; Thu, 21 Sep 2017 10:27:25 +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 100B9C21DEB\n\tfor ; Thu, 21 Sep 2017 10:27:25 +0000 (UTC)","from [86.59.122.178] (port=52083 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 1duyhU-0006yi-Cp; Thu, 21 Sep 2017 12:27: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":"<761A9677-8A29-40BF-8539-26C15C90EC48@theobroma-systems.com>","Mime-Version":"1.0 (Mac OS X Mail 10.3 \\(3273\\))","Date":"Thu, 21 Sep 2017 12:27:27 +0200","In-Reply-To":"<2510496.Zb8RDqHzGq@phil>","To":"Heiko Stuebner ","References":"<1505981969-49480-1-git-send-email-philipp.tomsich@theobroma-systems.com>\n\t<2510496.Zb8RDqHzGq@phil>","X-Mailer":"Apple Mail (2.3273)","X-Content-Filtered-By":"Mailman/MimeDel 2.1.18","Cc":"Stephen Warren ,\n\tAndre Przywara ,\n\tNisal Menuka , u-boot@lists.denx.de,\n\tKlaus Goger ,\n\tAndy Yan , Stefan Roese ,\n\tJagan Teki ","Subject":"Re: [U-Boot] [PATCH v3 0/6] 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":1772667,"web_url":"http://patchwork.ozlabs.org/comment/1772667/","msgid":"<3EDE248F-D39B-498B-987E-DF721D1AC9C7@theobroma-systems.com>","list_archive_url":null,"date":"2017-09-21T10:39:40","subject":"Re: [U-Boot] [PATCH v3 0/6] 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 21 Sep 2017, at 12:25, Dr. Philipp Tomsich wrote:\n> \n>> \n>> On 21 Sep 2017, at 11:44, Heiko Stuebner > wrote:\n>> \n>> Am Donnerstag, 21. September 2017, 11:09:49 CEST schrieb Heiko Stuebner:\n>>> Am Donnerstag, 21. September 2017, 10:19:23 CEST schrieb Philipp Tomsich:\n>>>> \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 turned out to require a some tweaking to system.h (making sure\n>>>> that the prototype for save_boot_params_ret is visible for A64)and\n>>>> start.S (so binutils knows that this is a possible function entry and\n>>>> it can correctly insert A32-to-Thumb transitions) and taking the axe\n>>>> to setjmp.h (which created quite a few issues with it not expecting\n>>>> A32/T32/Thumb call-sites and some fragility from GCC being smart about\n>>>> the clobber-list of the inline assembly... which led to r9 not being\n>>>> saved or restored).\n>>> \n>>> This is missing information on dependant series. Using the u-boot-rockchip\n>>> repository which is at\n>>> 782088de7be7 (\"rockchip: imply ADC and SARADC_ROCKCHIP on supported SoCs\")\n>>> \n>>> patches 1-3 apply, but patch 4 fails to apply as I seem to be missing some\n>>> dependencies.\n>>> \n>>> And the u-boot mailinglist seems to be configured very strangely, as it\n>>> seems to rip apart patch-series only sending me some parts.\n>>> \n>>> So far I can at least say, that the u-boot-rockchip repo at the above\n>>> commit still boots. Could you please point me to mbox versions\n>>> of needed base patches?\n>> \n>> Also, with patches 1-3 and 5 applied the radxarock board fails to start.\n>> I see the SPL banner and a \"Returning to boot ROM...\" and then nothing.\n>> \n>> I do belive it may have something to do with the TPL's + SPL's stack both\n>> being at the end of SRAM? Having the SPL go back to TPL and then\n>> back to bootrom was my original intention as well, but didn't work at\n>> the time.\n> \n> I didn’t expect the stacks to overlap… so returning from SPL to TPL can’t\n> work. However, the jump_to_spl() is at least partially to blame (we already\n> have a working C-runtime and there’s no point in reentering through the\n> reset entry-point).\n> \n> I need to ponder this a bit, but my gut feeling is that the TPL->SPL transition\n> can be done in a less intrusive way and may allow us to retain the TPL stack.\n\nI had to draw this out on a whiteboard to keep track of what stacks are in use\nand when they get destroyed (or returned to).\nClearly, returning to the TPL and expecting the C-runtime there to be intact\nwill not work. The problem is that when returning to jump_to_spl(), the TPL’s\nstack will have been overwritten by SPL.\n\nI’ll need to look at the disassembly, but it might be sufficient if I chain into the\nlongjmp directly in jump_to_spl()… or I may need to do something disruptive\n(e.g. switch stacks) in jump_to_spl.\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 3xyY5k596lz9s2G\n\tfor ;\n\tThu, 21 Sep 2017 20:39:54 +1000 (AEST)","by lists.denx.de (Postfix, from userid 105)\n\tid 6D9C9C21F74; Thu, 21 Sep 2017 10:39:50 +0000 (UTC)","from lists.denx.de (localhost [IPv6:::1])\n\tby lists.denx.de (Postfix) with ESMTP id BACF1C21EAB;\n\tThu, 21 Sep 2017 10:39:47 +0000 (UTC)","by lists.denx.de (Postfix, from userid 105)\n\tid 853CEC21EAB; Thu, 21 Sep 2017 10:39:46 +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 2DB69C21E26\n\tfor ; Thu, 21 Sep 2017 10:39:46 +0000 (UTC)","from [86.59.122.178] (port=52200 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 1duytR-0007Hz-Py; Thu, 21 Sep 2017 12:39:42 +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":"<3EDE248F-D39B-498B-987E-DF721D1AC9C7@theobroma-systems.com>","Mime-Version":"1.0 (Mac OS X Mail 10.3 \\(3273\\))","Date":"Thu, 21 Sep 2017 12:39:40 +0200","In-Reply-To":"<3CDC3C31-933B-4D38-ADE7-F9F9C354505F@theobroma-systems.com>","To":"Heiko Stuebner ","References":"<1505981969-49480-1-git-send-email-philipp.tomsich@theobroma-systems.com>\n\t<2510496.Zb8RDqHzGq@phil> <1575654.3LH0U9PvCD@phil>\n\t<3CDC3C31-933B-4D38-ADE7-F9F9C354505F@theobroma-systems.com>","X-Mailer":"Apple Mail (2.3273)","X-Content-Filtered-By":"Mailman/MimeDel 2.1.18","Cc":"Stephen Warren ,\n\tAndre Przywara ,\n\tNisal Menuka ,\n\tU-Boot Mailing List ,\n\tKlaus Goger ,\n\tAndy Yan , Stefan Roese ,\n\tJagan Teki ","Subject":"Re: [U-Boot] [PATCH v3 0/6] 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":1772668,"web_url":"http://patchwork.ozlabs.org/comment/1772668/","msgid":"<1515454.iN24rLG9oW@diego>","list_archive_url":null,"date":"2017-09-21T10:44:49","subject":"Re: [U-Boot] [PATCH v3 0/6] 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 Donnerstag, 21. September 2017, 12:25:17 CEST schrieb Dr. Philipp Tomsich:\n> > On 21 Sep 2017, at 11:44, Heiko Stuebner wrote:\n> > \n> > Am Donnerstag, 21. September 2017, 11:09:49 CEST schrieb Heiko Stuebner:\n> >> Am Donnerstag, 21. September 2017, 10:19:23 CEST schrieb Philipp Tomsich:\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 turned out to require a some tweaking to system.h (making sure\n> >>> that the prototype for save_boot_params_ret is visible for A64)and\n> >>> start.S (so binutils knows that this is a possible function entry and\n> >>> it can correctly insert A32-to-Thumb transitions) and taking the axe\n> >>> to setjmp.h (which created quite a few issues with it not expecting\n> >>> A32/T32/Thumb call-sites and some fragility from GCC being smart about\n> >>> the clobber-list of the inline assembly... which led to r9 not being\n> >>> saved or restored).\n> >> \n> >> This is missing information on dependant series. Using the\n> >> u-boot-rockchip\n> >> repository which is at\n> >> 782088de7be7 (\"rockchip: imply ADC and SARADC_ROCKCHIP on supported\n> >> SoCs\")\n> >> \n> >> patches 1-3 apply, but patch 4 fails to apply as I seem to be missing\n> >> some\n> >> dependencies.\n> >> \n> >> And the u-boot mailinglist seems to be configured very strangely, as it\n> >> seems to rip apart patch-series only sending me some parts.\n> >> \n> >> So far I can at least say, that the u-boot-rockchip repo at the above\n> >> commit still boots. Could you please point me to mbox versions\n> >> of needed base patches?\n> > \n> > Also, with patches 1-3 and 5 applied the radxarock board fails to start.\n> > I see the SPL banner and a \"Returning to boot ROM...\" and then nothing.\n> > \n> > I do belive it may have something to do with the TPL's + SPL's stack both\n> > being at the end of SRAM? Having the SPL go back to TPL and then\n> > back to bootrom was my original intention as well, but didn't work at\n> > the time.\n> \n> I didn’t expect the stacks to overlap… so returning from SPL to TPL can’t\n> work. However, the jump_to_spl() is at least partially to blame (we already\n> have a working C-runtime and there’s no point in reentering through the\n> reset entry-point).\n> \n> I need to ponder this a bit, but my gut feeling is that the TPL->SPL\n> transition can be done in a less intrusive way and may allow us to retain\n> the TPL stack.\n\nAlternatively, if you can think of an easier solution we could do away with\nthe TPL in its current form. When I did the rk3188 support, this looked like\nthe least-messy way to me, but it really only does the one jump back\nto the bootrom - so I'm not sure if there isn't simply an easier solution.\n\nAnd for example the (still wip?) rk3066 series did use spl+tpl in a different\nway due to bootrom-nand-limitations. rk3066 and rk3188 are quite similar\nwith the rk3066 simply not having the sd-boot capability, so if we want to\nhave nand-boot on rk3188 as well in the future, this may need a different\nrework again.\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 3xyYCs6pBmz9sBZ\n\tfor ;\n\tThu, 21 Sep 2017 20:45:13 +1000 (AEST)","by lists.denx.de (Postfix, from userid 105)\n\tid A30BBC21F7E; Thu, 21 Sep 2017 10:45:08 +0000 (UTC)","from lists.denx.de (localhost [IPv6:::1])\n\tby lists.denx.de (Postfix) with ESMTP id 27D90C21EAB;\n\tThu, 21 Sep 2017 10:45:06 +0000 (UTC)","by lists.denx.de (Postfix, from userid 105)\n\tid 3CEEBC21EAB; Thu, 21 Sep 2017 10:45:04 +0000 (UTC)","from gloria.sntech.de (gloria.sntech.de [95.129.55.99])\n\tby lists.denx.de (Postfix) with ESMTPS id EF4FDC21E26\n\tfor ; Thu, 21 Sep 2017 10:45:03 +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 1duyyQ-0005Pv-2t; Thu, 21 Sep 2017 12:44:50 +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":"Thu, 21 Sep 2017 12:44:49 +0200","Message-ID":"<1515454.iN24rLG9oW@diego>","User-Agent":"KMail/5.2.3 (Linux/4.11.0-1-amd64; KDE/5.28.0; x86_64; ; )","In-Reply-To":"<3CDC3C31-933B-4D38-ADE7-F9F9C354505F@theobroma-systems.com>","References":"<1505981969-49480-1-git-send-email-philipp.tomsich@theobroma-systems.com>\n\t<1575654.3LH0U9PvCD@phil>\n\t<3CDC3C31-933B-4D38-ADE7-F9F9C354505F@theobroma-systems.com>","MIME-Version":"1.0","Cc":"Stephen Warren ,\n\tAndre Przywara ,\n\tNisal Menuka ,\n\tU-Boot Mailing List ,\n\tKlaus Goger ,\n\tAndy Yan , Stefan Roese ,\n\tJagan Teki ","Subject":"Re: [U-Boot] [PATCH v3 0/6] 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":1774549,"web_url":"http://patchwork.ozlabs.org/comment/1774549/","msgid":"","list_archive_url":null,"date":"2017-09-25T08:46:27","subject":"Re: [U-Boot] [PATCH v3 0/6] 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, Heiko:\n\n\nI finally got the upstream u-boot run on a rk3188 board which can be \nattached by DS5 debugger,\n\nif you have some registers info want to check, please let me know.\n\n\nOn 2017年09月21日 18:44, Heiko Stübner wrote:\n> Am Donnerstag, 21. September 2017, 12:25:17 CEST schrieb Dr. Philipp Tomsich:\n>>> On 21 Sep 2017, at 11:44, Heiko Stuebner wrote:\n>>>\n>>> Am Donnerstag, 21. September 2017, 11:09:49 CEST schrieb Heiko Stuebner:\n>>>> Am Donnerstag, 21. September 2017, 10:19:23 CEST schrieb Philipp Tomsich:\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 turned out to require a some tweaking to system.h (making sure\n>>>>> that the prototype for save_boot_params_ret is visible for A64)and\n>>>>> start.S (so binutils knows that this is a possible function entry and\n>>>>> it can correctly insert A32-to-Thumb transitions) and taking the axe\n>>>>> to setjmp.h (which created quite a few issues with it not expecting\n>>>>> A32/T32/Thumb call-sites and some fragility from GCC being smart about\n>>>>> the clobber-list of the inline assembly... which led to r9 not being\n>>>>> saved or restored).\n>>>> This is missing information on dependant series. Using the\n>>>> u-boot-rockchip\n>>>> repository which is at\n>>>> 782088de7be7 (\"rockchip: imply ADC and SARADC_ROCKCHIP on supported\n>>>> SoCs\")\n>>>>\n>>>> patches 1-3 apply, but patch 4 fails to apply as I seem to be missing\n>>>> some\n>>>> dependencies.\n>>>>\n>>>> And the u-boot mailinglist seems to be configured very strangely, as it\n>>>> seems to rip apart patch-series only sending me some parts.\n>>>>\n>>>> So far I can at least say, that the u-boot-rockchip repo at the above\n>>>> commit still boots. Could you please point me to mbox versions\n>>>> of needed base patches?\n>>> Also, with patches 1-3 and 5 applied the radxarock board fails to start.\n>>> I see the SPL banner and a \"Returning to boot ROM...\" and then nothing.\n>>>\n>>> I do belive it may have something to do with the TPL's + SPL's stack both\n>>> being at the end of SRAM? Having the SPL go back to TPL and then\n>>> back to bootrom was my original intention as well, but didn't work at\n>>> the time.\n>> I didn’t expect the stacks to overlap… so returning from SPL to TPL can’t\n>> work. However, the jump_to_spl() is at least partially to blame (we already\n>> have a working C-runtime and there’s no point in reentering through the\n>> reset entry-point).\n>>\n>> I need to ponder this a bit, but my gut feeling is that the TPL->SPL\n>> transition can be done in a less intrusive way and may allow us to retain\n>> the TPL stack.\n> Alternatively, if you can think of an easier solution we could do away with\n> the TPL in its current form. When I did the rk3188 support, this looked like\n> the least-messy way to me, but it really only does the one jump back\n> to the bootrom - so I'm not sure if there isn't simply an easier solution.\n>\n> And for example the (still wip?) rk3066 series did use spl+tpl in a different\n> way due to bootrom-nand-limitations. rk3066 and rk3188 are quite similar\n> with the rk3066 simply not having the sd-boot capability, so if we want to\n> have nand-boot on rk3188 as well in the future, this may need a different\n> rework again.\n>\n>\n> Heiko\n>\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 3y0ypV194xz9sDB\n\tfor ;\n\tMon, 25 Sep 2017 19:05:06 +1000 (AEST)","by lists.denx.de (Postfix, from userid 105)\n\tid E72AFC220E5; Mon, 25 Sep 2017 08:51:11 +0000 (UTC)","from lists.denx.de (localhost [IPv6:::1])\n\tby lists.denx.de (Postfix) with ESMTP id CCBF6C21FD8;\n\tMon, 25 Sep 2017 08:51:07 +0000 (UTC)","by lists.denx.de (Postfix, from userid 105)\n\tid 0308FC21E0C; Mon, 25 Sep 2017 08:47:05 +0000 (UTC)","from regular1.263xmail.com (regular1.263xmail.com [211.150.99.135])\n\tby lists.denx.de (Postfix) with ESMTPS id 980D4C21F51\n\tfor ; Mon, 25 Sep 2017 08:47:00 +0000 (UTC)","from andy.yan?rock-chips.com (unknown [192.168.167.163])\n\tby regular1.263xmail.com (Postfix) with ESMTP id 9D53E1E165;\n\tMon, 25 Sep 2017 16:46:49 +0800 (CST)","from [172.16.12.133] (localhost [127.0.0.1])\n\tby smtp.263.net (Postfix) with ESMTPA id 71D17400;\n\tMon, 25 Sep 2017 16:46:30 +0800 (CST)","from [172.16.12.133] (unknown [58.22.7.114])\n\tby smtp.263.net (Postfix) whith ESMTP id 100280V2KR7;\n\tMon, 25 Sep 2017 16:46:39 +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_SORBS_WEB autolearn=no autolearn_force=no version=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":"=?utf-8?q?Heiko_St=C3=BCbner?= , \"Dr. Philipp Tomsich\"\n\t","References":"<1505981969-49480-1-git-send-email-philipp.tomsich@theobroma-systems.com>\n\t<1575654.3LH0U9PvCD@phil>\n\t<3CDC3C31-933B-4D38-ADE7-F9F9C354505F@theobroma-systems.com>\n\t<1515454.iN24rLG9oW@diego>","From":"Andy Yan ","Message-ID":"","Date":"Mon, 25 Sep 2017 16:46:27 +0800","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<1515454.iN24rLG9oW@diego>","Content-Language":"en-US","Cc":"Stephen Warren ,\n\tAndre Przywara ,\n\tNisal Menuka ,\n\tU-Boot Mailing List ,\n\tKlaus Goger ,\n\tStefan Roese , Jagan Teki ","Subject":"Re: [U-Boot] [PATCH v3 0/6] 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":1774550,"web_url":"http://patchwork.ozlabs.org/comment/1774550/","msgid":"","list_archive_url":null,"date":"2017-09-25T08:49:03","subject":"Re: [U-Boot] [PATCH v3 0/6] 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\nExcellent news.\nLooks like Heiko and I figured out what breaks the series last week (i.e. the SPL corrupts\nthe TPL’s stack—so my chaining will break things).\n\nI’ll resubmit without the chained returns later and then we can have a final test tomorrow.\n\nRegards,\nPhilipp.\n\n> On 25 Sep 2017, at 10:46, Andy Yan wrote:\n> \n> Hi Philipp, Heiko:\n> \n> \n> I finally got the upstream u-boot run on a rk3188 board which can be attached by DS5 debugger,\n> \n> if you have some registers info want to check, please let me know.\n> \n> \n> On 2017年09月21日 18:44, Heiko Stübner wrote:\n>> Am Donnerstag, 21. September 2017, 12:25:17 CEST schrieb Dr. Philipp Tomsich:\n>>>> On 21 Sep 2017, at 11:44, Heiko Stuebner wrote:\n>>>> \n>>>> Am Donnerstag, 21. September 2017, 11:09:49 CEST schrieb Heiko Stuebner:\n>>>>> Am Donnerstag, 21. September 2017, 10:19:23 CEST schrieb Philipp Tomsich:\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 turned out to require a some tweaking to system.h (making sure\n>>>>>> that the prototype for save_boot_params_ret is visible for A64)and\n>>>>>> start.S (so binutils knows that this is a possible function entry and\n>>>>>> it can correctly insert A32-to-Thumb transitions) and taking the axe\n>>>>>> to setjmp.h (which created quite a few issues with it not expecting\n>>>>>> A32/T32/Thumb call-sites and some fragility from GCC being smart about\n>>>>>> the clobber-list of the inline assembly... which led to r9 not being\n>>>>>> saved or restored).\n>>>>> This is missing information on dependant series. Using the\n>>>>> u-boot-rockchip\n>>>>> repository which is at\n>>>>> 782088de7be7 (\"rockchip: imply ADC and SARADC_ROCKCHIP on supported\n>>>>> SoCs\")\n>>>>> \n>>>>> patches 1-3 apply, but patch 4 fails to apply as I seem to be missing\n>>>>> some\n>>>>> dependencies.\n>>>>> \n>>>>> And the u-boot mailinglist seems to be configured very strangely, as it\n>>>>> seems to rip apart patch-series only sending me some parts.\n>>>>> \n>>>>> So far I can at least say, that the u-boot-rockchip repo at the above\n>>>>> commit still boots. Could you please point me to mbox versions\n>>>>> of needed base patches?\n>>>> Also, with patches 1-3 and 5 applied the radxarock board fails to start.\n>>>> I see the SPL banner and a \"Returning to boot ROM...\" and then nothing.\n>>>> \n>>>> I do belive it may have something to do with the TPL's + SPL's stack both\n>>>> being at the end of SRAM? Having the SPL go back to TPL and then\n>>>> back to bootrom was my original intention as well, but didn't work at\n>>>> the time.\n>>> I didn’t expect the stacks to overlap… so returning from SPL to TPL can’t\n>>> work. However, the jump_to_spl() is at least partially to blame (we already\n>>> have a working C-runtime and there’s no point in reentering through the\n>>> reset entry-point).\n>>> \n>>> I need to ponder this a bit, but my gut feeling is that the TPL->SPL\n>>> transition can be done in a less intrusive way and may allow us to retain\n>>> the TPL stack.\n>> Alternatively, if you can think of an easier solution we could do away with\n>> the TPL in its current form. When I did the rk3188 support, this looked like\n>> the least-messy way to me, but it really only does the one jump back\n>> to the bootrom - so I'm not sure if there isn't simply an easier solution.\n>> \n>> And for example the (still wip?) rk3066 series did use spl+tpl in a different\n>> way due to bootrom-nand-limitations. rk3066 and rk3188 are quite similar\n>> with the rk3066 simply not having the sd-boot capability, so if we want to\n>> have nand-boot on rk3188 as well in the future, this may need a different\n>> rework again.\n>> \n>> \n>> Heiko\n>> \n>> \n>> \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 3y0yqG2xTNz9sDB\n\tfor ;\n\tMon, 25 Sep 2017 19:05:46 +1000 (AEST)","by lists.denx.de (Postfix, from userid 105)\n\tid 0BC94C2210B; Mon, 25 Sep 2017 08:56:29 +0000 (UTC)","from lists.denx.de (localhost [IPv6:::1])\n\tby lists.denx.de (Postfix) with ESMTP id 6E4BDC21E37;\n\tMon, 25 Sep 2017 08:56:26 +0000 (UTC)","by lists.denx.de (Postfix, from userid 105)\n\tid B0FABC21FDB; Mon, 25 Sep 2017 08:49:10 +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 A72F6C21E37\n\tfor ; Mon, 25 Sep 2017 08:49:10 +0000 (UTC)","from 89-104-28-141.customer.bnet.at ([89.104.28.141]:52009\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 1dwP4b-00015o-5G; Mon, 25 Sep 2017 10:49:05 +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","Mime-Version":"1.0 (Mac OS X Mail 10.3 \\(3273\\))","From":"\"Dr. Philipp Tomsich\" ","In-Reply-To":"","Date":"Mon, 25 Sep 2017 10:49:03 +0200","Message-Id":"","References":"<1505981969-49480-1-git-send-email-philipp.tomsich@theobroma-systems.com>\n\t<1575654.3LH0U9PvCD@phil>\n\t<3CDC3C31-933B-4D38-ADE7-F9F9C354505F@theobroma-systems.com>\n\t<1515454.iN24rLG9oW@diego>\n\t","To":"Andy Yan ","X-Mailer":"Apple Mail (2.3273)","Cc":"Stephen Warren ,\n\tAndre Przywara ,\n\tNisal Menuka ,\n\tU-Boot Mailing List ,\n\tKlaus Goger ,\n\tStefan Roese , Jagan Teki ","Subject":"Re: [U-Boot] [PATCH v3 0/6] 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\" "}}]