OSDev.org

Hi everyone,
I recently started an EDK2 project for a little embedded board. Everything works fine so far, but now I struggle with the serial communication.

What I did:
I used this Introduction (step by step) to create my application: https://wiki.osdev.org/EDK2

Some additional functionality I added works so far:

• I successfully jumped to 32 Bit mode and can execute stuff there
• Printing stuff on the screen
• Accessing files (reading and writing)

Now I wanted to use the serial communication. This is what I tried:
In my .dec file:
Adding following : When calling SerialPortInitialize/...Send/...Receive in my main function, it executes those methods from MdePkg/Library/BaseSerialPortLibNull.c instead. (Obviously not sending anything on the serial bus)

How can I call the "correct" function instead of that stub/null thing? I tried to search in this forum, also in google for several hours now but can't find the answer yet.

Any help would be awesome, thank you for reading!!!

You need to use the EFI Serial IO protocol, not the serial port library. In your [Protocols] section of your .INF file, add: And then use the Serial IO protocol like you would any other protocol. (For packages/libraries/... you need to create a DXE (for drivers) or application (for EFI applications) with an INF file for each DXE or app, and then include that in a .dsc for your platform. I don't know what the DEC files are for.)

Okay, that totally makes sense. Somehow I mixed it up completely, thank you for bringing me back on track!

mattibendewald wrote:Okay, that totally makes sense. Somehow I mixed it up completely, thank you for bringing me back on track!

Understandable; I've made that mistake with TimerLib. EDK II's build system can be confusing, and what libraries to use and avoid can also be confusing. The rule of thumb, I think, is: if a library is a template-based library (that is, if it contains a *Null implementation), use the underlying protocol only; otherwise, you can use the protocol in conjunction with the library. In the (majority) of cases involving purely non-template-based libraries, the libraries extend the functionality of EFI applications that use their associated protocol(s), or provide simpler interfaces to the (possibly more complicated) interfaces provided by the protocol.