Re: jkh weird problem (reading pci device memory)

2006-08-12 Thread Niki Denev 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John Baldwin wrote:
 On Saturday 05 August 2006 10:06, Niki Denev wrote:
  for(i=0; i  sizeof(config_table_t); i++) {
  r =  bus_space_read_1(sc-bar.tag, sc-bar.hdl, i);
  *((u_int8_t *)sc-cfg_table + i) =  r;
  }
 
 Note that you can replace this with:
 
   bus_space_read_multi_1(sc-bar.tag, sc-bar.hdl, 0,
   (u_int8_t *)sc-cfg_table, sizeof(config_table_t));
 

I can't understand why the code above gives me different results.
i.e.:

for(i=0; i  sizeof(config_table_t); i++) {
*((u_int8_t *)sc-cfg_table + i) =  bus_read_1(sc-res, i);
}
printf(cfg_table signature : %08X\n, sc-cfg_table.signature);

This prints : cfg_table signaature 0xEFEFFEFE, which is the correct signature
that should be read from the card.

But this code :

bus_read_multi_1(sc-res, 0, (u_int8_t *)sc-cfg_table, 
sizeof(config_table_t));
printf(cfg_table signature : %08X\n, sc-cfg_table.signature);

prints : cfg_table signature 0xFEFEFEFE
which is not correct...

Shouldn't the above examples do exactly the same thing?


- --niki
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE3ZR2HNAJ/fLbfrkRAlVBAJ42fHV0cQ4uw5SIdUl7TQHaKkBSKQCZAcd6
eCFWNusXoCuqm88OObX+AFw=
=J0mZ
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: jkh weird problem (reading pci device memory)

2006-08-12 Thread John-Mark Gurney 
Niki Denev wrote this message on Sat, Aug 12, 2006 at 11:42 +0300:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 John Baldwin wrote:
  On Saturday 05 August 2006 10:06, Niki Denev wrote:
 for(i=0; i  sizeof(config_table_t); i++) {
 r =  bus_space_read_1(sc-bar.tag, sc-bar.hdl, i);
 *((u_int8_t *)sc-cfg_table + i) =  r;
 }
  
  Note that you can replace this with:
  
  bus_space_read_multi_1(sc-bar.tag, sc-bar.hdl, 0,
  (u_int8_t *)sc-cfg_table, sizeof(config_table_t));
  
 
 I can't understand why the code above gives me different results.
 i.e.:
 
   for(i=0; i  sizeof(config_table_t); i++) {
   *((u_int8_t *)sc-cfg_table + i) =  bus_read_1(sc-res, i);
   }
   printf(cfg_table signature : %08X\n, sc-cfg_table.signature);
 
 This prints : cfg_table signaature 0xEFEFFEFE, which is the correct signature
 that should be read from the card.
 
 But this code :
 
   bus_read_multi_1(sc-res, 0, (u_int8_t *)sc-cfg_table, 
 sizeof(config_table_t));
   printf(cfg_table signature : %08X\n, sc-cfg_table.signature);
 
 prints : cfg_table signature 0xFEFEFEFE
 which is not correct...
 
 Shouldn't the above examples do exactly the same thing?

No, read_multi reads from the same location every time..  This is for
things like a FIFO where the value can change each time, you want
bus_read_region_1...   Read the bus_space(9) man page for more info
about the differences between the two...

http://www.freebsd.org/cgi/man.cgi?query=bus_spaceapropos=0sektion=0manpath=FreeBSD+6.1-RELEASEformat=html

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: jkh weird problem (reading pci device memory) [ Success story ! ]

2006-08-12 Thread Niki Denev 

John-Mark Gurney writes:

No, read_multi reads from the same location every time..  This is for
things like a FIFO where the value can change each time, you want
bus_read_region_1...   Read the bus_space(9) man page for more info
about the differences between the two...

http://www.freebsd.org/cgi/man.cgi?query=bus_spaceapropos=0sektion=0manpath=FreeBSD+6.1-RELEASEformat=html

--
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.


Oh, that's what i was looking for... thanks.

I'm very new to all this, and it seems like i overloaded myself with 
information, and began to lose details. ( next time i'll read more 
carefully, and will not use lame excuses like this :) )


However, the good news is that i made some progress and now i can talk to 
the 3G card! The tty code is still a mess, (well, not only the tty code 
is a mess :) ) and i can't start PPP session yet, but issuing AT commands 
and getting response from the card works!


