[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Qemu-devel] eepro100c additions/changes required for VxWorks 5.4.2
|
From: |
ZAPPACOSTA, Rolando (Rolando) |
|
Subject: |
RE: [Qemu-devel] eepro100c additions/changes required for VxWorks 5.4.2 to work |
|
Date: |
Sat, 22 Aug 2009 18:42:55 +0200 |
Hi Reimar,
yes, you are correct, some of them could be considered cosmetic (I added them
initially for a better tracking of the emulation each time I launched it).
The ones really important are:
1)
@@ -257,6 +266,8 @@
/* Temporary data. */
eepro100_tx_t tx;
uint32_t cb_address;
+ /* used to store the partial values of the pointer before calling
eepro100_write_port */
+ uint16_t port_lo_word;
/* Statistical counters. */
eepro100_stats_t statistics;
===========> REASON: because VxWorks access it as two dwords and the emulation
fails if this is not implemented.
2)
@@ -782,27 +793,26 @@
TRACE(RXTX, logout
("transmit, TBD array address 0x%08x, TCB byte count 0x%04x, TBD count
%u\n",
tbd_array, tcb_bytes, s->tx.tbd_count));
- assert(!(s->tx.command & COMMAND_NC));
- assert(tcb_bytes <= sizeof(buf));
+ if (s->tx.command & COMMAND_NC) {
+ logout("support for NC=1 is not implemented\n");
+ assert (0);
+ }
+ if (tcb_bytes > sizeof(buf)) {
+ logout("illegal value of the TCB byte count! (cannot be greater than
0x%04x)\n", sizeof(buf));
+ assert (0);
+ }
if (!((tcb_bytes > 0) || (tbd_array != 0xffffffff))) {
logout
("illegal values of TBD array address and TCB byte count!\n");
}
- for (size = 0; size < tcb_bytes; ) {
- uint32_t tx_buffer_address = ldl_le_phys(tbd_address);
- uint16_t tx_buffer_size = lduw_le_phys(tbd_address + 4);
- //~ uint16_t tx_buffer_el = lduw_le_phys(tbd_address + 6);
- tbd_address += 8;
- TRACE(RXTX, logout
- ("TBD (simplified mode): buffer address 0x%08x, size 0x%04x\n",
- tx_buffer_address, tx_buffer_size));
- assert(size + tx_buffer_size <= sizeof(buf));
- cpu_physical_memory_read(tx_buffer_address, &buf[size],
- tx_buffer_size);
- size += tx_buffer_size;
+ if (tcb_bytes > 0) {
+ TRACE(RXTX, logout("TCB byte count>0, adding the data after the TCB
to the buffer\n"));
+ cpu_physical_memory_read(s->cb_address + 0x10, &buf[0], tcb_bytes);
+ size = tcb_bytes;
}
if (!(s->tx.command & COMMAND_SF)) {
/* Simplified mode. Was already handled by code above. */
+ TRACE(RXTX, logout("Simplified Mode, no TBDs have to be processed\n"));
if (tbd_array != 0xffffffff) {
UNEXPECTED();
}
===========> REASON: because VxWorks, at least on what I run, doesn't use TBDs
at all, just puts the data to be sent out by the emulation in memory (following
the TCB). In my humble opinion, this wasn't handled properly by the original
code but your comments are, of course, more than welcomed.
3)
@@ -918,6 +931,9 @@
/* Starting with offset 8, the command contains
* 64 dwords microcode which we just ignore here. */
break;
+ case CmdDiagnose:
+ TRACE(OTHER, logout(" Rolando: diagnose\n"));
+ break;
default:
missing("undefined command");
}
===========> REASON: even though diagnose is called by VxWorks, it should work
without this (I realized that later).
4)
@@ -1079,9 +1095,9 @@
return val;
}
-static void eepro100_write_eeprom(eeprom_t * eeprom, uint8_t val)
+static void eepro100_write_eeprom(eeprom_t * eeprom, uint32_t val)
{
- TRACE(OTHER, logout("val=0x%02x\n", val));
+ TRACE(OTHER, logout("val=0x%08x\n", val));
/* mask unwriteable bits */
//~ val = SET_MASKED(val, 0x31, eeprom->value);
===========> REASON: I don't remember exactly what part was requiring this but
my emulation failed without this change. If interested, I could change this
back and tell you what fails.
5)
@@ -1129,7 +1145,7 @@
if (reg < ARRAY_SIZE(mdi_reg_name)) {
p = mdi_reg_name[reg];
} else {
- snprintf(buffer, sizeof(buf), "reg=0x%02x", reg);
+ snprintf(buffer, sizeof(buffer), "reg=0x%02x", reg);
}
return p;
}
===========> REASON: got an overflow each time I tried to trace the run
otherwise.
6)
@@ -1484,6 +1504,23 @@
case SCBeeprom:
eepro100_write_eeprom(s->eeprom, val);
break;
+ case SCBPointer:
+ s->pointer = (s->pointer & 0xffff0000) + val;
+ logout(" Rolando: wrote the General Pointer, it's now 0x%08x\n",
s->pointer);
+ break;
+ case SCBPointer+2:
+ s->pointer = (s->pointer & 0xffff) + ( val * 0x10000 );
+ logout(" Rolando: wrote the General Pointer, it's now 0x%08x\n",
s->pointer);
+ break;
+ case SCBPort:
+ s->port_lo_word = val;
+ logout(" Rolando: stored the low-word of the Port Interface:
0x%04x\n", s->port_lo_word);
+ break;
+ case SCBPort+2:
+ val = s->port_lo_word + val*0x10000;
+ logout(" Rolando: got the hi-word of the Port Interface, calling it.
The command is 0x%08x\n", val);
+ eepro100_write_port(s, val);
+ break;
default:
logout("addr=%s val=0x%04x\n", regname(addr), val);
missing("unknown word write");
===========> REASON: same than for 1 above, VxWorks writes them as two words
instead of as just one single Dword.
HTH and please don't hesitate to give me your feedback.
Rolando.
________________________________________
From: Reimar Döffinger address@hidden
Sent: Saturday, August 22, 2009 17:55
To: ZAPPACOSTA, Rolando (Rolando)
Cc: address@hidden
Subject: Re: [Qemu-devel] eepro100c additions/changes required for VxWorks
5.4.2 to work
On Wed, Aug 19, 2009 at 11:38:21AM +0200, ZAPPACOSTA, Rolando (Rolando) wrote:
> I was able to make VxWorks 5.4.2 load from FTP it's target binary file (I'll
> now try to figure out why I receive some VxWorks errors once it finishes the
> download).
>
> To do so, I had to implement some 8255x features not yet included as well as
> to change some of the already coded ones.
Some of your changes are basically "cosmetic", e.g. replacing a single assert by
if+message+assert(0), could you please point out which parts are really
necessary?
Btw. I already some time ago sent a patch that implements CmdDiagnose (also sets
status to 0), which is also necessary for OpenSolaris (which also needs RX_ABORT
support in addition).
I find it hard to imagine that the reads you implemented are necessary, since
they
would be unaligned which I for some reason believe aren't allowed and/or in
real hardware get split by the PCI implementation or something...