Re: [edk2] EFI_BLOCK_IO_PROTOCOL questions

Subject: Re: [edk2] EFI_BLOCK_IO_PROTOCOL questions

From: rangasai C <rangasaic@gmail.com>

To: edk2-devel@lists.sourceforge.net

Date: 2010-09-09 22:01:26

Hi Qing,
I put some more traces and found that the EFI_BLOCK_IO_MEDIA is getting messed up in the FlushBlocks() function itself. These incorrect values are used in the ReadBlocks() function that follows the FlushBlocks() function.

Sai

On Thu, Sep 9, 2010 at 12:10 PM, rangasai C <rangasaic@gmail.com> wrote:
Hi Qing,
I have put a trace in the stop function but it's not getting called. So here is the sequence.
1. ReadBlocks(). This one has correct input parameters i.e. MediaId, BufferSize, Buffer etc.
2. FlushBlocks(). This function is called three times. I am just returning EFI_SUCCESS in this function. There is nothing in this function except the return value of EFI_SUCCESS.
3. ReadBlocks(). This is where the input parameters gets messed up. When I detect that, I reinstall the EFI_BLOCK_IO protocol with the correct EFI_BLOCK_IO_MEDIA structure. and everything is good after that.

I will try to see if I can put traces anywhere else where I think EFI_BLOCK_IO_PROTOCOL getting uninstalled.

Regards,
Sai


On Wed, Sep 8, 2010 at 11:40 PM, rangasai C <rangasaic@gmail.com> wrote:
Hi Qing,
I can add a trace in my stop function to see if it gets called but I wonder why would it get called. Also, if that is the case, how can I make sure that the upper level driver is not using any cached BlockIo protocol pointer ?
This would be an interesting experiment

Thanks,
Sai


On Wed, Sep 8, 2010 at 11:13 PM, Huang, Qing <qing.huang@intel.com> wrote:

Hi, Sai,

My guess is that the Stop() function of your driver binding protocol is invoked after the first call of ReadBlocks(). This will cause the original BlockIo protocol interface to be uninstalled. However, the upper level driver still uses the cached BlockIo protocol pointer to access the block device. Can you try adding some trace information on the Stop() routine? If not, can you please check other places in your driver whether the BlockIo protocol gets uninstalled/reinstalled?

Best regards,

Huang, Qing

From: rangasai C [mailto:rangasaic@gmail.com]
Sent: Thursday, September 09, 2010 10:28 AM


To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EFI_BLOCK_IO_PROTOCOL questions

Hi Qing,

Regarding the EFI_BLOCK_IO_MEDIA getting corrupted during the second call to ReadBlocks, I have tried to reinstall the protocol if I see a corruption in the ReadBlocks() function. It kind of solved the problem but like you said, may be with a performance impact. So this is how I am testing my option ROM. Just for simplicity I have removed all the bootable devices from my target system except my HBA. My RAMDISK (which is acting as a drive) has 64 bit DUET shell. I would expect that once I turn on the server, it should boot through my RAMDISK. Below is the sequence of output that I am actually seeing, when the UEFI firmware executes my driver.

1. ReadBlocks () gets called - This should be after the first installation of EFI_BLOCK_IO_PROTOCOL in Start() function. The EFI_BLOCK_IO_MEDIA looks good.

2. ReadBlocks () is called again, following a few calls to FlushBlocks(). This time theEFI_BLOCK_IO_MEDIA is messed up. I detect that and reinstall EFI_BLOCK_IO_PROTOCOL with the correctEFI_BLOCK_IO_MEDIA. This causes to call the ReadBlocks() again. TheEFI_BLOCK_IO_MEDIA is good in this third call to ReadBlocks()

3. By this time, I believe the BDS phase is already done because I don't see any more debug prints out of my hyperterminal. I also see a POST message which says it can't find any bootable device and gives me an option to press F1 to retry.
4. When I hit F1, I see that the system is launching the 64 bit shell from my RAMDISK.

So is the reason that I have to hit F1, because of the fact that I am reinstalling EFI_BLOCK_IO_PROTOCOL ?

If you have any suggestions on how to debug theEFI_BLOCK_IO_MEDIA corruption, please let me know.

Thanks for your time.

Regards,

Sai

On Mon, Sep 6, 2010 at 10:20 AM, rangasai C <rangasaic@gmail.com> wrote:

Hi Qing,

Since my drive is a fixed media, I would not expect the EFI_BLOCK_IO_MEDIA to get corrupted. I can debug from the device side (i.e. after the PCIe link layer) but I am not sure how I can debug from the host BIOS side. It would be tricky to debug this issue, if it is isolated as an Host BIOS issue.

