Re: [edk2] Sata hdds ports not recognized

2012-10-19 Thread Joe Thomas 
Rafael,


The error happen because the the GetNextDevice does not find anything.
Any idea about the problem ?

As I said before, the code works correctly on a notebook with a sas hdd, but 
don't work on a server with 2 sas hdds.

Thanks and Regards


Just to make sure you're not mixing SATA and SAS as interchangeable...

SAS hdds implement the SCSI protocol and thus the driver would (normally) 
export the EFI_EXT_SCSI_PASS_THRU_PROTOCOL. It's not uncommon for drivers to 
expose both - for example ATAPI devices in a SATA driver might return the same 
device for both ATA and EXT_SCSI pass thru. (Are you sure the notebook is SAS 
and not SATA?)

If your server has a SAS controller, then try EFI_EXT_SCSI_PASS_THRU_PROTOCOL. 
Same general idea as for ATA except that you're looking for Targets, not ports.

-Joe Thomas

// Joseph Thomas
// Principal Software Engineer
// Dot Hill Systems
// 2905 NorthWest Blvd., Suite 20
// Plymouth, MN 55441
// 763.226.2640

From: Rafael Machado [mailto:rafaelrodrigues.mach...@gmail.com]
Sent: Thursday, October 18, 2012 2:08 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Sata hdds ports not recognized

Thanks for the answer Isakov.
The code is this way now :

