Linaro-uefi

linaro-uefi@lists.linaro.org

811 discussions

[edk2] [PATCH] ArmPlatformPkg: PL061: fix accessing gpio value

by Haojian Zhuang

The way of accessing PL061 GPIODATA register is wrong. The spec said in below. In order to write to GPIODATA, the corresponding bits in the mask, resulting from the address bus, PADDR[9:2], must be HIGH. Otherwise the bit values remain unchanged by the write. Similarly, the values read from this register are determined for each bit, by the mask bit derived from the address used to access the data register, PADDR[9:2]. Bits that are 1 in the address mask cause the corresponding bits in GPIODATA to be read, and bits that are 0 in the address mask cause the corresponding bits in GPIODATA to be read as 0, regardless of their value. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Haojian Zhuang <haojian.zhuang(a)linaro.org> --- ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c index ff05662..35418c9 100644 --- a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c +++ b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c @@ -125,7 +125,7 @@ Get ( } } - if (MmioRead8 (PL061_GPIO_DATA_REG) & GPIO_PIN_MASK_HIGH_8BIT(Gpio)) { + if (MmioRead8 (PL061_GPIO_DATA_REG + (GPIO_PIN_MASK_HIGH_8BIT(Gpio) << 2))) { *Value = 1; } else { *Value = 0; @@ -186,14 +186,14 @@ Set ( case GPIO_MODE_OUTPUT_0: // Set the corresponding data bit to LOW for 0 - MmioAnd8 (PL061_GPIO_DATA_REG, GPIO_PIN_MASK_LOW_8BIT(Gpio)); + MmioAnd8 (PL061_GPIO_DATA_REG + (GPIO_PIN_MASK_HIGH_8BIT(Gpio) << 2), GPIO_PIN_MASK_LOW_8BIT(Gpio)); // Set the corresponding direction bit to HIGH for output MmioOr8 (PL061_GPIO_DIR_REG, GPIO_PIN_MASK_HIGH_8BIT(Gpio)); break; case GPIO_MODE_OUTPUT_1: // Set the corresponding data bit to HIGH for 1 - MmioOr8 (PL061_GPIO_DATA_REG, GPIO_PIN_MASK_HIGH_8BIT(Gpio)); + MmioOr8 (PL061_GPIO_DATA_REG + (GPIO_PIN_MASK_HIGH_8BIT(Gpio) << 2), GPIO_PIN_MASK_HIGH_8BIT(Gpio)); // Set the corresponding direction bit to HIGH for output MmioOr8 (PL061_GPIO_DIR_REG, GPIO_PIN_MASK_HIGH_8BIT(Gpio)); break; -- 2.1.4

9 years, 10 months

[PATCH] BeagleBoardPkg: fold configuration header into FD build

by Ard Biesheuvel

Instead of using a separate post-processing tool to add a configuration header to the flash image, add it to the FDF definition so that it gets emitted by the EDK2 build system. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> --- BeagleBoardPkg/BeagleBoardPkg.fdf | 11 ++++++++++- BeagleBoardPkg/ConfigurationHeader.bin | Bin 0 -> 512 bytes 2 files changed, 10 insertions(+), 1 deletion(-) create mode 100644 BeagleBoardPkg/ConfigurationHeader.bin diff --git a/BeagleBoardPkg/BeagleBoardPkg.fdf b/BeagleBoardPkg/BeagleBoardPkg.fdf index a6392440e64f..f101bdb7cd66 100644 --- a/BeagleBoardPkg/BeagleBoardPkg.fdf +++ b/BeagleBoardPkg/BeagleBoardPkg.fdf @@ -48,7 +48,16 @@ [FD.BeagleBoard_EFI] # RegionType <FV, DATA, or FILE> # ################################################################################ -0x00000000|0x000B0000 +0x00000000|0x00000200 +FILE = BeagleBoardPkg/ConfigurationHeader.bin + +0x00000200|0x00000008 +DATA = { + 0xF8, 0xDF, 0x0A, 0x00, # image size: 0xB0000 - 0x208 == 0xAFDF8 + 0x08, 0x82, 0x00, 0x80 # entry point: 0x80008208 +} + +0x00000208|0x000B0000 gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize FV = FVMAIN_COMPACT diff --git a/BeagleBoardPkg/ConfigurationHeader.bin b/BeagleBoardPkg/ConfigurationHeader.bin new file mode 100644 index 0000000000000000000000000000000000000000..150b3849fc35f6526f51ce32b3ab30c9555b284f GIT binary patch literal 512 zcmZ3$z`zgy#K^$eBiJ=0#M93`n1SH~P$C9d63BM;2y*m=iv0%yG-;}G4<0yhfRT}b z;V&ZtYXi_^W*`pWVq)e3GDLxFb07o*9v@B^n`Z+f11DGxD)mK>0cZpm90HjKW&uec n;)04d0%?%hf({p$jG$u2j?CSqq{_&^_=p9s97s7x?@$B)<?bO_ literal 0 HcmV?d00001 -- 1.9.1

9 years, 10 months

[PATCH v2 0/2] ArmPkg/ArmGicArchLib: use common source

by Ryan Harkin

The Arm and Aarch64 source files for ArmGicArchLib are copy/paste of each other with one minor difference to how they check for if the platform has GICv3. I made the change in two patches so that the diff could be identified separately from the move commit. The first patch makes both the Arm and Aarch64 versions identical and uses conditional compilation to handle Arm vs Aarch64. [PATCH v2 1/2] ArmPkg/ArmGicLibArchLib: common check for GICv3 The second patch then removes the duplication in favour of a single source file. [PATCH v2 2/2] ArmPkg/ArmGicArchLib: use common source file Changes since v1 - rename new function from ArmGicArchLibHasGicv3 to GicSystemRegistersSupported - make new function STATIC - remove whitespace change - keep the version with the space before and after '|'

9 years, 11 months

[PATCH 0/2] ArmPkg/ArmGicArchLib: use common source file

by Ryan Harkin

The Arm and Aarch64 source files for ArmGicArchLib are copy/paste of each other with one minor difference to how they check for if the platform has GICv3. I made the change in two patches so that the diff could be identified separately from the move commit. The first patch makes both the Arm and Aarch64 versions identical and uses conditional compilation to handle Arm vs Aarch64. [PATCH 1/2] ArmPkg/ArmGicLibArchLib: common check for GICv3 The second patch then removes the duplication in favour of a single source file. [PATCH 2/2] ArmPkg/ArmGicArchLib: use common source file

9 years, 11 months

[PATCH v2 0/6] ArmPkg: Move FDT and initrd offset higher in RAM

by Ryan Harkin

The previous post was a single patch. I've expanded the remit here a little, but I'll count them all as v2. This patch is only an informational DEBUG build only bit of output to let the developer be confident that things are loaded to sensible location. It is optional: [PATCH v2 1/6] ArmPkg: BdsLib: debug to show load addresses These two are the ones that actually fix the problem of the FDT and initrd being loaded to the wrong location according to the kernel recommendations: [PATCH v2 2/6] ArmPkg: BdsLib: move FDT above 128MiB boundary [PATCH v2 3/6] ArmPkg: BdsLib: move initrd above 128MiB boundary This patch removes the fixed PCDs that Ard mentioned. It is also optional, but I think it is a worthy tidyup: [PATCH v2 4/6] ArmPkg: BdsLib: replace fixed pcds with constants These two patches aren't part of the series, but I've included them because I needed them to get things working again. I actually would like these upstream because they are infini tely better than what is there, but I don't mind too much if I have to carry them in my own branch: [PATCH v2 5/6] ArmPlatformPkg/Bds: remove detection of EFI stub [PATCH v2 6/6] ArmPlatformPkg: tc2: match default config to Linaro

9 years, 11 months

Re: [Linaro-uefi] [PATCH] ArmPkg: Move FDT offset higher in RAM

by Ryan Harkin

[- CC edk2-devel + CC linaro-uefi] On 28 July 2015 at 11:02, Ard Biesheuvel <ard.biesheuvel(a)linaro.org> wrote: > On 28 July 2015 at 11:41, Ryan Harkin <ryan.harkin(a)linaro.org> wrote: > > > > > > On 28 July 2015 at 10:26, Ard Biesheuvel <ard.biesheuvel(a)linaro.org> > wrote: > >> > >> On 28 July 2015 at 11:01, Ryan Harkin <ryan.harkin(a)linaro.org> wrote: > >> > [+ Tixy as he's interested in making sure UEFI follows the Linux > >> > requirements] > >> > > >> > On 28 July 2015 at 07:39, Ard Biesheuvel <ard.biesheuvel(a)linaro.org> > >> > wrote: > >> > >> >> > >> >> On 27 July 2015 at 22:42, Ryan Harkin <ryan.harkin(a)linaro.org> > wrote: > >> >> > Device tree files in recent kernels (eg. Linux 4.2) can be >16KB. > >> >> > > >> >> > The max offset of 0x4000 meant that the device tree would be > >> >> > allocated > >> >> > at a "random address", which more often than not was above the > >> >> > recommended 128MiB boundary. > >> >> > > >> >> > >> >> From Documentation/arm/Booting: > >> >> > >> >> """ > >> >> 4b. Setup the device tree > >> >> ... > >> >> A safe location is just above the 128MiB boundary from start of RAM. > >> >> """ > >> >> > >> >> i.e., the documented protocol explicitly suggests using an address > > >> >> 128 > >> >> MB. > >> >> So what exactly goes wrong if you load it at a random address? > >> > > >> > > >> > For some reason, I've been reading this as "before" 128MiB. How > strange > >> > of > >> > me. > >> > > >> > The advice I was following was from the bottom of the email thread > where > >> > Nicolas Mitre says: > >> > > >> > "You can therefore load everything (zImage, initrd, DTB) sequentially > >> > from the 32MB mark in RAM and be safe." > >> > > >> > But mostly, I was trying to keep the bottom 32MB unused. > >> > > >> > >> Yes, I think that is the primary requirement here. > >> > >> > We don't have the option to load sequentially from 32MB unless I > change > >> > the > >> > code a lot more. I've already tried a hack that placed the 3 files > >> > sequentially from 0x82000000 on TC2 and it works well, although it's > >> > technically wrong because I didn't explicity reserve memory in those > >> > areas > >> > to stop UEFI from using it. > >> > > >> > I'll try changing the max offsets to be all above 128MiB and see if it > >> > still > >> > works. As Tixy pointed out to me, the problem I had with the Linux > >> > Loader's > >> > "random address" for the DTB is that it was always in the same region > >> > that > >> > Linux reserves for CMA. And I think that starts before the DTB is > >> > finished > >> > with. > >> > > >> > >> I think we could simply raise your max address limit to 132 MB: by the > >> looks of it, that is the maximum size the current kernel code will > >> ever be able to support since it uses two adjacent sections to map the > >> FDT, and sections are 2 MB at most when using long descriptors. > > > > > > I've tested it with a patch to change the max offsets to 0x84000000 and > it > > works well. My hacked in debug shows: > > > > linux: address 0x87FD2000 > > linux: length 0x42D248 > > Hmm, this doesn't look right. The zImage should be below 128 MB, since > it infers the base of DRAM by rounding down its own address to a > multiple of 128 MB. > I seem to have missed the part before where the PCD in question also > affects the placement of the zImage and not only the FDT. > > > fdt: address 0x87E6E000 > > fdt: length 0x3FFC > > initrd: address 0x87E73000 > > initrd: length 0x15E600 > > > > So the rules say: > - zImage between 32 MB and 128 MB > - FDT preferably at the next 128 MB boundary > - initrd preferably right above the FDT > > I guess your v1 was best after all: even if the FDT and initrd end up > below 128 MB, it is the best we can do with just this PCD > > OK, I can fix this, but it will take a few more lines of patch. Instead of loading the initrd to LINUX_MAX_OFFSET (ie. gArmTokenSpaceGuid.PcdArmLinuxKernelMaxOffset) we can load it to LINUX_FDT_MAX_OFFSET ( ie. gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset). I don't want to create another PCD for the initrd. Which brings me to a comment i missed earlier: > BTW it seems odd for the LinuxLoader - which is now a separate EFI > application - to use fixed PCDs to parametrise its behavior. I think > it would be justified to hardcode the recommended behavior as per the > Linux/ARM boot protocol right into the LinuxLoader binary. I am trying to keep as little churn as possible, but yes, I agree. It's wrong. Ideally, I'd like to delete the Linux Loader completely, or at least stop using it. But while I'm supporting non-EFI stubbed kernels, I'm stuck. > -- > Ard. > > > > > From this patch: > > > > diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec > > index b30de91..d5b930a 100644 > > --- a/ArmPkg/ArmPkg.dec > > +++ b/ArmPkg/ArmPkg.dec > > @@ -117,7 +117,7 @@ > > # > > gArmTokenSpaceGuid.PcdArmMachineType|0|UINT32|0x0000001E > > # The compressed Linux kernel is expected to be under 128MB from the > > beginning of the System Memory > > - > > > gArmTokenSpaceGuid.PcdArmLinuxKernelMaxOffset|0x08000000|UINT32|0x0000001F > > + > > > gArmTokenSpaceGuid.PcdArmLinuxKernelMaxOffset|0x08400000|UINT32|0x0000001F^M > > # Maximum file size for TFTP servers that do not support 'tsize' > > extension > > gArmTokenSpaceGuid.PcdMaxTftpFileSize|0x01000000|UINT32|0x00000000 > > > > @@ -159,7 +159,7 @@ > > # If the fixed FDT address is not available, then it should be loaded > > below the kernel. > > # The recommendation from the Linux kernel is to have the FDT below > 16KB. > > # (see the kernel doc: Documentation/arm/Booting) > > - gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x4000|UINT32|0x00000023 > > + > gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x08400000|UINT32|0x00000023^M > > # The FDT blob must be loaded at a 64bit aligned address. > > gArmTokenSpaceGuid.PcdArmLinuxFdtAlignment|0x8|UINT32|0x00000026 > > > > > > Of course, the comments will have to change too: "under 128MB" => "above > > 128MiB" and there is no recommendation for the device tree to be < 16KB. > > > > Unless I get further comment, I'll submit a v2 patch as above with the > > comments updated. > > > > > >> > >> > >> BTW it seems odd for the LinuxLoader - which is now a separate EFI > >> application - to use fixed PCDs to parametrise its behavior. I think > >> it would be justified to hardcode the recommended behavior as per the > >> Linux/ARM boot protocol right into the LinuxLoader binary. > >> > >> -- > >> Ard. > >> > >> > > >> > > >> >> > >> >> -- > >> >> Ard. > >> >> > >> >> > >> >> > This email thread explains that the device tree should be placed > >> >> > higher > >> >> > in RAM: > >> >> > > >> >> > > >> >> > > >> >> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/187476.html > >> >> > > >> >> > It also explaines that the kernel may use memory in the 16-32KB > range > >> >> > and that a zImage will by default be uncompressed to an offset of > >> >> > 32KB. > >> >> > > >> >> > Setting the FDT max offset at 128MiB will allow UEFI to place it > >> >> > higher > >> >> > up in memory, thus avoiding the problems with it being loaded to a > >> >> > random address. > >> >> > > >> >> > With this patch, by using AllocateMaxAdress, where possible the > Linux > >> >> > Loader will place the FDT, initrd and kernel at the top of the > 128MiB > >> >> > range, which also allows for more efficient zImage uncompression, > as > >> >> > per > >> >> > the above thread. > >> >> > > >> >> > Contributed-under: TianoCore Contribution Agreement 1.0 > >> >> > Signed-off-by: Ryan Harkin <ryan.harkin(a)linaro.org> > >> >> > --- > >> >> > ArmPkg/ArmPkg.dec | 2 +- > >> >> > 1 file changed, 1 insertion(+), 1 deletion(-) > >> >> > > >> >> > diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec > >> >> > index da0c8a9..67c8cc9 100644 > >> >> > --- a/ArmPkg/ArmPkg.dec > >> >> > +++ b/ArmPkg/ArmPkg.dec > >> >> > @@ -158,7 +158,7 @@ > >> >> > # If the fixed FDT address is not available, then it should be > >> >> > loaded > >> >> > below the kernel. > >> >> > # The recommendation from the Linux kernel is to have the FDT > >> >> > below > >> >> > 16KB. > >> >> > # (see the kernel doc: Documentation/arm/Booting) > >> >> > - > >> >> > gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x4000|UINT32|0x00000023 > >> >> > + > >> >> > > >> >> > > gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x08000000|UINT32|0x00000023 > >> >> > # The FDT blob must be loaded at a 64bit aligned address. > >> >> > gArmTokenSpaceGuid.PcdArmLinuxFdtAlignment|0x8|UINT32|0x00000026 > >> >> > > >> >> > -- > >> >> > 2.1.0 > >> >> > > >> > > >> > > > > > >

9 years, 11 months

Re: [Linaro-uefi] [PATCH] ArmPkg: Move FDT offset higher in RAM

by Leif Lindholm

Apologies for top-posting, I think this conversation should drop edk2-devel and move to linaro-uefi (added to cc), until there is consensus/conclusion. Could the next person replying to this thread delete edk2-devel from the recipient list please? / Leif On Tue, Jul 28, 2015 at 10:41:29AM +0100, Ryan Harkin wrote: > On 28 July 2015 at 10:26, Ard Biesheuvel <ard.biesheuvel(a)linaro.org> wrote: > > > On 28 July 2015 at 11:01, Ryan Harkin <ryan.harkin(a)linaro.org> wrote: > > > [+ Tixy as he's interested in making sure UEFI follows the Linux > > > requirements] > > > > > > On 28 July 2015 at 07:39, Ard Biesheuvel <ard.biesheuvel(a)linaro.org> > > wrote: > > >> > > >> On 27 July 2015 at 22:42, Ryan Harkin <ryan.harkin(a)linaro.org> wrote: > > >> > Device tree files in recent kernels (eg. Linux 4.2) can be >16KB. > > >> > > > >> > The max offset of 0x4000 meant that the device tree would be allocated > > >> > at a "random address", which more often than not was above the > > >> > recommended 128MiB boundary. > > >> > > > >> > > >> From Documentation/arm/Booting: > > >> > > >> """ > > >> 4b. Setup the device tree > > >> ... > > >> A safe location is just above the 128MiB boundary from start of RAM. > > >> """ > > >> > > >> i.e., the documented protocol explicitly suggests using an address > 128 > > >> MB. > > >> So what exactly goes wrong if you load it at a random address? > > > > > > > > > For some reason, I've been reading this as "before" 128MiB. How strange > > of > > > me. > > > > > > The advice I was following was from the bottom of the email thread where > > > Nicolas Mitre says: > > > > > > "You can therefore load everything (zImage, initrd, DTB) sequentially > > > from the 32MB mark in RAM and be safe." > > > > > > But mostly, I was trying to keep the bottom 32MB unused. > > > > > > > Yes, I think that is the primary requirement here. > > > > > We don't have the option to load sequentially from 32MB unless I change > > the > > > code a lot more. I've already tried a hack that placed the 3 files > > > sequentially from 0x82000000 on TC2 and it works well, although it's > > > technically wrong because I didn't explicity reserve memory in those > > areas > > > to stop UEFI from using it. > > > > > > I'll try changing the max offsets to be all above 128MiB and see if it > > still > > > works. As Tixy pointed out to me, the problem I had with the Linux > > Loader's > > > "random address" for the DTB is that it was always in the same region > > that > > > Linux reserves for CMA. And I think that starts before the DTB is > > finished > > > with. > > > > > > > I think we could simply raise your max address limit to 132 MB: by the > > looks of it, that is the maximum size the current kernel code will > > ever be able to support since it uses two adjacent sections to map the > > FDT, and sections are 2 MB at most when using long descriptors. > > > > I've tested it with a patch to change the max offsets to 0x84000000 and it > works well. My hacked in debug shows: > > linux: address 0x87FD2000 > linux: length 0x42D248 > fdt: address 0x87E6E000 > fdt: length 0x3FFC > initrd: address 0x87E73000 > initrd: length 0x15E600 > > From this patch: > > diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec > index b30de91..d5b930a 100644 > --- a/ArmPkg/ArmPkg.dec > +++ b/ArmPkg/ArmPkg.dec > @@ -117,7 +117,7 @@ > # > gArmTokenSpaceGuid.PcdArmMachineType|0|UINT32|0x0000001E > # The compressed Linux kernel is expected to be under 128MB from the > beginning of the System Memory > - > gArmTokenSpaceGuid.PcdArmLinuxKernelMaxOffset|0x08000000|UINT32|0x0000001F > + > gArmTokenSpaceGuid.PcdArmLinuxKernelMaxOffset|0x08400000|UINT32|0x0000001F^M > # Maximum file size for TFTP servers that do not support 'tsize' > extension > gArmTokenSpaceGuid.PcdMaxTftpFileSize|0x01000000|UINT32|0x00000000 > > @@ -159,7 +159,7 @@ > # If the fixed FDT address is not available, then it should be loaded > below the kernel. > # The recommendation from the Linux kernel is to have the FDT below 16KB. > # (see the kernel doc: Documentation/arm/Booting) > - gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x4000|UINT32|0x00000023 > + gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x08400000|UINT32|0x00000023^M > # The FDT blob must be loaded at a 64bit aligned address. > gArmTokenSpaceGuid.PcdArmLinuxFdtAlignment|0x8|UINT32|0x00000026 > > > Of course, the comments will have to change too: "under 128MB" => "above > 128MiB" and there is no recommendation for the device tree to be < 16KB. > > Unless I get further comment, I'll submit a v2 patch as above with the > comments updated. > > > > > > > BTW it seems odd for the LinuxLoader - which is now a separate EFI > > application - to use fixed PCDs to parametrise its behavior. I think > > it would be justified to hardcode the recommended behavior as per the > > Linux/ARM boot protocol right into the LinuxLoader binary. > > > > -- > > Ard. > > > > > > > > > > >> > > >> -- > > >> Ard. > > >> > > >> > > >> > This email thread explains that the device tree should be placed > > higher > > >> > in RAM: > > >> > > > >> > > > >> > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/187476.html > > >> > > > >> > It also explaines that the kernel may use memory in the 16-32KB range > > >> > and that a zImage will by default be uncompressed to an offset of > > 32KB. > > >> > > > >> > Setting the FDT max offset at 128MiB will allow UEFI to place it > > higher > > >> > up in memory, thus avoiding the problems with it being loaded to a > > >> > random address. > > >> > > > >> > With this patch, by using AllocateMaxAdress, where possible the Linux > > >> > Loader will place the FDT, initrd and kernel at the top of the 128MiB > > >> > range, which also allows for more efficient zImage uncompression, as > > per > > >> > the above thread. > > >> > > > >> > Contributed-under: TianoCore Contribution Agreement 1.0 > > >> > Signed-off-by: Ryan Harkin <ryan.harkin(a)linaro.org> > > >> > --- > > >> > ArmPkg/ArmPkg.dec | 2 +- > > >> > 1 file changed, 1 insertion(+), 1 deletion(-) > > >> > > > >> > diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec > > >> > index da0c8a9..67c8cc9 100644 > > >> > --- a/ArmPkg/ArmPkg.dec > > >> > +++ b/ArmPkg/ArmPkg.dec > > >> > @@ -158,7 +158,7 @@ > > >> > # If the fixed FDT address is not available, then it should be > > loaded > > >> > below the kernel. > > >> > # The recommendation from the Linux kernel is to have the FDT below > > >> > 16KB. > > >> > # (see the kernel doc: Documentation/arm/Booting) > > >> > - gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x4000|UINT32|0x00000023 > > >> > + > > >> > > > gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset|0x08000000|UINT32|0x00000023 > > >> > # The FDT blob must be loaded at a 64bit aligned address. > > >> > gArmTokenSpaceGuid.PcdArmLinuxFdtAlignment|0x8|UINT32|0x00000026 > > >> > > > >> > -- > > >> > 2.1.0 > > >> > > > > > > > > >

9 years, 11 months

question on relocating kernel image

by Haojian Zhuang

Hi all, There's efi_low_alloc() in $KERNEL/drivers/firmware/efi/libstub/efi-stub-helper.c. I have on question on the piece of code from efi_low_alloc(). /* * Don't allocate at 0x0. It will confuse code that * checks pointers against NULL. Skip the first 8 * bytes so we start at a nice even number. */ if (start == 0x0) start += 8; In handle_kernel_image() of $KERNEL/arch/arm64/kernel/efi-stub.c, it's used to allocate memory to relocate kernel to (dram_base + TEXT_OFFSET). Because of the above code, kernel has to be relocated into (dram_base + TEXT_OFFSET + SIZE_2M). With the above code, I'll get the "Ignoring memory" message from linux kernel. If I remove it, I won't get the message any more. [ 0.000000] efi: Getting EFI parameters from FDT: [ 0.000000] efi: System Table: 0x000000003da73f18 [ 0.000000] efi: MemMap Address: 0x0000000036d07618 [ 0.000000] efi: MemMap Size: 0x000004e0 [ 0.000000] efi: MemMap Desc. Size: 0x00000030 [ 0.000000] efi: MemMap Desc. Version: 0x00000001 [ 0.000000] EFI v2.40 by Linaro HiKey EFI Jun 28 2015 21:57:01 [ 0.000000] efi: [ 0.000000] Processing EFI memory map: [ 0.000000] 0x000000000000-0x000000000fff [Conventional Memory| | | | | |WB|WT|WC|UC] [ 0.000000] Ignoring memory block 0x0 - 0x1000 [ 0.000000] [ 0.000000] 0x000000001000-0x000000001fff [Loader Data | | | | | |WB|WT|WC|UC] [ 0.000000] Ignoring memory block 0x1000 - 0x2000 [ 0.000000] [ 0.000000] 0x000000002000-0x0000001fffff [Conventional Memory| | | | | |WB|WT|WC|UC] [ 0.000000] Ignoring memory range 0x2000 - 0x200000 [ 0.000000] [ 0.000000] 0x000000200000-0x000000e6bfff [Loader Data | | | | | |WB|WT|WC|UC] So let's review the code again, we'll always check the return status value of efi_low_alloc() in kernel. Why do we need to avoid the 0x0 address? I think we could remove the piece of code. Regards Haojian

9 years, 11 months

[PATCH v2 0/3] arm64: Add multiboot support (via fdt) for Xen boot

by fu.wei＠linaro.org

From: Fu Wei <fu.wei(a)linaro.org> - This adds support for the Xen boot on ARM specification for arm64. - The implementation for Xen is following <Multiboot on ARM Specification>: http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot and xen/docs/misc/arm/device-tree/booting.txt in Xen source code. - The multiboot/module commands have existed, so we use xen_hypervisor/xen_module instead. - This Xen boot support is built into linux module for aarch64, and can not be used alone. - Adding this functionality to the existing "linux" module is for reusing the existing code of devicetree. - Add the support of xen_hypervisor/xen_module commands in util/grub.d/20_linux_xen.in - Add the introduction of xen_hypervisor/xen_module commands in docs/grub.texi - The example of this support is <How to boot Xen with GRUB on AArch64 the Foundation FVP model> https://wiki.linaro.org/LEG/Engineering/Grub2/Xen_booting_on_Foundation_FVP… Changelog: v2: remove the patches which have been accepted. according to Vladimir's suggestion, change the command manes and relevant code: multiboot-->xen_hypervisor module-->xen_module improve the option parsing support for xen_hypervisor/xen_module commands. add a patch for adding xen_hypervisor/xen_module support in util/grub.d/20_linux_xen.in. update docs/grub.texi patch for the new command names. v1: The first version upstream patchset to grub-devel mailing list Fu Wei (3): arm64: Add Xen boot support file * util/grub.d/20_linux_xen.in: Add support of the XEN boot on aarch64 arm64: Add the introduction of xen_hypervisor/xen_module command in docs/grub.texi docs/grub.texi | 27 ++ grub-core/Makefile.core.def | 1 + grub-core/loader/arm64/linux.c | 6 + grub-core/loader/arm64/xen_boot.c | 615 ++++++++++++++++++++++++++++++++++++++ include/grub/arm64/xen_boot.h | 115 +++++++ util/grub.d/20_linux_xen.in | 14 +- 6 files changed, 775 insertions(+), 3 deletions(-) create mode 100644 grub-core/loader/arm64/xen_boot.c create mode 100644 include/grub/arm64/xen_boot.h -- 1.8.3.1

9 years, 11 months

Re: [Linaro-uefi] [edk2] Filesystem support

by Meenakshi Aggarwal

Hi, I have copied SCT and EFI shell in SD card. Followed following link for running sct from SD card. https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/SCT/HowTo Now, on running sct binary I am facing “InitShellApp: Application not started from Shell” error. What will be the reason behind? “Shell_Full.efi” is taken from EdkShellBinPkg/FullShell/AArch64/Shell_Full.efi path. FS0:\SCT\> ls Directory of: FS0:\SCT\ 07/20/2015 09:31 <DIR> 4,096 . 07/20/2015 09:31 <DIR> 0 .. 07/20/2015 09:25 440,736 SCT.efi 07/20/2015 09:25 27,616 StallForKey.efi 07/20/2015 09:30 <DIR> 4,096 Application 07/20/2015 09:30 <DIR> 4,096 Data 07/20/2015 09:30 <DIR> 4,096 Dependency 07/20/2015 09:30 <DIR> 4,096 Ents 07/20/2015 09:30 <DIR> 4,096 Proxy 07/20/2015 09:30 <DIR> 4,096 Report 07/20/2015 09:30 <DIR> 4,096 SCRT 07/20/2015 09:30 <DIR> 4,096 Sequence 07/20/2015 09:30 <DIR> 4,096 Support 07/20/2015 09:30 <DIR> 8,192 Test 07/19/2015 01:23 1,047,296 Shell_Full.efi 3 File(s) 1,515,648 bytes 12 Dir(s) FS0:\SCT\> SCT InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B DFEAA440 add-symbol-file /proj/nmgsw_be/users/b46476/code/UEFI/ls1043a-uefi/Build/UefiSct/DEBUG_ARMGCC/AARCH64/SctPkg/TestInfrastructure/SCT/Framework/Sct/DEBUG/SCT.dll 0xDC040260 Loading driver at 0x000DC040000 EntryPoint=0x000DC040260 SCT.efi InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF DF6C9018 InstallProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA FFFFF7E0 InitShellApp: Application not started from Shell remove-symbol-file /proj/nmgsw_be/users/b46476/code/UEFI/ls1043a-uefi/Build/UefiSct/DEBUG_ARMGCC/AARCH64/SctPkg/TestInfrastructure/SCT/Framework/Sct/DEBUG/SCT.dll 0xDC040260 FS0:\SCT\> Any help is appreciated. Thanks & Regards Meenakshi From: Andrew Fish [mailto:afish@apple.com] Sent: Wednesday, July 15, 2015 7:33 PM To: Aggarwal Meenakshi-B46476 Cc: edk2-devel(a)lists.sourceforge.net Subject: Re: [edk2] Filesystem support On Jul 15, 2015, at 6:29 AM, Meenakshi Aggarwal <meenakshi.aggarwal(a)freescale.com<mailto:meenakshi.aggarwal@freescale.com>> wrote: Hi, I need your help in running SCT from SD card on Freescale SoC. I have built SCT and copied following images on SD card (formatted with FAT32), inserted this SD card in my board: 1.EdkShellBinPkg/FullShell/Arm/Shell_Full.efi 2.Build/UefiSct/DEBUG_ARMGCC/SctPackageAARCH64/AARCH64/* On running shell I saw following entry: UEFI Interactive Shell v2.1 EDK II UEFI v2.40 (LS1043a Simulator EFI Jul 15 2015 16:55:13, 0x00000000) Mapping table FS0: Alias(s):HD0mohuqyt:;BLK0: HD(-1225503552,175,0,0x20021BE11DF9E45,0xAFAFAFAF1BC5D5A5) It is the hard drive device path. The UEFI spec defines these device path display formats in the “EFI Device Path Display Format Overview” section. HD(Partition,Type,Signature,Start, Size) HD(Partition,Type,Signature) (Display Only) The Partition is an integer representing the partition number. It is optional and the default is 0. If Partition is 0, then Start and Size are prohibited. The Type is an integer between 0-255 or else the keyword MBR (1) or GPT (2). The type is optional and the default is 2. The Signature is an integer if Type is 1 or else GUID if Type is 2. The signature is required. The Start is a 64-bit unsigned integer. It is prohibited if Partition is 0. Otherwise it is required. The Size is a 64-bit unsigned integer. It is prohibited if Partition is 0. Otherwise it is required. The SD spec defines the format to be an MBR partition with a single entry, that is formatted FAT32. SD XC is MBR formatted with exFAT :(. The partition driver should not bind to a malformed MBR (it produced the device path), so maybe this is memory corruption? https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Universal/Disk/… This is the binary data structure being converted to text: https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Protocol/Devi… /// /// The Hard Drive Media Device Path is used to represent a partition on a hard drive. /// typedef struct { EFI_DEVICE_PATH_PROTOCOL Header; /// /// Describes the entry in a partition table, starting with entry 1. /// Partition number zero represents the entire device. Valid /// partition numbers for a MBR partition are [1, 4]. Valid /// partition numbers for a GPT partition are [1, NumberOfPartitionEntries]. /// UINT32 PartitionNumber; /// /// Starting LBA of the partition on the hard drive. /// UINT64 PartitionStart; /// /// Size of the partition in units of Logical Blocks. /// UINT64 PartitionSize; /// /// Signature unique to this partition: /// If SignatureType is 0, this field has to be initialized with 16 zeros. /// If SignatureType is 1, the MBR signature is stored in the first 4 bytes of this field. /// The other 12 bytes are initialized with zeros. /// If SignatureType is 2, this field contains a 16 byte signature. /// UINT8 Signature[16]; /// /// Partition Format: (Unused values reserved). /// 0x01 - PC-AT compatible legacy MBR. /// 0x02 - GUID Partition Table. /// UINT8 MBRType; /// /// Type of Disk Signature: (Unused values reserved). /// 0x00 - No Disk Signature. /// 0x01 - 32-bit signature from address 0x1b8 of the type 0x01 MBR. /// 0x02 - GUID signature. /// UINT8 SignatureType; } HARDDRIVE_DEVICE_PATH; #define MBR_TYPE_PCAT 0x01 #define MBR_TYPE_EFI_PARTITION_TABLE_HEADER 0x02 #define NO_DISK_SIGNATURE 0x00 #define SIGNATURE_TYPE_MBR 0x01 #define SIGNATURE_TYPE_GUID 0x02 Thanks, Andrew Fish I am not getting from where it is populating these values of HD(). Now on selecting FS0, I saw following prints: Shell> fs0: FS0:\> ls Get RTC Year: 15 Mon: 07 Day: 15 Hour: 17 Min: 24 Sec: 59 Get DATE: 2015-07-15 TIME: 17:24:59 FSOpen: Open '.' Success File Not Found FS0:\> My UEFI binary has support of SD card, I can probe a card and its read, write and erase functionalities are working fine. I want to execute SCT.efi using shell. Kindly help me with this Along with the above issue, I am seeing following failures in OpenVolume() call: FATDirSize: cluster chain corrupt *OutputFileName 0x61 *OutputFileName 0x62 *OutputFileName 0x63 FatGrowEof: cluster chain corrupt FatShrinkEof: cluster chain corrupt What is the reason behind these prints? Regards Meenakshi From: Olivier Martin [mailto:Olivier.Martin@arm.com] Sent: Tuesday, June 16, 2015 4:43 PM To: edk2-devel(a)lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net> Subject: Re: [edk2] Filesystem support UEFI specification says ‘HD(Partition,Type,Signature,Start, Size)’. These values are specific to you partition table. gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath is specific to the ARM BDS. It is to create a default boot entry when you start your system for a first time. It is not (necessary) relevant to boot Linux or run SCT on your platform. I would say you have the appropriate list of EFI modules to get FAT support (if you already have SD support in your UEFI firmware). From: Meenakshi Aggarwal [mailto:meenakshi.aggarwal@freescale.com] Sent: 16 June 2015 10:10 To: edk2-devel(a)lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net> Subject: [edk2] Filesystem support Hi All, I want to boot linux and run SCT from SD card. I have seen BeagleBoard package code which is booting linux from SD. I got confused with entry: gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|L"VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)/zImage" from where are 0x3F and 0x19FC0 came. Is it some default value for start address and size? Do I need to create an FV entry for this? Also what all I need to include in my dsc and fdf file to enable support of filesystem. I can see following listed files for filesystem support (reference : BeagleBoard) Changes in FDF: # # FAT filesystem + GPT/MBR partitioning # INF MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf INF MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf INF FatBinPkg/EnhancedFatDxe/Fat.inf INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf Changes in DSC # # FAT filesystem + GPT/MBR partitioning # MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf Thanks & regards Meenakshi Aggarwal -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/_______________________________________________ edk2-devel mailing list edk2-devel(a)lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/edk2-devel

9 years, 11 months

← Newer
1
...
54
55
56
57
58
59
60
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-uefi