From your comments, it looks like the 8K issue is also a real issue which needs further debugging.

Thanks for your pointers.

Regards,

Sai Chaganty

On Sun, Sep 5, 2010 at 10:19 PM, Huang, Qing <qing.huang@intel.com> wrote:

Hi, Sai,

Please see my comments below:

Best regards,

Huang, Qing

From: rangasai C [mailto:rangasaic@gmail.com]
Sent: Friday, September 03, 2010 11:40 AM


To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EFI_BLOCK_IO_PROTOCOL questions

Thanks Qing.

I agree with you and I will be doing that.

I was also thinking to reinstall EFI_BLOCK_IO_PROTOCOL with correct EFI_BLOCK_IO_MEDIA contents everytime it gets messed up. Is that a correct thing to do or does it violates the spec ?

[Qing] It looks that EFI_BLOCK_IO_MEDIA gets corrupted unexpectedly. BlockIo protocol producer can reinstall it when it detects such corruption, but I am a little concerned about the performance impact as we usually do not need to reinstall that during ReadBlocks/WriteBlocks transactions. So I would recommend to find the root cause of EFI_BLOCK_IO_MEDIA corruption at the first step?

My other question is regarding the option ROM size. I have posted this in my previous queries as well, but basically everytime my image size goes beyond 8K, my target system hangs ( I guess either during shadowing or executing it). Currently my image size is 16 K but by compressing it, I am able to get it to 8K and therefore managing. However, it becomes difficult when I have to add a few extra lines of code, say the DEBUG prints. The image size goes beyond 8K and it's no good for me. I read somewhere that I can fix this by modifying my build environment, i.e. changing .env file or .dsc file. Is that correct ? Could you point me to the right direction ?

[Qing] This looks strange as 8K should not be a limitation of ROM size? Maybe more debugging efforts are required to dig out the root cause. As for size-reduction, the only technique I know about is to remove the DEBUG information by turning off EFI_DEBUG, EFI_SYMBOLIC_DEBUG, etc in config.env in your platform build directory. But this approach will turn off all debug info in your module. L

Thanks,

Sai

Regards,

Sai

On Thu, Sep 2, 2010 at 8:24 PM, Huang, Qing <qing.huang@intel.com> wrote:

Sai,

According to UEFI spec, EFI_BLOCK_IO_MEDIA is one of the interfaces in EFI_BLOCK_IO_PROTOCOL, so it should be set up by the producer of EFI_BLOCK_IO_PROTOCOL. All its fields should be ready-only to its consumers (DiskIo, partition and file system driver). It seems that EFI_BLOCK_IO_MEDIA is messed up from the 2nd call to ReadBlocks(), my guess is that the BlockIo protocol interface is no longer valid then. Chances are that the original BlockIo protocol instance is already uninstalled/reinstalled then, but its consumer still use the original and cached interface to read/write? You may add trace in your driver binding stop routine (usually the place to uninstall BlockIo instance) to test?

Best regards,

Huang, Qing

From: rangasai C [mailto:rangasaic@gmail.com]
Sent: Friday, September 03, 2010 10:50 AM


To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EFI_BLOCK_IO_PROTOCOL questions

Andrew,

I have seen the data that is being read from my drive during the first call to ReadBlocks() ( on a lecroy bus analyzer) and the data is correct, i.e. the data from LBA 0. However, the second call to ReadBlocks() ( right after the flushblocks()) is messed up. I printed out the contents of the EFI_BLOCK_IO_MEDIA during the call to ReadBlocks() using the EFI_BLOCK_IO_PROTOCOL context that is being passed. Interestingly, I see that it is already wrong during the second call to read. Here is a snap shot.

During the first call to ReadBlocks() ( correct one)

Media->MediaID: 1

Media->RemMedia: 0

Media->MediaPresent: 1

Media->LogicalPartition: 1

Media->Readonly: 0

Media->WriteCaching: 0

Media->BlockSize: 200

Media->IoAlign: 4

Media->LastBlock: 270F ***Currently I am having a RAMDISK instead of an actual drive for my experiments it has 10000 sectors***

During the Second call to ReadBlocks() ( wrong one)

Media->MediaID: CD78C1B0

Media->RemMedia: 0

Media->MediaPresent: 0

Media->LogicalPartition: 0

Media->Readonly: 0

Media->WriteCaching: C3

Media->BlockSize: F000DEF8

Media->IoAlign: F000DEF8

