Re: [U-Boot] [PATCH 0/9] ARMv7: add PSCI support to u-boot
On 11/21/2013 09:59 AM, Marc Zyngier wrote: PSCI is an ARM standard that provides a generic interface that ... Thanks again for posting this, I like the idea of adding PSCI handlers to u-boot for several platforms very much. This patch series contains 3 parts: - the first four patches are just bug fixes Those are fine, I already acked those patches. - the next three contain the generic PSCI code and build infrastructure As I heard you will rework these anyway, I will refrain from commenting in detail, just some generic comments on the approach: * Is the creation of a top-level psci directory for holding the PSCI binaries really necessary? Should this mimic the spl approach? Can you consider to move this at least into the arch/arm directory, as PSCI is ARM specific? Or add it to the SPL directory, as this serves a similar purpose? But maybe your new approach renders this all moot. * Can you keep the SMP bringup code in place and re-use it from the PSCI handlers instead of #ifndef PSCIing it? So maybe rename arch/arm/cpu/armv7/sunxi/psci.S to .../sunxi/smp.S? My idea here is to make PSCI an option in addition to the current SMP HYP mode code. So that for instance on VExpress (or better: Arndale) you could either use the existing code using the kernel's platform SMP code or enable PSCI in u-boot and let the kernel use that, too. I maybe ask too much for the first incarnation of the code, but that is how I would like to eventually see it. AFAIK Linux prefers PSCI over platform-defined SMP code, so this should work out of the box. * Is the use of TPIDRPRW Co. really safe? It looks like as we seem to be the only secure user (and they are banked), but I am just curious whether there is any prior art in using those registers temporarily. ... The kernel now boots in HYP mode, finds its secondary CPU without any additional SMP code, and runs KVM out of the box. Hopefully, the Xen/ARM guys can do the same fairly easily. BTW: Yesterday my PSCI host patches for Xen have been committed, so Xen should be able to use that feature just like the kernel does. Thanks! Andre. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] ARMv7: add PSCI support to u-boot
Hi Andre, On 06/12/13 11:43, Andre Przywara wrote: On 11/21/2013 09:59 AM, Marc Zyngier wrote: PSCI is an ARM standard that provides a generic interface that ... Thanks again for posting this, I like the idea of adding PSCI handlers to u-boot for several platforms very much. This patch series contains 3 parts: - the first four patches are just bug fixes Those are fine, I already acked those patches. - the next three contain the generic PSCI code and build infrastructure As I heard you will rework these anyway, I will refrain from commenting in detail, just some generic comments on the approach: * Is the creation of a top-level psci directory for holding the PSCI binaries really necessary? Should this mimic the spl approach? Can you consider to move this at least into the arch/arm directory, as PSCI is ARM specific? Or add it to the SPL directory, as this serves a similar purpose? But maybe your new approach renders this all moot. The code base I have at the moment completely gets rid of the psci directory, and make that code a separate section that can be relocated to secure memory or simply marked as reserved. * Can you keep the SMP bringup code in place and re-use it from the PSCI handlers instead of #ifndef PSCIing it? So maybe rename arch/arm/cpu/armv7/sunxi/psci.S to .../sunxi/smp.S? My idea here is to make PSCI an option in addition to the current SMP HYP mode code. So that for instance on VExpress (or better: Arndale) you could either use the existing code using the kernel's platform SMP code or enable PSCI in u-boot and let the kernel use that, too. The main problem is the SMP wake-up code in u-boot. With PSCI, you really don't want to wake up the secondaries at all, and you wait until the kernel does an SMC. The current code wakes up the CPUs unconditionnally, and put them in a separate pen, and I'd really like to avoid dealing with a pen in the PSCI case (stupid platforms like VExpress might still require it, but that's an orthogonal discussion). I maybe ask too much for the first incarnation of the code, but that is how I would like to eventually see it. AFAIK Linux prefers PSCI over platform-defined SMP code, so this should work out of the box. Not really. So far, it will use the the platform SMP code if it is defined, and fallback to PSCI otherwise. There were patches from Stephen Boyd to use the enable-method property in the cpu node to select PSCI though. I need to ping him on that. * Is the use of TPIDRPRW Co. really safe? It looks like as we seem to be the only secure user (and they are banked), but I am just curious whether there is any prior art in using those registers temporarily. As you said, we own secure mode entirely. So they really are scratch registers, free to be used. ... The kernel now boots in HYP mode, finds its secondary CPU without any additional SMP code, and runs KVM out of the box. Hopefully, the Xen/ARM guys can do the same fairly easily. BTW: Yesterday my PSCI host patches for Xen have been committed, so Xen should be able to use that feature just like the kernel does. Excellent! I really need to sort these patches out and repost the whole series... Thanks, M. -- Jazz is not dead. It just smells funny... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] ARMv7: add PSCI support to u-boot
On 12/06/2013 01:12 PM, Marc Zyngier wrote: Hi Andre, On 06/12/13 11:43, Andre Przywara wrote: On 11/21/2013 09:59 AM, Marc Zyngier wrote: PSCI is an ARM standard that provides a generic interface that ... Thanks again for posting this, I like the idea of adding PSCI handlers to u-boot for several platforms very much. This patch series contains 3 parts: - the first four patches are just bug fixes Those are fine, I already acked those patches. - the next three contain the generic PSCI code and build infrastructure As I heard you will rework these anyway, I will refrain from commenting in detail, just some generic comments on the approach: * Is the creation of a top-level psci directory for holding the PSCI binaries really necessary? Should this mimic the spl approach? Can you consider to move this at least into the arch/arm directory, as PSCI is ARM specific? Or add it to the SPL directory, as this serves a similar purpose? But maybe your new approach renders this all moot. The code base I have at the moment completely gets rid of the psci directory, and make that code a separate section that can be relocated to secure memory or simply marked as reserved. Nice! * Can you keep the SMP bringup code in place and re-use it from the PSCI handlers instead of #ifndef PSCIing it? So maybe rename arch/arm/cpu/armv7/sunxi/psci.S to .../sunxi/smp.S? My idea here is to make PSCI an option in addition to the current SMP HYP mode code. So that for instance on VExpress (or better: Arndale) you could either use the existing code using the kernel's platform SMP code or enable PSCI in u-boot and let the kernel use that, too. The main problem is the SMP wake-up code in u-boot. With PSCI, you really don't want to wake up the secondaries at all, and you wait until the kernel does an SMC. The current code wakes up the CPUs unconditionnally, Yes, and I want to do away with this if PSCI is defined - as this is not needed. I just asked for keeping the SMP wakeup code as generic as possible and neither tie it to PSCI nor HYP mode, so that either of them can reference that. But, ... and put them in a separate pen, and I'd really like to avoid dealing with a pen in the PSCI case (stupid platforms like VExpress might still require it, but that's an orthogonal discussion). Yes, there is indeed this problem with the pen. Maybe one can use your upcoming relocation code to move the pen to a more secure place (defined per platform). With avoid dealing with a pen you mean to wakeup from the system's pen and immediately jump to the OS init code, without staying in a wfi loop in some special memory? I maybe ask too much for the first incarnation of the code, but that is how I would like to eventually see it. AFAIK Linux prefers PSCI over platform-defined SMP code, so this should work out of the box. Not really. So far, it will use the the platform SMP code if it is defined, and fallback to PSCI otherwise. Indeed. So I was mistaken on this. I thought it worked this way once at least with Highbank/Midway (could have been an internal branch, though). There were patches from Stephen Boyd to use the enable-method property in the cpu node to select PSCI though. I need to ping him on that. That one that is mandatory on ARM64? Makes sense, then. Regards, Andre. * Is the use of TPIDRPRW Co. really safe? It looks like as we seem to be the only secure user (and they are banked), but I am just curious whether there is any prior art in using those registers temporarily. As you said, we own secure mode entirely. So they really are scratch registers, free to be used. ... The kernel now boots in HYP mode, finds its secondary CPU without any additional SMP code, and runs KVM out of the box. Hopefully, the Xen/ARM guys can do the same fairly easily. BTW: Yesterday my PSCI host patches for Xen have been committed, so Xen should be able to use that feature just like the kernel does. Excellent! I really need to sort these patches out and repost the whole series... Thanks, M. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] ARMv7: add PSCI support to u-boot
On 06/12/13 13:03, Andre Przywara wrote: Yes, there is indeed this problem with the pen. Maybe one can use your upcoming relocation code to move the pen to a more secure place (defined per platform). Yes, that's what I've done. Also rewritten some of it to be able to execute solely in secure mode (you can't do SMC+HVC there, as you'd try to run non-secure from secure RAM...). With avoid dealing with a pen you mean to wakeup from the system's pen and immediately jump to the OS init code, without staying in a wfi loop in some special memory? Even better, waking up the CPUs from power-off directly, configuring the per-cpu part of the GIC and jumping to the kernel. Almost nothing. M. -- Jazz is not dead. It just smells funny... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] ARMv7: add PSCI support to u-boot
On 22/11/13 03:58, Anup Patel wrote: On 22 November 2013 07:24, Christoffer Dall christoffer.d...@linaro.org wrote: On 21 November 2013 07:04, Marc Zyngier marc.zyng...@arm.com wrote: Hi Rob, On 21/11/13 14:28, Rob Herring wrote: On Thu, Nov 21, 2013 at 2:59 AM, Marc Zyngier marc.zyng...@arm.com wrote: PSCI is an ARM standard that provides a generic interface that supervisory software can use to manage power in the following situations: - Core idle management - CPU hotplug - big.LITTLE migration models - System shutdown and reset It basically allows the kernel to offload these tasks to the firmware, and rely on common kernel side code. More importantly, it gives a way to ensure that CPUs enter the kernel at the appropriate exception level (ie HYP mode, to allow the use of the virtualization extensions), even across events like CPUs being powered off/on or suspended. The main idea here is to reuse some of the existing u-boot code to create a separate blob that can live in SRAM (or a reserved page of memory), containing a secure monitor that will implement the PSCI operations. This code will still be alive when u-boot is long gone, hence the need for a piece of memory that will not be touched by the OS. Interesting. As a separate binary, I'm not sure this belongs or benefits from being in u-boot. I would like to see this as a more generic secure firmware loader or PSCI code be a part of u-boot code directly. With the latter, you could extend it beyond PSCI to things like env variable access (basically equivalent to UEFI runtime services). I'm not saying we should do that though. So I started this by having something that was actually part of u-boot, and copying itself into SRAM, patching stuff as it went. The net result was that I was reinventing a runtime linker. Needless to say, I gave up quickly... ;-) I'm curious; why did you need to reinvent a linker? This was all just assembly right? Could you not write it as position independent code and just copy a blob of code and be done with it? We really cannot assume that all power related programming sequence for SOCs will simple and easy to fit in position independent code. I am not saying it is impossible but it will not be easy to translate complex C code to position independent assembly code. An Independent binary of a secured firmware makes more sense here. Also, if secured firmware is an independent binary then it need not be open source. If it is not open source, it has no purpose in u-boot, and I have strictly no intention to support such a thing. Quite the opposite, actually. Eventually, I want to get completely rid of the loading bit, and just let u-boot relocate its secure monitor part into secure memory (irrespective of it being actually secure or not). M. -- Jazz is not dead. It just smells funny... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] ARMv7: add PSCI support to u-boot
On 22/11/13 01:54, Christoffer Dall wrote: On 21 November 2013 07:04, Marc Zyngier marc.zyng...@arm.com wrote: Hi Rob, On 21/11/13 14:28, Rob Herring wrote: On Thu, Nov 21, 2013 at 2:59 AM, Marc Zyngier marc.zyng...@arm.com wrote: PSCI is an ARM standard that provides a generic interface that supervisory software can use to manage power in the following situations: - Core idle management - CPU hotplug - big.LITTLE migration models - System shutdown and reset It basically allows the kernel to offload these tasks to the firmware, and rely on common kernel side code. More importantly, it gives a way to ensure that CPUs enter the kernel at the appropriate exception level (ie HYP mode, to allow the use of the virtualization extensions), even across events like CPUs being powered off/on or suspended. The main idea here is to reuse some of the existing u-boot code to create a separate blob that can live in SRAM (or a reserved page of memory), containing a secure monitor that will implement the PSCI operations. This code will still be alive when u-boot is long gone, hence the need for a piece of memory that will not be touched by the OS. Interesting. As a separate binary, I'm not sure this belongs or benefits from being in u-boot. I would like to see this as a more generic secure firmware loader or PSCI code be a part of u-boot code directly. With the latter, you could extend it beyond PSCI to things like env variable access (basically equivalent to UEFI runtime services). I'm not saying we should do that though. So I started this by having something that was actually part of u-boot, and copying itself into SRAM, patching stuff as it went. The net result was that I was reinventing a runtime linker. Needless to say, I gave up quickly... ;-) I'm curious; why did you need to reinvent a linker? This was all just assembly right? Could you not write it as position independent code and just copy a blob of code and be done with it? There is more than just that. Some of the code is actually shared between u-boot and PSCI, so in the process of copying to SRAM, you have to patch some things there. Some of it could be rewritten as being PIC, but there is more fundamental issues about the current approach: the way the code is structured, it expects to be able to switch directly from secure to non-secure in the same memory space. With secure memory, that's a killer (you're pulling the rug (and entire floor) from under your own feet). So I'm now heading towards changing the non-secure-switching part of u-boot to be able to return directly into the payload, instead of carrying on within the same memory-space. This will then allow moving that code to secure memory, and then we'll be able to share it between u-boot and PSCI. Well, I think... ;-) M. -- Jazz is not dead. It just smells funny... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/9] ARMv7: add PSCI support to u-boot
PSCI is an ARM standard that provides a generic interface that supervisory software can use to manage power in the following situations: - Core idle management - CPU hotplug - big.LITTLE migration models - System shutdown and reset It basically allows the kernel to offload these tasks to the firmware, and rely on common kernel side code. More importantly, it gives a way to ensure that CPUs enter the kernel at the appropriate exception level (ie HYP mode, to allow the use of the virtualization extensions), even across events like CPUs being powered off/on or suspended. The main idea here is to reuse some of the existing u-boot code to create a separate blob that can live in SRAM (or a reserved page of memory), containing a secure monitor that will implement the PSCI operations. This code will still be alive when u-boot is long gone, hence the need for a piece of memory that will not be touched by the OS. This patch series contains 3 parts: - the first four patches are just bug fixes - the next three contain the generic PSCI code and build infrastructure - the last two implement the CPU_ON method of the Allwinner A20 (aka sun7i). I realize the A20 u-boot code is not upstream yet (BTW is anyone actively working on that?), but hopefully that should give a good idea of how things are structured so far. The patches are against a merge of u-boot mainline and the sunxi tree as of ten days ago. As for using this code, it goes like this: sun7i# ext2load mmc 0:1 0x4000 /boot/sunxi-psci.bin 908 bytes read in 18 ms (48.8 KiB/s) sun7i# cp 0x4000 0x4000 0x1000 sun7i# ext2load mmc 0:1 40008000 /boot/zImage 3415087 bytes read in 184 ms (17.7 MiB/s) sun7i# setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/nfs nfsroot=10.1.203.35:/export/roots/bobby-brown,tcp,v3 rw ip=dhcp sun7i# bootz 40008000 The kernel now boots in HYP mode, finds its secondary CPU without any additional SMP code, and runs KVM out of the box. Hopefully, the Xen/ARM guys can do the same fairly easily. I'm wildly cross-posting this patch series, including to lists I'm not subscribed to. Please keep me on Cc for any comment you may have. Cheers, M. Marc Zyngier (9): ARM: HYP/non-sec: fix alignment requirements for vectors ARM: HYP/non-sec: move switch to non-sec to the last boot phase ARM: HYP/non-sec: add a barrier after setting SCR.NS==1 ARM: non-sec: reset CNTVOFF to zero ARM: HYP/non-sec: add generic ARMv7 PSCI code ARM: HYP/non-sec: make pen code sections depend on !ARMV7_PSCI ARM: HYP/non-sec: add the option for a second-stage monitor sunxi: HYP/non-sec: add sun7i PSCI backend sunxi: HYP/non-sec: configure CNTFRQ on all CPUs Makefile | 5 ++ arch/arm/cpu/armv7/Makefile | 4 ++ arch/arm/cpu/armv7/nonsec_virt.S | 21 +- arch/arm/cpu/armv7/psci.S| 109 arch/arm/cpu/armv7/sunxi/Makefile| 3 + arch/arm/cpu/armv7/sunxi/config.mk | 6 +- arch/arm/cpu/armv7/sunxi/psci.S | 119 +++ arch/arm/cpu/armv7/sunxi/u-boot-psci.lds | 63 arch/arm/cpu/armv7/virt-v7.c | 2 + arch/arm/lib/bootm.c | 5 +- include/configs/sun7i.h | 7 ++ psci/Makefile| 67 + 12 files changed, 406 insertions(+), 5 deletions(-) create mode 100644 arch/arm/cpu/armv7/psci.S create mode 100644 arch/arm/cpu/armv7/sunxi/psci.S create mode 100644 arch/arm/cpu/armv7/sunxi/u-boot-psci.lds create mode 100644 psci/Makefile -- 1.8.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] ARMv7: add PSCI support to u-boot
On Thu, Nov 21, 2013 at 2:59 AM, Marc Zyngier marc.zyng...@arm.com wrote: PSCI is an ARM standard that provides a generic interface that supervisory software can use to manage power in the following situations: - Core idle management - CPU hotplug - big.LITTLE migration models - System shutdown and reset It basically allows the kernel to offload these tasks to the firmware, and rely on common kernel side code. More importantly, it gives a way to ensure that CPUs enter the kernel at the appropriate exception level (ie HYP mode, to allow the use of the virtualization extensions), even across events like CPUs being powered off/on or suspended. The main idea here is to reuse some of the existing u-boot code to create a separate blob that can live in SRAM (or a reserved page of memory), containing a secure monitor that will implement the PSCI operations. This code will still be alive when u-boot is long gone, hence the need for a piece of memory that will not be touched by the OS. Interesting. As a separate binary, I'm not sure this belongs or benefits from being in u-boot. I would like to see this as a more generic secure firmware loader or PSCI code be a part of u-boot code directly. With the latter, you could extend it beyond PSCI to things like env variable access (basically equivalent to UEFI runtime services). I'm not saying we should do that though. BTW, you will need to mark this region reserved in the dtb if in system RAM. Rob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] ARMv7: add PSCI support to u-boot
On 21 November 2013 07:04, Marc Zyngier marc.zyng...@arm.com wrote: Hi Rob, On 21/11/13 14:28, Rob Herring wrote: On Thu, Nov 21, 2013 at 2:59 AM, Marc Zyngier marc.zyng...@arm.com wrote: PSCI is an ARM standard that provides a generic interface that supervisory software can use to manage power in the following situations: - Core idle management - CPU hotplug - big.LITTLE migration models - System shutdown and reset It basically allows the kernel to offload these tasks to the firmware, and rely on common kernel side code. More importantly, it gives a way to ensure that CPUs enter the kernel at the appropriate exception level (ie HYP mode, to allow the use of the virtualization extensions), even across events like CPUs being powered off/on or suspended. The main idea here is to reuse some of the existing u-boot code to create a separate blob that can live in SRAM (or a reserved page of memory), containing a secure monitor that will implement the PSCI operations. This code will still be alive when u-boot is long gone, hence the need for a piece of memory that will not be touched by the OS. Interesting. As a separate binary, I'm not sure this belongs or benefits from being in u-boot. I would like to see this as a more generic secure firmware loader or PSCI code be a part of u-boot code directly. With the latter, you could extend it beyond PSCI to things like env variable access (basically equivalent to UEFI runtime services). I'm not saying we should do that though. So I started this by having something that was actually part of u-boot, and copying itself into SRAM, patching stuff as it went. The net result was that I was reinventing a runtime linker. Needless to say, I gave up quickly... ;-) I'm curious; why did you need to reinvent a linker? This was all just assembly right? Could you not write it as position independent code and just copy a blob of code and be done with it? (I'm sure it's not that simple, but I'm curious to know why). -Christoffer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] ARMv7: add PSCI support to u-boot
Hi Rob, On 21/11/13 14:28, Rob Herring wrote: On Thu, Nov 21, 2013 at 2:59 AM, Marc Zyngier marc.zyng...@arm.com wrote: PSCI is an ARM standard that provides a generic interface that supervisory software can use to manage power in the following situations: - Core idle management - CPU hotplug - big.LITTLE migration models - System shutdown and reset It basically allows the kernel to offload these tasks to the firmware, and rely on common kernel side code. More importantly, it gives a way to ensure that CPUs enter the kernel at the appropriate exception level (ie HYP mode, to allow the use of the virtualization extensions), even across events like CPUs being powered off/on or suspended. The main idea here is to reuse some of the existing u-boot code to create a separate blob that can live in SRAM (or a reserved page of memory), containing a secure monitor that will implement the PSCI operations. This code will still be alive when u-boot is long gone, hence the need for a piece of memory that will not be touched by the OS. Interesting. As a separate binary, I'm not sure this belongs or benefits from being in u-boot. I would like to see this as a more generic secure firmware loader or PSCI code be a part of u-boot code directly. With the latter, you could extend it beyond PSCI to things like env variable access (basically equivalent to UEFI runtime services). I'm not saying we should do that though. So I started this by having something that was actually part of u-boot, and copying itself into SRAM, patching stuff as it went. The net result was that I was reinventing a runtime linker. Needless to say, I gave up quickly... ;-) What could be done would be for u-boot to be at least partially linked to run from some other region. That would allow for the secure mode services to be both part of u-boot, and stay resident. That'd probably be a good thing to have a look at. BTW, you will need to mark this region reserved in the dtb if in system RAM. Yes. Eventually, I'd like the psci mode to be entirely generated from u-boot, as well as the eventual RAM reserved. M. -- Jazz is not dead. It just smells funny... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] ARMv7: add PSCI support to u-boot
On 22 November 2013 07:24, Christoffer Dall christoffer.d...@linaro.org wrote: On 21 November 2013 07:04, Marc Zyngier marc.zyng...@arm.com wrote: Hi Rob, On 21/11/13 14:28, Rob Herring wrote: On Thu, Nov 21, 2013 at 2:59 AM, Marc Zyngier marc.zyng...@arm.com wrote: PSCI is an ARM standard that provides a generic interface that supervisory software can use to manage power in the following situations: - Core idle management - CPU hotplug - big.LITTLE migration models - System shutdown and reset It basically allows the kernel to offload these tasks to the firmware, and rely on common kernel side code. More importantly, it gives a way to ensure that CPUs enter the kernel at the appropriate exception level (ie HYP mode, to allow the use of the virtualization extensions), even across events like CPUs being powered off/on or suspended. The main idea here is to reuse some of the existing u-boot code to create a separate blob that can live in SRAM (or a reserved page of memory), containing a secure monitor that will implement the PSCI operations. This code will still be alive when u-boot is long gone, hence the need for a piece of memory that will not be touched by the OS. Interesting. As a separate binary, I'm not sure this belongs or benefits from being in u-boot. I would like to see this as a more generic secure firmware loader or PSCI code be a part of u-boot code directly. With the latter, you could extend it beyond PSCI to things like env variable access (basically equivalent to UEFI runtime services). I'm not saying we should do that though. So I started this by having something that was actually part of u-boot, and copying itself into SRAM, patching stuff as it went. The net result was that I was reinventing a runtime linker. Needless to say, I gave up quickly... ;-) I'm curious; why did you need to reinvent a linker? This was all just assembly right? Could you not write it as position independent code and just copy a blob of code and be done with it? We really cannot assume that all power related programming sequence for SOCs will simple and easy to fit in position independent code. I am not saying it is impossible but it will not be easy to translate complex C code to position independent assembly code. An Independent binary of a secured firmware makes more sense here. Also, if secured firmware is an independent binary then it need not be open source. -- Anup (I'm sure it's not that simple, but I'm curious to know why). -Christoffer ___ kvmarm mailing list kvm...@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