phobos# uname -a
FreeBSD phobos 7.0-CURRENT FreeBSD 7.0-CURRENT #11: Fri Jun 30 09:11:17 EDT 2006 
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/PHOBOS  i386


- card insert here

nozomi0: Option N.V. GlobeTrotter 3G+ mem 0xc0212000-0xc02127ff 
irq 11 at device 0.0 on cardbus0

nozomi0: card has 2048 bytes of memory
nozomi0: [GIANT-LOCKED]
nozomi0: Version of card: 3
nozomi0: Initialization OK

phobos# cu -l /dev/ttyN0
Connected
ati
Manufacturer: Option N.V.
Model: GlobeTrotter 3G+
Revision: 3.15.0Hd (Date: Feb 06 2006, Time: 12:53:15)

OK
~
[EOT]



Regards,
Niki Denev


P.S.: For those not reading the whole thread[s], this is my attempt
to port the linux (Nozomi)[1] driver for the latest generation of 3G 
(HSDPA/UMTS/GPRS) PCMCIA cards made by Option (also branded as Vodafone 
Mobile Connect) to FreeBSD.


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: jkh weird problem (reading pci device memory)

2006-08-08 Thread John Baldwin 
On Monday 07 August 2006 18:05, John-Mark Gurney wrote:
 John Baldwin wrote this message on Mon, Aug 07, 2006 at 15:27 -0400:
  sc-cfg_table.signature = letoh32(bus_read_4(sc-bar.res, 0));
  sc-cfg_table.version = letoh16(bus_read_2(sc-bar.res, 4));
  sc-cfg_table.dummy = bus_read_1(sc-bar.res, 5);
 
 Note that this may or may not be correct...  the bus_read_X macros
 do endian conversion if the bus is of different endianness than the
 processor arch...  So if the device is on a PCI bus, and the machine
 is sparc64, the bus_read_X will already be swapped as necessary... If
 you don't want the byte swapping to be done for you, there are the
 _stream versions...  The are useful for transfering data like disk
 data that needs to maintain the same order...

Then why are folks adding these macros to things like mpt?

-- 
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: jkh weird problem (reading pci device memory)

2006-08-08 Thread John-Mark Gurney 
John Baldwin wrote this message on Tue, Aug 08, 2006 at 13:42 -0400:
 On Monday 07 August 2006 18:05, John-Mark Gurney wrote:
  John Baldwin wrote this message on Mon, Aug 07, 2006 at 15:27 -0400:
 sc-cfg_table.signature = letoh32(bus_read_4(sc-bar.res, 0));
 sc-cfg_table.version = letoh16(bus_read_2(sc-bar.res, 4));
 sc-cfg_table.dummy = bus_read_1(sc-bar.res, 5);
  
  Note that this may or may not be correct...  the bus_read_X macros
  do endian conversion if the bus is of different endianness than the
  processor arch...  So if the device is on a PCI bus, and the machine
  is sparc64, the bus_read_X will already be swapped as necessary... If
  you don't want the byte swapping to be done for you, there are the
  _stream versions...  The are useful for transfering data like disk
  data that needs to maintain the same order...
 
 Then why are folks adding these macros to things like mpt?

I haven't seen the patches for mpt, but usually they are only doing
the byte swapping to data structures that are to be dma'd to/from
the card...  As when dma happens, there is no byte swapping done..

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: jkh weird problem (reading pci device memory)

2006-08-07 Thread John Baldwin 
On Saturday 05 August 2006 10:06, Niki Denev wrote:
   for(i=0; i  sizeof(config_table_t); i++) {
   r =  bus_space_read_1(sc-bar.tag, sc-bar.hdl, i);
   *((u_int8_t *)sc-cfg_table + i) =  r;
   }

Note that you can replace this with:

bus_space_read_multi_1(sc-bar.tag, sc-bar.hdl, 0,
(u_int8_t *)sc-cfg_table, sizeof(config_table_t));

However, if you are really reading in a table with more than just chars, you 
might want to read the individual fields and byteswap them as needed (if you 
care about portability to a big-endian arch like sparc).  That is, if your 
device stores the table as little-endian and you had:

typedef struct _config_table {
uint32_t signature;
uint16_t version;
uint8_t dummy;
} config_table_t;

You would do this instead:

sc-cfg_table.signature = letoh32(bus_read_4(sc-bar.res, 0));
sc-cfg_table.version = letoh16(bus_read_2(sc-bar.res, 4));
sc-cfg_table.dummy = bus_read_1(sc-bar.res, 5);

