From: "Reimar Döffinger" <Reimar.Doeffinger@gmx.de>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] eepro100c additions/changes required for VxWorks 5.4.2 to work
Date: Sat, 22 Aug 2009 22:09:06 +0200 [thread overview]
Message-ID: <20090822200906.GA3456@1und1.de> (raw)
In-Reply-To: <0A54BACCF270364FBD51EAC504A0F067109713D8@FRMRSSXCHMBSC2.dc-m.alcatel-lucent.com>
I am only looking at this because I hacked this code, not because
I have anything to say on whether it gets in...
On Sat, Aug 22, 2009 at 06:42:55PM +0200, ZAPPACOSTA, Rolando (Rolando) wrote:
> 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).
> 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.
I don't really understand that, the values always already gets stored to and
restored from ->mem...
> @@ -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);
> + }
That part I meant with cosmetics, I think it would simplify things to do it at best in
a different patch. Btw. there is a huge amount of trailing whitespace after that }
> 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);
Lots of trailing whitespace here too. And s->cb_address + 0x10 was already calulated
before and stored in tbd_address.
Also if extended TCB is enabled I think it must be + 0x20. I admit that the Intel
specification says differently but that does not make any sense (I suspect
they just did not consider that case)...
Apart from that I think this is correct, reading the specification.
> @@ -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).
No, it will crash with an assert due to the missing(...), as said I already
sent a patch myself (that sets status to 0).
> 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.
Except for a compiler bug I can't see how it could make a difference...
> 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;
I guess reasonable in principle (though it might be simpler to get rid of the
pointer variable and just read it whenever necessary form s->mem),
except that you need to use le16_to_cpu on val I think.
(val << 16) seems better to me than (val * 0x10000).
prev parent reply other threads:[~2009-08-22 20:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-19 9:38 [Qemu-devel] eepro100c additions/changes required for VxWorks 5.4.2 to work ZAPPACOSTA, Rolando (Rolando)
2009-08-22 15:55 ` Reimar Döffinger
2009-08-22 16:42 ` ZAPPACOSTA, Rolando (Rolando)
2009-08-22 20:09 ` Reimar Döffinger [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090822200906.GA3456@1und1.de \
--to=reimar.doeffinger@gmx.de \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).