Ronald G Minnich <[EMAIL PROTECTED]> writes: > I'm sorry I can't get this. > > Here is some code. > > .text > 9: mov $TTYS0_LSR, %dx > inb %dx, %al > test $0x20, %al > je 9b > mov $TTYS0_TBR, %dx > mov $'A', %al > outb %al, %dx > jmp 9b > > Here is the assembly of the code: > > gcc -o testserial.o -c testserial.S > ld -T elfImage.lds -o testserial.elf testserial.o [snip mkelfImage run]. > Any hint on what I'm doing wrong?
Sorry for the long delay. I have been having a hard time figuring out how to explain to you what is happening, and what you are doing wrong. First by it's very lonesome testserial.elf is perfectly fine, mkelfImage is not needed. To explain more I think I will have to tell you the history of my ELF booting work because quick small explanations, nor a handful of examples do not seem to be getting the job done. I started with Ron's LinuxBIOS kernel loader, and his LOBOS work. Both of these use the x86 kernel's 32 bit entry point. And they both pass to that kernel all of the information it needs from the stripped off 16bit code. At the time I was also setting up and stabalizing network booting using etherboot for Linux NetworX. I was doing this as a stop gap measure to by time until I could get LinuxBIOS on motherboards we could use. So I wanted a format that I could use both with network booting and with LinuxBIOS. Etherboot had a nice file format format that would allow it to load fairly arbitrary programs. But the format was not portable to non-x86 platforms. A major requirement for LinuxBIOS. So I started hunting for a portable file format with the same properties that Etherboots native file format had. That is: Load this chunk of file into this chunk of memory, and repeat for the next chunk. When done jump to this address. I looked at a serveral different file formats and the cleanest was the common ELF file format, which was a real suprise to me. To work with etherboot I wrote the first version of mkelfImage modeled after mknbi but using a different file format. And jumping to the kernels 32 bit entry point. At that point I had etherboot gathering up the required 16bit bios data for me. And after writing an ELF loader for LinuxBIOS there the code sat while I worked on other issues. I have had several interesting experiences since that point. The port of LinuxBIOS to the alpha, and my subsequent failure to port mkelfImage. My ports of memtest86 and etherboot to LinuxBIOS. Some talks on the linux-kernel mailing list with H. Peter Anvin, and others. And my experience maintaining mkelfImage. >From the alpha port, the memtest86 port and the etherboot port I have discovered that making ELF bootable images is almost trivial. Usually it requires just small changes to the makefile or the build system of a program. So a utility like mkelfImage is generally overkill if you can actually modify the source. On the question of the difficulty of a full operating system port to LinuxBIOS the court is still out. From the linux on alpha port there were a lot assumptions all over the architecuture specific code as to just how the firmware was setup, and it would have required some heavy lifting. Looking at the linux on X86 code, there are some embedded assumptions (like writing to the bios data area) and the lifting doesn't look as bad. Given that for every OS there will be some amount of heavy lifting when we introduce it to LinuxBIOS is it worth it to have our own interface? From history with environments like OS/2 emulating windows, and my personal experience with dosemu. I can say that anytime you must be bug compatible with someone else just to get users it is a loosing battle. However there is already enough variation in the current x86 firmware that we wouldn't have to be bug compatible, and we do have users without it so on x86 it is a possibility. However much of the value of LinuxBIOS on the high end comes from enabling things the current x86 firmware doesn't have interfaces for. So really a port is required anyway. So yes having our own interfaces is worth it because that part of our appeal. For some users it might be worth having a bootloader that implements a compatibility interface. But since I don't currently have a use for it I'm going to implement it. O.k. coming back to focus. In talking with the kernel developers and especially H. Peter Anvin I have come to realize that if some bios table has bugs you want to be as close to the source of that information as you can. This is because a normal kernel is both more widely tested, and is developed faster than a bootloader (which you want to be as static as possible once it works). And our scheme of gathering up BIOS information and passing it to a loaded kernel puts the kernel one step removed from the source of the data, and makes it harder to work around bugs. And for this reason I have changed the ELF booting to not pass information and instead have the loaded image gather all of the information it needs. In my working with mkelfImage and mknbi. I have to say that they are good tools, and mkelfImage is great for prototyping what needs to happen. But you pretty much have to port them to an individual OS. So while in the more mature mknbi all of the variants (mknbi-linux, mknbi-dos, mknbi-rom) are handled by one perl script. The mknbi --target option (which picks linux, dos, or rom) is quite important. And unfortunantely I haven't implemented a similiar option yet for mkelfImage. And the lack of a --target option to specify linux or 9load and have mkelfImage to completely different things depending on the OS is what I belive you are missing. The current mkelfImage really is quite linux OS specific but it can't tell a non-linux vmlinux from the linux OS itself. >From where I am sitting it looks just as easy and probably easier to do pure native ELF booting ports than to port mkelfImage, to another OS. mkelfImage-linux supports every optional ELF booting feature under the sun so it is a good piece of example code. Given all of that, my current plans are to maintain mkelfImage until we get a true native linux port included in a stable linux kernel. At which point mkelfImage will be unnecessary. My plans don't including giving up on the tool writing business though. There is definentily a place for a ``compresself'' to make self extracting ELF executables. And there is a place for a ``kparam'' to set a linux command line, add an initrd, and in general replace rdev and be portable. All of that is a little ways out but I think those will be stable maintable solution for what I want to do. And Ron with that background. I guess I can say that mkelfImage-linux hard codes the location of the data segment at 1MB. Because that is what x86 linux always does. And the code is much simpler that way. Eric