EFI_STATUS TestMain(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
{
 EFI_STATUSStatus = EFI_SUCCESS;
 EFI_ATA_PASS_THRU_PROTOCOL*ataProtocol;
 UINT16 Port;
 UINT16 PortMultiplierPort;
 EFI_HANDLE *HandleBuffer = (EFI_HANDLE *) NULL;
 UINTN HandleCount = 0;
 UINTN HandleIndex = 0;
 Print(L*\n);
 Print(L*Ata*\n);
 Print(L*\n);
 Status = gBS-LocateHandleBuffer(ByProtocol,
 gEfiAtaPassThruProtocolGuid,
 NULL,
 HandleCount,
 HandleBuffer);
 if (Status == EFI_SUCCESS)
 {
  Print(LgEfiAtaPassThruProtocolGuid HandleCount: %d\n, HandleCount);
  // Loop to walk in the handles
  for (HandleIndex = 0; HandleIndex  HandleCount; HandleIndex ++)
  {
   Print(LHandleIndex: %d\n, HandleIndex);
   Status = gBS-OpenProtocol(HandleBuffer[HandleIndex],
  gEfiAtaPassThruProtocolGuid,
  (VOID **) ataProtocol,
  ImageHandle,
  NULL,
  EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL);
   Port = 0x;
   PortMultiplierPort = 0x;
   if(EFI_ERROR(Status))
   {
Print(LStatus: %x\n, Status);
   }
   do {
 Status = ataProtocol-GetNextPort(ataProtocol,
 Port);
 if(!EFI_ERROR(Status))
 {
  Status = ataProtocol-GetNextDevice(ataProtocol,
   Port,
   PortMultiplierPort);
  if(!EFI_ERROR(Status))
  {
   Print(LPort: %d\n,Port);
   Print(LPortMultiplierPort: %d\n, PortMultiplierPort);
   Print(L---\n);
  }
  else
  {
   Print(LStatus: %x\n, Status);
  }
 }
 else
 {
  Print(LStatus: %x\n, Status);
 }
   }while(!EFI_ERROR(Status));
  }
 }
 else
 {
  Print(LStatus: %x\n, Status);
 }
  return Status;
}


The prints are displaied on the following way:

*
*Ata*
*
gEfiAtaPassThruProtocolGuid HandleCount: 1
HandleIndex: 0
Status: E


The error happen because the the GetNextDevice does not find anything.
Any idea about the problem ?

As I said before, the code works correctly on a notebook with a sas hdd, but 
don't work on a server with 2 sas hdds.

Thanks and Regards

PS.: should the command dh -p AtaPassThru return something in my case ? This 
command doesn't return nothing. Neither on the server, where the code does not 
work, nor on the notebook, where the code works.

Thanks everyone.
Rafael R. Machado


2012/10/18 Sergey Isakov isakov...@bk.rumailto:isakov...@bk.ru
No, Rafael.
You must assign Port = 0x;  inside for() cycle, not outside.

Type
dh -b
 to see all handles and their protocols
Sergey

On 18.10.2012, at 16:42, Rafael Machado 
rafaelrodrigues.mach...@gmail.commailto:rafaelrodrigues.mach...@gmail.com 
wrote:


Thanks for the answers Feng and Isakov.

On my first message I din't put my hole function here.
The variables you mentioned were already declared and initialized this way:

 EFI_STATUSStatus = EFI_SUCCESS;
 EFI_ATA_PASS_THRU_PROTOCOL*ataProtocol;
 UINT16 Port;
 UINT16 PortMultiplierPort;

 EFI_HANDLE *HandleBuffer = (EFI_HANDLE *) NULL;

 UINTN HandleCount = 0;
 UINTN HandleIndex = 0;
 Port = 0x;
 PortMultiplierPort = 0x;

I think probably the problem is what Feng told.
I have two questions.

First.
I've searched for a command to  check all available protocols on a computer.
I didn't find anything.
Does any of you know if is there a command that do this kind of magic ?
Some comand like:  shell: list_all_available_protocols_on_this_computer (with 
a better name)

Second.
As Feng told, even if the shell main screen display the HDDs thare is a 
possibility of not having access to the ata_pass_thru_protocol. But how the 
HDDs are recognized by the system ?

Thanks again everyone.
Rafael R

Re: [edk2] Both legacy OpROM and UEFI BSD loaded

2012-10-30 Thread Joe Thomas 
Our experience is that every platform BIOS will do it differently...

Expect that both legacy and UEFI will run, that you have no control over which 
runs first, and that calls may alternate between one and the other...

In other words, plan for the worst and you'll avoid a lot of debugging 
headaches down the road...
[One platform implemented CSM and alternated calls between legacy INT13 and 
UEFI BlockIo - really messes up the device registers when this happens... Big 
issues with boot manager on this system as well...]

// Joseph Thomas
// Principal Software Engineer
// Dot Hill Systems
// 2905 NorthWest Blvd., Suite 20
// Plymouth, MN 55441
// 763.226.2640

From: Li, Elvin [mailto:elvin...@intel.com]
Sent: Thursday, October 25, 2012 2:58 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Both legacy OpROM and UEFI BSD loaded

We can run both UEFI and Legacy OpROM start in preboot, but it will bring 
potential problem as device configuration will be possibly messed up, unless 
the BIOS or UEFI/Legacy OpROM aware this. BlockIo protocol is used to access 
storage device in preboot phase, BlockIo protocol is based on either UEFI or 
Legacy OpROM, not possibly both.

From: Prakash, Sathya [mailto:sathya.prak...@lsi.com]
Sent: Thursday, October 25, 2012 2:59 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Both legacy OpROM and UEFI BSD loaded

It is two ROM images loaded in flash separately.  Loading into memory is not a 
problem, but if they are executed interchangeably will the initialization 
routines of OptionROM and BSD be called every time before the switch happens?  
And whether the system firmware make sure both the services will not be used at 
same time?

Thanks
Sathya

From: Ramesh Raju [mailto:rame...@ami.com]mailto:[mailto:rame...@ami.com]
Sent: Wednesday, October 24, 2012 10:32 PM
To: 'edk2-devel@lists.sourceforge.net'
Subject: Re: [edk2] Both legacy OpROM and UEFI BSD loaded

Sathya,

  I assume that  both the images are packed in single option rom. Normal case 
will be, load only one image from option rom. But it's really depend on the 
UEFI firmware. They might loaded both the images to support both UEFI and 
Legacy OS booting.

Thanks,
Ramesh

From: Prakash, Sathya [mailto:sathya.prak...@lsi.com]
Sent: Wednesday, October 24, 2012 1:41 AM
To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net
Subject: [edk2] Both legacy OpROM and UEFI BSD loaded

Hello All,
In our add-on controllers we flash both UEFI and Legacy OptionROM images and we 
have seen in some platforms both legacy OpROM and UEFI BSD are loaded by the 
UEFI system firmware. Is it acceptable case and if so do the system firmware 
can have the possibility of executing either of them in a interchangeable way 
(means whether the images or just loaded in memory are they both get executed 
simulatenously?)

PS: How the add on controllers has to behave for this?
Thanks
Sathya

The information contained in this message may be confidential and proprietary 
to American Megatrends, Inc. This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited. Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] SouceLevelDebug w/WinDbg and DuetPkgX64