Media->LastBlock: F000DEF8F000DD30

During the Third call to ReadBlocks() ( wrong one)

Media->MediaID: CD78C1B0

Media->RemMedia: 0

Media->MediaPresent: 0

Media->LogicalPartition: 0

Media->Readonly: 0

Media->WriteCaching: C3

Media->BlockSize: F000DEF8

Media->IoAlign: F000DEF8

Media->LastBlock: F000DEF8F000DD30

So my questions are:

1. Why the second and third calls to ReadBlocks() is messed up ? Is it something my driver is doing or is it the UEFI firmware that is running on the target system or is it normal and something I have to take care from my side ?

2. Before I install the EFI_BLOCK_IO_PROTOCOL, I setup it's functions including the EFI_BLOCK_IO_MEDIA. Is that the correct thing to do ?

Thanks in advance.

Regards,

Sai

On Thu, Aug 26, 2010 at 4:31 PM, Andrew Fish <afish@apple.com> wrote:

Do you have a log of the LBA addresses being accessed?

The initial accesses to your device will be from probes of the partition driver and then the file system driver. Bad data read from the driver could cause some strange behavior.

Andrew Fish

On Aug 26, 2010, at 4:28 PM, rangasai C wrote:

Mike,

1. My target system is actually one of the type two servers mentioned in the uef.org website and it has 12GB of memory on it.

2. YES, the buffer address and block count parameters are passed into ReadBlocks()

I have double checked my code and found a few local variables that were uninitialized. I did initialize them and the behavior is still the same.

At this point, I guess I am trying to isolate the issue between host BIOS and my device. I am also trying to understand why the block count suddenly jumps to a high value in the read function that follows the Flushblocks () function ( Before that the values were decent), Since the host BIOS is a black box for me I am trying to make sure if there is anything else I have to do in my device driver besides the following two major steps

1. Install EFI_DRIVER_BINDING_PROTOCOL

2. Initialize my controller and install EFI_BLOCK_IO_PROTOCOL, in the Start() function

Also, is it safe to say that if an image works with loadpciromcommand under shell, then the exact same image should work as an option ROM ?

Thanks for your time.

Regards,

Sai

On Thu, Aug 26, 2010 at 3:13 PM, Kinney, Michael D <michael.d.kinney@intel.com> wrote:

Sai,

It also looks like the read buffer address is between 8 GB and 9 GB. I assume you do not really have that much system memory in your platform.

Are these the buffer address and block count parameter passed into ReadBlocks()?

typedef

EFI_STATUS

(EFIAPI *EFI_BLOCK_READ)(

IN EFI_BLOCK_IO_PROTOCOL *This,

IN UINT32 MediaId,

IN EFI_LBA Lba,

IN UINTN BufferSize,

OUT VOID *Buffer

);

Given the unusual values, I am suspecting a 64-bit pointer issue or an uninitialized variable.

Thanks,

Mike


From: rangasai C [mailto:rangasaic@gmail.com]
Sent: Wednesday, August 25, 2010 8:03 PM


To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EFI_BLOCK_IO_PROTOCOL questions

Hello Mike,

I would like to resume this discussion as I have made some progress.
Just to summarize, I am working on a PCIe option ROM which installs a EFI_BLOCK_IO_PROTOCOL. I am able to create a .rom file (MyDrv.rom) by using efirom.exe ( from the tools directory of \Platform\X64\Tools).

The target system has no other bootable devices except a 64bit DUET USB key.

At this point,I've programmed this image into my card and booted my target system.

I see a system hang when the DUET shell tries to initialize. With some debugging, I figured out that it is hanging when it is trying to list the devices it found during the boot (it hangs right after it displays the shell banner showing the version number).

I have tested this .rom file under shell, in my earlier experiments, by using loadpcirom command and I can see my driver listed, when I use the driverscommand.

I took some DEBUG() traces in both cases ( i.e. when loaded from shell and when loaded as option ROM).

When loaded from shell

When loaded from shell (using loadpcirom), I see that first theRead()function is called (only once) with a block count of 1 and a valid Buffer address. Then I do map -r from the shell and I see that the Flush () function is called followed by a call to the Read() function with a block count of 1and a valid physical address. At this point point I can see my drive in the list of bootable devices in shell. I can also navigate into my driver ( dir, cp, etc.)

=== after loadpcirom command ===

Read_func Buffer_PhyAdd: CCDCF01C

Read_func blk cnt: 1

== after map -r ===

Entered Flush function

Read_func Buffer_PhyAdd: CCDCEC98

