[PATCH 0/2] call32 update
by Kevin O'Connor
Fix call32() so that it doesn't require %ss==0, and enable it to pass
a parameter.
-Kevin
Kevin O'Connor (2):
Don't pass return address to transition(32,16,16big) on stack.
Enhance call32() to pass a parameter to called function.
src/entryfuncs.S | 2 +-
src/resume.c | 2 +-
src/romlayout.S | 14 ++++++++++----
src/stacks.c | 22 +++++++++++-----------
src/util.h | 1 +
5 files changed, 24 insertions(+), 17 deletions(-)
--
1.7.3.2
8 years, 7 months
Re: [SeaBIOS] [RFC] [PATCH 1/2] Implement support for transitioning from 16 bit to 32 bit
by Kevin O'Connor
On Tue, Nov 23, 2010 at 06:31:41AM -0500, Stefan Berger wrote:
> Yes, this block is duplicated, but the code around it is different than
> what exists.
>
> Would you want the same type of transparency in the code, i.e., using the
> function tables and
> the tricks with the #defines? Either way is fine, but it gives me
> direction on how to proceed.
I think you should just use call32() and not do anything special. I
don't see why you need a function table or any defines.
BTW, do you really need to be in 32bit mode, or can this just be done
in 16bit mode?
-Kevin
8 years, 7 months
[RFC][PATCH] 0/2: Call 32 bit functions from 16 bit code with parameters
by Stefan Berger
I am posting the following patches as an RFC. I would want to use them
later on for BIOS extensions where work in 32 bit space seems easier to
handle due to device addresses and ACPI tables that need to be written
into for example being >1M and several function calls invoking functions
in 32 bit space from 16 bit space. Parameters to function can be easily
passed from 16bit. Also, it doesn't add much code, but provides
convenience that others may be able to use as well.
It currently uses the fact that 32 bit code is being relocated into
higher memory.
The intention of the patches is to allow a transition from 16 bit to 32
bit as transparent as possible from the C-programming point of view.
This means that one should be able to call 32 bit code from 16 bit and
be able to pass parameters to the function in 32 bit space and be able
to get the result from that function call. The assumption currently is
that integers are passed.
Existing code in stack.c seems not to support the passing of parameters,
so this would an extension to existing functionality.
All patches should apply cleanly to the tip.
Regards,
Stefan
8 years, 7 months
[RFC][PATCH 2/2] Add another test function and call tests from 16 bit.
by Stefan Berger
The following patch adds another test function, 'hello_world' to the 32
bit functions. The intention is to show what needs to be done to support
one more function call -- not much. This and the already-existing test
function are then called from handle_1a in 16 bit space.
After enabling the debugging output, the following then becomes visible:
handle_1a at 0x00008356
Calling hello world
Hello world at 0x7ffe48f3
test at 0x7ffe4905
a=7,b=8,c=9,d=10,e=11,f=12
Result from upcall res=56
The result 'res' is the result of a*b.
Signed-off-by: Stefan Berger <stefanb(a)us.ibm.com>
---
src/clock.c | 5 +++++
src/upcall.c | 5 +++++
2 files changed, 10 insertions(+)
Index: seabios/src/clock.c
===================================================================
--- seabios.orig/src/clock.c
+++ seabios/src/clock.c
@@ -13,6 +13,7 @@
#include "bregs.h" // struct bregs
#include "biosvar.h" // GET_GLOBAL
#include "usb-hid.h" // usb_check_event
+#include "upcall.h"
// RTC register flags
#define RTC_A_UIP 0x80
@@ -445,6 +446,10 @@ handle_1aXX(struct bregs *regs)
void VISIBLE16
handle_1a(struct bregs *regs)
{
+dprintf(1, "handle_1a at %p\n", handle_1a);
+dprintf(1,"Calling hello world\n");
+hello_world();
+dprintf(1,"Result from upcall res=%d\n", test_highbios(7,8,9,10,11,12));
debug_enter(regs, DEBUG_HDL_1a);
switch (regs->ah) {
case 0x00: handle_1a00(regs); break;
Index: seabios/src/upcall.c
===================================================================
--- seabios.orig/src/upcall.c
+++ seabios/src/upcall.c
@@ -11,6 +11,11 @@ test_highbios(u8 a, u16 b, u32 c, u8 d,
return a*b;
}
+void
+hello_world(void)
+{
+ dprintf(1,"Hello world at %p\n", hello_world);
+}
#define FUNC(IDX, NUMPARMS, RETTYPE, NAME, PARMS ...) \
[IDX] = NAME,
Index: seabios/src/upcall_protos.h
===================================================================
--- seabios.orig/src/upcall_protos.h
+++ seabios/src/upcall_protos.h
@@ -6,7 +6,9 @@
/* all function names below must be expanded with _upcall */
# define test_highbios test_highbios_upcall
+# define hello_world hello_world_upcall
#endif
FUNC(0, 6, int , test_highbios, u8 a, u16 b, u32 c,u8 d, u16 e, int f)
+FUNC(1, 0, void, hello_world , void)
\ No newline at end of file
8 years, 7 months
[RFC][PATCH] 0/2: Call 32 bit functions from 16 bit code and pass parameters
by Stefan Berger
I am posting the following patches as an RFC. I would want to use them
later on for BIOS extensions where work in 32 bit space seems easier to
handle due to device addresses and ACPI tables that need to be written
into for example being >1M and several function calls invoking functions
in 32 bit space from 16 bit space. Parameters to function can be easily
passed from 16bit. Also, it doesn't add much code, but provides
convenience that others may be able to use as well.
It currently uses the fact that 32 bit code is being relocated into
higher memory.
The intention of the patches is to allow a transition from 16 bit to 32
bit as transparent as possible from the C-programming point of view.
This means that one should be able to call 32 bit code from 16 bit and
be able to pass parameters to the function in 32 bit space and be able
to get the result from that function call. The assumption currently is
that integers are passed.
Existing code in stack.c seems not to support the passing of parameters,
so this would an extension to existing functionality.
All patches should apply cleanly to the tip.
Regards,
Stefan
8 years, 7 months
seabios 0.6.1 regression
by Avi Kivity
Installing Windows XP with seabios 0.6.1, immediately after the first
reboot, Windows hangs in protected mode instead of proceeding with
installation.
I'm bisecting this, but if anyone can point to a likely culprit, I can
try it first.
--
error compiling committee.c: too many arguments to function
8 years, 7 months
[PATCH v3 0/2] pciinit: fix overflow when bar allocation
by Isaku Yamahata
Changes v2 -> v3:
- use [first, last] instead of [start, end)
Changes v1 -> v2:
- add comment.
Patch description:
This patch set fixes PCI bar allocation when bar overflow occured.
I checked if pmm_alloc facility can be used, but it doesn't suit for
pci bar allocation. So I resulted in new API, pci_region which
encapsulates region allocation and overflow checks.
The first patch introduces pci_region, and the second patch fixes
the overflow case with pci_region.
Isaku Yamahata (2):
pci: introduce pci_region to manage pci io/memory/prefmemory regions.
pciinit: use pci_region functions.
Makefile | 3 +-
src/pci_region.c | 77 ++++++++++++++++++++++++++++++++++
src/pciinit.c | 122 ++++++++++++++++++++++++++---------------------------
src/util.h | 29 +++++++++++++
4 files changed, 168 insertions(+), 63 deletions(-)
create mode 100644 src/pci_region.c
8 years, 7 months
[PATCH] fix virtio-blk failure after reboot
by Gleb Natapov
vring_virtqueue should be zeroed otherwise old values will be reused
after reboot.
Signed-off-by: Gleb Natapov <gleb(a)redhat.com>
diff --git a/src/virtio-blk.c b/src/virtio-blk.c
index 34d7863..7a25826 100644
--- a/src/virtio-blk.c
+++ b/src/virtio-blk.c
@@ -109,6 +109,7 @@ init_virtio_blk(u16 bdf)
goto fail;
}
memset(vdrive_g, 0, sizeof(*vdrive_g));
+ memset(vq, 0, sizeof(*vq));
vdrive_g->drive.type = DTYPE_VIRTIO;
vdrive_g->drive.cntl_id = bdf;
vdrive_g->vq = vq;
--
Gleb.
8 years, 7 months
