Re: UCLK
Joerg Reisenweber <[EMAIL PROTECTED]> writes: > Am Do 28. August 2008 schrieb Werner Almesberger: > > Joerg Reisenweber wrote: [...] > > Sounds good and safe to me as well. One problem is that UCLK/GPH8 is > > currently used in GTA03, so we'd have to find a way to free this if > > we don't want to regress. > > one more good reason to do it *now*, as we easily can reorder GPIO for GTA03 > in this stage of development. > So I guess I'll set up a ECN for GTA02 *and* GTA03. That'd be great to have UCLK/GPH8 accessible on an external pad for hacking purpose. I have some SDR plan on interfacing an AD9874[1], but since the Samsung SoC has no SPORT, it should fall back to an UART interface plus an external clock, because of high baudrate. Receiving WFM stations should then be possible, as well as higher band shortwave broadcast, 2m amateur band, marine, aviation, etc. [1] http://www.analog.com/en/rfif-components/rxtx-subsystems/AD9874/products/product.html -- Stephane - F8CFE ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: UCLK
Cesar Eduardo Barros wrote: > Not incorrectly, just following table 1-1 (the whole pinout was probably > copied from there or from a nearby table). Ah yes, the inconsistency is Samsung's. Normally, they call it UEXTCLK, except at this one place. > So far, nobody (except perhaps Joerg) seems to have checked the routing > and possible issues with having a 48MHz signal there. Yup, but we can't really help him with the layout ... and all the other aspects look good. - Werner ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: UCLK
Werner Almesberger escreveu: > Joerg Reisenweber wrote: >> I thought about much more basic things like "check if it's the right pin >> name", > > Yup, except that UEXTCLK (GPH8) is incorrectly labeled UCLK in our > schematics. Not incorrectly, just following table 1-1 (the whole pinout was probably copied from there or from a nearby table). >> "check if the whole idea is actually feasible" etc. > > So far, everybody seems to think so. So far, nobody (except perhaps Joerg) seems to have checked the routing and possible issues with having a 48MHz signal there. I also have no idea which kinds, amounts and values of magic capacitors or resistors would be needed to avoid a 100+ thread on the community mailing list about GPS not working, audio noise, or some other strange symptom. He also has to check if it cannot use too much current, cause mysterious sleep issues, or LEDs blinking while people aren't looking. >> Not eager to search the whole manual for "UEXTCLK" > > xpdf Enter Ctrl-F U E X T C L K Enter Enter ... > > I see that Cesar has posted a lot more references. BTW, xpdf also > shows a table of content for the 2442 manual, so you can jump right > to the section you're looking for :-) I use kpdf, which also has both a text search and the table of contents (you can switch between it and the thumbnails). -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED] ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: UCLK
Joerg Reisenweber escreveu: > Am Do 28. August 2008 schrieb Werner Almesberger: >> Joerg Reisenweber wrote: >>> Ah, and btw: does anybody have a decent set of bookmarks/pointers/quotes > to >>> S3C2442 datasheet sections needed to facilitate my duty to validate this > ECN? >> I think we need a more specific question :-) >> >> I.e., it's a connection between pads that are currently unconnected, >> they both can be disabled if it turns our they cannot be used, and >> the only thing between them is another pad that is usually disabled, >> So what additional validation do you need ? >> >> If sending UCLK to from CLKOUT1 to UEXTCLK should end up exciting >> CLKOUT0 and causing some obscure interference, we probably won't >> find out in any theoretical study anyway. > > I thought about much more basic things like "check if it's the right pin > name", "check if logic levels, fan in and fan out match", "check if the whole > idea is actually feasible" etc. > For this I have to scrutinize the corresponding sections in CPU datasheet, so > I understand what I'm asking for and what it should work like, instead of > just forwarding a "bake recipe" from ML. So some pointer would be welcome ;-) > Not eager to search the whole manual for "UEXTCLK" I just replied in another email before seeing this one, but knowing what you want I can make a better reply (for the GTA02, the file I have is um_s3c2442b_rev12.pdf from the Samsung website): - Chapter 1 (overview), the big pinout diagram (1-6), both tables following it (1-15 has the three pins in question at the bottom, at N22, AA13, AE14), the legend for the table (1-21, 1-22), the following table doesn't say much but has the signals again (on the UART and clock sections). - Chapter 7 (clock & power), the diagram (7-3), the PPL values table (7-23) which is where 48MHz comes from (note that 96MHz is also an option, but I think the USB block needs 48MHz; we should check the kernel and u-boot source to see which mode they are using). - Chapter 9 (I/O ports) has the GPH control registers (9-20) which is where the default state for the pins come from, and MISCCR (9-25) which choses which clock will be output. - Chapter 11 (UART) has right on the introduction a mention of UEXTCLK (11-1), the baud rate generator description (11-7), and the UBRDIV divider registers (11-21). - Chapter 25 (electrical data) should also say something about the pins electrical and timing characteristics, but I couldn't find anything more relevant than the generic voltage and current limits. Note also that in some places it calls it UCLK instead of UEXTCLK (in particular in some tables at chapter 1). -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED] ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: UCLK
Joerg Reisenweber wrote: > I thought about much more basic things like "check if it's the right pin > name", Yup, except that UEXTCLK (GPH8) is incorrectly labeled UCLK in our schematics. > "check if logic levels, fan in and fan out match", Pages 1-15 and 1-22 of the 2442 manual. > "check if the whole idea is actually feasible" etc. So far, everybody seems to think so. > Not eager to search the whole manual for "UEXTCLK" xpdf Enter Ctrl-F U E X T C L K Enter Enter ... I see that Cesar has posted a lot more references. BTW, xpdf also shows a table of content for the 2442 manual, so you can jump right to the section you're looking for :-) - Werner ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: UCLK
Joerg Reisenweber escreveu: > Am Do 28. August 2008 schrieb Joerg Reisenweber: >> Am Do 28. August 2008 schrieb Werner Almesberger: >>> Joerg Reisenweber wrote: >>>> Should we try to set up a ECN demanding future (GTA02) devices to have >> this? >>>> Andy? Werner? I consider engineering risk very low, as we always may > fall >>>> back to current scheme. >>> Sounds good and safe to me as well. One problem is that UCLK/GPH8 is >>> currently used in GTA03, so we'd have to find a way to free this if >>> we don't want to regress. >> one more good reason to do it *now*, as we easily can reorder GPIO for GTA03 >> in this stage of development. >> So I guess I'll set up a ECN for GTA02 *and* GTA03. >> Andy, any comments? > > Ah, and btw: does anybody have a decent set of bookmarks/pointers/quotes to > S3C2442 datasheet sections needed to facilitate my duty to validate this ECN? > Much appreciated ;-)! Do not know if this is what you want, but: - CLKOUT is described on chapter 7 (clock & power management), as is the UPLL (together with the the 48MHz frequency). The output selection is at CLKSEL on MISCCR on chapter 9 (I/O ports). - On the input side, the selection is made at the UCON registers, described at chapter 11 (UART). The baud rate formula can also be found there (UBRDIV registers). - The pad function selection is as usual, described on chapter 9 (I/O ports). Both GPH8 and GPH9/10 default at GPHCON to GPIO input, and at GPHDN to pulldown enabled (resulting on two 100K pull downs and two inputs on the trace, which should not cause any problem). - If I'm reading the table on chapter 1 (overview) correctly, on sleep GPH8 would become Hi-Z and GPH9/10 would output a low logic level (again should not cause any problem). The same table coupled with the next one shows the type of both pins. This is all for GTA02. My email backlog is growing again, so I probably missed an email which would tell me which SoC the GTA03 will use. Of course, what matters is what the datasheet won't tell: - Chapter 25 (electrical data) seems to assume both in the diagrams and in the tables that the pin will be driven from HCLK. How will it behave being driven from the USB PLL? - In the same chapter, what are the timing constraints for UEXTCLK? I'd guess it's the same as EXTCLK, but didn't find anything saying that explicitly. Will it be compatible with the output from the USB PLL? -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED] ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: UCLK
Am Do 28. August 2008 schrieb Werner Almesberger: > Joerg Reisenweber wrote: > > Ah, and btw: does anybody have a decent set of bookmarks/pointers/quotes to > > S3C2442 datasheet sections needed to facilitate my duty to validate this ECN? > > I think we need a more specific question :-) > > I.e., it's a connection between pads that are currently unconnected, > they both can be disabled if it turns our they cannot be used, and > the only thing between them is another pad that is usually disabled, > So what additional validation do you need ? > > If sending UCLK to from CLKOUT1 to UEXTCLK should end up exciting > CLKOUT0 and causing some obscure interference, we probably won't > find out in any theoretical study anyway. I thought about much more basic things like "check if it's the right pin name", "check if logic levels, fan in and fan out match", "check if the whole idea is actually feasible" etc. For this I have to scrutinize the corresponding sections in CPU datasheet, so I understand what I'm asking for and what it should work like, instead of just forwarding a "bake recipe" from ML. So some pointer would be welcome ;-) Not eager to search the whole manual for "UEXTCLK" /jOERG signature.asc Description: This is a digitally signed message part. ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: UCLK
Joerg Reisenweber wrote: > Ah, and btw: does anybody have a decent set of bookmarks/pointers/quotes to > S3C2442 datasheet sections needed to facilitate my duty to validate this ECN? I think we need a more specific question :-) I.e., it's a connection between pads that are currently unconnected, they both can be disabled if it turns our they cannot be used, and the only thing between them is another pad that is usually disabled, So what additional validation do you need ? If sending UCLK to from CLKOUT1 to UEXTCLK should end up exciting CLKOUT0 and causing some obscure interference, we probably won't find out in any theoretical study anyway. - Werner ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: UCLK
Am Do 28. August 2008 schrieb Joerg Reisenweber: > Am Do 28. August 2008 schrieb Werner Almesberger: > > Joerg Reisenweber wrote: > > > Should we try to set up a ECN demanding future (GTA02) devices to have > this? > > > Andy? Werner? I consider engineering risk very low, as we always may fall > > > back to current scheme. > > > > Sounds good and safe to me as well. One problem is that UCLK/GPH8 is > > currently used in GTA03, so we'd have to find a way to free this if > > we don't want to regress. > > one more good reason to do it *now*, as we easily can reorder GPIO for GTA03 > in this stage of development. > So I guess I'll set up a ECN for GTA02 *and* GTA03. > Andy, any comments? Ah, and btw: does anybody have a decent set of bookmarks/pointers/quotes to S3C2442 datasheet sections needed to facilitate my duty to validate this ECN? Much appreciated ;-)! /jOERG signature.asc Description: This is a digitally signed message part. ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: UCLK
Am Do 28. August 2008 schrieb Werner Almesberger: > Joerg Reisenweber wrote: > > Should we try to set up a ECN demanding future (GTA02) devices to have this? > > Andy? Werner? I consider engineering risk very low, as we always may fall > > back to current scheme. > > Sounds good and safe to me as well. One problem is that UCLK/GPH8 is > currently used in GTA03, so we'd have to find a way to free this if > we don't want to regress. one more good reason to do it *now*, as we easily can reorder GPIO for GTA03 in this stage of development. So I guess I'll set up a ECN for GTA02 *and* GTA03. Andy, any comments? /jOERG signature.asc Description: This is a digitally signed message part. ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: UCLK
Joerg Reisenweber wrote: > Should we try to set up a ECN demanding future (GTA02) devices to have this? > Andy? Werner? I consider engineering risk very low, as we always may fall > back to current scheme. Sounds good and safe to me as well. One problem is that UCLK/GPH8 is currently used in GTA03, so we'd have to find a way to free this if we don't want to regress. - Werner ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: UCLK
Am Do 28. August 2008 schrieb Cesar Eduardo Barros: > Andy Green escreveu: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Somebody in the thread at some point said: > > | In a message from Ben Dooks on linux-arm-kernel about cpufreq, he said: > > | > > | > > - My patches have code to use hardware flow control to "pause" the > > | > > serial ports during frequency transitions, so as to not confuse the > > | > > GTA01 GSM modem (or Openmoko's gsmd). > > | > > > | > That is useful for designs that forgot to provide a stable UCLK to > > | > provide UART baud clocks... all of the ones that I've had a direct > > | > hand in working on feed back or feed in an external known (and stable) > > | > clock. > > | > > | It might be worth considering this on future designs (looking at the > > | schematics, GTA01 uses the pin for something else, while GTA02 doesn't > > | connect the pin at all). > > > > It's a good point, it would help the UART continuity during clock > > change. But it means adding an oscillator somewhere? There's a PLL > > from the Wolfson we could maybe use. > > A possible trick would be to route the output of the USB PLL to a pin, > and have a trace linking that pin to the UART external clock. The USB > PLL isn't affected when the main PLL changes (or at least shouldn't be). > > For the GTA02, for instance, that would mean a trace between > UEXTCLK/GPH8 and CLKOUT1/GPH10 (which would also allow several other > options besided the USB PLL). Both pins are free on the GTA02, but I > don't know if routing that trace would be easy (especially considering > the trace would be carrying a 48MHz signal). > > For a USB clock of 48MHz, that would give us a UBRDIV of 25 for 115200, > which feeding the formula in the reverse results in a baud rate of > 115385, an error of 0.16% (unless I made a mistake on the calculations). > This is less than the about 1.87% where things start having problems. > > Of course, even with all that it would still be a good idea to "pause" > the flow control during the PLL lock time to avoid a buffer overrun, but > the AFC might be able to do it automatically for us. The problem avoided > by using a stable clock is mainly the frequency changing (or the clock > stopping) in the middle of a byte. Sounds very attractive, and stopping clock in midst of an inbound byte is an absolute NoGo for e.g. GSM-TTY. To avoid this we had to assert flow control to stop, and then delay for the maximum time to take effect of this. This delay slows down clock rate changes considerably. Probably routing of a 48MHz signal from one pin of CPU to another is no issue (if we care for decent shielding of this trace ;-). However we can't do this for devices prior to GTA02A8 (A7 maybe), for obvious reasons. So sw would have to check for hw-revision (once again ;-). Should we try to set up a ECN demanding future (GTA02) devices to have this? Andy? Werner? I consider engineering risk very low, as we always may fall back to current scheme. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: UCLK
Andy Green escreveu: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Somebody in the thread at some point said: > | In a message from Ben Dooks on linux-arm-kernel about cpufreq, he said: > | > | > > - My patches have code to use hardware flow control to "pause" the > | > > serial ports during frequency transitions, so as to not confuse the > | > > GTA01 GSM modem (or Openmoko's gsmd). > | > > | > That is useful for designs that forgot to provide a stable UCLK to > | > provide UART baud clocks... all of the ones that I've had a direct > | > hand in working on feed back or feed in an external known (and stable) > | > clock. > | > | It might be worth considering this on future designs (looking at the > | schematics, GTA01 uses the pin for something else, while GTA02 doesn't > | connect the pin at all). > > It's a good point, it would help the UART continuity during clock > change. But it means adding an oscillator somewhere? There's a PLL > from the Wolfson we could maybe use. A possible trick would be to route the output of the USB PLL to a pin, and have a trace linking that pin to the UART external clock. The USB PLL isn't affected when the main PLL changes (or at least shouldn't be). For the GTA02, for instance, that would mean a trace between UEXTCLK/GPH8 and CLKOUT1/GPH10 (which would also allow several other options besided the USB PLL). Both pins are free on the GTA02, but I don't know if routing that trace would be easy (especially considering the trace would be carrying a 48MHz signal). For a USB clock of 48MHz, that would give us a UBRDIV of 25 for 115200, which feeding the formula in the reverse results in a baud rate of 115385, an error of 0.16% (unless I made a mistake on the calculations). This is less than the about 1.87% where things start having problems. Of course, even with all that it would still be a good idea to "pause" the flow control during the PLL lock time to avoid a buffer overrun, but the AFC might be able to do it automatically for us. The problem avoided by using a stable clock is mainly the frequency changing (or the clock stopping) in the middle of a byte. -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED] ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: UCLK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | In a message from Ben Dooks on linux-arm-kernel about cpufreq, he said: | | > > - My patches have code to use hardware flow control to "pause" the | > > serial ports during frequency transitions, so as to not confuse the | > > GTA01 GSM modem (or Openmoko's gsmd). | > | > That is useful for designs that forgot to provide a stable UCLK to | > provide UART baud clocks... all of the ones that I've had a direct | > hand in working on feed back or feed in an external known (and stable) | > clock. | | It might be worth considering this on future designs (looking at the | schematics, GTA01 uses the pin for something else, while GTA02 doesn't | connect the pin at all). It's a good point, it would help the UART continuity during clock change. But it means adding an oscillator somewhere? There's a PLL from the Wolfson we could maybe use. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAki1cBsACgkQOjLpvpq7dMrLhQCeOz0JgQB6VQtnsMvaBrFvJTeS IbAAnRdHVxKvYsAFuBPnx27vOIjzkKBb =aOYk -END PGP SIGNATURE- ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
UCLK
In a message from Ben Dooks on linux-arm-kernel about cpufreq, he said: > > - My patches have code to use hardware flow control to "pause" the > > serial ports during frequency transitions, so as to not confuse the > > GTA01 GSM modem (or Openmoko's gsmd). > > That is useful for designs that forgot to provide a stable UCLK to > provide UART baud clocks... all of the ones that I've had a direct > hand in working on feed back or feed in an external known (and stable) > clock. It might be worth considering this on future designs (looking at the schematics, GTA01 uses the pin for something else, while GTA02 doesn't connect the pin at all). -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED] ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
