On Tue, Mar 13, 2012 at 06:44:19PM +0900, Daniel Castro wrote:
> Hello,
>
> Sorry to bring this again, but I am still struggling with 16 bit disk operation.
>
> This time I have a simpler question.
>
> When I do container_of(...) I get pointer to 0xd630.
> The address when I created the drive struct is 0x000fd630.
> What do I need to do to be able to use the return of container_of in 16bit code?
When in "segmented" mode (both 16bit mode and 32bit segmented mode)
the processor does not have a uniform view of memory. This is quite
complex and painful to work with, so basically no modern systems use
it anymore. For compatibility, seabios must still support 16bit mode
though. This means that when it is in segmented mode it has a
different view of memory than the init code (which runs in regular
32bit flat mode).
So, the following code:
u8 myglobal VAR16VISIBLE;
...
dprintf(1, "myglobal addr = %p\n", &myglobal);
Will show two different results - it prints 0xf1234 in 32bit flat mode
(it's a variable in the f-segment). In 16bit mode it shows up as
0x1234 - the build arranges for this in order to keep the address
within a 16bit range. To access the variable in 16bit mode, one must
use GET_GLOBAL(myglobal) - this will arrange for the proper segment
accessor (in this case %cs) to be used in conjunction with the
variable address (eg, 0x1234) to load the proper value.
However, the following code:
int *myptr VAR16VISIBLE;
...
myptr = malloc_fseg(16);
...
dprintf(1, "myptr = %p\n", GET_GLOBAL(myptr));
The dprintf will show 0xf4567 regardless of the mode it is in. That
is because the pointer is loaded up at runtime with a 32 bit flat
address, and the build has no way of "fixing" that up. To access the
content of the pointer, one would use the GET_GLOBALFLAT() macro.
To make things slightly more complex, a *drive_g pointer returned from
block.c:getDrive() makes the conversion from GLOBALFLAT to GLOBAL (via
the GLOBALFLAT2GLOBAL macro. So, if you're working with drive_g
pointers, you should just use GET_GLOBAL. This, BTW, is the reason
for the "_g" and "_gf" sufixes found in places through the code -
they're identifiers for pointers that are global vs globalflat.
Also, be aware that *every* pointer access (that isn't pointing to a
variable on the stack) must be wrapped in a macro. Failure to do this
will result in random data being read. As an example of this, to read
the integer pointed to by the global variable "myptr" above, one would
need to run GET_GLOBALFLAT(*GET_GLOBAL(myptr)) - one macro to extract
the global variable and the other macro to extract the data pointed to
by the global variable.
So, basically, pointers have to be accessed the correct way in order
for the system to work. I know this is complex, but it's just the
reality of programming in segmented mode. This complexity has nothing
to do with container_of - that macro works the same way regardless of
the mode.
-Kevin
On Mon, Mar 12, 2012 at 02:40:14PM +0000, Julian Pidancet wrote:
> On Sat, Mar 10, 2012 at 7:01 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
> > On Wed, Mar 07, 2012 at 02:41:05AM +0000, Julian Pidancet wrote:
> >> Implements VBE function 15h defined in the VBE/DDC standard.
> >> Contains a preliminary implementation for bochsvga which returns
> >> a hardcoded EDID with some generic informations.
> >>
> >> It seems Xorg refuses to use resolutions higher than 1024x768 if
> >> the ROM doesn't return an EDID with timing informations to support
> >> it.
> >>
> >> I think this work can be completed to add support for the Geode vga
> >> ROM, as an I2C interface is probably available to extract the EDID
> >> from a real monitor.
> >
> > I'm okay with the change, but I don't think it should be enabled in
> > the upcoming SeaBIOS v1.7.0 release. Perhaps add a config setting and
> > disable it by default.
> >
> > Also, the comment on patch 2 seems to indicate it is untested. I
> > think it should be tested before committing.
> >
>
> How about including only the first of this 2-patch set. It only adds
> the 15h function stub and is a pretty low-risk change.
What's the gain to having the stub present? It will always just
return an error code, right?
-Kevin
Steve Goodrich wrote:
> the USB/SD adapter would start enumeration, but would fail out
> during TEST_UNIT_READY because the device came back with a STALL
> (this via a LeCroy/CACT USB analyzer). I compared the transactions
> to those done during USB enumeration/configuration in Linux, and I
> noticed that the Direction bit in bmCBWFlags is *cleared* for the
> TEST_UNIT_READY command in Linux, but *set* in coreboot.
>
> In both cases, dCBWDataTransferLength is zero.
>
> The USB MSC spec that I'm using states:
> If [dCBWDataTransferLength] is zero, the device and the host
> shall transfer no data between the CBW and the associated CSW,
> and the device shall ignore the value of the Direction bit in
> bmCBWFlags.
>
> Obviously, this device is not ignoring the Direction flag. So...
> what should it be? I modified Paolo's patch (usb-msc.c,
> usb_cmd_data() function) from 27 Feb 2012 to look like this:
> cbw.dCBWDataTransferLength = bytes;
> if ((cbw.CBWCB[0] == CDB_CMD_WRITE_10) ||
> (cbw.CBWCB[0] == CDB_CMD_TEST_UNIT_READY)) {
> cbw.bmCBWFlags = USB_DIR_OUT;
> } else {
> cbw.bmCBWFlags = USB_DIR_IN;
> }
> cbw.bCBWLUN = 0; // XXX
It would have helped to see a patch rather than only the new code.
> This change allows the device to work, but:
> 1. Is this the right way to do this?
It's not more right or wrong than the other way around.
> 2. Will this break anything else?
I'm sure it will break plenty of other non-compliant USB MSC devices
which also do not ignore the direction bit and require it to be 1.
> 3. Are there other commands that should be set for OUT instead of IN?
Hm, commands? Not sure what you mean here.
The only other thing you could do is to make the code detect the
STALL, clear the stall, and then try with the direction bit inverted.
This will work with devices which are not too broken to support
clearing the stall. This may be a subset or a superset of those with
broken MSC bulk-only implementations. Lots of fun when engineers are
too stupid to follow specifications. :(
The behavior might actually depend on the SD card rather than the
USB-to-SD converter chip. This may or may not be relevant for you
to investigate.
//Peter
I've been working with coreboot and SeaBIOS lately to try to get a platform
working, including having boot capability using an SD-to-USB adapter. I got
stuck on this last part: the USB/SD adapter would start enumeration, but
would fail out during TEST_UNIT_READY because the device came back with a
STALL (this via a LeCroy/CACT USB analyzer). I compared the transactions to
those done during USB enumeration/configuration in Linux, and I noticed that
the Direction bit in bmCBWFlags is *cleared* for the TEST_UNIT_READY command
in Linux, but *set* in coreboot.
In both cases, dCBWDataTransferLength is zero.
The USB MSC spec that I'm using states:
If [dCBWDataTransferLength] is zero, the device and the host
shall transfer no data between the CBW and the associated CSW,
and the device shall ignore the value of the Direction bit in
bmCBWFlags.
Obviously, this device is not ignoring the Direction flag. So... what
should it be? I modified Paolo's patch (usb-msc.c, usb_cmd_data() function)
from 27 Feb 2012 to look like this:
cbw.dCBWDataTransferLength = bytes;
if ((cbw.CBWCB[0] == CDB_CMD_WRITE_10) ||
(cbw.CBWCB[0] == CDB_CMD_TEST_UNIT_READY)) {
cbw.bmCBWFlags = USB_DIR_OUT;
} else {
cbw.bmCBWFlags = USB_DIR_IN;
}
cbw.bCBWLUN = 0; // XXX
This change allows the device to work, but:
1. Is this the right way to do this?
2. Will this break anything else?
3. Are there other commands that should be set for OUT instead of IN?
Thanks!
-- Steve G.
Hello,
Sorry to bring this again, but I am still struggling with 16 bit disk operation.
This time I have a simpler question.
When I do container_of(...) I get pointer to 0xd630.
The address when I created the drive struct is 0x000fd630.
What do I need to do to be able to use the return of container_of in 16bit code?
Thanks in advance and sorry for bothering so much.
Daniel
--
+-=====---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| | | Daniel Castro, |
| | | Consultant/Programmer.|
| | | U Andes |
+-------------------------------------+
Implements VBE function 15h defined in the VBE/DDC standard.
Contains a preliminary implementation for bochsvga which returns
a hardcoded EDID with some generic informations.
It seems Xorg refuses to use resolutions higher than 1024x768 if
the ROM doesn't return an EDID with timing informations to support
it.
I think this work can be completed to add support for the Geode vga
ROM, as an I2C interface is probably available to extract the EDID
from a real monitor.
Julian Pidancet (2):
vgasrc: Add skeleton for VBE function 15h (VBE/DDC Standard)
bochsvga: Implement vbe 15h function
src/vbe.h | 5 +++
vgasrc/bochsvga.c | 88 +++++++++++++++++++++++++++++++++++++++++++++++++++++
vgasrc/bochsvga.h | 2 +
vgasrc/stdvga.c | 11 ++++++
vgasrc/stdvga.h | 2 +
vgasrc/vbe.c | 34 ++++++++++++++++++++
vgasrc/vgahw.h | 12 +++++++
7 files changed, 154 insertions(+), 0 deletions(-)
--
Julian Pidancet