(Note this also uses the shorter bus_read functions which just take a struct 
resouce *.)

I have no idea why the printf's make a difference, unless perhaps your card 
needs a bit of a delay after it is inserted before it's firmware is fully up 
and running.  In that case you might want to insert a delay.  Something like 
this:

/* XXX: Doesn't it want to print rman_get_size() / 1024 instead? */
device_printf(dev, card has %uKB memory\n, sc-card_type);

count = 0;
while (letoh32(bus_read_4(sc-bar.res, 0)) != CONFIG_MAGIC) {
/* If it's not up after a half-second, give up. */
if (count  50) {
device_printf(dev, ConfigTable Bad!\n);
return (ENXIO);
}
count++;

/* Wait 10 ms. */
DELAY(1);
}


-- 
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: jkh weird problem (reading pci device memory)

2006-08-07 Thread Niki Denev 
On Monday 07 August 2006 22:27, John Baldwin wrote:
 On Saturday 05 August 2006 10:06, Niki Denev wrote:
  for(i=0; i  sizeof(config_table_t); i++) {
  r =  bus_space_read_1(sc-bar.tag, sc-bar.hdl, i);
  *((u_int8_t *)sc-cfg_table + i) =  r;
  }

 Note that you can replace this with:

   bus_space_read_multi_1(sc-bar.tag, sc-bar.hdl, 0,
   (u_int8_t *)sc-cfg_table, sizeof(config_table_t));


I tried this, but for some reason it gave me different result than the loop 
i'm using right now.
maybe i'm not doing something right, i'll check again.

 However, if you are really reading in a table with more than just chars,
 you might want to read the individual fields and byteswap them as needed
 (if you care about portability to a big-endian arch like sparc).  That is,
 if your device stores the table as little-endian and you had:

 typedef struct _config_table {
   uint32_t signature;
   uint16_t version;
 uint8_t dummy;
 } config_table_t;

 You would do this instead:

   sc-cfg_table.signature = letoh32(bus_read_4(sc-bar.res, 0));
   sc-cfg_table.version = letoh16(bus_read_2(sc-bar.res, 4));
   sc-cfg_table.dummy = bus_read_1(sc-bar.res, 5);

Yes, i'm aware of this problem, and if everything goes well i will 
try to make it big-endian friendly, but for now it's easier for me to deal 
with less code :)


 (Note this also uses the shorter bus_read functions which just take a
 struct resouce *.)

Cool! this looks much more convenient. Maybe they must be noted in the manual 
page?

 I have no idea why the printf's make a difference, unless perhaps your card
 needs a bit of a delay after it is inserted before it's firmware is fully
 up and running.  In that case you might want to insert a delay.  Something
 like this:

Thanks! The card really needed a delay to setup it's memory right, and i 
was reading it too soon. (which is also a mistake, because in the original 
linux driver the config table read is done later from the interrupt handler,
when the card has had the time to init it's memory properly.)

   /* XXX: Doesn't it want to print rman_get_size() / 1024 instead? */
   device_printf(dev, card has %uKB memory\n, sc-card_type);
the KB suffix here is a typo :-/


   count = 0;
   while (letoh32(bus_read_4(sc-bar.res, 0)) != CONFIG_MAGIC) {
   /* If it's not up after a half-second, give up. */
   if (count  50) {
   device_printf(dev, ConfigTable Bad!\n);
   return (ENXIO);
   }
   count++;

   /* Wait 10 ms. */
   DELAY(1);
   }

Thanks for the useful info!

Best Regards,
Niki Denev
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: jkh weird problem (reading pci device memory)

2006-08-07 Thread John-Mark Gurney 
John Baldwin wrote this message on Mon, Aug 07, 2006 at 15:27 -0400:
   sc-cfg_table.signature = letoh32(bus_read_4(sc-bar.res, 0));
   sc-cfg_table.version = letoh16(bus_read_2(sc-bar.res, 4));
   sc-cfg_table.dummy = bus_read_1(sc-bar.res, 5);

Note that this may or may not be correct...  the bus_read_X macros
do endian conversion if the bus is of different endianness than the
processor arch...  So if the device is on a PCI bus, and the machine
is sparc64, the bus_read_X will already be swapped as necessary... If
you don't want the byte swapping to be done for you, there are the
_stream versions...  The are useful for transfering data like disk
data that needs to maintain the same order...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]