Hi all:
I just started to play around with ARM UEFI stuff and has issue booting into Linux when trying to test the EDK2 software on Qemu. This seems like the right place to ask. I followed the instruction in (http://edk2.svn.sourceforge.net/viewvc/edk2/trunk/edk2/BeagleBoardPkg/readm…) including downloading the specific version of binaries / tools. When trying to run UEFI (both in NOR flash method as well as SD card method), UEFI started successfully. However, I kept on getting "Did not find Linux kernel" error when trying to boot Linux. From EBL, I can see the zImage file is present (cd fs1:; dir). The zImage file is basically vmlinuz-2.6.35-1008-linaro-omap from the hwpack. I even tried to extract zImage from uImage, but the result is still the same.
I am wondering if anyone has run into the same issue and can give me a hint on what else to try.
Thanks,
Alan Chuang
---------------- Console Log -------------------
The default boot selection will start in 1 seconds
CMD0 response: 0
MmcStatus: 18000
CMD5 fails. Not an SDIO card.
CMD8 success. CMD8 response: 1CE
Card is SD2.0
CMD55 success. CMD55 response: 120
SD card detected. ACMD41 OCR: C0FFFF00
High capacity card.
CMD2 response: EF006219 1DEADBE 454D5521 AA585951
CMD3 response: RCA 4567
CMD9 response: A400000 FFF7F80 5B590000 400E0032
Card type: 4, BlockSize: 200, NumBlocks: 400000
MaxDataTransferRate: 0x32, Frequency: 25000 KHz, ClockFrequencySelect: 4
SD Memory Card set to 4-bit mode
SD Card Media Change on Handle 0x8792E290
SD Card ReinstallProtocolInterface ()
ERROR: Did not find Linux kernel.
[1] Linux from SD
- VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)/zImage
- LoaderType: 1
- Arguments:
[2] EBL
[3] Boot Manager
Start: 3
[1] Add Boot Device Entry
[2] Update Boot Device Entry
[3] Remove Boot Device Entry
[4] Return to main menu
Choice: 2
[1] Linux from SD
- VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)/zImage
- Arguments:
Update entry: 1
File path of the EFI Application or the kernel: zImage
Has FDT support? [y/n] n
Arguments to pass to the binary:
Description for this new Entry: Linux from SD
[1] Add Boot Device Entry
[2] Update Boot Device Entry
[3] Remove Boot Device Entry
[4] Return to main menu
Choice: 4
[1] Linux from SD
- VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)/zImage
- LoaderType: 1
- Arguments:
[2] EBL
[3] Boot Manager
Start: 2
EhcCreateUsb2Hc: capability length 0
EhcDriverBindingStart: failed to create USB2_HC
add-symbol-file /home/alanc/UEFI/src2/edk2/Build/BeagleBoard/DEBUG_ARMGCC/ARM/EmbeddedPkg/Ebl/Ebl/DEBUG/Ebl.dll 0x85BCD240
Embedded Boot Loader (EBL) prototype. Built at 09:56:17 on Aug 12 2011
THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN 'AS IS' BASIS,
WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
Please send feedback to edk2-devel(a)lists.sourceforge.net
BeagleEdk2 >device
Firmware Volume Devices:
fv0: 0x80008000 - 0x80087FFF : 0x00080000
fv1: 0x87C4A000 - 0x87E0751F : 0x001BD520
File System Devices:
fs0: SemihostFs:
fs1: boot:
Block IO Devices:
blk0: Size = 0x10000000
blk1: Removable Size = 0x80000000
blk2: fs1: Removable Partition Size = 0x33F8000
blk3: Removable Partition Size = 0x7CC00000
BeagleEdk2 >devicepaths
EhcCreateUsb2Hc: capability length 0
EhcDriverBindingStart: failed to create USB2_HC
[0x87A00790] MemoryMapped(0xB,0x80008000,0x80087FFF)
[0x87A00490] MemoryMapped(0xB,0x87C4A000,0x87E0751F)
[0x87975B10] VenHw(6696936D-3637-467C-87CB-14EA8248948C)/Uart(115200,8,N,1)
[0x8796B910] VenHw(4D00EF14-C4E0-426B-81B7-30A00A14AAD6)
[0x8792E290] VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)
[0x8792D390] PciRoot(0x0)/Pci(0x0,0x0)
[0x87918890] VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)
[0x8790A890] VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)
[0x8790A590] VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(2,MBR,0x00000000,0x1A000,0x3E6000)
BeagleEdk2 >exit
remove-symbol-file /home/alanc/UEFI/src2/edk2/Build/BeagleBoard/DEBUG_ARMGCC/ARM/EmbeddedPkg/Ebl/Ebl/DEBUG/Ebl.dll 0x85BCD240
[1] Linux from SD
- VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)/zImage
- LoaderType: 1
- Arguments:
[2] EBL
[3] Boot Manager
Start:
-- 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.
Thank you to everyone who attended the ARM boot architecture summit at
Linaro Connect Q3.11 a week ago. It was a big help in understanding
what the focus needs to be over the next 6 months, but it also
highlighted just how large the boot architecture work is.
I've put the meeting minutes up on the boot architecture wiki page[1],
and I'll be editing them and sorting out the action items. The
remainder of August is fully booked for me, and I've got the
impression that many others are in the same boat, so I'm deferring the
next conference call until September when most of us will be back into
a normal routine.
The next face to face meeting will be a BoF at Linux Plumbers
conference in Santa Rosa, California. September 7-9. Jon Masters is
organizing it.
The face to face meeting after that will most likely be scheduled in
conjunction with ELC-E/LinuxCon Europe/Kernel Summit in Prague at the
end of October.
[1] https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-08-05
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
On Wed, Jul 06, 2011, Olivier Martin wrote:
> Anyway, these are the build instructions to build the Tianocore project
> (UEFI Open Source implementation) and to test on qEmu:
> http://edk2.svn.sourceforge.net/viewvc/edk2/trunk/edk2/BeagleBoardPkg/readme
> .txt?revision=11997
I had started following these, but ran into some issues with my setup;
I will try with the alternate build-next.sh approach too, to see
whether I get other issues or not.
The two classes of issues I ran into was:
a) variables being written to, but never read
b) conditions being always true
I indeed had to apply the patch you mention; what's the state of that
patch? Are these things which will get merged soonish? Without the
patch, my toolchain wouldn't be properly picked up (it'd try running
c:/program files/ stuff and calling a CS toolchain) and I had some
error conditions like '-(' in linker invocations due to missing '\'
escapes. These go away with the patch and my toolchain is picked up
and works.
I'm running Ubuntu oneiric (which will become 11.10) and the toolchain
I've used is our packaged Linaro GCC based cross-compiler
(arm-linux-gnueabi-gcc from the gcc-arm-linux-gnueabi package).
a) variables being written to, but never read
This is stuff like:
--- a/edk2/BaseTools/Source/C/EfiLdrImage/EfiLdrImage.c
+++ b/edk2/BaseTools/Source/C/EfiLdrImage/EfiLdrImage.c
@@ -181,7 +181,7 @@ Returns:
CHAR8* OutputFileName = NULL;
CHAR8* InputFileNames[MAX_PE_IMAGES + 1];
UINT8 InputFileCount = 0;
- BOOLEAN QuietFlag = FALSE;
+ //BOOLEAN QuietFlag = FALSE;
UINT64 DebugLevel = 0;
UINT64 VerboseLevel = 0;
EFI_STATUS Status = EFI_SUCCESS;
@@ -220,7 +220,7 @@ Returns:
}
if ((stricmp (argv[0], "-q") == 0) || (stricmp (argv[0], "--quiet") == 0)) {
- QuietFlag = TRUE;
+ //QuietFlag = TRUE;
argc --;
argv ++;
continue;
QuietFlag is never used (read), newer gccs detect this and report it as
a fatal warning by default (not sure where this warning is configured
as a fatal one, whether it's in UEFI or in the toolchain config).
There are many such cases, but some are a bit more worrying, like
variables holding the return values of fread of fwrite not being
checked:
--- a/edk2/BaseTools/Source/C/GenVtf/GenVtf.c
+++ b/edk2/BaseTools/Source/C/GenVtf/GenVtf.c
@@ -1141,7 +1141,7 @@ Returns:
EFI_STATUS Status;
UINT64 CompStartAddress;
UINT64 FileSize;
- UINT64 NumByteRead;
+ //UINT64 NumByteRead;
UINT64 NumAdjustByte;
UINT8 *Buffer;
FILE *Fp;
@@ -1189,7 +1189,7 @@ Returns:
//
// Read first 64 bytes of PAL header and use it to find version info
//
- NumByteRead = fread (Buffer, sizeof (UINT8), SIZE_OF_PAL_HEADER, Fp);
+ /* NumByteRead = */fread (Buffer, sizeof (UINT8), SIZE_OF_PAL_HEADER, Fp);
//
// PAL header contains the version info. Currently, we will use the header
@@ -1200,7 +1200,7 @@ Returns:
}
}
- NumByteRead = fread (Buffer, sizeof (UINT8), (UINTN) FileSize, Fp);
+ /* NumByteRead = */fread (Buffer, sizeof (UINT8), (UINTN) FileSize, Fp);
fclose (Fp);
//
I just quickly hacked the source to get it to build, but we should fix
the code to loop until all bytes have been read or to raise an error.
The last such cases is a conditional piece of code:
--- a/edk2/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
+++ b/edk2/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
@@ -1919,11 +1919,13 @@ static SRes LzmaEnc_CodeOneBlock(CLzmaEnc *p, Bool useLimits, UInt32 maxPackSize
static SRes LzmaEnc_Alloc(CLzmaEnc *p, UInt32 keepWindowSize, ISzAlloc *alloc, ISzAlloc *allocBig)
{
UInt32 beforeSize = kNumOpts;
+ #ifdef COMPRESS_MF_MT
Bool btMode;
+ #endif
if (!RangeEnc_Alloc(&p->rc, alloc))
return SZ_ERROR_MEM;
- btMode = (p->matchFinderBase.btMode != 0);
#ifdef COMPRESS_MF_MT
+ btMode = (p->matchFinderBase.btMode != 0);
p->mtMode = (p->multiThread && !p->fastMode && btMode);
#endif
b) conditions being always true
A bunch of asserts trigger a warning in newer GCCs, essentially the
ASSERT macros in question are doing multiple things:
- testing whether the object is null
- testing some other condition on the object, like some state being
correct
but the objects are guaranteed to never be null from GCC PoV, so it
raises a fatal warning; as a workaround I just commented the asserts
out, but I guess what we should do is review whether any of the
ASSERT_LOCKED() users has a chance of getting a NULL pointer, and
either drop the NULL check or replace the macro with two.
--- a/edk2/MdeModulePkg/Core/Dxe/Event/Event.c
+++ b/edk2/MdeModulePkg/Core/Dxe/Event/Event.c
@@ -225,7 +225,7 @@ CoreNotifyEvent (
//
// Event database must be locked
//
- ASSERT_LOCKED (&gEventQueueLock);
+ //ASSERT_LOCKED (&gEventQueueLock);
//
// If the event is queued somewhere, remove it
I got this for a bunch of ASSERT_LOCKED(),
ASSERT_PROTOCOL_ALREADY_INSTALLED(), and ASSERT_VOLUME_LOCKED()
These are all issues in edk2, except the ASSERT_VOLUME_LOCKED() macro
issue which is the only issue in FatPkg and only there.
A cleaner workaround would be to make this warnings non-fatal for now
for this toolchain, but the code should also be fixed not to trigger
them. What's the best way to address this? Is there some bug tracker
I should report these issues at?
To try the resulting image, I just did:
qemu-system-arm -mtdblock \
../Build/BeagleBoard/DEBUG_ARMGCC/FV/BeagleBoard_EFI_flashboot.fd \
-nographic -M beagle
which sent this on the serial port:
UART Enabled
Magic delay to disable watchdog timers properly.
ASSERT_EFI_ERROR (Status = Unsupported)
ASSERT /home/lool/git/edk2/edk2/edk2/EmbeddedPkg/Library/PrePiLib/PrePiLib.c(73): !EFI_ERROR (Status)
I didn't actually look into this issue yet.
I tried passing a barebox based SD image I had built earlier (see other
message) with -sd sd.img, but that didn't change the output.
--
Loïc Minier
Okay, minutes from the last meeting are posted to the wiki, and the
next meeting is scheduled for tomorrow, 3 hours earlier to accommodate
Jean in China (0600MDT, 0800EDT, 1200UTC). Email me if you want to
attend and I'll add you to the invite.
g.
On Thu, Jun 23, 2011 at 10:47 PM, Grant Likely
<grant.likely(a)secretlab.ca> wrote:
> Hi all,
>
> here are the notes from today's meeting. Please look over it an make
> sure all of it is okay by you for posting on the public wiki. If
> there is anything sensitive that should not be published, then let me
> know right away so that I can edit it out.
>
> Cheers,
> g.
>
>
>
> Meeting notes from ARM Boot Architecture Meeting, June 23, 2011
>
> https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-06-23
>
> == Attendees ==
>
> Loïc Minier
> Grant Likely
> Olivier Martin
> Jean-Christophe PLAGNIOL-VILLARD
> Jon Masters
> Andrew Pickard
>
>
> == Minutes ==
>
> * Need to think about what do we actually care about and write it down
> * Should be careful to consider non-Linux OSes
> * Want to get to a standard ARM platform
>
> * Time to market also an important consideration
>
>
> Notes on process:
> - We are not a standards body - need to be agile and try to base on
> existing standards
> - We need to be congnisent of other operating systems and other architectures
>
> Other Topics (maybe to put on the backburner):
> * How to we boot multiple CPUs of heterogeneous architectures
> * How does the boot architecture define how to start other CPUs, and
> other scenarii like kexec or virtualization? security / secure boot
> also impact the boot architecture subtly
>
> Licensing: GPL might be a problem for some specific pieces of code,
> e.g. touching CPU initialization
> * Specifications should remain as abstract of the licensing as
> possible though
> * Eveything we discuss should be public and avaiable free of charge
>
> Bootloader consolidation: we agree that there wont be consolidation on
> a single bootloader, instead a variety of bootloaders have to be
> supported
>
> Skeleton of boot architecture plan at
> https://wiki.linaro.org/OfficeofCTO/BootArchitecture/
> * Not clear whether we want to specify UI though
>
> What's the output?
> * Standard?
> * Wiki page? web site?
> * Need to work dynamically in the beginning, then freeze a version 1
> or something of the recommendations
> * Deliverable of some kind at the August Linaro meeting
>
> Dealing with legacy?
> * Could provide old-world boot media chainloading into new-world boot
> architecture media
> * Hard to implement security architecture in this mode
> * Don't care about legacy beyond a point (why care with product lifecycles?)
>
> Another output is one or more reference implementation(s) which can be
> deployed in production (be it UEFI, Barebox or whatever)
>
> Need to make sure we document the things which are NOT covered in our
> outputs/documents
>
> Should add definitions for terms; particuarly in the case of secure
> boot terminology.
>
> Need to handle booting secondary "bootloaders" like GRUB. Need to
> handle bits beyond just kernel, including initramfs, and other data
> images that need to be loaded by the bootloader.
>
>
> Power Management & PM handoff to the kernel.
>
> Plan agenda ahead of calls and assign time slots
>
> Suggest having a whole day/half day to advance (bootstrap!) this effort
>
> Topics raised after meeting:
> Privacy: The goal is to have everything open and public, but anybody
> can request for a conversation on the mailing list to be kept private
> in the interest of open communication.
>
> Minimal "run time" service type of interface for example to allow
> second stage bootloader to retrieve "files". However, this should not
> be massive overkill.
>
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
On Wed, Jul 06, 2011, Olivier Martin wrote:
> UEFI Device Path
> ----------------
> UEFI has the concept of 'Device Path'. Every hardware devices supported by
> the UEFI firmware on the platform have a representation that defined the
> hardware path to access to this device and their properties.
I had a couple of questions on this:
* is the definition ARM specific or across all arches?
* is there a registry of GUID and allowed interfaces?
--
Loïc Minier
Hi,
one of the big issue on the device tree will be to update it at
runtime from the bootloader
As example the same board have 2 version with only one difference the
Main Oscilator. So to support it easly without having 2 DT will want
to update the default DT with the proper Osc value from the
bootlaoder.
But as the bootloader will not be able to be udpate in the futur on
production board, we will have to never change to format of the DT
otherwise the bootloder will not be able to work on never kernel.
This is one of issue that nearly all of the PowerPC kernel dev meet
ofen with the couple u-boot + kernel + DT
To avoid this we may use a script to update the DT and then specify
how we get the information from the bootloader. So in this case, the
script we will manage the dependency of the current format version of
the DT.
Best Regards,
J.
HI,
Barebox flow basecly the linux kernel architecture
We use as linux a file system (devfs) to manage the device
such as NOR, NAND, SPI Flash, Memory, phy, SD etc...
As have a pseudo POSIX API to implement command application
such as ls, rm, mount, boot etc...
You can see barebox as "Small Linux like" bootlader
To extend it's fonctionality at runtime we use modules (same as in the
kernel).
We do not support yet ABI Application
With start from anywhere and they relocate our self at the right
addres in DDR after have init the soc and the board. Which include the
DDR.
After we use the initcall to init:
1: the core
Usualy clock and pio
2: console
uart
3: core device
using the device / driver model of the kernel
4: Filesystem
register filesytem
5: device
using the device / driver model of the kernel
as Frambuffer, and other
Then we mount a ramfs and devfs and execute a script /env/bin/init
all the boot sequence is manage by script based on Hush from busybox
we have a default scripting implementation to boot but you are free to
manage it how you want
we an boot from any media and from tftp, nfs with uImage or zImage or
Image
You can manage your boot loader configuration and boot from via a Menu
which can be manage in C or in shell
Over uart and soon over Framebuffer
Best Regards,
J.