Read_func blk cnt: 1

When loaded as expansion ROM

In this case, the behavior from the above case. It starts with calling the Read() function 6 times with a block count of 1 and a valid Buffer address. The Bufferaddress are sometimes the same and sometimes they are different. Then it calls the Flush()followed by a call to the Read()function again. In this last call to Read(), the block count is huge and so is the Bufferaddress

Read_func Buffer_PhyAdd: CD2C301C

Read_func blk cnt: 1

Read_func Buffer_PhyAdd: CD30BD98

Read_func blk cnt: 1

Read_func Buffer_PhyAdd: CD30BD98

Read_func blk cnt: 1

Read_func Buffer_PhyAdd: CCE2101C

Read_func blk cnt: 1

Read_func Buffer_PhyAdd: CCE36A18

Read_func blk cnt: 1

Read_func Buffer_PhyAdd: CCE36A18

Read_func blk cnt: 1

Entered Flush function

Read_func Buffer_PhyAdd: 23FFF2018

Read_func blk cnt: 78006F

Could you explain why the block count is so high ? Since I am reading one block at a time, the high block count number in the last Read() explains why I am seeing the system hang.

FYI, since I am in the initial stage of development, I am advertising my drive to be of 5 MBs. I am basically trying to prove the concept here.

Thanks in advance and let me know if you any need any other information

Regards,

Sai

On Fri, Jul 30, 2010 at 12:23 PM, Kinney, Michael D <michael.d.kinney@intel.com> wrote:

The PCI Bus Driver will read the PE/COFF image from the Option ROM and start it during PCI enumeration. This is done by calling LoadImage() and StartImage().

A UEFI Driver that follows the UEFI Driver Model will only register a Driver Binding Protocol in the entry point of the driver, so no connect operations will be performed when the driver is started by the PCI Bus Driver.

The Boot Manager (BDS Phase) is responsible for connecting the devices required to establish console(s) and connect the devices required for booting. The Boot Manager does this through calls to ConnectController(). ConnectController() calls the Supported() and Start() functions in drivers that have registered Driver Binding Protocols.

The EFI Shell command connect r will force all drivers to be connected to all devices.

If your driver is not showing up in the drivers command list, then the driver is not be loaded from the PCI Option ROM. If you manually load the driver from the shell, do you see your driver in the drivers list? If so, then you may have an issue with the PCI Option ROM format or programming.

When you load your driver from the Shell, are Block I/O Protocols produced? If not, then you may have some issues with your Supported() or Start() functions.

The dh d <HandleNumber> is a useful command to see what devices a driver is managing or the state of a device that is being managed by a driver.

The openinfo command is useful for debugging the use of the OpenProtocol() API to make sure the state of your controller and any child devices follows the UEFI Spec.

Other useful commands are devices and devtree.

Best regards,

Mike


From: rangasai C [mailto:rangasaic@gmail.com]
Sent: Friday, July 30, 2010 10:33 AM


To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EFI_BLOCK_IO_PROTOCOL questions

I am curious to know what would the host BIOS do when

1. It finds an option ROM for a bootable device, reads the first few LBAs and finds no valid data ( garbage). Will it try to still boot ? or try for some time and give up? or unload the driver ?

2.It finds an option ROM for a bootable device,tries to do a read but the Read() function returns a EFI_DEVICE_ERROR or EFI_NO_MEDIA ?

Thanks,

Sai

On Fri, Jul 30, 2010 at 10:24 AM, rangasai C <rangasaic@gmail.com> wrote:

