**** BEGIN LOGGING AT Mon May 30 23:59:57 2005
May 31 05:40:45 <ep1220> [g2]: ?
May 31 06:52:24 <[g2]> ep1220, HEY!
May 31 06:55:27 <ep1220> hey
May 31 06:55:38 <ep1220> there is a new problem.
May 31 06:55:53 <ep1220> TRST seems to be actively driven.
May 31 06:56:49 <ep1220> this means R135 likely must be uninstalled
May 31 06:57:16 <ep1220> and a proper driving of this signal during reset must be ensured
May 31 06:58:42 <ep1220> but there are also good news:
May 31 06:58:57 <ep1220> My NSLU2 has a JTAG interface and is still alive :-)
May 31 06:59:21 <ep1220> I got the FTDI in JTAG on channel A and Rs232 on Channel B
May 31 06:59:36 <ep1220> It nicely relays Redboot messages at startup
May 31 08:17:36 <[g2]> ep1220-away, CONGRATS!
May 31 11:02:32 <ka6sox> hiya ep1220
May 31 11:02:40 <ep1220> Hi ka6sox
May 31 11:03:18 <ep1220> did You find time to work on the schematic ?
May 31 11:03:49 <ka6sox> ep1220: yes I did...but I have questions.
May 31 11:04:13 <ep1220> I am all ears
May 31 11:04:22 <[g2]> ep1220, congrats on the FTDI !
May 31 11:04:33 <ep1220> [g2] THX!
May 31 11:04:36 <ka6sox> I was wondering about the /reset pin and how it is implemented.
May 31 11:05:04 <ep1220> It is an o.C or o.D.
May 31 11:05:30 <ka6sox> okay is there a particular pin that it is implemented on?
May 31 11:05:39 <ka6sox> (I don't see anything about it in the docs)
May 31 11:05:52 <ep1220> Yuo mean on the JTAG header ?
May 31 11:06:24 <ep1220> Or maybe You mean /reset on the FTDI 2232 ?
May 31 11:06:39 <ep1220> I was talking about XScale Reset
May 31 11:07:32 <ka6sox> oh..I was refering to the FTDI chip pin
May 31 11:08:18 <ep1220> I C. the FTDI: reset is generated internally.
May 31 11:08:44 <ep1220> So You can just wire the /reset to Vcc.
May 31 11:09:43 <ka6sox> okay the pin out of the FTDI chip to the Xscale is?
May 31 11:10:13 <ep1220> FTDI reset != Xscale Reset.
May 31 11:10:25 <ka6sox> (not assuming that there isn't a specific pin that is used for /reset to the Xscale)
May 31 11:10:48 <ka6sox> in this case I want the pin that goes to the Target.
May 31 11:10:56 <ep1220> My prototype uses GPIOL1. followed by a MOSFET to make it open-drain.
May 31 11:11:10 <ep1220> You will pass it thru the CPLD I asume.
May 31 11:11:28 <ka6sox> yes and then I'll implement OC in the CPLD
May 31 11:12:04 <ep1220> good plan
May 31 11:12:43 <ep1220> Do You still plan to use OC for CPLD->FTDI connection ?
May 31 11:12:52 <ka6sox> okay so GPIOL1(FTDI)->CPLD(in)->CPLD(oc)->Xscale(!reset)
May 31 11:13:21 <ka6sox> OC is only for the Output connections to the Target.
May 31 11:14:15 <ep1220> XSCALE Reset: yes. But make sure it is OC even when the FTDI is not yet initialized.
May 31 11:15:08 <ep1220> Maybe use GLIOL2 as a general JTAG out enable pin (active low, as it has a pullup) 
May 31 11:17:39 <ka6sox> okay and the pullup is internal.
May 31 11:17:52 <ep1220> Yes is internal
May 31 11:18:04 <ep1220> I take this back. GPIOL1 has a pullup as well and You can do the OC non-inverting, right ?
May 31 11:18:20 <ka6sox> the CPLD can do the inversion.
May 31 11:18:36 <ka6sox> to make it right again.
May 31 11:19:26 <ka6sox> I was looking to make this dongle have RS232 available so it has all the connections to do debug work.
May 31 11:19:39 <ep1220> good
May 31 11:19:54 <ep1220> I did this today.
May 31 11:20:31 <ep1220> but requires to have proper USB IDs sent by the chip.
May 31 11:20:49 <ep1220> So You need to add an EEPROM.
May 31 11:21:07 <ka6sox> I planned on that...
May 31 11:22:14 <ep1220> Let us talk about the OC to the JTAG target.
May 31 11:22:32 <ka6sox> k
May 31 11:22:43 <ka6sox> back in 5 minutes.
May 31 11:22:50 <ep1220> till then.
May 31 11:31:27 <ka6sox> back
May 31 11:31:46 <ep1220> Looked at the datasheets. Think You do not need OC.
May 31 11:32:09 <ep1220> FTDI has VCCIO at 3.3V. Input thershold is max. 1.5V
May 31 11:32:28 <ep1220> Xilinx at 2.5V VCCIO has Vout min 1.9V
May 31 11:32:47 <ep1220> so they should talk toeach other
May 31 11:33:06 <ep1220> Xilinx has n.P. with Inout 3.3V
May 31 11:33:16 <ep1220> s/inout/Input/
May 31 11:33:23 <ka6sox> yeah..I'm not worried about the FTDI<->CPLD connection.
May 31 11:33:33 <ka6sox> only the CPLD<->Target connection.
May 31 11:34:46 <ep1220> Don't You use CPLD VCCIo == Target VCC ?
May 31 11:35:31 <ka6sox> no because there is only 1 Vccio connection to the CPLD
May 31 11:36:03 <ka6sox> so I'm going to use the 5v tolerance of the CPLD for receiving from target and OC for talking to Target
May 31 11:36:46 <ep1220> Isnt the CPLD 3.3V outputvoltage 5V TTL compatible ?
May 31 11:37:16 <ep1220> if this is the case then You do not need OC
May 31 11:37:32 <ka6sox> yes but I wanted this device to work on devices with 2.5v I/O as well.
May 31 11:37:51 <ka6sox> so using a OC will allow us to use it for 2.5v-5.0v devices.
May 31 11:38:35 <ep1220> You always want the CPLD VCCIO at 3.3V ?
May 31 11:38:59 <ka6sox> yes
May 31 11:39:13 <ka6sox> so that it properly interfaces to the FS
May 31 11:39:18 <ka6sox> er FTDI chip
May 31 11:40:07 <ep1220> As I said above: The FTDI will not have problems seeing the CPLD 2.5V hi-voltage
May 31 11:40:21 <ep1220> and recognizing it as Hi level.
May 31 11:40:26 <ka6sox> what about 5.0v?
May 31 11:41:00 <ep1220> the FTDI will never see 5V. it is fixed at 3.3.
May 31 11:41:39 <ep1220> With target at 5, CPLD must have VCCIO 3.3
May 31 11:42:01 <ep1220> Again no prob CPLD -> FTDI
May 31 11:42:02 <ka6sox> it makes it simpler (only 1 Voltage regulator) with the CPLD (3.3v Core) if I just make it 3.3v (core and I/O)
May 31 11:42:20 <ep1220> that is right.
May 31 11:42:33 <ep1220> but OC can limit JTAG speed
May 31 11:42:49 <ep1220> when YOu have a target with many devices in the jain.
May 31 11:43:08 <ep1220> TMS and TCK then might have to drive higher capacitive load.
May 31 11:45:04 <ep1220> One possibility: Take the CPLD VCCIO from the target for 2.5V
May 31 11:45:18 <ep1220> and from internal 3.3 for the other 2.
May 31 11:45:31 <ep1220> Would only require a jumper/switch.
May 31 11:45:45 <ka6sox> okay
May 31 11:45:56 <ep1220> And the CPLD can be easily configured to do OC or pull/push.
May 31 11:45:58 <ka6sox> you are right about OC limitig speed.
May 31 11:47:54 <ep1220> I suggest You also add a pull-down (10K) to the JTAG TRSTn.
May 31 11:48:32 <ep1220> This makes sure a target can properly reset even if the JTAG-Probe is not activated.
May 31 11:49:04 <ep1220> XSCALE e.g. needs TRSTn low during reset, else the JTAG controller might not initialize.
May 31 11:49:45 <ka6sox> okay so things that don't use it are not affected
May 31 11:50:33 <ka6sox> do you use Xilinx or Altera?
May 31 11:50:39 <ep1220> yes. Only affects the JTAG controller.
May 31 11:51:22 <ep1220> I used Xilinx and small PLDs (lattice, AMD, ...)
May 31 11:51:33 <ep1220> no experience with ALTERA.
May 31 11:51:43 <ka6sox> okay..me too.
May 31 11:51:50 <ep1220> actually Xilinx is also some time back ...
May 31 11:52:03 <ka6sox> started with PAL's a bunch of years ago.
May 31 11:52:46 <ep1220> When I started Xilinx did not yet exist :-)
May 31 11:57:04 <ep1220> do You have more questions ?
May 31 11:58:05 <ka6sox> no..I'm in Northern California (about 10hrs from home) and will look at the logs when I get home to reference.
May 31 11:58:22 <ka6sox> this has been most helpful.
May 31 11:58:40 <ep1220> I am glad I could help.
May 31 11:59:11 <ep1220> BTW: Who is the Xscale bootloader expert in this channel ?
May 31 11:59:24 <ka6sox> beewoolie
May 31 12:00:02 <ep1220> Is he here often ?
May 31 12:00:11 <ep1220> Did not yet see this nick.
May 31 12:00:48 <ka6sox> yes he has been here often...also [g2] has been doing a lot of work with him.
May 31 12:01:20 <[g2]> beewoolie is quite excited about the possibility of loading the i-cache
May 31 12:01:40 <ep1220> I might have some questions for him.
May 31 12:02:07 <ka6sox> [g2]: that seems to be the best method of programming the bootloaders fast.
May 31 12:02:15 <[g2]> I'm sure we all will have questions :)
May 31 12:02:57 <ep1220> I soon need a small prog to load into the i-cache.
May 31 12:03:18 <ep1220> if I want to look at bootlaoder source:
May 31 12:03:27 <ep1220> would You say redboot is OK ?
May 31 12:03:44 <ka6sox> seems complicated.
May 31 12:04:00 <ep1220> is there are simpler one ?
May 31 12:04:07 <ka6sox> APEX
May 31 12:04:42 <[g2]> http://wiki.buici.com/twiki/bin/view/Main/ApexBootloader#IXP42x_and_the_Linksys_NSLU2_aka
May 31 12:05:10 <ep1220> THX for the link.
May 31 12:05:19 <ka6sox> I need to get on the road...long trip ahead.
May 31 12:05:20 <[g2]> ep1220, please let us know if you are ready, I've built and run APEX on the NSLU2
May 31 12:05:49 <[g2]> I'll be happy get you an image or help you build you own image that should work
May 31 12:05:53 <ep1220> ka6sox: have a good trip.
May 31 12:06:01 <[g2]> safe travels ka6sox 
May 31 12:06:14 <ep1220> [g2]: in first step i want something very simple.
May 31 12:06:32 <ep1220> A prog which just turns on an LED :-)
May 31 12:06:46 <[g2]> OK.
May 31 12:06:58 <ep1220> most likely the Xscale needs some basic initialization.
May 31 12:07:09 <ep1220> that#s why i want to look at bootloader source
May 31 12:07:12 <[g2]> APEX already does the XMAS-tree dance on the LEDs
May 31 12:07:29 <ep1220> How large is it ?
May 31 12:09:46 <[g2]> APEX is only 16K
May 31 12:09:57 <[g2]> we could fit 2 copies in the icache :)
May 31 12:10:26 <ep1220> there are 2 i-caches.
May 31 12:10:51 <ep1220> the mini-i-cache is 2K (on devices with 32K i-cache)
May 31 12:11:00 <ep1220> Jtag can write to both.
May 31 12:11:27 <ep1220> but only the mini-i-cache can not be invalidated by the CPU
May 31 12:11:42 <ep1220> so it is safer, and usually used for debugging.
May 31 12:13:09 <ep1220> If i start with the full thing, i might have a harder time tracing down problems
May 31 12:17:30 <[g2]> ep1220 so you'd like a program for the mini-cache that turns on an LED or toggles an LED ?
May 31 12:17:55 <ep1220> yes.
May 31 12:18:26 <ep1220> Turn on and stay in an endless loop
May 31 12:19:01 <ep1220> best a different LED than used by the original NSLU bootloader.
May 31 12:19:27 <[g2]> ok
May 31 12:22:03 <ep1220> may i interpret this: you volunteer to write one ? :-)
May 31 12:23:35 * [g2] is looking at the code right now
May 31 12:24:09 <[g2]> I'm wondering if we can write out the serial port
May 31 12:25:21 <ep1220> I know too little about the Xscale peripherals ..
May 31 12:25:36 <[g2]> I'll send e-mail to beewoolie
May 31 12:25:56 <[g2]> I'm sure either he or I should be able to get you setup
May 31 12:26:03 <ep1220> THX !
May 31 12:26:07 <[g2]> are you ready now ?
May 31 12:26:46 <ep1220> I ahve no more questions.
May 31 12:27:26 <[g2]> your serial connection is working at 115200 ?
May 31 12:27:35 <ep1220> yes.
May 31 12:27:36 <[g2]> and you are ready to test now
May 31 12:28:05 <ep1220> no. First I have to solve the issue with TRST.
May 31 12:28:28 <[g2]> ok.. so you should be ready to test soon
May 31 12:28:43 <ep1220> next 2 days my time is thight.
May 31 12:29:02 <ep1220> should be ready friday/weekend.
May 31 12:29:30 <[g2]> okay... I send e-mail to beewoolie now and try to make sure we are ready when you are
May 31 12:29:39 <[g2]> possibly with several tests
May 31 12:29:44 <[g2]> like LED first,
May 31 12:29:49 <[g2]> then serial
May 31 12:29:55 <[g2]> then whole thing 
May 31 12:30:11 <[g2]> or maybe serial + memory controller
May 31 12:30:17 <[g2]> and flash
May 31 12:30:26 <[g2]> sound like a good plan ?
May 31 12:30:30 <ep1220> would be great, best in this order.
May 31 12:30:41 <[g2]> Ok...
May 31 12:30:48 <[g2]> I'm off to write some e-mails
May 31 12:30:49 <ep1220> to get me started, just the LED suffices ..
May 31 12:31:14 <[g2]> well the whole bootloader is already done, it's just making stuff in a format you can use
May 31 12:31:40 <ep1220> I need to write the Data to the JTAG.
May 31 12:32:02 <ep1220> So best format would be a c file.
May 31 12:32:24 <ep1220> in there an array  int bootProg[] = { ... }
May 31 12:32:42 <ep1220> but an object or image would do as well.
May 31 12:32:44 <[g2]> ok
May 31 12:32:55 <ep1220> i know how to get the data out there.
May 31 12:33:19 <[g2]> it's trivial to convert the object/data to a c structure
May 31 12:33:53 <ep1220> agree.
May 31 12:34:00 <[g2]> Ok.. I'll be on it
May 31 12:34:31 <ep1220> THX. for sure safes me a lot of time.
May 31 12:34:44 <[g2]> as your work saves us a lot of time
May 31 12:35:01 <[g2]> working together we can really move mountains :)
May 31 12:36:07 <ep1220> yes, we can get things done much faster.
May 31 12:36:17 <ep1220> when working together
May 31 12:41:34 <[g2]> ep1220, isn't the 2K mini-cache a data cache ?
May 31 12:41:53 <ep1220> there is a mini-data-cache.
May 31 12:42:01 <ep1220> but also a mini i-cache.
May 31 12:42:10 <[g2]> ah...
May 31 12:42:16 <ep1220> the mini-i-cache can only be loaded thru JTAG.
May 31 12:42:28 <[g2]> really ?
May 31 12:42:59 <ep1220> yes. that's why it is not mentionend in the more general sections of the manual.
May 31 12:43:17 <ep1220> and only few people now about it.
May 31 12:43:30 <[g2]> it sounds like this is specifically setup for doing what we are doing 
May 31 12:43:43 <ep1220> yes. it is for debugging only.
May 31 12:43:54 <[g2]> or board bring  up :)
May 31 12:44:22 <ep1220> right.
May 31 12:44:27 <[g2]> heh
May 31 12:45:40 <ep1220> Only Intel has this nice feature (AFAIK)
May 31 12:45:55 <ep1220> On ARM and MIPS doing the same thing is a more complicated.
May 31 12:46:16 <[g2]> actually, the Cirrus has a buffer that can be loaded via SERIAL
May 31 12:46:35 <[g2]> but that needs a hw jumper
May 31 12:46:46 <ep1220> I only know about JTAG debugging ;-)
May 31 14:18:29 <Jacmet> the extra blocks could be skipped if we went for a std redboot
May 31 14:18:38 <Jacmet> argh
**** ENDING LOGGING AT Tue May 31 23:59:56 2005