Dreamcast build broken
Hi,
I've been trying to compile a Linux 3.1 vanilla kernel for my dreamcast, but the final binary fails to load on emulators and on the real hardware. The config I'm using is the default one created with "make dreamcast_defconfig".
Is the dreamcast build broken or am I doing something wrong? I tried to git-bisect the commit(s) which introduced the error, but not all kernels will build with GCC 4.5.2, I'll need a good number of different toolchains...
Regards,
Paul
Hi,
The commit which breaks the dreamcast build is the commit 37b7a97884ba64bf7d403351ac2a9476ab4f1bba :
sh: machvec IO death.
Regards,
Paul
Quoted 6 lines · Paul Cercueil
Hi,
The commit which breaks the dreamcast build is the commit
37b7a97884ba64bf7d403351ac2a9476ab4f1bba:
sh: machvec IO death.
It builds fine for me. You will actually have to supply the build error you are experiencing if you expect any further assistance, however.
Quoted 9 lines · Paul Mundt
Quoted 6 lines · Paul Cercueil
Hi,
The commit which breaks the dreamcast build is the commit
37b7a97884ba64bf7d403351ac2a9476ab4f1bba:
sh: machvec IO death.It builds fine for me. You will actually have to supply the build error you are experiencing if you expect any further assistance, however.
Hi,
I am able to compile the Linux kernel, the problem is not the compilation. I do get the "vmlinux" binary once the compilation completes.
However, starting from commit 37b7a97884ba64bf7d403351ac2a9476ab4f1bba and up to the latest vanilla Linux 3.1,
the vmlinux binary won't start on my dreamcast or on the lxdream emulator.
Quoted 7 lines · Paul Cercueil
Quoted 1 line · Paul Mundt
However, starting from commit
37b7a97884ba64bf7d403351ac2a9476ab4f1bbaand up to the latest vanilla Linux 3.1,
the vmlinux binary won't start on my dreamcast or on the lxdream emulator.
No output at all?
Quoted 9 lines · Adrian McMenamin
Quoted 7 lines · Paul Cercueil
Quoted 1 line · Paul Mundt
However, starting from commit
37b7a97884ba64bf7d403351ac2a9476ab4f1bbaand up to the latest vanilla Linux 3.1,
the vmlinux binary won't start on my dreamcast or on the lxdream emulator.No output at all?
Hi,
Sorry for the late reply.
That's right, there is no output at all. Perhaps the binary starts correctly but then it crashes before the activation of the framebuffer.
I am facing another issue about the dreamcast build: the entry point of the kernel is set to 0x8c002000, which does not appear to be correct. When booting a CD, the bootloader (contained inside the IP.bin file) loads the main executable at 0x8c010000.
On a side note, the kernel inside the old DCLinux (based on Linux 2.4) has an entry point set to 0x8c012000.
Quoted 14 lines · Paul Cercueil
Quoted 9 lines · Adrian McMenamin
Quoted 7 lines · Paul Cercueil
Quoted 1 line · Paul Mundt
However, starting from commit
37b7a97884ba64bf7d403351ac2a9476ab4f1bbaand up to the latest vanilla Linux 3.1,
the vmlinux binary won't start on my dreamcast or on the lxdream emulator.No output at all?
Hi,
Sorry for the late reply.
Quoted 8 lines
That's right, there is no output at all. Perhaps the binary starts correctly but then it crashes before the activation of the framebuffer.
I am facing another issue about the dreamcast build: the entry point of the kernel is set to
0x8c002000, which does not appear to be correct. When booting a CD, the bootloader (contained inside the IP.bin file) loads the main executable at0x8c010000.
This is not entirely correct. IP.BIN code does (normally) does not load the main executable. When the original SEGA BootROM boots from a CD-ROM (not GD-ROM), it loads the "hidden" IP.BIN at 0x8C008000 and the "1ST_READ.BIN" (typical name, could be different) to 0x8C010000. After that it will start executing code contained in IP.BIN, which can perform additional startup things. One common technique for bootable CD-ROMs was to put the 1ST_READ.BIN descrambling code into IP.BIN.
For more details see http://mc.pp.se/dc/ip.bin.html
Quoted 2 lines
On a side note, the kernel inside the old DCLinux (based on Linux 2.4) has an entry point set to
0x8c012000.
Could make sense if there are some additional things happening in IP.BIN. However, setting the entry point to 0x8C002000 seems incorrect indeed, as this conflicts with the memory area that is used by the resident GDC driver code of the original SEGA BootROM. With a custom IP.BIN it _is_ possible to copy the already loaded 1ST_READ.BIN to a lower memory address than 0x8C010000 (e.g. 0x8C002000), but it will render the resident BootROM code useless. If the resident BootROM functions are not used by the software being executed there will be no further consequences and some additional KBytes of RAM available ;)
Cheers,
Oleg