gdb remote debugging + shared video ram question

[Rene Reusner]

s6994440 at mail.inf.tu-dresden.de(s6994440 at mail.inf.tu-dresden.de)@2006.01.30 14:49:19 +0100:
> Hello,
> 
> I'm a l4 beginner. So I have 2 questions to standard issues (guess) .
> 
> 1.:
> 
> I followed the Building & Using Fiasco html to the debugging point.
> - I removed the -nowait Kerneloption
> - I edited the .gdbinit file with
> 	>  file ../build_x862/kernel.image  (current compiled kernel)
> 	>  target remote /dev/ttyS0	(debugging on COM1)
> - When fiasco comes up, I start gdb and immediatly after that my
> testmachine reboots, when it comes back up everytime i type c in my host
> debugger it reboots again.

Debugging via serial line and gdb requieres an "very very old" gdb.
Because everybody here uses the JDB, we really don't support it anymore.

> - When I use >  file ../build_x86/kernel.image, a kernelimage I built some
> time ago, gdb says > 0x00000000 in ?? ()

Use "main" or the symlink "fiasco" file, which points to main.

"kernel.image" is the unstripped plain elf version, useful for objdump
and co (for debugging at assembler level).

> and again, when I press c it reboots.
> - There was no KDB::Init- Message at all.
> - I expected the kernel to continue normal operation like with the
> "nowait" option after pressing c in the debugger..., Am I wrong ?
> - Kernelconfiguration in globalconfig.out
> - My menu.lst:
>      38 title fiasco
>      39 kernel $(P)/bootstrap
>      40 modaddr 0x02000000
>      41 module $(PF)/fiasco-o -comport 1 -comspeed 115200
>      42 module $(P)/sigma0
>      43 module $(P)/roottask
> 
> 2.:
> 
> My testmachine is an Advantech PCM 5820. It shares the video mem with
> normal RAM. When I boot up DOpE I get several error messages (see file
> error.txt)
> The following lines put L4io about my video:
> 
> io      |   40800000-40ffffff : Cyrix Corporation 5530 Video [Kahlua]
> io      | WARNING: Cannot handle memory 40800000-40ffffff for device
> 1078:0104

Uhhh, this is an Problem with the L4-V2 API,
To cite an comment from the fiasco sourcecode in
map_util.cpp:

// For IPC mapping purposes, sigma0 addresses 0x40000000-0xbfffffff
// are shifted to 0x80000000-0xffffffff -- ugly but true!

The purpose of this, was to allow mapping of device memory, which is
behind the 3GB barrier.

I don't think, an quick "hack" in the fiasco kernel source
in map_util.cpp will help, because the userland needs some fixes too.
But i leave the this question to the userland experts.

rene