Re: [U-Boot] how to get u-boot code with arm64: core support
Hi Bhupesh, > U-boot doesn't have ARM trusted firmware support as of now. U-boot for > ARMv8 starts in EL3, whereas UEFI starts in EL2 as trusted firmware itself > is working in EL3. Since the ATF software doesn't really care whether it is loading uefi or u-boot and since it wants to load non-secure images as EL2 or EL1 (https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/user-guide.md See section "Normal World Software Execution"), why would we want to assume u-boot starts in EL3 mode by default? If we want to support EL3 execution for convenience to those that don't have ATF setup, that might make sense, but then shouldn't initial EL3 execution and subsequent switching levels be debug CONFIG options? Thanks. Regards, Darwin Rambo -- View this message in context: http://u-boot.10912.n7.nabble.com/PATCH-v15-00-10-arm64-patch-tp167751p172079.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v15 07/10] arm64: core support
On 14-01-22 04:29 PM, Scott Wood-2 [via U-Boot] wrote: > > > On Tue, 2014-01-14 at 09:52 +0800, FengHua wrote: >> hi bhupesh, >> >>> Hi David, >>> >>> In reference to my mail above, I see that the transition to EL2 (from EL3) >>> which occurs very early >>> in start.S needs to be changed on lines of the ARMv7 code, i.e. the EL2 >>> transition should happen just >>> before Linux is booted up by the u-boot. >>> >>> The reason for the same is that a no of ARM IPs like GIC, SMMU and >>> TZPC/TZASC need to be configured to >>> allow non-secure accesses from Linux world (which runs in EL1 mode). Adding >>> the assembly code for all >>> such IPs in 'setup_el3' function in start.S, will bloat the start.S and >>> also increase the chances of a >>> bug in the assembly code. >>> >>> Hence, I would like to propose a strategy to shift from EL3 to EL2 to some >>> point in u-boot code after the >>> C Run Time has been initialized (similar to present ARMv7 u-boot code). >>> >>> If you are ok with the same, I can try to send out some RFC patches rebased >>> against your latest v16 code-base. >>> >>> Please let me know. >>> Regards, >>> Bhupesh >>> >> Actually, patch v16 did exception level switch in the way as you said. >> please review the code. >> Both master and slaves switch to el2(el1) just before jumping to linux >> kernel. BTW,if any good conception please feel free to patch it. > > How would you handle running U-Boot under a secure firmware, or under a > hypervisor? Why not take the Linux approach of running most code in > EL1, with exception handlers pointing at code to handle special > situations (such as returning to EL2 before OS entry)? > > As for bloating start.S, could leaving EL3 be done in early C code > rather than in early asm or late C code? Or, bundle U-Boot with a tiny > "insecure firmware" that provides the minimum functionality needed with > similar APIs that would be used with real secure firmware. Hi Scott, Why is any EL3 code in u-boot at all? That's not the ARM ATF approach I believe but I'm not an expert in this. Please see http://lists.denx.de/pipermail/u-boot/2014-January/171581.html and (https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/user-guide.md See section "Normal World Software Execution") Thanks. Darwin > > -Scott > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > > > > > ___ > If you reply to this email, your message will be added to the discussion > below: > http://u-boot.10912.n7.nabble.com/PATCH-v15-00-10-arm64-patch-tp167751p172101.html > > To unsubscribe from [PATCH v15 00/10] arm64 patch, visit > http://u-boot.10912.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=167751&code=ZHJhbWJvQGJyb2FkY29tLmNvbXwxNjc3NTF8LTQ0Nzc3MTIxNQ== > -- View this message in context: http://u-boot.10912.n7.nabble.com/PATCH-v15-00-10-arm64-patch-tp167751p172102.html Sent from the U-Boot mailing list archive at Nabble.com.___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how to get u-boot code with arm64: core support
On 14-01-25 11:46 AM, bhupesh.sha...@freescale.com [via U-Boot] wrote: > > >> >> However, if we set up u-boot so that it can wake up at any security >> level and migrate to non-secure EL1, that might be a nice compromise. >> But having specific EL3 startup assumptions and code that is always >> present in u-boot seems like the wrong approach to me. At the very >> least, we should wrap the EL3 code in a CONFIG option since this is not >> the planned entry state for final deployment. > > ... You seem to miss a critical detail here, security extensions were also > part > of the ARMv7 architecture (although optional) and were controlled by the > ID_PFR1, Processor Feature Register 1, Security Extensions, bits[7:4]: > > Permitted values are: > 0b Not implemented. > 0b0001 Security Extensions implemented. > > So, there was a likelihood that some ARMv7 SoCs still didn't have security > extensions > enabled - I have used one and hence can vouch that a u-boot running as > bare-metal s/w > helped me in early SoC bringup. > > In ARMv8, we still have the AArch32 state which still has a ID_PFR1_EL1 > register, with > the same definition for security extension bits. > > I agree that for AArch64 state, it makes sense that the s/w to be launched at > reset > (usually a BootROM or ATF) executes in a Secure aware (i.e. is EL3 aware) and > then provides > control to a bootloader running in EL2 world (the case presently with UEFI). > > But that binds the bootloader, in this case u-boot, with an ATF being > available before > the first early bootloader s/w can be used to play-around with the Pre-SoC > emulators or even the > SoC. > > A midway solution can be still have u-boot AArch64 EL3 compliant, but under a > #ifdef which gets turned-off > when u-boot is launched with ATF and turned-on when u-boot is launched as the > 1st s/w component > on the SoC (and in this case u-boot starts up in secure EL2 and assumes that > all boot-time or run-time security settings > are taken care of by the ATF and in case any board/platform specific security > settings need to be applied the u-boot code > can do the same as it is running in secure EL2). I think that should make > both the world's happy. That's exactly what I suggested earlier when I mentioned a CONFIG option for EL3-specific code. Thanks for the detailed and clear response. > > I add David Feng in cc here for his views on the same and request others as > well to pitch in with their thoughts. > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > > > > > ___ > If you reply to this email, your message will be added to the discussion > below: > http://u-boot.10912.n7.nabble.com/PATCH-v15-00-10-arm64-patch-tp167751p172379.html > > To unsubscribe from [PATCH v15 00/10] arm64 patch, visit > http://u-boot.10912.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=167751&code=ZHJhbWJvQGJyb2FkY29tLmNvbXwxNjc3NTF8LTQ0Nzc3MTIxNQ== > -- View this message in context: http://u-boot.10912.n7.nabble.com/PATCH-v15-00-10-arm64-patch-tp167751p172383.html Sent from the U-Boot mailing list archive at Nabble.com.___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fatls shows duplicated entries with long and short names
Hello, If it helps, I would respectfully like to add that I reverted this change and it fixes my problem nicely. I'm on an ARM platform (not yet upstreamed to u-boot), with a microSD card inserted with valid files on it that I can read on other systems. I have an Oct 16, 2013 version of U-Boot 2013.10 Before I was seeing: capri> fatls mmc 1 dcim/106gopro ./ ../ 486383878 gopr0150.mp4 486383878 gopr0150.mp4 185120785 gopr0151.mp4 185120785 gopr0151.mp4 75273257 gopr0152.mp4 75273257 gopr0152.mp4 660782172 gopr0153.mp4 660782172 gopr0153.mp4 735056468 gopr0154.mp4 735056468 gopr0154.mp4 7571812 gopr0155.jpg 7571812 gopr0155.jpg 7670056 gopr0156.jpg 7670056 gopr0156.jpg 7801014 gopr0157.jpg 7801014 gopr0157.jpg 172345390 gopr0158.mp4 172345390 gopr0158.mp4 1501760194 gopr0159.mp4 1501760194 gopr0159.mp4 56610361 gopr0160.mp4 56610361 gopr0160.mp4 1069538258 gopr0161.mp4 1069538258 gopr0161.mp4 7301275 gopr0162.jpg 7301275 gopr0162.jpg 1890783532 gopr0163.mp4 1890783532 gopr0163.mp4 28 file(s), 2 dir(s) Now by putting the checksum calculation inside the if statement I am seeing: capri> fatls mmc 1 dcim/106gopro ./ ../ 486383878 gopr0150.mp4 185120785 gopr0151.mp4 75273257 gopr0152.mp4 660782172 gopr0153.mp4 735056468 gopr0154.mp4 7571812 gopr0155.jpg 7670056 gopr0156.jpg 7801014 gopr0157.jpg 172345390 gopr0158.mp4 1501760194 gopr0159.mp4 56610361 gopr0160.mp4 1069538258 gopr0161.mp4 7301275 gopr0162.jpg 1890783532 gopr0163.mp4 14 file(s), 2 dir(s) I sincerely hope this helps the discussion. Best Regards, Darwin Rambo Broadcom Corporation -- View this message in context: http://u-boot.10912.n7.nabble.com/fatls-shows-duplicated-entries-with-long-and-short-names-tp165377p168231.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fatls shows duplicated entries with long and short names
I reverted my local change and the directory listing shows no duplicates
anymore which is surprising. An inspection of the generated assembly shows
more or less the same code with the exception of the early branch taken if
'dols' is 0. The 16/8 comparison is still awkward, but at this point I'm not
confident that is the real problem here. The changing result with the same
original code seems to point to perhaps a different root cause.
Here's the original assembly:
if (vfat_enabled) {
__u8 csum = mkcksum(dentptr->name,
dentptr->ext)
;
ae012560: e1a4mov r0, r4
ae012564: e2841008add r1, r4, #8
ae012568: ebfffc81bl ae011774
if (dols && csum == prevcksum) {
ae01256c: e59dc010ldr ip, [sp, #16]
ae012570: e35ccmp ip, #0
ae012574: 0a05beq ae012590
ae012578: e59dc024ldr ip, [sp, #36] ; 0x24
ae01257c: e15ccmp r0, ip
prevcksum = 0x;
ae012580: 030fcfffmovweq ip, #65535 ; 0x
dentptr++;
ae012584: 02844020addeq r4, r4, #32
return NULL;
}
if (vfat_enabled) {
__u8 csum = mkcksum(dentptr->name,
dentptr->ext)
;
if (dols && csum == prevcksum) {
prevcksum = 0x;
ae012588: 058dc024streq ip, [sp, #36] ; 0x24
ae01258c: 0a35beq ae012668
dentptr++;
continue;
}
}
Here's the version without the local crc variable:
if (vfat_enabled) {
if (dols && mkcksum(dentptr->name,
dentptr->ext)
== prevcksum) {
ae012560: e59dc010ldr ip, [sp, #16]
ae012564: e35ccmp ip, #0
ae012568: 0a08beq ae012590
ae01256c: e1a4mov r0, r4
ae012570: e2841008add r1, r4, #8
ae012574: ebfffc7ebl ae011774
ae012578: e59dc024ldr ip, [sp, #36] ; 0x24
ae01257c: e15ccmp r0, ip
prevcksum = 0x;
ae012580: 030fcfffmovweq ip, #65535 ; 0x
dentptr++;
ae012584: 02844020addeq r4, r4, #32
debug("Dentname == NULL - %d\n", i);
return NULL;
}
if (vfat_enabled) {
if (dols && mkcksum(dentptr->name,
dentptr->ext)
== prevcksum) {
prevcksum = 0x;
ae012588: 058dc024streq ip, [sp, #36] ; 0x24
ae01258c: 0a35beq ae012668
dentptr++;
continue;
}
}
--
View this message in context:
http://u-boot.10912.n7.nabble.com/fatls-shows-duplicated-entries-with-long-and-short-names-tp165377p168237.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
