SeaBIOS October 2011

seabios@seabios.org

33 participants
56 discussions

Little help with 16bit code
by Daniel Castro 23 Oct '11

23 Oct '11

Hello, I am in the process of compiling the 16bit part of the code, I am in need of a little help. In my code I have some macros: RING_GET_REQUEST(bi->private,bi->private->req_prod_pvt); The macro translates to: (&((bi->private)->sring->ring[((bi->private->req_prod_pvt) & (((bi->private)->nr_ents) - 1))].req)) So should I use the macro like this in 16Bit code: struct blkif_request *ring_req = MAKE_FLATPTR(GET_SEG(SS), RING_GET_REQUEST(bi->private,bi->private->req_prod_pvt)); Also, nn the hypercall part the only real problem is the pointers that I use as params in the calls, should I mask it before calling it, for example something like: evtchn_send_t send; send.port = bi->port; hypercall_event_channel_op(EVTCHNOP_send,MAKE_FLATPTR(GET_SEG(SS), &send)); There is no limitation on the code that can run in 16Bit only memory addressing, right? As I undestand it, GET_SEG(SS) makes the pointer from that segment, and the MAKE_FLATPTR makes it behave like segment:offset. Right? So I do not have to worry beyond that point. For now I am doing a copy from my front-ring memory buffer to op->lba buffer, Its far from perfect but I have two advantages, first I do not need to make/revoke permission in for inter-domain comunication, If I were to manipulate it directly on the buffer, I would have to change permision on every operation (fast but hard to manage). The ring gets the permision before, so when the actual movement comes it is already settled up. Second I am not creating any new structures, only pointers to existing structures, which would make my 16Bit code simpler (at least I hope). Thanks for any contributions, I really appreciate the help, the prototype is almost complete... Thanks again, Daniel -- +-=====---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | | | Daniel Castro, | | | | Consultant/Programmer.| | | | U Andes | +-------------------------------------+

1 0

Re: [SeaBIOS] POST Memory Manager emulation in SeaBIOS
by Kevin O'Connor 21 Oct '11

21 Oct '11

On Sat, Oct 15, 2011 at 03:38:27PM +0700, Darmawan Salihun wrote: > On 10/13/11, Kevin O'Connor <kevin(a)koconnor.net> wrote: > > I guess the boot hangs at this point? > > Well, not exactly. It was a break point in IDA Pro that stops the > execution there. > Anyway, the log above was for a gPXE ROM which I don't know exactly. > It seems "bundled" with SeaBIOS or Coreboot. Recent versions of QEmu place gPXE in the virtual NIC's rom. I'm sure there is some command option to disable it (or you could just do "-net none"). > The log for my target option ROM was inadvertently not included. > Here it is: > ------------ [...] > pnp call arg1=50 > -------------- Hrmm - the PNP support in SeaBIOS is really just a stub. The 0x50 function isn't supported (it looks to be an smbios call). -Kevin

2 2

Re: [SeaBIOS] Help with 16bit and 32bitFlat
by Kevin O'Connor 20 Oct '11

20 Oct '11

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

4 6

Re: [SeaBIOS] Help with 16bit and 32bitFlat
by Kevin O'Connor 20 Oct '11

20 Oct '11