I don't see my driver in the Shell, when I type "drivers" command in shell (and I am not sure why). Although, if I don't install the BLOCK_IO protocol ( i.e comment that line in the code). I do see my driver in the shell (ofcourse it won't do anything).

It's interesting to know that the driver won't be connected automatically. My understand was (and please correct me if I am wrong here), in general, during PCIenumeration, the BIOS allocates resources and checks for optionROMs. If it detects option ROM image (after verifying the signature bytes), it shadows the image and jumps to it's entry point and starts executing it. Is shadowing not similar to loading the image and executing not analogous to connecting the driver ?

On Fri, Jul 30, 2010 at 10:12 AM, Andrew Fish <afish@apple.com> wrote:

Can you see your driver in the shell drivers command?

You driver will not get connected (have its Supported() and Stop() functions called) automatically. It will only get connected in specific places, like when the shell loads, or if you do a connect command from the shell.

Andrew Fish

On Jul 30, 2010, at 10:08 AM, rangasai C wrote:

Tian,

I am using DUET only for obtaining shell environment. So basically I have formatted my USB key to a DUET disk to boot a 64bit shell..My driver, on the other hand, is built under EDK1.05 framework and doesn't use of the DUET files or libraries.

Also, I am able to see my debug messages otherwise. It's just that after I install the block Io Protocol, I don't see any messages that I have printed in my read() write(), reset() and Flush () functions.

Basically I can say that for some reason, the BIOS is not calling the functions of EFI_BLOCK_IO_PROTOCOL, even though the interface has been published by my driver.

Thanks,

Sai

On Thu, Jul 29, 2010 at 8:16 PM, Tian, Feng <feng.tian@intel.com> wrote:

Hi, Sai

Could you ensure the debug lib instance of your Pcie device driver is chosen correctly?

In DuetPkg, because of the size limitation, most of drivers are assigned to use BaseDebugLibNull instance which will cause no debug info output.

If you want to see the DEUBG message for your module, you should add such rule in DuetPkgX64.dsc

Path to your Pcie device driver/xxx.inf {

<PcdsFixedAtBuild>

gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F

gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80000042

<LibraryClasses>

DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf

SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf

}

Because your case is hard to root-cause by description, so using debug message to debugging seems the only wayJ

Thanks

Tian Feng

From: rangasai C [mailto:rangasaic@gmail.com]
Sent: Friday, July 30, 2010 7:47 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EFI_BLOCK_IO_PROTOCOL questions

I agree. These kind of issues is hard to explain or guess via emails but I will try to provide as much information I can.

Basically I am using EDK1.05 framework. I am installing the Driver Binding protocol as a global variable, in my driver entry point

return INSTALL_ALL_DRIVER_PROTOCOLS_OR_PROTOCOLS2 (

ImageHandle,

SystemTable,

&gMyDriverBinding,

ImageHandle,

&gMyDriverComponentName,

NULL,

NULL

);

Where gMyDriverBinding is a global variable

EFI_DRIVER_BINDING_PROTOCOL gMyDriverBinding = {

MyDriverBindingSupported,

MyDriverBindingStart,

MyDriverBindingStop,

0x15,

NULL,

NULL

};

and gMyDriverComponentName is also a global variable

EFI_COMPONENT_NAME2_PROTOCOL gMyDriverComponentName = {

MyDriverComponentNameGetDriverName,

MyDriverComponentNameGetControllerName,

LANGUAGE_CODE_ENGLISH

};

On Thu, Jul 29, 2010 at 4:15 PM, Andrew Fish <afish@apple.com> wrote:

OK Hard to guess at what is wrong? Are you allocating your protocol as a local variable on the stack so it no longer exists when your driver entry point returns?

Andrew Fish

On Jul 29, 2010, at 3:40 PM, rangasai C wrote:

You are right. Since this is a device driver, I am installing EFI_DRIVER_BINDING_PROTOCOL. The start() function first initializes the controller and before exiting, it installs EFI_BLOCK_IO_PROTOCOL. For debugging purpose I modified the Read(), Write(), Flush() and Reset() functions such that it just prints a debug message (something like DEBUG((EFI_D_ERROR,"Entered Read function \n")); ) and returns EFI_SUCCESS. I dont' see those messages in my hyperterminal.

On Thu, Jul 29, 2010 at 3:33 PM, Andrew Fish <afish@apple.com> wrote:

You should be installing an EFI_DRIVER_BINDING_PROTOCOL and the Start() function should install an instance of the EFI_BLOCK_IO protocol.

Sent from my iPad


On Jul 29, 2010, at 2:19 PM, rangasai C <rangasaic@gmail.com> wrote:

> Hi All,
> I have written a PCIe device driver which, after initializing the controller, installs a EFI_BLOCK_IO protocol. I don't have a debugger but with DEBUG() macro and DUET, I could verify that Initialization code works and gBS->InstallMultipleProtocolInterfaces () returns Success after I install (or produce) EFI_BLOCK_IO protocol. At this point I would expect that the host BIOS should call the EFI_BLOCK_IO protocol function (Read(), Write(), Reset() and Flush()). However, I see the system hangs. The last message I see in my hyper terminal is the return status of gBS->InstallMultipleProtocolInterfaces, which is EFI_SUCCESS.
>
> Has anyone seen this kind of behavior ? Is there anything, I should be doing here ?.. By the way, I tested my driver by loading through the shell before I converted into option ROM. It works fine in the shell environment.
>
> I am not sure where to look in order to debug this issue !
>
> Thanks in advance.
> Regards,
> Sai

> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel