Make an expansion board with a serial port(s) for WL-500b/g

Printable View

Show 40 post(s) from this thread on one page

21-11-2005, 07:26
wtzm

Quote:

Originally Posted by Technik

Sorry for the late response... :rolleyes:

Appreciated nevertheless. :)
I suppose the kernel finds and initializes the serial ports in sbmips.c, funktion sb_serial_init, is this right? The wl500g has a "extif core" (don't know what this is all about, but as the signals are named EIF_OE, EIF_WE, et cetera, I assume this is EXTIF related), so add(regs, irq, 13500000, 0) is called. The third variable is called baud_base. Hm... 13,5MHz? Was the 12,75MHz XTAL just close enough to this value to make it work, or are the 12,75MHz defined somewhere else?
By the way - I would find further information about the inner workings of the bcm47xx series really usefully, especially I don't really understand what these "cores" are and what "core switching" is about. I allready did a fair bit of reading the kernel sources but if there is some kind of tutorial available for this platform (without signing any kind of NDA...), this would really help me.
21-11-2005, 09:47
Oleg

Quote:

Originally Posted by wtzm

By the way - I would find further information about the inner workings of the bcm47xx series really usefully, especially I don't really understand what these "cores" are and what "core switching" is about. I allready did a fair bit of reading the kernel sources but if there is some kind of tutorial available for this platform (without signing any kind of NDA...), this would really help me.

This is a concept of silicon backplane bus, which should be covered for the SiByte sb1250 cpu. Try this link http://www.broadcom.com/products/Ent...ons-Processors
21-11-2005, 20:45
wtzm

Thanks for the link Oleg; I have taken a look at the BCM1125H/BCM1250 User Manual; It is quit a nice read and although I'm not sure how much of this applies to my wl500g, Chapter 11 - "Generic/Boot bus" was very interesting and helped me in understanding the bus which the external uart(s) and parport is connected to.
21-11-2005, 21:25
Oleg

Well, it has nothing is common with wl500g, except silicon bus backplane (chip internal bus) concept. ;)
21-11-2005, 23:01
wtzm

Ah, ok, this pretty much confirms my "guesstimation". :D
27-11-2005, 13:39
wtzm

1 Attachment(s)

Another question concerning the extif: I have read sbextif.h and sbmips.c, where the timing/delay parameters are initialized:

Code:

/* Set programmable interface timing for external uart */ tmp = CEIL(10, ns) << FW_W3_SHIFT; /* W3 = 10nS */ tmp = tmp | (CEIL(20, ns) << FW_W2_SHIFT); /* W2 = 20nS */ tmp = tmp | (CEIL(100, ns) << FW_W1_SHIFT); /* W1 = 100nS */ tmp = tmp | CEIL(120, ns); /* W0 = 120nS */ W_REG(&eir->prog_waitcount, tmp); /* 0x01020a0c for a 100Mhz clock */

Does anyone (Oleg? ;)) know which timing parameters W0 to W3 are? This seems to be quite different from the BCM1250 (there are far more parameters described in the BCM1250 manual).
The reason I'm asking this is that I want to add not only the (D)UART but maybe also other devices (i2c using a pcf8584 would be nice, some additional GPIO ports using 74ls273, etc...). To do this it is necessary to implement a simple address decoding circuit; the current one is quit inefficient - the lpt port is selected every time A4 is asserted, so it's not only available at 0xbf800010 but at 0xbf800018 as well because A3 is not checked. So if this is properly done the address range from 0xbf800018 to 0xbf80001f would be available for other purposes. The same is true for the range from 0xbf800400 to 0xbf80040f (if the chip select for the UART is only generated when A10 is low) and 0xbf800418 to 0xbf80041f. I have listed only these ranges because A10 and A4 to A0 are all easily accessible from pcb pads or pins and this method would give us 8+16+8=32 memory locations which should be enough for most applications.
I have attached a image, just in case my english wasn't intelligible. ;)
BTW: Technik, have you any opinion whether it really is a 12,75MHz XTAL or rather 13,5MHz? (See post #41)
27-11-2005, 18:10
Technik

Quote:

Originally Posted by wtzm

...
BTW: Technik, have you any opinion whether it really is a 12,75MHz XTAL or rather 13,5MHz? (See post #41)

Try 13,0MHz XTAL then...:) In fact I am using 12,288 MHz and it works fine as well. Please note 5% difference is perfectly OK in any case.
11-12-2005, 17:58
wtzm

I've built the UART board, using a new PC16550DV (accidentely ordered it - I actually wanted a PC16552DV), 13,56MHz Crytal.
I haven't implemented my plans for this address decoding circuit yet, so simply connected /CS2 = /EIF_CS and CS0 = CS1 = Vcc (with CS0 = A3 PMON wouldn't print any startup message - apparently it only uses the UART at 0xbf800000) therefore the kernel recognizes one UART at 0xbf800000 and a second one at 0xbf800008. PMON access is working, but shell access via the serial console is somehow messed up - if I transmit certain characters (eg. 'o' '~' or 'ö') the shell acts as if I have pressed this character or <LF> a few times... :confused:
As the whole circuit isn't really shielded and the TX and RX wires are at the moment just loosely connected to my serial port, I first blamed these events on EM-interference or cosmic rays :D, but when I transmitted the same characters while using pmon, they just appeared/worked as they should.
I'm using minicom; 115200 bps, 8n1, no flow-control (and this should be the right settings...).
Any ideas why this is happening?

@Technik: In post #21 you wrote about similar problems, did you solve them?
13-12-2005, 12:04
Artie

Quote:

Originally Posted by wtzm

I've built the UART board, using a new PC16550DV (accidentely ordered it - I actually wanted a PC16552DV), 13,56MHz Crytal.
I haven't implemented my plans for this address decoding circuit yet, so simply connected /CS2 = /EIF_CS and CS0 = CS1 = Vcc (with CS0 = A3 PMON wouldn't print any startup message - apparently it only uses the UART at 0xbf800000) therefore the kernel recognizes one UART at 0xbf800000 and a second one at 0xbf800008. PMON access is working, but shell access via the serial console is somehow messed up - if I transmit certain characters (eg. 'o' '~' or 'ö') the shell acts as if I have pressed this character or <LF> a few times...

UART here programmed by PMON to work with oscillator 7 times faster than in PC, so ideal crystal must be 115200x16x7 = 12.9024MHz, but +/-5% also would be Ok.
13.56MHz gives you baudrate 121071 (instead of 115200), which exceed 5% margins and it's a cause of this seldom errors...

So just change your crystal to 13MHz... :)
13-12-2005, 12:42
wtzm

Thanks the answer. :)
Hm... will try this; I also have a 12,75MHz ready. But I still don't understand why this error _never_ appears in PMON, but can be reproduced reliably after startup, when using the shell...
13-12-2005, 13:09
Artie

Quote:

Originally Posted by wtzm

But I still don't understand why this error _never_ appears in PMON, but can be reproduced reliably after startup, when using the shell...

As far as I understand you, your comp always receive bytes from WL without errors ('cause PMON only send data, don't receive it), but WL sometimes "misunderstand" bytes from comp (when you try to work with shell) ?
If so, maybe it depends on schematic of UART chip in your comp (how much times and at which phase it samples each received bit; - there was many different chips, and some of them doesn't perform proper majoritation on tree samples per bit).

In any case, 13.56MHz - is not a right frequency. ;)
13-12-2005, 14:03
wtzm

Quote:

Originally Posted by Artie

As far as I understand you, your comp always receive bytes from WL without errors ('cause PMON only send data, don't receive it), but WL sometimes "misunderstand" bytes from comp (when you try to work with shell) ?

Not completely correct. I have communicated with PMON (if you cancel the boot with Ctrl+C) succesfully und this works - I can issue commands, etc.
With PMON if I send an 'o' it receives (and echoes back) an 'o'. This doesn't work on the console (after bootup). Sometimes it echoes a few 'o', or it acts as if I had transmitted a line-feed.
In the meantime I have conducted tests with my 12,75MHz Crytal. The results are the same...
By the way from where do you know that PMON expects a frequency of 7x the standard (1.8432MHz)?
I still have the opinion that 13,5MHz is the value that the linux kernel expects for serial port initialization (-> sbmips.c).
13-12-2005, 18:38
Artie