On Wed, Oct 19, 2011 at 04:08:06PM +0900, Daniel Castro wrote: > In the makefile I have included in SRC32FLAT xen-blk.c to run my code, > if I put it in SRCBOTH the following error is displayed. > 32bit flat init size: 68896 > Linking out/rom16.o > out/code16.o: In function `xen_blk_op': > make: *** [out/rom16.o] Error 1 Was this just a cut-and-paste error, or is the compiler/linker really coming back with an error and no description? If it's the latter it seems like you have a toolchain problem. You can use "make V=1" to see the full compiler command, but I'd guess trying with a different binutils/compiler may help narrow down the issue. -Kevin

2 1

[PATCH 0/1] ACPI: Call ACPI remove handler when handling ACPI eject
by pingfank＠linux.vnet.ibm.com 20 Oct '11

20 Oct '11

From: Liu Ping Fan <pingfank(a)linux.vnet.ibm.com> When I tried to enable cpu hotplug feature for qemu-kvm, I found that the ACPI device eject event just skipped by kernel. static void acpi_bus_notify(acpi_handle handle, u32 type, void *data) { case ACPI_NOTIFY_EJECT_REQUEST: /* TBD */---> skipped from here } But I notice, in drivers/acpi/dock.c, dock_notify()->handle_eject_request() will handle such event for ACPI _dock device. So what we shall do, changing Qemu's SeaBIOS or changing the kernel? If changing SeaBIOS, will it affect guest MS-Window? Thanks, ping fan

3 4

Re: [SeaBIOS] block device process_op question
by Kevin O'Connor 20 Oct '11

20 Oct '11

On Wed, Oct 19, 2011 at 09:17:29PM +0900, Daniel Castro wrote: > Hello, > > When the process_op is called and passed to the appropriate handling > function, how can I differentiate which drive the operation is > directed to? Inside my function xen_process_op called by process_op > with the drive_op as a parameter I use GET_GLOBAL(drive_s) to get the > block device, how can I be sure I am getting the correct drive, and > not another one? I'm not sure I understand the question. During the init phase, you should create a drive_s struct for every drive and then register that drive. If a user attempts to access a drive, the disk_op_s will be populated with a pointer to the drive_s that you created during the init phase for the particular drive that the user wishes to access. If you're asking how you can distinguish between multiple drives - create a local struct that includes a drive_s struct and use the container_of macros (as the other drivers do). > If my question sounds confusing, maybe I am misunderstanding the use > of the structures... sorry about that... could someone help me with > this little bit. > Who calls process_op? who receives the answer from process_op? A read call will take (roughly) the following path: romlayout.S:entry_13(), disk.c:handle_13(), disk.c:disk_13(), disk.c:disk_1302(), block.c:send_disk_op(), block.c:__send_disk_op(), block.c:process_op(). -Kevin

1 0

Re: [SeaBIOS] Help with 16bit and 32bitFlat
by Peter Stuge 19 Oct '11

19 Oct '11

Daniel Castro wrote: > out/code16.o: In function `process_op': > /home/daniel/workspace/seabios_patch/src/block.c:304: undefined > reference to `process_xen_op' > make: *** [out/rom16.o] Error 1 > > Linking out/rom16.o > out/code16.o: In function `xen_blk_op': > make: *** [out/rom16.o] Error 1 What toolchain are you using? Many distribution toolchains have been broken by the distribution's patches, and can not build SeaBIOS. There's a script in coreboot to build a toolchain. Clone the repo and run make crossgcc. Someone else has to clarify how to work with this toolchain in SeaBIOS. //Peter

2 1

block device process_op question
by Daniel Castro 19 Oct '11

19 Oct '11

Hello, When the process_op is called and passed to the appropriate handling function, how can I differentiate which drive the operation is directed to? Inside my function xen_process_op called by process_op with the drive_op as a parameter I use GET_GLOBAL(drive_s) to get the block device, how can I be sure I am getting the correct drive, and not another one? If my question sounds confusing, maybe I am misunderstanding the use of the structures... sorry about that... could someone help me with this little bit. Who calls process_op? who receives the answer from process_op? Thanks for your time, Daniel -- +-=====---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | | | Daniel Castro, | | | | Consultant/Programmer.| | | | U Andes | +-------------------------------------+

1 0

Help with 16bit and 32bitFlat
by Daniel Castro 19 Oct '11

19 Oct '11

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: 32bit flat init size: 68944 Linking out/rom16.o out/code16.o: In function `process_op': /home/daniel/workspace/seabios_patch/src/block.c:304: undefined reference to `process_xen_op' make: *** [out/rom16.o] Error 1 In the makefile I have included in SRC32FLAT xen-blk.c to run my code, if I put it in SRCBOTH the following error is displayed. 32bit flat init size: 68896 Linking out/rom16.o out/code16.o: In function `xen_blk_op': make: *** [out/rom16.o] Error 1 Any clue on how to solve this? Thanks for the help, Daniel -- +-=====---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | | | Daniel Castro, | | | | Consultant/Programmer.| | | | U Andes | +-------------------------------------+

1 0

[PATCH 0/1] ACPI: Call ACPI remove handler when handling ACPI eject
by pingfank＠linux.vnet.ibm.com 19 Oct '11

19 Oct '11

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS October 2011