Kernel panic on the Dreamcast

bridged with qdn.public.qnxrtp.sh4
Post Reply
Jeremy Penner

Kernel panic on the Dreamcast

Post by Jeremy Penner » Thu Sep 19, 2002 3:51 pm

Figured I'd throw this out here:
I've been doing work on getting QNX running on the Sega Dreamcast. I've
got it booting (via my own custom startup-dc) and talking over a serial
port. I've been trying to write a simple program which draws "Hello
world" on the actual TV screen; making sure I can actually map all the
necessary video RAM and so forth before I go and write a full Photon driver.

After doing the standard edit-compile-copy-test loop for a while, the
kernel suddenly crashed in code that had been running just fine. I took
a screenshot, have a look:
http://www.astranetwork.com/~jeremy/kernelpanic.png

This might be related: I was also seeing a very odd bug whereby a static
variable in my "main.c" was suddenly being set to 0 - after calling a
function in another module ("video.s")! You can see this in the debug
output before the crash. I got around this temporarily by setting it
just before I used it, since it turned out that I only ever used the
value once. Still, very strange. (video.s _works_, it's the standard
Dreamcast sample video code, and in fact I used it to debug the startup
program when I was developing, as for some reason the built-in SCIF code
in the startup library was only giving me garbage.) Is there something
I could be setting improperly in the syspage that could possibly cause
behaviour like this?

Thanks,
Jeremy

Brian Stecher

Re: Kernel panic on the Dreamcast

Post by Brian Stecher » Fri Sep 20, 2002 2:59 pm

Jeremy Penner <jeremy@astranetwork.com> wrote:
After doing the standard edit-compile-copy-test loop for a while, the
kernel suddenly crashed in code that had been running just fine. I took
a screenshot, have a look:
http://www.astranetwork.com/~jeremy/kernelpanic.png
Caveats: I don't really know the SH architecture and I _really_ don't
know anything about Dreamcasts.

A prime mistake to make in startup is to lie about where usable memory
is. If the video memory is in the generic memory region and the OS
is also told that it can use that address range, much hilarity will ensue.

--
Brian Stecher (bstecher@qnx.com) QNX Software Systems, Ltd.
phone: +1 (613) 591-0931 (voice) 175 Terence Matthews Cr.
+1 (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8

Jeremy Penner

Re: Kernel panic on the Dreamcast

Post by Jeremy Penner » Sat Sep 21, 2002 3:52 pm

Brian Stecher wrote:
A prime mistake to make in startup is to lie about where usable memory
is. If the video memory is in the generic memory region and the OS
is also told that it can use that address range, much hilarity will ensue.
Well, for a time, I was telling startup that the Dreamcast's BIOS
routines were fair game for usable RAM, but that was causing me to not
boot at all =] The DC's usable RAM section is 16 meg starting from
0x0c000000, but the BIOS routines are stored from 0x0c000000 -
0x0c008000, so they'd obviously be the first things to go =]

Hmm... taking another look at my startup code, what would happen if my
usable RAM and "device" RAM overlapped? Hilarity, I'd imagine! I just
realized that I was adding "0x0c000000 - 0x0c07ffff" as a device, which
is one f too many. (Incidentally, should I be adding that as something
else, "bios" memory or something? I'm currently just adding every
non-system RAM or ROM as a "device".)

Thanks for the help!
Jeremy
--
Jeremy Penner Internet: jeremy@astra.mb.ca
Astra Network QUICS: jpenner
QNX Consulting and Custom Programming URL: http://www.astra.mb.ca
+1 (204) 987-7475 Fax: +1 (204) 987-7479
---------------------------------------------------------------------------
"He's in it for the money, not the science!"
-- _Twister_, Bill describing the evil, villainous rival tornado chasers

Jeremy Penner

Re: Kernel panic on the Dreamcast

Post by Jeremy Penner » Sat Sep 21, 2002 4:02 pm

Jeremy Penner wrote:
Hmm... taking another look at my startup code, what would happen if my
usable RAM and "device" RAM overlapped? Hilarity, I'd imagine! I just
realized that I was adding "0x0c000000 - 0x0c07ffff" as a device, which
is one f too many. (Incidentally, should I be adding that as something
else, "bios" memory or something? I'm currently just adding every
non-system RAM or ROM as a "device".)
I fixed the overlapping RAM in startup-dc, and my "hello" program kernel
panicked immediately. So disregard this. Any other ideas?

Jeremy
--
Jeremy Penner Internet: jeremy@astra.mb.ca
Astra Network QUICS: jpenner
QNX Consulting and Custom Programming URL: http://www.astra.mb.ca
+1 (204) 987-7475 Fax: +1 (204) 987-7479
---------------------------------------------------------------------------
"He's in it for the money, not the science!"
-- _Twister_, Bill describing the evil, villainous rival tornado chasers

Brian Stecher

Re: Kernel panic on the Dreamcast

Post by Brian Stecher » Tue Sep 24, 2002 2:00 pm

Jeremy Penner <jeremy@astranetwork.com> wrote:
Jeremy Penner wrote:
Hmm... taking another look at my startup code, what would happen if my
usable RAM and "device" RAM overlapped? Hilarity, I'd imagine! I just
realized that I was adding "0x0c000000 - 0x0c07ffff" as a device, which
is one f too many. (Incidentally, should I be adding that as something
else, "bios" memory or something? I'm currently just adding every
non-system RAM or ROM as a "device".)

I fixed the overlapping RAM in startup-dc, and my "hello" program kernel
panicked immediately. So disregard this. Any other ideas?
Just a thorough code review of all callout routines.

--
Brian Stecher (bstecher@qnx.com) QNX Software Systems, Ltd.
phone: +1 (613) 591-0931 (voice) 175 Terence Matthews Cr.
+1 (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8

Post Reply

Return to “qdn.public.qnxrtp.sh4”