4 Attachment(s)

Quote:

Originally Posted by wtzm

Not completely correct. I have communicated with PMON (if you cancel the boot with Ctrl+C) succesfully und this works - I can issue commands, etc.
With PMON if I send an 'o' it receives (and echoes back) an 'o'. This doesn't work on the console (after bootup). Sometimes it echoes a few 'o', or it acts as if I had transmitted a line-feed.
In the meantime I have conducted tests with my 12,75MHz Crytal. The results are the same...

Sorry, then I have no ideas. :(

You can try to send some characters with chess-board patterns in upper nibble (for example 0x55 - 'U' or 0xAA - 'ê') and check how they will be echoed back...

Quote:

Originally Posted by wtzm

By the way from where do you know that PMON expects a frequency of 7x the standard (1.8432MHz)?
I still have the opinion that 13,5MHz is the value that the linux kernel expects for serial port initialization (-> sbmips.c).

Frequency from XTAL1 pin in all UART chips (if they are 8250 compatible, of course) divided by 16-bit value of DLL/DLH register pair (and you can see this frequency at BAUDOUT' pin of your UART by scope) then divided by 16; - thus we get needed baudrate.
So, to get 115200 baud with 13.5MHz crystal we must load DLL/DLH with value of 7,32421875... But this registers are integer ;), so we can only load either 7 or 8. - In first case we will have 120536 baud, in second - 105469. Not 115200...

Btw, my port-extender to WL500G works fine with "canonical" 1.843MHz (look at generator on second photo) - it's only needed to set PC terminal to 16457 baud. Some terminal programs doesn't know how to do this, but mine - know. :)
Another way to get 115200 baud with 1.843 quartz - setserial /dev/tts/0 baud_base 115200 divisor 1 spd_cust (but this will work only untill reboot, of course).
13-12-2005, 21:47
Technik

Quote:

Originally Posted by wtzm

@Technik: In post #21 you wrote about similar problems, did you solve them?

No - it seems that Kernel is not able to receive bytes from UART correctly (input - it looks like MSB is corrupted - sometimes - and incorrectly recognized as logical H). Output seems to be OK in any case. In PMON everything works fine in both directions. I did not analyze this problem deeply yet nor tried to change any serial port parameters.

Update: I have just tried Bray's Terminal 1.9b (http://bray.velenje.cx/avr/terminal/) instead of Hyperterminal and set parameters to 115200, 8, space, 1, XON/XOFF. No more corrupted characters...
14-12-2005, 06:54
wtzm

I have already tried enabling software flow-control and the different parity settings, but I've never tried _both_...
I will try this as soon as possible.
14-12-2005, 11:17
Technik

Quote:

Originally Posted by wtzm

I have already tried enabling software flow-control and the different parity settings, but I've never tried _both_...
I will try this as soon as possible.

I have tried the same in Hyperterminal - no luck. I don't say Hyperterminal is bad but... :rolleyes: Strange anyway. Perhaps changing default ttys0 parameters could be the right way.
14-12-2005, 13:21
wtzm

Hm... I was using minicom for my tests, but I don't have time at the moment to test this with parity and sw-flowcontrol.
19-12-2005, 16:49
wtzm

Quote:

Originally Posted by Technik

Update: I have just tried Bray's Terminal 1.9b (http://bray.velenje.cx/avr/terminal/) instead of Hyperterminal and set parameters to 115200, 8, space, 1, XON/XOFF. No more corrupted characters...

Doesn't work for me.
Setting the UART type with

Code:

setserial /dev/tts/0 uart 16550

(it was set to a 16550A - which is AFAIK correct for a PC16550DV) and killing the currently running shell for tts/0, solved my problems, but I really don't understand why...
20-12-2005, 11:58
vlad75

Can I have one of your's trx files? :o
20-12-2005, 13:17
wtzm

Quote:

Originally Posted by vlad75

Can I have one of your's trx files? :o

Ehm... I don't have any firmware with embedded setserial - the setserial program was copied to the router using scp.

Show 40 post(s) from this thread on one page