Hello Tobias,
thanks for your report! See my comments below.
Afterwards I have been playing around with the user land, writing a
simple program loaded as module from grub which is printing "Hello
Word!" onto the kernel console. First I tried linking in all the needed
object files for getting the printf directive to work. When
I realized that this would not be that easy because it would require
almost the complete kernel to link into it
Sorry, you lost me here. If your goal was to create an _user_space_
program that writes something to the kernel console, why would you need
to _link_ it with the kernel? The kernel and any user space program are
two completely separate entities.
I simply used the libc from the HelenOS userspace for linking.
Yes, this is definitively a better way to go.
Alternatively, you don't even need the complete HelenOS libc to
implement such a basic task as printing a string to the kernel console
from user space. You just need to implement simplified variants of the
following functions (say for IA-32) and a few other things:
__entry (from uspace/lib/c/arch/ia32/src/entry.S)
__syscall_fast (from uspace/lib/c/arch/ia32/src/syscall.S)
__main (from uspace/lib/c/generic/libc.c)
klog_write (from uspace/lib/c/generic/io/klog.c)
The decision whether you should use the complete HelenOS libc or whether
you should create your own stripped down run-time library is an
extension of the question I have already written about previously:
What should be the target software architecture of Genode/SPARTAN?
Should it be a complete HelenOS user land with Genode user land running
side-by-side? Should it be just the SPARTAN kernel with Genode user
land? Or should it be a customized combination of both?
The problem is that all attempts of printing
something to the serial port (using qemu with the "-serial mon:stdio"
option which should redirect all output from the serial port to the
console where qemu is started from) failed (the code can be found in
.base-spartan/src/simple_serial_print). So the question is what went
wrong. Is the linking that something that can't be processed by the
kernel (in my opinion unlikely because there where no complaints that
the module could not be loaded)?
Again, could you please explain what do you mean exactly by "linking
[..] processed by the kernel"? You don't link the user space task with
the kernel.
Or am I not able to access the serial
port the way I am trying to (e.g. because of enabled port protection)?
This is a correct hypothesis. You have to use the SYS_IOSPACE_ENABLE
syscall to ask the kernel for permission to access the I/O port range.
See the function pio_enable() in uspace/lib/c/generic/ddi.c for the user
space interface of the syscall.
Furthermore there is the question if there are different serial ports
for different architectures? Because I found different serial port
implementations for sparc (./kernel/genarch/drivers/ns16550) and ARM
(./kernel/genarch/drivers/s3c24xx_uart) but none for x86, with whom I am
working currently.
You know, accessing peripherals on a PC can be a tricky business. That's
why we have a complete device driver framework in HelenOS.
But serial ports are legacy devices even on PCs and they can be
(usually) trusted to be located on well-known I/O addresses.
The I/O address 0x3f8 from your code is the same as the hard-wired I/O
address in our DDF (see uspace/drv/bus/isa/isa.dev), therefore I believe
it should work fine in QEMU.
1) Are there any serial port implementations in the kernel I can use?
(in general and specific for the x86 architecture)
We currently don't have a kernel PC serial port (NS8250) driver in
HelenOS, but we have an user space PC serial port driver (see
uspace/drv/char/ns8250).
- if no: do you have any suggestions how I can access the serial
port in general?
Well, an user space driver sample is perhaps even better for you than a
kernel driver sample.
2) Do I have to pay attention to any special things while linking when
using the genode linker script? (like special required sections, special
placement of segments/sections, etc.)
Nothing specific comes to my mind. The kernel would print an error
message to the kernel console if the loading of the user space binary
should fail (see kinit() in kernel/generic/src/main/kinit.c).
On the other hand, if you suspect a problem with the kernel ELF loader,
you should inspect the code in more detail
(kernel/generic/src/lib/elf.c). The loader is indeed simplified and it
might just skip segments or sections which it doesn't know.
M.D.
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
