It isn’t as loud as I had feared…. I also took some pictures while I was assembling it… So far so good! Â This is the picture I like the most:
I know it’s not all that exciting, but it sure is for me!
It isn’t as loud as I had feared…. I also took some pictures while I was assembling it… So far so good! Â This is the picture I like the most:
I know it’s not all that exciting, but it sure is for me!
I haven’t even tried to build it yet, but after finding a git repository here I had to ‘share’ it somewhere… Looks like there is some SMP bug fixes, and other good stuff so I’ll hope it’ll run on the new Qemu!
And for those of us without git, you can download a zip from the site!
Neat!
While trying to install Virtual PC for windows on the Windows 8 Build 8102, I eventually found out after a lot of finagling that it just isn’t supported. However, get this Hyper-V is in there!
I was hoping for maybe some kind of desktop hyper-v experience but hell I’ll take anything I can get at this point.. At least I can still load up the cisco VPN in my old VM and keep on working there… But I probably shouldn’t have loaded 8 on my main machine.. Live & Learn.
it doesn’t do much, but it does work!.. I saw it mentioned here, and the source archive can be downloaded here.
So I went through the steps of  building a 64bit cross tool to build it.. Although Qemu won’t boot the kernel directly, and it uses GRUB which isn’t so bad but I haven’t made a transparent boot system for it just yet…  Maybe I can use a CD-ROM ISO image…
C:\temp\trunk4>build C:\temp\trunk4>del *.o kernel.bin kernel.ld C:\temp\trunk4>x86_64-pc-elf-cpp -Iinclude -P -C -DLINKER_SCRIPT -o kernel.ld kernel.lds C:\temp\trunk4>x86_64-pc-elf-gcc -Iinclude -Xassembler --divide -c -o startup.o startup.S C:\temp\trunk4>x86_64-pc-elf-gcc -Wall -nostdlib -nodefaultlibs -mcmodel=large -Iinclude -c -o kmain.o kmain.c kmain.c: In function 'kmain': kmain.c:17: warning: unused variable 'n' kmain.c:15: warning: unused variable 'str' C:\temp\trunk4>x86_64-pc-elf-gcc -Wall -nostdlib -nodefaultlibs -mcmodel=large -Iinclude -c -o idt.o idt.c C:\temp\trunk4>x86_64-pc-elf-gcc -Iinclude -Xassembler --divide -c -o isr.o isr.S C:\temp\trunk4>x86_64-pc-elf-gcc -Wall -nostdlib -nodefaultlibs -mcmodel=large -Iinclude -c -o pic.o pic.c C:\temp\trunk4>x86_64-pc-elf-gcc -Wall -nostdlib -nodefaultlibs -mcmodel=large -Iinclude -c -o console.o console.c C:\temp\trunk4>x86_64-pc-elf-ld -nodefaultlibs -z max-page-size=0x1000 -o kernel.bin -T kernel.ld startup.o kmain.o idt.o isr.o pic.o console.o C:\temp\trunk4>x86_64-pc-elf-objdump -S kernel.bin 1>kernel.asm
The ‘warnings’ are all my fault… As I wanted a string not the 1,2,3,4…
So for the two or three people who care, my archive is here… I may move crap around, but at the same time building a 64bit cross compiler was a real chore.. More so because that x86_64-elf bare targets didn’t exist until some time around 4.3.2 which… is involved to build.
Well my server still seems up so that is good…!
A little digging around and I found the article from the logs  (well more like an avalanche of logs!)
Which just seems… Odd. Â Of all the things, it’s an old post about Windows 3.0. Â No mention of Xenix or OS/2 the other protected mode OS’s of 1990…
But I can’t complain over 600 visits beyond the norm is a good thing. Â Too bad nobody stuck around for other pages.
I guess the challenge is for me to make the site more…. compelling to read? I know I’ve been far too terse  the last few years.  Oh well.  One interesting thing is that last night the amount of SPAM actually dropped! … The RSS traffic picked up so we shall see how/if popular this gets… lol
Dennis Ritchie just passed.  He was best known for the creation of the C programming language, and of course his work on Unix & Plan9.
He was 70.
What about people who want to leverage the ‘cloud’ for ancient/legacy systems..?  No doubt I’d imagine there would even be a call for that kind of thing.  I mean hell I still run Exchange 5.5 at home, are there other people/companies that would want to continue running their old software, but instead of doing it a home, run it in a real data center?
Anyways, I’m looking forward to Proxmox / VE 2.0, they’ve even dropped a beta.
I was hoping to do more with this, but things are going other ways in life. Â Anyways a while back I had touched on xv6, a MIT teaching tool and semiport of Unix v6 to the i386! Â The best part about it, is that it is SMALL…
I’ve been playing with it the last day on the latest version of Qemu and hit a snag with its SMP support (yes it does have that!) so I played with it, and couldn’t figure it out so I had to turn it off.. It is something ACPI related, and probably along the reason why Windows x64 doesn’t run on new Qemu either..
I’ve built the cross compiling environment needed (A bare elf compiler/linker/assembler) and managed to smash enough of it into a single directory that you won’t need MinGW installed, but can rather invoke ‘build.bat’ which will compile link, dd the disk image, and launch Qemu.
I’ve had trouble with mkfs so… you’ll have to live with a prebuilt root image.
If you want to build your own cross compiling toolchain, there is a good guide here on the OSWiki. Â Naturally you’ll want my previous post on some snags I ran into on MinGW if you do choose that as your target environment.
What I’d love to do is port newlib, and see just how useful this xv6 could become.. Â I would imagine adding signals (well beyond kill) may allow things like bash 1.x to run, and maybe gcc itself.. Which would be cool.
You can download my work here. Â Check it out, it’s cool!
rm -f collect2.exe gcc -DCROSS_COMPILE -DIN_GCC -g -O2 -DHAVE_CONFIG_H -o collect2.exe collect2.o tlink.o hash.o intl.o underscore.o version.o obstack.o -ladvapi32 ../libiberty/libiberty.a collect2.o: In function `handler': C:\MinGW\msys\1.0\src\gcc-2.95.3\gcc/collect2.c:527: undefined reference to `kill' collect2.o: In function `scan_prog_file': C:\MinGW\msys\1.0\src\gcc-2.95.3\gcc/collect2.c:2269: undefined reference to `pipe' C:\MinGW\msys\1.0\src\gcc-2.95.3\gcc/collect2.c:2292: undefined reference to `fork' collect2: ld returned 1 exit status make[1]: *** [collect2.exe] Error 1 make[1]: Leaving directory `/usr/src/gcc-2.95.3/gcc' make: *** [all-gcc] Error 2
Ugh, isn’t that annoying? Well it turns out from the mailing list…
The mingw32-hosted GCCs does not need ‘collect2.exe’ hence
set USE_COLLECT2= nothing (empty) in the <gcc_obj_dir>/gcc/Makefile
This needs to be fixed in GCC mainlne.
Regards.
Nitin.
And the other half….
fixincl.c:316: error: `SIGQUIT' undeclared (first use in this function) fixincl.c:316: error: (Each undeclared identifier is reported only once fixincl.c:316: error: for each function it appears in.) fixincl.c:323: error: `SIGALRM' undeclared (first use in this function) fixincl.c: In function `internal_fix': fixincl.c:808: warning: implicit declaration of function `pipe' fixincl.c:816: warning: implicit declaration of function `fork' fixincl.c:845: warning: implicit declaration of function `sleep' fixincl.c:860: warning: implicit declaration of function `fcntl' fixincl.c:860: error: `F_DUPFD' undeclared (first use in this function
Which is fixed by changing
STMP_FIXINC = stmp-fixinc
into
STMP_FIXINC =
Oops!