Hi all,
How can one debug kernel before there is no printk mechanism in kernel.
Regards,
Krishna Chaitanya
On Wed, 30 Mar 2005, krishna wrote:
> Hi all,
>
> How can one debug kernel before there is no printk mechanism in kernel.
>
> Regards,
> Krishna Chaitanya
Write directly to screen memory at 0x000b8000, or write to the
RS-232C UART while polling the TX buf empty bit, or just write
bits that mean something to you out the printer port.
Screen - memory is 16-bit words with the high-word being
an attibute byte. FYI 0x07 is a good B&W byte. You can
initialize a pointer to it as:
unsigned short *screen = 0xc00b8000; Since low memory
is always mapped, the above cheat will work. The 0xc0000000
is PAGE_OFFSET.
An early '486 was brought up into a 32-bit protected-mode
(non linux) operating system using these debugging methods.
The first time I got to see some symbol written to the
screen in protected-mode marked the start of a week-end-
long party. Have fun!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
Video memory is at b800:0000, for humans 0x0000b800, not at 0x000b8000
On Wednesday 30 March 2005 04:47 pm, linux-os wrote:
> On Wed, 30 Mar 2005, krishna wrote:
> > Hi all,
> >
> > How can one debug kernel before there is no printk mechanism in kernel.
> >
> > Regards,
> > Krishna Chaitanya
>
> Write directly to screen memory at 0x000b8000, or write to the
> RS-232C UART while polling the TX buf empty bit, or just write
> bits that mean something to you out the printer port.
>
> Screen - memory is 16-bit words with the high-word being
> an attibute byte. FYI 0x07 is a good B&W byte. You can
> initialize a pointer to it as:
>
> unsigned short *screen = 0xc00b8000; Since low memory
> is always mapped, the above cheat will work. The 0xc0000000
> is PAGE_OFFSET.
>
> An early '486 was brought up into a 32-bit protected-mode
> (non linux) operating system using these debugging methods.
> The first time I got to see some symbol written to the
> screen in protected-mode marked the start of a week-end-
> long party. Have fun!
>
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
> Notice : All mail here is now cached for review by Dictator Bush.
> 98.36% of all statistics are fiction.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Wed, 30 Mar 2005, Vicente Feito wrote:
> Video memory is at b800:0000, for humans 0x0000b800, not at 0x000b8000
>
Wrong. "real-mode" can use a segment address of b800, that doesn't
work in protected mode. A segment address of b800:0000 is never
under any conditions 0000b800.
FYI, a real-mode segment is a 16-byte entity, therefore there are
many segment:offset combinations that can get you to 0x000b8000.
>
> On Wednesday 30 March 2005 04:47 pm, linux-os wrote:
>> On Wed, 30 Mar 2005, krishna wrote:
>>> Hi all,
>>>
>>> How can one debug kernel before there is no printk mechanism in kernel.
>>>
>>> Regards,
>>> Krishna Chaitanya
>>
>> Write directly to screen memory at 0x000b8000, or write to the
>> RS-232C UART while polling the TX buf empty bit, or just write
>> bits that mean something to you out the printer port.
>>
>> Screen - memory is 16-bit words with the high-word being
>> an attibute byte. FYI 0x07 is a good B&W byte. You can
>> initialize a pointer to it as:
>>
>> unsigned short *screen = 0xc00b8000; Since low memory
>> is always mapped, the above cheat will work. The 0xc0000000
>> is PAGE_OFFSET.
>>
>> An early '486 was brought up into a 32-bit protected-mode
>> (non linux) operating system using these debugging methods.
>> The first time I got to see some symbol written to the
>> screen in protected-mode marked the start of a week-end-
>> long party. Have fun!
>>
>> Cheers,
>> Dick Johnson
>> Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
>> Notice : All mail here is now cached for review by Dictator Bush.
>> 98.36% of all statistics are fiction.
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
Did you try turning on CONFIG_EARLY_PRINTK=y? That will allow printk
to a serial console much earlier.
You need to build the serial driver in too:
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
--
Jon Smirl
[email protected]
On Wednesday 30 March 2005 06:09 pm, linux-os wrote:
> On Wed, 30 Mar 2005, Vicente Feito wrote:
> > Video memory is at b800:0000, for humans 0x0000b800, not at 0x000b8000
>
> Wrong. "real-mode" can use a segment address of b800, that doesn't
> work in protected mode. A segment address of b800:0000 is never
> under any conditions 0000b800.
I was referring to the basic conditions, haven't played under protected mode
with that, only in real mode, I assumed the question was under that mode.
What you mean is this:
B800:0010 -> B8010H right?
>
> FYI, a real-mode segment is a 16-byte entity, therefore there are
> many segment:offset combinations that can get you to 0x000b8000.
I'm aware of that, it has nothing to do with my statement.
>
> > On Wednesday 30 March 2005 04:47 pm, linux-os wrote:
> >> On Wed, 30 Mar 2005, krishna wrote:
> >>> Hi all,
> >>>
> >>> How can one debug kernel before there is no printk mechanism in kernel.
> >>>
> >>> Regards,
> >>> Krishna Chaitanya
> >>
> >> Write directly to screen memory at 0x000b8000, or write to the
> >> RS-232C UART while polling the TX buf empty bit, or just write
> >> bits that mean something to you out the printer port.
> >>
> >> Screen - memory is 16-bit words with the high-word being
> >> an attibute byte. FYI 0x07 is a good B&W byte. You can
> >> initialize a pointer to it as:
> >>
> >> unsigned short *screen = 0xc00b8000; Since low memory
> >> is always mapped, the above cheat will work. The 0xc0000000
> >> is PAGE_OFFSET.
> >>
> >> An early '486 was brought up into a 32-bit protected-mode
> >> (non linux) operating system using these debugging methods.
> >> The first time I got to see some symbol written to the
> >> screen in protected-mode marked the start of a week-end-
> >> long party. Have fun!
> >>
> >> Cheers,
> >> Dick Johnson
> >> Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
> >> Notice : All mail here is now cached for review by Dictator Bush.
> >> 98.36% of all statistics are fiction.
> >> -
> >> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> >> in the body of a message to [email protected]
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >> Please read the FAQ at http://www.tux.org/lkml/
>
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
> Notice : All mail here is now cached for review by Dictator Bush.
> 98.36% of all statistics are fiction.
On Wed, 30 Mar 2005, Vicente Feito wrote:
> On Wednesday 30 March 2005 06:09 pm, linux-os wrote:
>> On Wed, 30 Mar 2005, Vicente Feito wrote:
>>> Video memory is at b800:0000, for humans 0x0000b800, not at 0x000b8000
>>
>> Wrong. "real-mode" can use a segment address of b800, that doesn't
>> work in protected mode. A segment address of b800:0000 is never
>> under any conditions 0000b800.
> I was referring to the basic conditions, haven't played under protected mode
> with that, only in real mode, I assumed the question was under that mode.
> What you mean is this:
> B800:0010 -> B8010H right?
>
Sort of, but incomplete....
The real-mode segment is a 16-byte thing:
0001:0000 = 0x00000010
0002:0000 = 0x00000020
0003:0000 = 0x00000030
b801:0000 = 0x000B8010
b802:0000 = 0x000B8020
b803:0000 = 0x000B8030
To get the physical address, you multiply the
segment by 0x10 and add the offset. To access
these in 32-bit "linear" mode, you use the
address on the right. To access these in paged-
mode on Linux, you OR in PAGE_OFFSET. This
is an artifact of how the low-memory page-tables
were written. It is not the "correct" way. There
are macros available to perform the translation
for you if you are making some driver that needs
to work over many kernel versions.
[SNIPPED]
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
linux-os wrote:
> On Wed, 30 Mar 2005, krishna wrote:
>
>> Hi all,
>>
>> How can one debug kernel before there is no printk mechanism in kernel.
>>
>> Regards,
>> Krishna Chaitanya
Here's an implementation by Keith Owens:
http://kernelnewbies.org/documents/videochar.txt
The patch there is to Linux 2.4.18, but should be workable
on many versions.
> Write directly to screen memory at 0x000b8000, or write to the
> RS-232C UART while polling the TX buf empty bit, or just write
> bits that mean something to you out the printer port.
>
> Screen - memory is 16-bit words with the high-word being
> an attibute byte. FYI 0x07 is a good B&W byte. You can
> initialize a pointer to it as:
>
> unsigned short *screen = 0xc00b8000; Since low memory
> is always mapped, the above cheat will work. The 0xc0000000
> is PAGE_OFFSET.
>
> An early '486 was brought up into a 32-bit protected-mode
> (non linux) operating system using these debugging methods.
> The first time I got to see some symbol written to the
> screen in protected-mode marked the start of a week-end-
> long party. Have fun!
--
~Randy