2014-05-02 Thread Joe Thomas 
Seems like this is an ongoing question without any definitive answer...

I have a hardware driver I'm trying to debug using DuetPkgX64 (need to access 
real HW and platforms we have access to don't support SourceLevelDebug...)

After some missteps, I can at least connect to the debug agent running WInDbg.  
The problem is that the target keeps reporting an Access Violation in the 
TimerInterruptHandler.
This is without my driver being loaded yet.

Before I decide if this is something I can tackle, has anyone encountered 
this/know how to resolve?

Thanks!





Kernel Debugger connection established
Debugger data list address is NULL
Connected to eXDI Device 0 x64 target at (Fri May  2 08:42:43.683 2014 
(GMT-5)), ptr64 TRUE
Symbol search path is: *** Invalid ***

* Symbol loading may be unreliable without a symbol search path.   *
* Use .symfix to have the debugger choose a symbol path.   *
* After setting your symbol path, use .reload to refresh symbol locations. *

Executable search path is:
eXDI Device Kernel Version 0 UP Free x64
Machine Name:
Primary image base = 0x` Loaded module list = 
0x`
System Uptime: not available
The call to LoadLibrary(kdexts) failed, Win32 error 0n2
The system cannot find the file specified.
Please check your debugger configuration and/or network access.
Access violation - code c005 (first/second chance not available)
`bf52e988 0fae07  fxsave  [rdi]
0: kd .sympath C:  
\UEFI\EDK2\BUILD\DUETPKGX64\DEBUG_VS2005\X64\MDEMODULEPKG\CORE\DXE\DXEMAIN\DEBUG\
Symbol search path is: C:  
\UEFI\EDK2\BUILD\DUETPKGX64\DEBUG_VS2005\X64\MDEMODULEPKG\CORE\DXE\DXEMAIN\DEBUG\
Expanded Symbol search path is: c:  
\uefi\edk2\build\duetpkgx64\debug_vs2005\x64\mdemodulepkg\core\dxe\dxemain\debug\
0: kd .reload /f DXECORE=0x0`BF503000
0: kd .load C:\Program Files (x86)\Intel\Intel(R) UEFI Development Kit 
Debugger Tool\UdkExtension.dll
0: kd g
Access violation - code c005 (first/second chance not available)
DXECORE!TimerInterruptHandle+0xf8:
`bf52e988 0fae07  fxsave  [rdi]
0: kd .echo Target encountered an exception: Vector = 13, Error Code = 
Target encountered an exception: Vector = 13, Error Code = 



0: kd r
rax= rbx=0002 rcx=0008
rdx= rsi=00022110 rdi=bf4d1a38
rip=bf52e988 rsp=bf4d1a38 rbp=bf4d1d88
r8=  r9= r10=
r11= r12= r13=
r14= r15=
iopl=0 nv up di pl nz na pe nc
cs=0038  ss=0018  ds=0018  es=0018  fs=  gs=f000 efl=00010002
DXECORE!TimerInterruptHandle+0xf8:
`bf52e988 0fae07  fxsave  [rdi]ds:0018:`bf4d1a38=00


`bf52e961 0f23f8  mov dr7,rax
`bf52e964 0f21f0  mov rax,dr6
`bf52e967 50  pushrax
`bf52e968 4833c0  xor rax,rax
`bf52e96b 0f23f0  mov dr6,rax
`bf52e96e 0f21d8  mov rax,dr3
`bf52e971 50  pushrax
`bf52e972 0f21d0  mov rax,dr2
`bf52e975 50  pushrax
`bf52e976 0f21c8  mov rax,dr1
`bf52e979 50  pushrax
`bf52e97a 0f21c0  mov rax,dr0
`bf52e97d 50  pushrax
`bf52e97e 4881ec0002  sub rsp,200h
`bf52e985 488bfc  mov rdi,rsp
`bf52e988 0fae07  fxsave  [rdi]ds:0018:`bf4d1a38=00
`bf52e98b ff7510  pushqword ptr [rbp+10h]
`bf52e98e fc  cld
`bf52e98f 488bd4  mov rdx,rsp
`bf52e992 4c8bf9  mov r15,rcx
`bf52e995 4883ec28sub rsp,28h
`bf52e999 e83e9e  callDXECORE!InterruptProcess 
(`bf5287dc)
`bf52e99e 4883c428add rsp,28h
`bf52e9a2 4883c408add rsp,8
`bf52e9a6 488bf4  mov rsi,rsp
`bf52e9a9 0fae0e  fxrstor [rsi]
`bf52e9ac 4881c40002  add rsp,200h
`bf52e9b3 58  pop rax
`bf52e9b4 0f23c0  mov dr0,rax
`bf52e9b7 58  pop rax



Console output:

Enter DxeIpl ...
Handoff:
Handoff.BfvBase = BF549000, BfvLength = 15
Handoff.DxeIplImageBase = BF53C000, DxeIplImageSize = D000
Handoff.DxeCoreImageBase = BF502000, DxeCoreImageSize = 3A000
Prepare Cpu HOB information ...
Prepare BFV HOB information ...
Prepare Memory HOB information ...
Prepare NV Storage information ...
NV Storage Base = BF4D2000
Stack Top=0xBF4D2000, Stack Bottom=0xBF4B2000
Prepare DxeCore memory

Re: [edk2] making UEFI driver part of optrom

2014-08-06 Thread Joe Thomas 
Sushma,

When you say “We placed this UEFI driver ROM image, below the legacy optrom and 
flashed the same on the PCIe card.”, how exactly did you do this?

Did you change the headers in the legacy image to indicated that it no longer 
is the last image?

It’s been several years since I’ve done this so I’m still going back trying to 
find the tools we used but it almost sounds like the PCI Data Structure in the 
legacy ROM wasn’t updated and therefore, the BIOS only sees the one image, 
regardless of what you put after… (There’s a ‘Last Image Indicator’ that needs 
to have bit 7 set to zero in all images except the last. In this, case, the 
legacy image should be zero and the UEFI image should be 1 (0x80). The UEFI 
image then needs to follow the legacy image at ‘Image Length’ * 512 bytes.)

I’ll try to find what we did and forward if I can.

-Joe

// Joseph Thomas
// Principal Software Engineer
// Dot Hill Systems
// 2905 NorthWest Blvd., Suite 20
// Plymouth, MN 55441
// 763.226.2640

From: Ramesh R. [mailto:rame...@ami.com]
Sent: Wednesday, August 06, 2014 7:19 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] making UEFI driver part of optrom

Hi Sushma,

  It’s depend on the platform BIOS to decide which option rom needs to be 
invoked. May be the BIOS you are having invokes only Legacy option rom if it’s 
exists and doesn’t launch the UEFI option rom.

I mean to say from the option rom we can’t control which option rom needs to be 
launched. It’s decided by the platform BIOS.

Thanks,
Ramesh

From: sushma s [mailto:sushma.bharadw...@gmail.com]
Sent: 06 August 2014 11:33
To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] making UEFI driver part of optrom

Hello,

As suggested, we placed only uefi.rom in the PCIE optrom, our UEFI driver is 
getting loaded during boot.
But if i keep both the legacy optrom images, and UEFI driver rom image, i below 
the other in the optrom space, my UEFI driver is not getting loaded.

Any additional changes required to make both images co-exist. Please advise.

Regards,
Sushma.S

On Mon, Aug 4, 2014 at 11:17 AM, Onipchuk Vladimir 
v-onipc...@yandex.rumailto:v-onipc...@yandex.ru wrote:

 We are able to successfully load the UEFI driver ROM using loadpicrom UEFI
 shell command.
During loadpcirom command please make sure what start function was loaded 
(not just entrypoint).


 In the PCIE card optrom layout We placed this UEFI driver ROM image, below
 the legacy optrom image and flashed the same on the PCIe card.
Try to place only UEFI driver ROM image on the PCIe card.

Thanks,
Vladimir

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] EDK2 GenFw

2014-09-17 Thread Joe Thomas 
Mike/others,

Further info...


I've cloned https://github.com/tianocore/edk2, 

Downloaded the Linaro toolchain binaries, 'wget 
http://releases.linaro.org/13.07/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.8-2013.07-1_linux.tar.xz'
Unpacked them ' tar xf gcc-linaro-aarch64-linux-gnu-4.8-2013.07-1_linux.tar.xz'

Set the env variable ' export AARCH64LINUXGCC_TOOLS_PATH=path to 
gcc-linaro-aarch64 directory/bin/'

And used the following in Conf/target.txt
ACTIVE_PLATFORM   = MdeModulePkg/MdeModulePkg.dsc
TARGET   = DEBUG
TARGET_ARCH = AARCH64  (must be caps even though 
the listed arch in the comment is mixed case)
TOOL_CHAIN_TAG = ARMLINUXGCC

If you tried building, be sure to clean the Build directory first -- I had 
mixed results when switching between toolschains...

The first relocation is 0x0, which I believe is R_ARM_NONE (as opposed to 
R_AARCH64_NONE which is defined as 256). I believe this can be ignored by 
adding a case with a break stmt to the (e_machine == EM_AARCH64) sections.
The other is 0x105 (261) or R_AARCH64_PREL32 (S + A - P) which I really have no 
idea how to handle. (I haven't looked at GenFW, etc. to try and figure out.)
(Both of these relocations show up in you log capture.)

Anyways, using the Linaro tool chain, I've build the HelloWorld.efi app and 
successfully run it, as well as building other driver code that (modulo hw 
issues), runs as expected as well.





// Joseph Thomas
// Principal Software Engineer
// Dot Hill Systems
// 2905 NorthWest Blvd., Suite 20
// Plymouth, MN 55441
// 763.226.2640

-Original Message-
From: Brainerd, Mike [mailto:mike.brain...@amd.com] 
Sent: Tuesday, September 16, 2014 5:51 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EDK2 GenFw

I downloaded EDK2 yesterday, 'git clone https://github.com/tianocore/edk2'.
I have also downloaded 'linaro-edk2' with the same issues.
And, it does appear to be relocation issues.

Command:   build -v
This is a truncated output: 

echo objcopy not needed for 
/home/develop/sandbox/edk2/Build/MdeModule/DEBUG_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
objcopy not needed for 
/home/develop/sandbox/edk2/Build/MdeModule/DEBUG_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
cp -f 
/home/develop/sandbox/edk2/Build/MdeModule/DEBUG_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
 
/home/develop/sandbox/edk2/Build/MdeModule/DEBUG_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.debug
echo --strip-unneeded -R .eh_frame 
/home/develop/sandbox/edk2/Build/MdeModule/DEBUG_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
--strip-unneeded -R .eh_frame 
/home/develop/sandbox/edk2/Build/MdeModule/DEBUG_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
echo 
--add-gnu-debuglink=/home/develop/sandbox/edk2/Build/MdeModule/DEBUG_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG\HelloWorld.debug
 
/home/develop/sandbox/edk2/Build/MdeModule/DEBUG_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
--add-gnu-debuglink=/home/develop/sandbox/edk2/Build/MdeModule/DEBUG_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUGHelloWorld.debug
 
/home/develop/sandbox/edk2/Build/MdeModule/DEBUG_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
cp -f 
/home/develop/sandbox/edk2/Build/MdeModule/DEBUG_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.debug
 /home/develop/sandbox/edk2/Build/MdeModule/DEBUG_GCC48/AARCH64
GenFw -e UEFI_APPLICATION -o 
/home/develop/sandbox/edk2/Build/MdeModule/DEBUG_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.efi
 
/home/develop/sandbox/edk2/Build/MdeModule/DEBUG_GCC48/AARCH64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
echo Symbol renaming not needed for 
/home/develop/sandbox/edk2/Build/MdeModule/DEBUG_GCC48/AARCH64/MdeModulePkg/Bus/Pci/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupportDxe/OUTPUT/./IncompatiblePciDeviceSupport.obj
Symbol renaming not needed for 
/home/develop/sandbox/edk2/Build/MdeModule/DEBUG_GCC48/AARCH64/MdeModulePkg/Bus/Pci/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupportDxe/OUTPUT/./IncompatiblePciDeviceSupport.obj
gcc   -g -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds 
-ffunction-sections -fdata-sections -c -include AutoGen.h 
-DSTRING_ARRAY_NAME=IncompatiblePciDeviceSupportStrings -g -Os -fshort-wchar 
-fno-strict-aliasing -Wall -Werror -Wno-array-bounds -c -include AutoGen.h 
-mcmodel=large -mlittle-endian -fno-short-enums -save-temps -fverbose-asm 
-fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer 
-fno-builtin -Wno-address

Re: [edk2] Does EADK support AArch64?

2014-10-09 Thread Joe Thomas 
Joey,

Don't know about EADK but go back in the mailing list archive and look for 
EDK2 GenFw. I posted some info on 9/17 about getting drivers and applications 
(MdeModule/Application/HelloWorld) to build for AArch64.

I've ported several of our drivers and apps (using the StdLib package) to 
AArch64 so shouldn't be too hard to do what you want. Note - there will be LOTS 
of variable defined but not used warnings/errors that will need to be 
corrected along the way...

-Joe Thomas

// Joseph Thomas
// Principal Software Engineer
// Dot Hill Systems
// 2905 NorthWest Blvd., Suite 20
// Plymouth, MN 55441
// 763.226.2640

From: Joey (Xiaozhen) Zhong [mailto:zho...@broadcom.com]
Sent: Thursday, October 09, 2014 1:14 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Does EADK support AArch64?

Hi,

Our project needs to port existing UEFI diag application code from X86 to Arm 
A57 core (AArch64),
Current codebase is using EDK Toolkit 2, so we need to move to EADK.  Does EADK 
have
AArch64 support?  I searched documents and email threads but can not find much 
info on this.

Thanks,
Joey Zhong
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] PEI driver help

2014-12-01 Thread Joe Thomas 
Folks,

I'm trying to convert/port one of our DXE drivers to PEI (for Recovery support) 
but I'm having trouble finding useful information on generating a PEIM module 
that can be integrated into a BIOS.

Does anyone have any good pointers/info that might help point the way? Thanks.


Background:

-  DXE module being built under Edk_1.xx

-  Final output is .DXE or .DXE.ORG file (as well as the .efi)


-  BIOS is MMTOOL compatible


-  Building PEI module w/Edk2

-  Output from 'build' process is name.debug, name.dll or 
name.efi; none are in proper format for use by MMTOOL

Current (test) PEI module is a simple DEBUG() statement and return 
EFI_UNSUPPORTED for PeimEntry(). [Using MdeModulePkg/Bus/Pci/IdeBusPei/* as 
template files.] MMTOOL seems to like output by GenFfs... GenFfs want's 
something with a PE or TE section such as GenSec outputs. Putting the resulting 
output into the BIOS bricks the system... Don't have a debugger that will tell 
me what's happening (hence trying to start with something that will output a 
debug message and exit...)

Thanks again...

// Joseph Thomas
// Principal Software Engineer
// Dot Hill Systems
// 2905 NorthWest Blvd., Suite 20
// Plymouth, MN 55441
// 763.226.2640

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] PEI driver help

2014-12-02 Thread Joe Thomas 
Andrew –

Thanks!

At this point, I’m not sure of anything…  not the least of which is the 
DebugLib.
Continuing to experiment, I did find that if I compile the PEI driver for IA32 
(as opposed to X64), then at least it doesn’t brick the BIOS. Doesn’t mean that 
my code is running since I’m not getting any output but small steps work as 
well. [Very thankful this is still a socketed BIOS chip and not surface mounted 
yet…]

I have some folks helping to get some answers about a number of different 
questions from the BIOS development team so maybe I’ll get hooked up with the 
correct person.
I posted because it just seems like there’s a void when it comes to finding 
information on PEI drivers in general (as opposed to DXE drivers for example).

-Joe Thomas

// Joseph Thomas
// Principal Software Engineer
// Dot Hill Systems
// 2905 NorthWest Blvd., Suite 20
// Plymouth, MN 55441
// 763.226.2640

From: Andrew Fish [mailto:af...@apple.com]
Sent: Monday, December 01, 2014 1:50 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] PEI driver help


On Dec 1, 2014, at 8:48 AM, Joe Thomas 
joe.tho...@dothill.commailto:joe.tho...@dothill.com wrote:

Folks,

I’m trying to convert/port one of our DXE drivers to PEI (for Recovery support) 
but I’m having trouble finding useful information on generating a PEIM module 
that can be integrated into a BIOS.

Does anyone have any good pointers/info that might help point the way? Thanks.


Background:
-  DXE module being built under Edk_1.xx
-  Final output is .DXE or .DXE.ORGhttp://dxe.org/ file (as well as 
the .efi)

-  BIOS is MMTOOL compatible

-  Building PEI module w/Edk2
-  Output from ‘build’ process is name.debug, name.dll or 
name.efi; none are in proper format for use by MMTOOL

Current (test) PEI module is a simple DEBUG() statement and return 
EFI_UNSUPPORTED for PeimEntry(). [Using MdeModulePkg/Bus/Pci/IdeBusPei/* as 
template files.] MMTOOL seems to like output by GenFfs… GenFfs want’s something 
with a PE or TE section such as GenSec outputs. Putting the resulting output 
into the BIOS bricks the system… Don’t have a debugger that will tell me what’s 
happening (hence trying to start with something that will output a debug 
message and exit…)


You can try running VolInfo on the FV that contains your PEIM to see how it got 
packaged up.

The DebugLib can have different underlying implementations. Are you sure you 
are using a DebugLib instance that is compatible with the platform?

Thanks,

Andrew Fish


Thanks again…

// Joseph Thomas
// Principal Software Engineer
// Dot Hill Systems
// 2905 NorthWest Blvd., Suite 20
// Plymouth, MN 55441
// 763.226.2640

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] PEI memory map and PCI mapping

2015-04-03 Thread Joe Thomas 
Folks,

I've been tasked with developing a PEI driver for a PCI device.

So far, I've managed to enumerate bus 0 -- skipping bridge chips for now but 
will probably need to support that later -- find the device I'm interested in, 
and size the memory BAR's.

My question is this:
Knowing the size I want to map, what's the proper way to 
identify/map an area of the PEI memory space to assign to the BAR's? What about 
support for I/O vs. MEM space?

What I've found skimming through the EDK2 code looks like only real RAM is 
supported. The PEI Spec. doesn't seem to talk about non-physical regions. (DXE 
has the MemMapIO type but I don't find any equivalent in PEI.) I hate to wildly 
start picking unused address and just start using them. Seems REALLY likely to 
break.

Any pointers to information would be appreciated.

Thanks.

-Joe Thomas

// Joseph Thomas
// Principal Software Engineer
// Dot Hill Systems
// 2905 NorthWest Blvd., Suite 20
// Plymouth, MN 55441
// 763.226.2640

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel