Re: [SeaBIOS] Help with 16bit and 32bitFlat
On Wed, Oct 19, 2011 at 04:08:06PM +0900, Daniel Castro wrote:
Hello,
I am trying to add a process_op in block.c for Xen, yet the linker throws an error for out rom16, yet my code will only run in 32Bit FLAT. The specific error is undefined referece to process_xen_op (my function defined elsewhere) Here is the make output:
The disk access code is called from 16bit mode, and thus it needs to be compiled in 16bit mode. The link errors you are seeing are there to force a build error (instead of failing mysterously at run time). What does your driver do that requires 32bit mode? The ahci driver has to access some memory addresses above 1 meg to work properly and so it uses the pci_readl/writel() functions which trampoline to/from 32bit mode to acomplish this. If you need to do something similar, you could use that as a model. -Kevin
On Wed, 2011-10-19 at 20:25 -0400, Kevin O'Connor wrote:
On Wed, Oct 19, 2011 at 04:08:06PM +0900, Daniel Castro wrote:
Hello,
I am trying to add a process_op in block.c for Xen, yet the linker throws an error for out rom16, yet my code will only run in 32Bit FLAT. The specific error is undefined referece to process_xen_op (my function defined elsewhere) Here is the make output:
The disk access code is called from 16bit mode, and thus it needs to be compiled in 16bit mode. The link errors you are seeing are there to force a build error (instead of failing mysterously at run time).
What does your driver do that requires 32bit mode?
I thought that, apart from the entry points and some special cases, SeaBIOS mostly ran in 32-bit mode. Have I just misunderstood?
The ahci driver has to access some memory addresses above 1 meg to work properly and so it uses the pci_readl/writel() functions which trampoline to/from 32bit mode to acomplish this. If you need to do something similar, you could use that as a model.
-Kevin
_______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
-- Ian Campbell Q: Why do the police always travel in threes? A: One to do the reading, one to do the writing, and the other keeps an eye on the two intellectuals.
Hi,
The disk access code is called from 16bit mode, and thus it needs to be compiled in 16bit mode. The link errors you are seeing are there to force a build error (instead of failing mysterously at run time).
What does your driver do that requires 32bit mode?
Access special pages for communication with the hypervisor (grant tables, request ring).
I thought that, apart from the entry points and some special cases, SeaBIOS mostly ran in 32-bit mode. Have I just misunderstood?
Pretty much all initialization code (including drive probing) runs in 32bit mode. Any 16bit interrupt handling runs in 16bit mode.
The ahci driver has to access some memory addresses above 1 meg to work properly and so it uses the pci_readl/writel() functions which trampoline to/from 32bit mode to acomplish this. If you need to do something similar, you could use that as a model.
Another option would be to have the int15 handler trampoline to 32bit mode before calling process_op. cheers, Gerd
On Thu, Oct 20, 2011 at 11:44:50AM +0200, Gerd Hoffmann wrote:
The ahci driver has to access some memory addresses above 1 meg to work properly and so it uses the pci_readl/writel() functions which trampoline to/from 32bit mode to acomplish this. If you need to do something similar, you could use that as a model.
Another option would be to have the int15 handler trampoline to 32bit mode before calling process_op.
I assume you mean int13 (disk access). The trouble with doing this is it would break any code that calls int13 in vm86 mode. Granted, anything using AHCI would already not work in this mode, but it's a leap to restrict this for all disk access. -Kevin
On Thu, Oct 20, 2011 at 11:44:50AM +0200, Gerd Hoffmann wrote:
The disk access code is called from 16bit mode, and thus it needs to be compiled in 16bit mode. The link errors you are seeing are there to force a build error (instead of failing mysterously at run time).
What does your driver do that requires 32bit mode?
Access special pages for communication with the hypervisor (grant tables, request ring).
If Xen just wants to run its handler in 32bit mode (and doesn't care about vm86 mode), it should be possible to do something like: int process_xen_op(struct disk_op_s *op) { extern void _cfunc32flat_process_xen32_op(struct disk_op_s *); return call32(_cfunc32flat_process_xen32_op, op, DISK_RET_EPARAM); } int VISIBLE32FLAT process_xen32_op(struct disk_op_s *op) { if (! CONFIG_XEN_DISK_HANDLER) return 0; ... } Be aware that stack space is still limited here though (~512 bytes). -Kevin
On Thu, Oct 20, 2011 at 9:57 PM, Kevin O'Connor <kevin@koconnor.net> wrote:
On Thu, Oct 20, 2011 at 11:44:50AM +0200, Gerd Hoffmann wrote:
The disk access code is called from 16bit mode, and thus it needs to be compiled in 16bit mode. The link errors you are seeing are there to force a build error (instead of failing mysterously at run time).
What does your driver do that requires 32bit mode?
Access special pages for communication with the hypervisor (grant tables, request ring).
If Xen just wants to run its handler in 32bit mode (and doesn't care about vm86 mode), it should be possible to do something like:
int process_xen_op(struct disk_op_s *op) { extern void _cfunc32flat_process_xen32_op(struct disk_op_s *); return call32(_cfunc32flat_process_xen32_op, op, DISK_RET_EPARAM); }
int VISIBLE32FLAT process_xen32_op(struct disk_op_s *op) { if (! CONFIG_XEN_DISK_HANDLER) return 0; ... }
Be aware that stack space is still limited here though (~512 bytes).
I am really want to use the 16Bit for the proccess_op, then only place I have no idea if it will work (not that I see why not) is doing a hypercall when I have to signal the RING that there is a request in flight.
-Kevin
-- +-=====---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | | | Daniel Castro, | | | | Consultant/Programmer.| | | | U Andes | +-------------------------------------+
On Thu, Oct 20, 2011 at 07:33:42AM +0100, Ian Campbell wrote:
On Wed, 2011-10-19 at 20:25 -0400, Kevin O'Connor wrote:
On Wed, Oct 19, 2011 at 04:08:06PM +0900, Daniel Castro wrote:
Hello,
I am trying to add a process_op in block.c for Xen, yet the linker throws an error for out rom16, yet my code will only run in 32Bit FLAT. The specific error is undefined referece to process_xen_op (my function defined elsewhere) Here is the make output:
The disk access code is called from 16bit mode, and thus it needs to be compiled in 16bit mode. The link errors you are seeing are there to force a build error (instead of failing mysterously at run time).
What does your driver do that requires 32bit mode?
I thought that, apart from the entry points and some special cases, SeaBIOS mostly ran in 32-bit mode. Have I just misunderstood?
All the init and boot code runs in 32bit mode. However, the 16bit handlers still run in 16bit mode. There has been talk of using SMM to trampoline into 32bit mode for more of the handlers. Anything less than SMM can't trampoline 100% reliably (and even SMM may be difficult to get correct). -Kevin
participants (4)
-
Daniel Castro -
Gerd Hoffmann -
Ian Campbell -
Kevin O'Connor