Hello, How do I convert an Assembly JMP instruction to C. What I would like to do is execute an executable assembly blob located in memory. From the docs I have read, for assembly you just need to issues a JMP to the memory location to execute it. How to do the same in C, that is the question...
P.S. This question is leading up to something great :-)
On Wed, Sep 10, 2008 at 1:35 PM, Joseph Smith joe@settoplinux.org wrote:
Hello, How do I convert an Assembly JMP instruction to C. What I would like to do is execute an executable assembly blob located in memory. From the docs I have read, for assembly you just need to issues a JMP to the memory location to execute it. How to do the same in C, that is the question..
P.S. This question is leading up to something great :-)
one way to get an abs jump is something like:
void (*f) (void);
f = (some nice cast) 0x8010000;
f();
or some such. I've used many variants, over the years, exact invocation is compiler dependent.
ron
Joseph Smith wrote:
Hello, How do I convert an Assembly JMP instruction to C. What I would like to do is execute an executable assembly blob located in memory. From the docs I have read, for assembly you just need to issues a JMP to the memory location to execute it. How to do the same in C, that is the question...
P.S. This question is leading up to something great :-)
Does that code return via "ret"? If so, you'd need a call instead of a jmp, which is basically a function call.
If it does not return, I suggest you use asm volatile (" jmp 0xADDR;\n");
Stefan
On Wed, 10 Sep 2008 22:43:03 +0200, Stefan Reinauer stepan@coresystems.de wrote:
Joseph Smith wrote:
Hello, How do I convert an Assembly JMP instruction to C. What I would like to
do
is execute an executable assembly blob located in memory. From the docs
I
have read, for assembly you just need to issues a JMP to the memory location to execute it. How to do the same in C, that is the question...
P.S. This question is leading up to something great :-)
Does that code return via "ret"? If so, you'd need a call instead of a jmp, which is basically a function call.
If it does not return, I suggest you use asm volatile (" jmp 0xADDR;\n");
no, this place would be "the point of no return" (seems a little scary leaving the comfort of coreboot). :-)
But seriously, would asm volatile() be better than Ron,s solution? Also this would be executed from a payload using libpayload, is there already something written in libpayload?
On Wed, Sep 10, 2008 at 1:58 PM, Joseph Smith joe@settoplinux.org wrote:
But seriously, would asm volatile() be better than Ron,s solution?
For me the rule is simple: if it can be done in C, it should not be done in assembly. That's why C was created.
I feel that the c solution is far superior :-)
ron
On Wed, 10 Sep 2008 14:08:14 -0700, "ron minnich" rminnich@gmail.com wrote:
On Wed, Sep 10, 2008 at 1:58 PM, Joseph Smith joe@settoplinux.org
wrote:
But seriously, would asm volatile() be better than Ron,s solution?
For me the rule is simple: if it can be done in C, it should not be done in assembly. That's why C was created.
I feel that the c solution is far superior :-)
I agree with you here Ron, thanks.
Joseph Smith wrote:
How do I convert an Assembly JMP instruction to C.
Short answer: You can't. There is setjmp() but it is not supported in libpayload.
Write a function in assembly that you can call from C. There should be lots of examples of this on the net. One immediate resource idea is http://asmutils.sf.net/
//Peter
On Wed, 10 Sep 2008 22:45:13 +0200, Peter Stuge peter@stuge.se wrote:
Joseph Smith wrote:
How do I convert an Assembly JMP instruction to C.
Short answer: You can't. There is setjmp() but it is not supported in libpayload.
Write a function in assembly that you can call from C. There should be lots of examples of this on the net. One immediate resource idea is http://asmutils.sf.net/
Good guess Peter that I would be executing this from libpayload. The link above does not seem to be working for me?
Joseph Smith wrote:
Good guess Peter that I would be executing this from libpayload. The link above does not seem to be working for me?
My bad. Look for asmutils in the menu at http://asm.sf.net/ AKA http://linuxassembly.org/ There is even a 5kb libc.
Or just go with Ron's idea. :)
//Peter
OK, My JMP question is about copying a drives mbr to memory 0x7c00 and or 0x0600 at 512 byte blocks. Which is doable. I haven't decided wetheir to try Ron's suggestion and try to execute the mbr (hence the JMP question) OR we could even write code to translate the mbr and JMP/execute directly to the active bootable partition OR even better we could write code translate the mbr, goto the active bootable partition and translate it, and JMP/execute right to the boot manager, thus bypassing a whole bunch of real mode interrupts. What do you think?
The question is: Do you know if coreboot ties up any memory at these addresses?
On Thu, 11 Sep 2008 23:53:04 +0200, Peter Stuge peter@stuge.se wrote:
Joseph Smith wrote:
My JMP question is about copying a drives mbr to memory 0x7c00 and or 0x0600 at 512 byte blocks.
..
What do you think?
I think you should just use SeaBIOS.
Nope. This will be a autoboot_mbr option of FILO. Here is how it will work:
It will comb through each drive and attempt to boot the first drive with a valid mbr signature bit (0xAA55). Maybe a slight delay for user intervention, and then boot boot the drive based on the info in the mbr.
On 11/09/08 17:49 -0400, Joseph Smith wrote:
OK, My JMP question is about copying a drives mbr to memory 0x7c00 and or 0x0600 at 512 byte blocks. Which is doable. I haven't decided wetheir to try Ron's suggestion and try to execute the mbr (hence the JMP question) OR we could even write code to translate the mbr and JMP/execute directly to the active bootable partition OR even better we could write code translate the mbr, goto the active bootable partition and translate it, and JMP/execute right to the boot manager, thus bypassing a whole bunch of real mode interrupts. What do you think?
You won't be successful. Any executable code in any MBR is going to use real mode software interrupts. You can't get around that, you shouldn't try. We have very intellegent payloads that can boot any operating system imaginable. Use that.
Jordan
On Thu, 11 Sep 2008 16:03:04 -0600, Jordan Crouse jordan.crouse@amd.com wrote:
On 11/09/08 17:49 -0400, Joseph Smith wrote:
OK, My JMP question is about copying a drives mbr to memory 0x7c00 and or 0x0600 at 512 byte blocks. Which is doable. I haven't decided wetheir to try Ron's
suggestion
and try to execute the mbr (hence the JMP question) OR we could even
write
code to translate the mbr and JMP/execute directly to the active
bootable
partition OR even better we could write code translate the mbr, goto the active bootable partition and translate it, and JMP/execute right to the boot manager, thus bypassing a whole bunch of real mode interrupts. What
do
you think?
You won't be successful. Any executable code in any MBR is going to use real mode software interrupts. You can't get around that, you shouldn't try. We have very intellegent payloads that can boot any operating
system
imaginable. Use that.
Ah, Jordan you speak to soon. I have learn a way to setup a simple real mode interrupt handler, capable of sending generic/dummy responses back to the software....
Joseph Smith wrote:
I think you should just use SeaBIOS.
Nope. This will be a autoboot_mbr option of FILO. Here is how it will work:
So you're teaching FILO how to act like a BIOS.
I will fight that patch hard. I'm afraid I think this design is completely misguided.
Joseph Smith wrote:
Ah, Jordan you speak to soon. I have learn a way to setup a simple real mode interrupt handler, capable of sending generic/dummy responses back to the software....
We generally want less of these, not more. Because they are needed for compatibility reasons the ideal scenario is to contain them in one single place. That place is SeaBIOS.
If you want BIOS behavior, just use a BIOS.
//Peter
On Fri, 12 Sep 2008 00:19:11 +0200, Peter Stuge peter@stuge.se wrote:
Joseph Smith wrote:
I think you should just use SeaBIOS.
Nope. This will be a autoboot_mbr option of FILO. Here is how it will work:
So you're teaching FILO how to act like a BIOS.
I will fight that patch hard. I'm afraid I think this design is completely misguided.
Joseph Smith wrote:
Ah, Jordan you speak to soon. I have learn a way to setup a simple real mode interrupt handler, capable of sending generic/dummy responses back to the software....
We generally want less of these, not more. Because they are needed for compatibility reasons the ideal scenario is to contain them in one single place. That place is SeaBIOS.
If you want BIOS behavior, just use a BIOS.
Dam it Peter, I don't want to make FILO into a "BIOS". I would think by now you would know better than that. I just want to make it boot like a bootloader should. A bootloader should be able to boot a drive without specifing PATHS. It should be able to read the drives info and boot to the OS. No matter what OS it is.....
Joseph Smith wrote:
If you want BIOS behavior, just use a BIOS.
Dam it Peter, I don't want to make FILO into a "BIOS".
You want to make it act like one.
I just want to make it boot like a bootloader should. A bootloader should be able to boot a drive without specifing PATHS.
Now this is an interesting discussion!
It should be able to read the drives info and boot to the OS. No matter what OS it is.....
That requires standardization among the OSes. They all have to behave the same way to some limited degree. At present, the standard is BIOS and SeaBIOS is how we implement this standard. It has already been done, don't spend time implementing it again. (But please help Kevin out if you want to.)
As for a new standard I think we should start out by evaluating all current disklabel schemes to see what state of the art is, and how we can improve upon it.
//Peter
As for a new standard I think we should start out by evaluating all current disklabel schemes to see what state of the art is, and how we can improve upon it.
Ahh, that is the whole point I'm trying to get accross. I have been studying mbrs/partition tables and how they work, and what data is contained in them. I really think it is possible to take the data from the mbr/partition table and manipulate it to our advantage, thus bypassing ALL real mode interrupts. The problem would be if an OS (like windows) deciedes to make a INT call....
But for Linux, I really feel it is possible.
Joseph Smith wrote:
state of the art
mbrs/partition tables
See how those two don't fit together?
I really think it is possible to take the data from the mbr/partition table and manipulate it to our advantage, thus bypassing ALL real mode interrupts. The problem would be if an OS (like windows) deciedes to make a INT call....
You are missing the point.
If you implement the BIOS method, you will only reach more code that requires and assumes a BIOS method. This makes perfect sense;
The MBR assumes a BIOS is available. Code that the MBR points to somehow will also assume a BIOS, because there is no way the computer would execute that code unless a BIOS is running and arrived there by enumerating MBRs, picking one and going on from there.
But for Linux, I really feel it is possible.
The MBR path will lead to the Linux real mode entry point.
I hope you agree with me that one major design goal of a new boot standard will be to eliminate real mode from x86 boot.
Stop wasting time on BIOS things. Do a comparison with all other disk labels that the composite of Linux, BSD and Windows NT supports.
//Peter
mbrs/partition tables
See how those two don't fit together?
Sorry bad terminoligy MBR/first sector of the Active Partition
I really think it is possible to take the data from the mbr/partition table and manipulate it to our advantage, thus bypassing ALL real mode interrupts. The problem would be if an OS (like windows) deciedes to make a INT call....
You are missing the point.
If you implement the BIOS method, you will only reach more code that requires and assumes a BIOS method. This makes perfect sense;
The MBR assumes a BIOS is available. Code that the MBR points to somehow will also assume a BIOS, because there is no way the computer would execute that code unless a BIOS is running and arrived there by enumerating MBRs, picking one and going on from there.
But for Linux, I really feel it is possible.
The MBR path will lead to the Linux real mode entry point.
I hope you agree with me that one major design goal of a new boot standard will be to eliminate real mode from x86 boot.
Yes. But I will hope that you will agree with me that a "smart" bootloader not having to specify a PATH is key.
Stop wasting time on BIOS things. Do a comparison with all other disk labels that the composite of Linux, BSD and Windows NT supports.
I have.
I got your point. I realize "executing" these "BIOS things" is the wrong way to go. You would be bound to run into a real mode interrupt. Which you are really opposed to. But, All the info to boot is laid out in the MBR/first sector of the Active Partition.
1. the MBR tells us where to find first sector of the Active Partition. 2. The first sector of the Active Partition tells us where OS Boot Sector code (GRUB stage2) is
Why is that so complicated to see?
Joseph Smith schrieb:
are really opposed to. But, All the info to boot is laid out in the MBR/first sector of the Active Partition.
The first sector contains code. Code, that usually relies on BIOS services to proceed (eg. to load its own config, to load the kernel, etc)
- the MBR tells us where to find first sector of the Active Partition.
- The first sector of the Active Partition tells us where OS Boot Sector
code (GRUB stage2) is
Even GRUB stage2 relies on BIOS services for all kind of hardware access. Granted, there are native drivers (some of them appeared because of coreboot), but I think you usually won't find them in the boot sector of an installed system.
When it comes to other boot loaders, all bets are off (though I'd wager a bet that except for highly specialized stuff, all of them rely on BIOS, if only, to support booting from various IDE/SCSI/whatever controllers)
Regards, Patrick Georgi
On 12.09.2008 01:31, Peter Stuge wrote:
Joseph Smith wrote:
I really think it is possible to take the data from the mbr/partition table and manipulate it to our advantage, thus bypassing ALL real mode interrupts. The problem would be if an OS (like windows) deciedes to make a INT call....
You are missing the point. [...] I hope you agree with me that one major design goal of a new boot standard will be to eliminate real mode from x86 boot.
Stop wasting time on BIOS things. Do a comparison with all other disk labels that the composite of Linux, BSD and Windows NT supports.
Let me quote Jordan Crouse with a statement that fits perfectly into this discussion:
There is no one true load method. If [...] is willing to do the work, then it is something that should be considered. It makes nothing obsolete and it makes coreboot more useful. It is hard to object to that.
Regards, Carl-Daniel
Hi,
Stefan Reinauer wrote:
So you're teaching FILO how to act like a BIOS.
I will fight that patch hard. I'm afraid I think this design is completely misguided.
Citing Jordan:
Indeed - lets stop trying to beat up Joseph and let him write some code.
My point which I hope came through in the end was that BIOS behavior is already available with coreboot by way of SeaBIOS, so I don't think it is very good to add it to more places because they will not be as good as SeaBIOS are.
Same reasoning as for consolidating option ROM init to use SeaBIOS rather than a bunch of interrupt services in coreboot code.
If you want BIOS behavior, just use a BIOS.
Oh do we start sending people away with their ideas now?
No, didn't mean to say that. s/a BIOS/SeaBIOS/
Carl-Daniel Hailfinger wrote:
Stop wasting time on BIOS things.
Let me quote Jordan Crouse with a statement that fits perfectly into this discussion:
There is no one true load method. If [...] is willing to do the work, then it is something that should be considered. It makes nothing obsolete and it makes coreboot more useful. It is hard to object to that.
I don't agree that adding BIOS behavior to FILO would make FILO more useful. Quite the opposite.
I think it would be better to keep BIOS behavior in a single place, and have it be really excellent there. I think that place is SeaBIOS.
FILO can instead be a playground for completely new things, better than BIOS, if we can think of any. I know I want to try! :)
Yes, that is much more long term than "boot my box today" (i.e. boot my box like a BIOS) - please use BIOS compatibility (SeaBIOS) for that.
SeaBIOS is not getting enough credit, it is a really awesome project.
//Peter
I just want to make it boot like a bootloader should. A bootloader should be able to boot a drive without specifing PATHS.
Now this is an interesting discussion!
So, Peter do you have any ideas on how we could make this happen?
On Fri, 12 Sep 2008 03:01:31 +0200, Peter Stuge peter@stuge.se wrote:
Joseph Smith wrote:
So, Peter do you have any ideas on how we could make this happen?
Peter Stuge wrote:
Do a comparison with all other disk labels that the composite of Linux, BSD and Windows NT supports.
I'm not sure what you mean by "disk labels"? The only thing I could find is a disklabel for BSD, and I don't see how that would help us?
On Thu, 11 Sep 2008 21:23:06 -0400, Joseph Smith joe@settoplinux.org wrote:
On Fri, 12 Sep 2008 03:01:31 +0200, Peter Stuge peter@stuge.se wrote:
Joseph Smith wrote:
So, Peter do you have any ideas on how we could make this happen?
Peter Stuge wrote:
Do a comparison with all other disk labels that the composite of Linux, BSD and Windows NT supports.
I'm not sure what you mean by "disk labels"? The only thing I could find is a disklabel for BSD, and I don't see how that would help us?
So for Linux do you mean reading /etc/fstab to find the /boot label and going from there???
Joseph Smith wrote:
So for Linux do you mean reading /etc/fstab to find the /boot label and going from there???
No, that is a much later problem.
We are at the stage when all we know are physical hard drives, and we want to look up where an operating system is, and how we start it.
The how may be answered by multiboot.
The where is your mission, should you choose to accept it.
Where in this case means which physical drive, which partition and which file.
Look at the different existing solutions for this problem to see if one of them will work for us, or if they can be improved upon to fit.
//Peter
On Thu, Sep 11, 2008 at 10:31 PM, Peter Stuge peter@stuge.se wrote:
Joseph Smith wrote:
So for Linux do you mean reading /etc/fstab to find the /boot label and going from there???
No, that is a much later problem.
We are at the stage when all we know are physical hard drives, and we want to look up where an operating system is, and how we start it.
The how may be answered by multiboot.
The where is your mission, should you choose to accept it.
Where in this case means which physical drive, which partition and which file.
Look at the different existing solutions for this problem to see if one of them will work for us, or if they can be improved upon to fit.
Alright, this is an entirely honest question, how complex is the mbr? And how standardized is it? What's required to access it? And the big question, would it be possible to create a new mbr that could be easily parsed by FILO, but still compatible with fuctory BIOS, possibly by using a method similar to windows chainloading? Just throwing this out there, no idea if/how it would actually work.
-Corey
On Fri, 12 Sep 2008 00:13:18 -0400, "Corey Osgood" corey.osgood@gmail.com wrote:
On Thu, Sep 11, 2008 at 10:31 PM, Peter Stuge peter@stuge.se wrote:
Joseph Smith wrote:
So for Linux do you mean reading /etc/fstab to find the /boot label and going from there???
No, that is a much later problem.
We are at the stage when all we know are physical hard drives, and we want to look up where an operating system is, and how we start it.
The how may be answered by multiboot.
The where is your mission, should you choose to accept it.
Where in this case means which physical drive, which partition and which file.
Look at the different existing solutions for this problem to see if one of them will work for us, or if they can be improved upon to fit.
Alright, this is an entirely honest question, how complex is the mbr? And how standardized is it? What's required to access it? And the big question, would it be possible to create a new mbr that could be easily parsed by FILO, but still compatible with fuctory BIOS, possibly by using a method similar to windows chainloading? Just throwing this out there, no idea if/how it would actually work.
It is pretty darn simple, it tells a few bits about the drive and where to find the first boot sector of the Active partition. But it is a 16bit binary blob normally executed in real mode. We could create our own FILO MBR, but I don't know if that would be the right solution eithor....
-- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
On Fri, Sep 12, 2008 at 12:19 AM, Joseph Smith joe@settoplinux.org wrote:
On Fri, 12 Sep 2008 00:13:18 -0400, "Corey Osgood" corey.osgood@gmail.com wrote:
On Thu, Sep 11, 2008 at 10:31 PM, Peter Stuge peter@stuge.se wrote:
Joseph Smith wrote:
So for Linux do you mean reading /etc/fstab to find the /boot label and going from there???
No, that is a much later problem.
We are at the stage when all we know are physical hard drives, and we want to look up where an operating system is, and how we start it.
The how may be answered by multiboot.
The where is your mission, should you choose to accept it.
Where in this case means which physical drive, which partition and which file.
Look at the different existing solutions for this problem to see if one of them will work for us, or if they can be improved upon to fit.
Alright, this is an entirely honest question, how complex is the mbr? And how standardized is it? What's required to access it? And the big question, would it be possible to create a new mbr that could be easily parsed by FILO, but still compatible with fuctory BIOS, possibly by using a method similar to windows chainloading? Just throwing this out there, no idea if/how it would actually work.
It is pretty darn simple, it tells a few bits about the drive and where to find the first boot sector of the Active partition. But it is a 16bit binary blob normally executed in real mode. We could create our own FILO MBR, but I don't know if that would be the right solution eithor....
Why not? If legacy free is the way we're gonna go, why not get rid of the legacy MBR while we're at it?
-Corey
On Fri, 12 Sep 2008 00:24:32 -0400, "Corey Osgood" corey.osgood@gmail.com wrote:
On Fri, Sep 12, 2008 at 12:19 AM, Joseph Smith joe@settoplinux.org
wrote:
On Fri, 12 Sep 2008 00:13:18 -0400, "Corey Osgood"
wrote:
On Thu, Sep 11, 2008 at 10:31 PM, Peter Stuge peter@stuge.se wrote:
Joseph Smith wrote:
So for Linux do you mean reading /etc/fstab to find the /boot label and going from there???
No, that is a much later problem.
We are at the stage when all we know are physical hard drives, and we want to look up where an operating system is, and how we start it.
The how may be answered by multiboot.
The where is your mission, should you choose to accept it.
Where in this case means which physical drive, which partition and which file.
Look at the different existing solutions for this problem to see if one of them will work for us, or if they can be improved upon to fit.
Alright, this is an entirely honest question, how complex is the mbr? And how standardized is it? What's required to access it? And the big question, would it be possible to create a new mbr that could be easily parsed by FILO, but still compatible with fuctory BIOS, possibly by using a method similar to windows chainloading? Just throwing this out there, no idea if/how it would actually work.
It is pretty darn simple, it tells a few bits about the drive and where
to
find the first boot sector of the Active partition. But it is a 16bit binary blob normally executed in real mode. We could create our own FILO MBR, but I don't know if that would be the right solution eithor....
Why not? If legacy free is the way we're gonna go, why not get rid of the legacy MBR while we're at it?
Hmm. You got me thinking, the gears are turning. We would have to deal with a binary blob though instead a simple text file. pros vs cons?
On Fri, 12 Sep 2008, Joseph Smith wrote:
On Fri, 12 Sep 2008 00:24:32 -0400, "Corey Osgood" corey.osgood@gmail.com wrote:
On Fri, Sep 12, 2008 at 12:19 AM, Joseph Smith joe@settoplinux.org
wrote:
On Fri, 12 Sep 2008 00:13:18 -0400, "Corey Osgood"
wrote:
On Thu, Sep 11, 2008 at 10:31 PM, Peter Stuge peter@stuge.se wrote:
Joseph Smith wrote:
So for Linux do you mean reading /etc/fstab to find the /boot label and going from there???
No, that is a much later problem.
We are at the stage when all we know are physical hard drives, and we want to look up where an operating system is, and how we start it.
The how may be answered by multiboot.
The where is your mission, should you choose to accept it.
Where in this case means which physical drive, which partition and which file.
Look at the different existing solutions for this problem to see if one of them will work for us, or if they can be improved upon to fit.
Alright, this is an entirely honest question, how complex is the mbr? And how standardized is it? What's required to access it? And the big question, would it be possible to create a new mbr that could be easily parsed by FILO, but still compatible with fuctory BIOS, possibly by using a method similar to windows chainloading? Just throwing this out there, no idea if/how it would actually work.
It is pretty darn simple, it tells a few bits about the drive and where
to
find the first boot sector of the Active partition. But it is a 16bit binary blob normally executed in real mode. We could create our own FILO MBR, but I don't know if that would be the right solution eithor....
Why not? If legacy free is the way we're gonna go, why not get rid of the legacy MBR while we're at it?
Hmm. You got me thinking, the gears are turning. We would have to deal with a binary blob though instead a simple text file. pros vs cons?
A while back Seagate announced they are stopping production of the ATA hard drive. In a few short years the MBR will have gone the way of the 5.25 inch floppy. Even now there are some live-cd distros that don't need a hard drive.
Russ
On Fri, Sep 12, 2008 at 1:20 AM, Russell Whitaker russ@ashlandhome.net wrote:
On Fri, 12 Sep 2008, Joseph Smith wrote:
On Fri, 12 Sep 2008 00:24:32 -0400, "Corey Osgood" corey.osgood@gmail.com wrote:
On Fri, Sep 12, 2008 at 12:19 AM, Joseph Smith joe@settoplinux.org
wrote:
On Fri, 12 Sep 2008 00:13:18 -0400, "Corey Osgood"
wrote:
On Thu, Sep 11, 2008 at 10:31 PM, Peter Stuge peter@stuge.se wrote:
Joseph Smith wrote: > > So for Linux do you mean reading /etc/fstab to find the /boot label > and going from there???
No, that is a much later problem.
We are at the stage when all we know are physical hard drives, and we want to look up where an operating system is, and how we start it.
The how may be answered by multiboot.
The where is your mission, should you choose to accept it.
Where in this case means which physical drive, which partition and which file.
Look at the different existing solutions for this problem to see if one of them will work for us, or if they can be improved upon to fit.
Alright, this is an entirely honest question, how complex is the mbr? And how standardized is it? What's required to access it? And the big question, would it be possible to create a new mbr that could be easily parsed by FILO, but still compatible with fuctory BIOS, possibly by using a method similar to windows chainloading? Just throwing this out there, no idea if/how it would actually work.
It is pretty darn simple, it tells a few bits about the drive and where
to
find the first boot sector of the Active partition. But it is a 16bit binary blob normally executed in real mode. We could create our own FILO MBR, but I don't know if that would be the right solution eithor....
Why not? If legacy free is the way we're gonna go, why not get rid of the legacy MBR while we're at it?
Hmm. You got me thinking, the gears are turning. We would have to deal with a binary blob though instead a simple text file. pros vs cons?
A while back Seagate announced they are stopping production of the ATA hard drive. In a few short years the MBR will have gone the way of the 5.25 inch floppy. Even now there are some live-cd distros that don't need a hard drive.
I call bullshit. I found one news article on it, not linked to a press release or any substantiating evidence. Can't find a PR on Seagate's website or anywhere else. And I can't honestly imagine that there's so much of a difference between PATA and SATA hard drives that no longer manufacturing PATA drives would have any considerable impact on their bottom line. 5 1/4" drives were around when only geeks and secretaries had PCs, that's just not the case today. If you know where there's an official announcement, please, send me the link.
-Corey
Joseph Smith wrote:
On Fri, 12 Sep 2008 03:01:31 +0200, Peter Stuge peter@stuge.se wrote:
Joseph Smith wrote:
So, Peter do you have any ideas on how we could make this happen?
Peter Stuge wrote:
Do a comparison with all other disk labels that the composite of Linux, BSD and Windows NT supports.
I'm not sure what you mean by "disk labels"? The only thing I could find is a disklabel for BSD, and I don't see how that would help us?
It's just another name for "partition table" being more generic because partition tables often safe more information that just the partitions (see the MBR)
Peter Stuge wrote:
As for a new standard I think we should start out by evaluating all current disklabel schemes to see what state of the art is, and how we can improve upon it.
I still like Amiga's Rigid Disk Label best. It stores the firmware's filesystem driver for each file in the "partition table" to a partition so the firmware can always read a disk, no matter how new and weird the filesystem is. It also has no limitation on partitions.
Stefan Reinauer wrote:
evaluating all current disklabel schemes
I still like Amiga's Rigid Disk Label best. It stores the firmware's filesystem driver for each file in the "partition table" to a partition so the firmware can always read a disk, no matter how new and weird the filesystem is. It also has no limitation on partitions.
Now we're talking.
Do you know if there is some documentation for it still, or at least some code?
Do we want to consider different architectures at this point already?
//Peter
Peter Stuge schrieb:
Stefan Reinauer wrote:
evaluating all current disklabel schemes
I still like Amiga's Rigid Disk Label best. It stores the firmware's filesystem driver for each file in the "partition table" to a partition so the firmware can always read a disk, no matter how new and weird the filesystem is. It also has no limitation on partitions.
Now we're talking.
Do you know if there is some documentation for it still, or at least some code?
Do we want to consider different architectures at this point already?
If so: bytecode. seriously.
Patrick Georgi
Peter Stuge wrote:
Stefan Reinauer wrote:
evaluating all current disklabel schemes
I still like Amiga's Rigid Disk Label best. It stores the firmware's filesystem driver for each file in the "partition table" to a partition so the firmware can always read a disk, no matter how new and weird the filesystem is. It also has no limitation on partitions.
Now we're talking.
'bout what?
Do you know if there is some documentation for it still, or at least some code?
http://en.wikipedia.org/wiki/Amiga_Rigid_Disk_Block http://www.freiburg.linux.de/~stepan/bin/amiga-fdisk-0.04.tar.gz
Do we want to consider different architectures at this point already?
Don't we always?
Peter Stuge wrote:
So you're teaching FILO how to act like a BIOS.
I will fight that patch hard. I'm afraid I think this design is completely misguided.
Citing Jordan:
Indeed - lets stop trying to beat up Joseph and let him write some code. We do not want to be that project that never matures because we are too busy trying to second guess ourselves and generate "perfect" code out of the chute. Working code beats conjecture any day of the week.
If you want BIOS behavior, just use a BIOS.
Oh do we start sending people away with their ideas now?
On 12/09/08 09:42 +0200, Stefan Reinauer wrote:
Peter Stuge wrote:
So you're teaching FILO how to act like a BIOS.
I will fight that patch hard. I'm afraid I think this design is completely misguided.
Citing Jordan:
Indeed - lets stop trying to beat up Joseph and let him write some code. We do not want to be that project that never matures because we are too busy trying to second guess ourselves and generate "perfect" code out of the chute. Working code beats conjecture any day of the week.
I've been quoted out of context here, twice. I think that this was a completely different discussion then the previous one. Joe has unearthed two related but orthogonal areas of concern for the coreboot community. One, is related to emulating legacy systems and executing the MBR, which falls in the SeaBIOS camp. The other is related to drive enumeration, which is an ongoing problem that we need to face. Joe set out to address the latter problem by unintentionally trying to solve the former problem.
I think that eventually we figured things out and got on the right path - I think that this speaks to a need for improving our communication on both sides. Joe should have been more forthcoming with his plans, and we shouldn't have been so quick to judge, rather we should have educated more. And I apologize for my actions in this matter.
Jordan
On Fri, 12 Sep 2008 10:26:11 -0600, Jordan Crouse jordan.crouse@amd.com wrote:
On 12/09/08 09:42 +0200, Stefan Reinauer wrote:
Peter Stuge wrote:
So you're teaching FILO how to act like a BIOS.
I will fight that patch hard. I'm afraid I think this design is completely misguided.
Citing Jordan:
Indeed - lets stop trying to beat up Joseph and let him write some code. We do not want to be that project that never matures because we are too busy trying to second guess ourselves and generate "perfect" code out of the chute. Working code beats conjecture any day of the week.
I've been quoted out of context here, twice. I think that this was a completely different discussion then the previous one. Joe has unearthed two related but orthogonal areas of concern for the coreboot community. One, is related to emulating legacy systems and executing the MBR, which falls in the SeaBIOS camp. The other is related to drive enumeration, which is an ongoing problem that we need to face. Joe set out to address the latter problem by unintentionally trying to solve the former problem.
I think that eventually we figured things out and got on the right path - I think that this speaks to a need for improving our communication on both sides. Joe should have been more forthcoming with his plans, and we shouldn't have been so quick to judge, rather we should have educated more. And I apologize for my actions in this matter.
No worries Jordan. That's what discussions are all about. I started this discussion thinking one thing and came out with a whole differnt vision. But I think it will end up working out for the better in the end.
P.S. Peter can be a little abrasive when you mention the words "real mode interrupt" or "BIOS" (no offence Peter), I should have expected that, and I did not take it personal.
On 11/09/08 18:05 -0400, Joseph Smith wrote:
On Thu, 11 Sep 2008 16:03:04 -0600, Jordan Crouse jordan.crouse@amd.com wrote:
On 11/09/08 17:49 -0400, Joseph Smith wrote:
OK, My JMP question is about copying a drives mbr to memory 0x7c00 and or 0x0600 at 512 byte blocks. Which is doable. I haven't decided wetheir to try Ron's
suggestion
and try to execute the mbr (hence the JMP question) OR we could even
write
code to translate the mbr and JMP/execute directly to the active
bootable
partition OR even better we could write code translate the mbr, goto the active bootable partition and translate it, and JMP/execute right to the boot manager, thus bypassing a whole bunch of real mode interrupts. What
do
you think?
You won't be successful. Any executable code in any MBR is going to use real mode software interrupts. You can't get around that, you shouldn't try. We have very intellegent payloads that can boot any operating
system
imaginable. Use that.
Ah, Jordan you speak to soon. I have learn a way to setup a simple real mode interrupt handler, capable of sending generic/dummy responses back to the software....
Well, if you do that well enough to boot an arbitrary bootloader (say, syslinux), then you have ended up implementing SeaBIOS all over again. If you are going to implement real-mode calls, then please, lets consolidate our energies into a single project.
Jordan
-
Carl-Daniel Hailfinger -
Corey Osgood -
Jordan Crouse -
Joseph Smith -
Patrick Georgi -
Peter Stuge -
ron minnich -
Russell Whitaker -
Stefan Reinauer