qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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).

      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).