- What changes are required to be made to the kernel to enable migration to SCC.
we have summarized the changes necessary to run Linux on the SCC in a paper, which was published at the MARC Symposium in Ettlingen, Germany last year: Linux Operating System Support for the SCC Platform - An Analysis - Hasso Plattner Institute, Sobania, Troger, Polze.pdf. Here's a very short overview:
The SCC uses almost unmodified P54C cores, which are comparable to a Pentium core originally running at 90MHz. So if your kernel works on an old Pentium-based system, it should work on the SCC as well. There are some caveats with memory management and I/O, though.
Differences between the GaussLake (SCC) and original P54C include larger caches and support for MPBT mappings. The MPBT mapping type can be enabled via a bit in CR4 (this bit is marked reserved in the original P54C manual), and it seems to be mutually exclusive with PSE (which can also be globally enabled via CR4). I got strange results when having both features enabled at the same time.
I mention this because the GaussLake advertises availability of PSE via CPUID. So if your kernel behaves like Linux and unconditionally enables PSE in CR4 in these cases, you may want to change that. However, this change is not required; you can use PSE if you do not want MPBT, it works just as fine as on a regular P54C.
Now for I/O. The SCC does not have a PC-compatible "chipset" (or "south bridge"), so none of the standard PC devices (like CMOS/RTC, IDE controller...) or memory mappings (VGA frame buffer below 1MB) are available.
Starting with sccKit 188.8.131.52 (the current version), there is a minimal "SCC BIOS" in place, but it mostly contains stubs to allow standard Linux real-mode boot code to run. The only function that has really been implemented is querying the E820 memory map.
Starting with one of the later sccKit versions (I think it was 1.4.0), there is a VGA frame buffer available in core-private physical memory. For sccKit 184.108.40.206, if you query the E820 memory map, you will notice that the end of physical memory is some MB before the end of a 16MB LUT slot. This non-assigned space can be read from the MCPC and act like a frame buffer. I have never looked at the details, though; you should be able to find them in the source code of the sccgfx driver or the sccDisplay program for the MCPC. If you do not need a VGA frame buffer, you can ignore this space completely and just go with the E820 map as on a regular PC.
Again starting with 220.127.116.11, there are 4 virtual serial ports (16550A-compatible) available per core, at standard PC I/O ports. These are connected via "virtual null-modem cables" to devices on the MCPC, thus allowing programs like minicom to exchange data with the core. If you want to use these ports, please note that the device emulation does not generate interrupts to the cores; you must use polling on the SCC. On the MCPC, they appear like standard serial devices.
- The steps to load a kernel binary on to a SCC core.
I think the easiest method would be to prepare a file like "linux.obj" (that is generated by the official toolchain).
You do this by generating a memory image for your kernel; this is a binary file that can be copied as-is into target memory and started by simply jumping to its entry point (in real mode).
Then, create a load.map file and run bin2obj on it. The load.map lists binary files and (core-private) addresses at which they will be loaded. bin2obj generates the "obj" file that can then be used by sccBoot/sccGui to start your kernel.
bin2obj is available as part of sccKit. Also included are source and binaries for the other files mentioned in the default load.map, like our minimal SCC BIOS, its real-mode interrupt vector table and the reset vector code. The two other files mentioned in the default load.map (setup.bin and vmlinux) hold the real-mode and protected-mode portion of the Linux kernel.
- A method to debug the kernel once it is loaded and running.
There is no SCC-specific debug method, it works just like kernel debugging on a real PC. You can use above-mentioned virtual serial ports to communicate with an in-kernel debug stub.
Thanks a lot for the detailed explanation!! I guess I will first try to load a small piece of code instead of the kernel
as I am not very clear with the method of loading. I will have to look into the sources. Thanks!!
Is there any documentation available for the steps to use virtual serial ports and minicom ?