| 00:10:26 | Sammy_ | hello ....!! |
| 08:05:29 | erikm | good mornin |
| 16:47:38 | rmk | there isn't any defined interface at the moment ;( |
| 16:48:01 | rmk | hmm. |
| 16:48:06 | Russ|werk | I know, I would think that they would belong there |
| 16:48:20 | Russ|werk | instead of that sa1100_frontlight diff that nico has |
| 16:48:23 | BZFlag | rmk: your phone shipped usps gem. 3-4 days is the quote they gave me. |
| 16:49:24 | Russ|werk | I don't think the ioctl's should be arm specific though, as a lot of arches use backlit lcd's with a framebuffer driver |
| 16:49:49 | Russ|werk | and added ioctl's is a lot cleaner than adding a new major or minor for the backlight |
| 16:50:48 | Russ|werk | maybe a backlight on/off ioctl, backlight status ioctl (on or off) |
| 16:50:56 | rmk | well, bear in mind that ioctls are currently the most hated thing atm. |
| 16:51:15 | Russ|werk | set intensity ioctl, read intensity ioctl (0 to 0xff) |
| 16:51:20 | rmk | if you're going to add any ioctls, use the _IOC* macros in asm/ioctl.h |
| 16:51:21 | Russ|werk | rmk: wasn't aware of that |
| 16:51:41 | rmk | it came up at the kernel 2.5 conference. |
| 16:51:42 | Russ|werk | rmk: maybe a /proc interface then, which would be seperate from the fb driver |
| 16:51:56 | Russ|werk | or, /proc is getting too crowded as well |
| 16:52:01 | rmk | yep ;( |
| 16:52:16 | rmk | I think you should probably ask the FB people |
| 16:52:31 | Russ|werk | then where should it be added? |
| 16:52:43 | erikm | I wonder what will happen in 2.5: no new ioctls, /proc too crowded... |
| 16:52:52 | Russ|werk | new majors/minors certainly aren't popular |
| 16:52:57 | rmk | see what the FB people say |
| 16:53:21 | Russ|werk | erikm: communicate with the kernel using your mind |
| 16:53:33 | rmk | Russ: applications don't have minds tho |
| 16:53:47 | erikm | boggles |
| 16:53:55 | erikm | +++ blob-graphicsclient/src/start-ld-script Wed Jul 25 15:04:03 2001 |
| 16:53:55 | erikm | @@ -15,7 +15,7 @@ |
| 16:53:55 | erikm | ENTRY(_start) |
| 16:53:55 | erikm | SECTIONS |
| 16:53:56 | erikm | { |
| 16:53:56 | erikm | - . = 0x00000000; |
| 16:53:58 | erikm | + . = 0x08000000; |
| 16:54:17 | erikm | he moved the first stage loader to the second static bank |
| 16:54:36 | erikm | there *must* be something at 0x00000000 or otherwise his board won't boot at all |
| 16:54:51 | Russ|werk | he probably wants to do chain booting |
| 16:55:16 | Russ|werk | like he has a CE loader, and he's putting blob on a flash card or something |
| 16:56:38 | erikm | BZFlag: you have experience with CE loaders. is it possible that it indeed works like that? |
| 16:57:25 | erikm | mails jim gettys for iPaq hardware information so he can use JTAG to reburn the flash if something goes wrong |
| 16:57:37 | erikm | wants to port blob to iPaq (of course :) |
| 16:58:08 | BZFlag | erikm: I do have experience with the ipaq ce loader, it jumps to a fixed offset in flash that is the ce entry point. |
| 16:58:42 | BZFlag | so perhaps you could put blob there. it might even be 0x08000000 ... though I was thinking 0x04000000 |
| 16:59:06 | BZFlag | erikm will need to sign a compaq nda. |
| 16:59:11 | erikm | BZFlag: 0x08000000 is the second static bank (according to the SA1110 memory map) |
| 16:59:29 | erikm | BZFlag: I expect so, yes. but that's no problem for me |
| 16:59:34 | BZFlag | right. I'm just trying to recall the ce jump point. |
| 17:00:02 | BZFlag | I can send you a copy. I got it and decided not to sign it, so I don't have jtag on my ipaqs |
| 17:00:05 | Russ|werk | erikm: speaking of flash relocations |
| 17:00:33 | erikm | BZFlag: I did that earlier just to be able to see iPaq when I visited CRL. lasted only two weeks because after that they released the iPaq |
| 17:00:45 | Russ|werk | erikm: for a "super" shannon, that would support more than 48M of ram, is would likely be neccessary to not use the onboard bank |
| 17:00:47 | BZFlag | doesn't the graphics client have 2 flash banks? |
| 17:01:03 | Russ|werk | erikm: so that usable ram would start at 0xd0000000 |
| 17:01:15 | BZFlag | more that 40M you mean? |
| 17:01:18 | erikm | BZFlag: do you have a grpahicsclient to test blob with? |
| 17:01:21 | BZFlag | yes |
| 17:01:54 | erikm | BZFlag: ok, I'll add the sane parts of the graphicsclient patch |
| 17:01:57 | BZFlag | a couple different boxes, just different sized active screen.s |
| 17:02:02 | Russ|werk | BZFlag: more than 40M, yes |
| 17:02:31 | BZFlag | I also have an HP calypso that I've been meaning to get running with the new code. |
| 17:02:32 | erikm | Russ|werk: shouldn't be a real problem with blob, but more with the kernel |
| 17:03:26 | BZFlag | you want the messy source for that? they merged netboot, messed up automake and autoconf, hacked and slashed, but it does do tftp over CF ne2k cards. |
| 17:03:50 | Russ|werk | erikm: just letting you know, that a different rambase may be a desired feature in the future |
| 17:03:51 | erikm | BZFlag: sounds like a cool holidays project |
| 17:04:08 | BZFlag | holidays? what are those? |
| 17:04:25 | erikm | BZFlag: that's when I don't get paid to hack :) |
| 17:05:15 | BZFlag | oh, I know about those alright. ;-) |
| 17:05:15 | erikm | Russ|werk: I understand, but I don't think we want it right now |
| 17:06:01 | erikm | BZFlag: but yes, I am interested in the HP stuff. |
| 17:06:26 | BZFlag | hmm... could the MMU just map the offboard to c000 ? or will the kernel try to "fix" that? |
| 17:06:54 | BZFlag | erikm: got an incoming directory someplace? Perhaps I should just scp it to the SF blob dir? |
| 17:07:01 | erikm | BZFlag: you are supposed to start the kernel with the MMY off |
| 17:07:08 | erikm | BZFlag: email is no problem with me |
| 17:07:14 | erikm | s/MMY/MMU/ |
| 17:08:50 | BZFlag | hmm.. that leaves a chicken and egg issue, cause if the onboard needs to be off, where will the kernel be? ;-) |
| 17:11:14 | rmk | bz: in memory, same place it always is |
| 17:11:31 | rmk | what's the chicken and egg issue? |
| 17:14:26 | erikm | rmk: would it be possible to make pass the BOOT_MEM information via an ATAG_ node, or would *that* make a chicken and egg issue? |
| 17:14:59 | rmk | most definitely |
| 17:15:32 | rmk | however, I suppose we could scan for it... |
| 17:15:53 | Russ|werk | erikm: I think is the shannon had a 64M RAM card, there would need to be a kernel configure option that would look for paramater, etc at 0xd000100 |
| 17:16:02 | Russ|werk | s/is/if |
| 17:16:03 | BZFlag | the kernel is normally in the onboard mem on exec no? |
| 17:16:03 | rmk | it would make booting without the tags impossible |
| 17:16:51 | erikm | rmk: configure option :) |
| 17:16:54 | rmk | bz: what's the difference between "onboard" mem and normal mem? |
| 17:16:57 | BZFlag | now how to handle booting same image with and without the 64M sodimm.... |
| 17:17:25 | BZFlag | rmk: c000 always is the first bank no? |
| 17:17:47 | erikm | Russ|werk: where does that 64M memory live? second DRAM bank or so? |
| 17:18:01 | Russ|werk | rmk: the shannon has an sodimm slot, but I think if we used 64M sodim, we would have to change the row/column addressing, which would mean not using the two onboard 4M banks |
| 17:18:17 | BZFlag | nods |
| 17:18:20 | erikm | Russ|werk: ah, like that. |
| 17:18:44 | erikm | Russ|werk: hmm, are there 64MB EDO sodimms? |
| 17:18:49 | BZFlag | on board is bank 0 and 1, sodimm is 2 and 3 I expect. but 64M would need to be all four, right? |
| 17:18:55 | erikm | BZFlag: yes, c000 is the first one |
| 17:19:12 | erikm | BZFlag: each bank can take 128MB |
| 17:19:56 | BZFlag | oh. I was thinking that the mapping was restricted to 16M. hmm. |
| 17:20:26 | erikm | BZFlag: no, I currently have a LART with 32MB in the first bank, and 64MB in the second |
| 17:20:48 | BZFlag | how's that mapping setup? |
| 17:21:20 | erikm | BZFlag: eh, what do you mean? |
| 17:25:03 | Russ|werk | how many pins is the SODIMM supposed to have? |
| 17:27:20 | BZFlag | phy? 72 pins on these. 144 on modern sodimms |
| 17:27:28 | Russ|werk | ah |
| 17:27:52 | Russ|werk | all the 64M EDO SODIMMs I'm finding have 144 pins, the point may be moot |
| 17:28:04 | BZFlag | just wondering if there is a mapping config that will allow the onboard 8M and the 64M sodimm. |
| 17:28:51 | BZFlag | http://www.crucial.com/store/partspecs.asp?imodule=CT8M32E4T6 |
| 17:28:54 | Russ|werk | I would have to see the schematics for teh tuxscreen, and info on the dimm |
| 17:29:05 | erikm | Russ|werk: I can't tell you without taking my laptop appart |
| 17:29:41 | erikm | BZFlag: I think it's more a hardware problem then a software problem |
| 17:30:03 | BZFlag | http://www.crucial.com/store/partspecs.asp?imodule=CT16M32E8T6 <- 64M |
| 17:31:07 | erikm | BZFlag: put the links on the wiki |
| 17:31:33 | erikm | BZFlag: it might worth trying out with the 32MB one first |
| 17:32:19 | Russ|werk | http://tuxscreen.net/wiki/view/Users/CarlWorth |
| 17:33:43 | BZFlag | yes, since the 32M is known to work with Inferno, it's just sw. |
| 17:33:50 | BZFlag | unknown for the 64M |
| 17:34:16 | BZFlag | http://TuxScreen.net/wiki/view/Main/SODIMM |
| 17:37:41 | erikm | BZFlag: the 64MB one could indeed have different row/column layout |
| 17:37:51 | Russ|werk | rmk: what is the status of the sa1100 ir driver? |
| 17:38:12 | rmk | works for SIR, FIR not sure. |
| 17:38:34 | Russ|werk | it hangs on boot for me...I'll add some printk's |
| 17:38:52 | erikm | Russ|werk: IIRC some of the #ipaq guys also got it working with consumer IR |
| 17:39:03 | Russ|werk | rmk: the shannon has a infrared keyboard I'd like to eventually use for console |
| 17:39:08 | erikm | Russ|werk: so you can control your TV with your iPaq |
| 17:39:43 | Russ|werk | erikm: thats what an hp48 is for |
| 18:27:38 | erikm | cool, jim gettys doesn't have problems with the jtag spec |
| 18:27:54 | erikm | "FYI: we're currently testing an iPAQ with 128 meg of memory: so I hope |
| 18:27:55 | erikm | you've got better sizing routines that we had... |
| 18:27:55 | erikm | " |
| 18:29:03 | Russ|werk | by far |
| 18:29:33 | Russ|werk | now just add auto row detection/memory timings |
| 18:31:30 | erikm | I think that's very hard to do |
| 18:31:39 | Russ|werk | I know |
| 18:41:39 | Russ|werk | it was meant to be slightly funny |
| 18:42:24 | erikm | ok |
| 18:43:15 | BZFlag | erikm: he'll get you jtag without nda? or using what you have already signed? |
| 18:43:31 | erikm | I don't know |
| 18:43:33 | BZFlag | If he's giving it away, I'd like to know too. ;-) |
| 18:43:50 | erikm | he left it to jamey hicks, we'll see what he will come up with |
| 18:56:50 | erikm | hehe, I answered jg that I think we have better memory sizing routines. I mean: if you can do it on LART, you can do it on everything |
| 18:56:51 | erikm | ;) |
| 19:12:49 | BZFlag | is jamey considering moving to blob? that would be a Good Thing. |
| 19:13:04 | BZFlag | get them to contribute as well, and reduce the duplication. |
| 19:13:09 | Russ|werk | hopefully it would been less chance of an iPAQ becoming a doorstop |
| 19:13:24 | BZFlag | blob, on it's way to world domination. |
| 19:15:55 | erikm | BZFlag: I haven't heard from jamey yet |
| 19:16:36 | erikm | Russ|werk: that's exactly why I want the ipaq jtag specs. cause I *will* brick it when I'm developing blob for ipaq |
| 19:18:56 | Russ|werk | just open the thing up see if you can see any labeled test pads |
| 19:22:13 | erikm | Russ|werk: IIRC it doesn't |
| 19:22:59 | Russ|werk | is it BGA? |
| 19:23:33 | erikm | yes, sa1110 |
| 19:26:07 | Russ|werk | I was thinking, maybe the params block should use tags like the kernel tags |
| 19:29:05 | erikm | that was exactly what I was thinking |
| 19:30:32 | Russ|werk | any reason blob should need to write the parms block? |
| 19:30:59 | erikm | storing the command line would be handy |
| 19:31:05 | erikm | or the ethernet address |
| 19:31:22 | erikm | or settings like autoboot timeout |
| 19:31:39 | Russ|werk | but stuff like partition tables, bootfs, ramdisk, etc |
| 19:31:54 | Russ|werk | one might need to change those while in blob to be able to boot |
| 19:32:25 | Russ|werk | ahh....no it doesn't |
| 19:32:33 | Russ|werk | "download parms" |
| 19:33:06 | erikm | and then "flash parms"? |
| 19:33:10 | Russ|werk | yah |
| 19:33:13 | erikm | hmm |
| 19:33:15 | Russ|werk | how about this |
| 19:33:24 | Russ|werk | add a tag/key to each param |
| 19:33:39 | Russ|werk | the default key is TAG_ALL or something |
| 19:34:02 | erikm | I think 'set cmdline="root=/dev/hda1 read-only console=ttySA0,9600"' would be handy to do |
| 19:34:16 | Russ|werk | but then there could be others, that are normally dormant, unless that user selects an alternate key/config |
| 19:34:34 | Russ|werk | erikm: I think bot <cmdline> is sufficent there |
| 19:34:49 | erikm | I personally change the amount of goodies connected to a LART quite often, an just using a set command would be quite handy |
| 19:34:59 | Russ|werk | right right right |
| 19:35:15 | erikm | no, because then you have to use "boot bla" for each and every boot |
| 19:35:19 | Russ|werk | I guess the config tags would be numbered |
| 19:35:47 | Russ|werk | for every default tag, that you want loaded all the time, you put 0 as the tag |
| 19:37:15 | Russ|werk | for a tag that you want to specify, like if you wanted key 1 to be boot from hd |
| 19:37:43 | Russ|werk | you'd have tags in your tag list with the '1' key that would say no ramdisk, and another one that would give the cmdline |
| 19:37:56 | Russ|werk | maybe key 2 would be ramdisk |
| 19:38:33 | Russ|werk | so there would be a tag somewhere with key2 that would enable teh ramdisk, and cmdline tag with key 2 that would have the proper command line |
| 19:38:51 | erikm | so you want multiple setting namespaces and a way to select between those? |
| 19:39:08 | Russ|werk | right |
| 19:39:14 | erikm | hmm |
| 19:39:17 | Russ|werk | so you could say, blob> config 1 |
| 19:39:33 | Russ|werk | maybe have a config name tag that would associate a name with a key |
| 19:39:47 | Russ|werk | so you could say config boot_from_hd |
| 19:40:09 | rmk | Russ: boot profiles |
| 19:40:26 | erikm | rmk: yes |
| 19:40:34 | erikm | rmk: you think it is sane? |
| 19:40:58 | Russ|werk | which would make it *very* easy to use a gpio to set which key/config to use |
| 19:41:04 | rmk | I know other people wanting to do that, but they have more complex setups |
| 19:41:09 | rmk | eg, tftp booting etc. |
| 19:41:27 | erikm | rmk: don't worry, we will put bootp/tftp into blob |
| 19:41:43 | rmk | in which case, I'll say add profiles before you do. |
| 19:42:30 | rmk | what you could do (which I haven't seen anywhere else) is to create a linked list of profiles... |
| 19:42:58 | rmk | the idea would be is you try to boot your preferred profile. if that is, say tftp, and it fails, you move on to the next one (which could be load out of flash) |
| 19:43:09 | erikm | rmk: oooh, cool! |
| 19:43:26 | Russ|werk | rmk: the kernel tag struct with an extra value, config |
| 19:43:43 | rmk | Russ: don't go mad over the tag structs |
| 19:43:53 | Russ|werk | ok |
| 19:43:58 | rmk | the command line is quite a powerful way to specify stuff. |
| 19:44:11 | Russ|werk | I mean tag structs for blob, not the kernel |
| 19:44:12 | rmk | think about the command line as "things someone would want to type in and change easily" |
| 19:44:19 | rmk | ah, |
| 19:44:39 | erikm | rmk: the tag structs look like a good idea to use in blob |
| 19:44:41 | Russ|werk | they would be just like kernel tag structs, but would have a config/key value |
| 19:44:45 | rmk | erikm: the idea is you have blob setup to do tftp, then microdrive, then flash (say) |
| 19:45:14 | rmk | if you connect it to the lan, you get tftp. if not, then you get a kernel loaded off your microdrive. or whatever. |
| 19:45:29 | erikm | I like the idea |
| 19:45:45 | Russ|werk | and some userspace util to convert a config file to a parms block |
| 19:45:51 | BZFlag | also a default flash, with a gpio that does tftp/udrive will be common |
| 19:46:40 | Russ|werk | BZFlag: could make a tag that has gpio to check, and if its set/cleared, which config to use first |
| 19:46:42 | rmk | bz: whatever - you could configure it to do it anyway you want |
| 19:47:11 | rmk | Russ: that becomes a script ;) |
| 19:47:28 | Russ|werk | course, you could go overboard and put memory timings, etc in there too |
| 19:48:18 | erikm | let's make it openprom compliant |
| 19:48:20 | erikm | ;) |
| 19:48:26 | Russ|werk | rmk: do you know if nico is going to release another patch soon? |
| 19:48:36 | Russ|werk | erikm: I'm aparently too young |
| 19:48:57 | Russ|werk | because I have no clue what an openprom is |
| 19:49:03 | erikm | Russ|werk: openprom is what Suns and Macs have. |
| 19:49:22 | erikm | Russ|werk: nico is at OLS right now, don't expect anything before saturday |
| 19:49:46 | Russ|werk | erikm: are we going to scrap bootldr and redboot partition tables and use tags instead? |
| 19:50:20 | erikm | Russ|werk: openprom is IEEE 1275. it's actually Forth based. quite sane. PCI should have used it |
| 19:50:30 | Russ|werk | ooh ooh ooh, mtd partitioning passed in kernel tags |
| 19:51:05 | erikm | Russ|werk: I think we don't need that. some kind of partition table in flash isn't too bad |
| 19:51:26 | rmk | Russ: the partition table has to be stored somewhere non-volatile _anyway_ |
| 19:51:32 | Russ|werk | right, but maybe you want to select your partition table at boot (probably not though) |
| 19:51:41 | erikm | Russ|werk: MTD partitioning is something the kernel can work out itself. no need to pass that through the bootloader |
| 19:51:56 | Russ|werk | bootldr patitions it is |
| 19:53:00 | erikm | I think I want bootldr partitioning compatibility first. in that way people can use it as a drop-in replacement for bootldr |
| 19:53:01 | rmk | Russ: Linus has a great distaste for things that use integers to pass stuff around. He'd rather all boot loaders used command lines. This is the reason I'm saying don't go mad - I don't want the kernel tag stuff to sprawl all over the kernel and then have Linus refuse to accept any more. |
| 19:53:56 | rmk | Linus' argument is along the lines of "strings are easily extendable. Fixed length integers aren't". |
| 19:54:11 | rmk | He's right as ever. |
| 19:54:31 | Russ|werk | erikm: how hoes mtd know where to find the bootldr table? |
| 19:55:06 | erikm | Russ: I haven't looked at it yet, but I think it looks at a magic address in flash |
| 19:55:11 | rmk | it reads some of the flash, and looks to see if it finds something it recognises. |
| 19:55:34 | rmk | eg, redboot reads the last erase block from flash, and checks to see if it starts with 'RedBoot' |
| 19:55:48 | Russ|werk | rmk: thats 128k gone |
| 19:56:14 | rmk | yep. |
| 19:56:33 | rmk | the ARM Firmware Suite flash partitioning is hilarious when it comes to JFFS2 though. |
| 19:56:50 | Russ|werk | why's that? |
| 19:57:06 | rmk | AFS has a series of "footers" at the end of each image, and then end of the last block of the image. |
| 19:57:15 | Russ|werk | heh |
| 19:57:23 | rmk | JFFS2, while scanning, decides that the last erase block needs to be cleaned up, and removes the footers. |
| 19:57:38 | erikm | hehe |
| 19:57:43 | rmk | end result is that JFFS2 removes the partitioning info. ;( |
| 19:57:59 | erikm | rmk: blame dwmw2 ;) |
| 19:58:16 | rmk | needs to persuade ARM to drop AFS and come up with a sensible partitioning scheme. |
| 20:02:11 | erikm | hmm. |
| 20:03:06 | erikm | Darwin Chen (the guy that send me the graphicsclient) wants CVS write access. I'm not too sure about it. |
| 20:03:34 | Russ|werk | I would clear up his diffs first |
| 20:03:44 | Russ|werk | so he understands why you disagree |
| 20:04:37 | erikm | I just removed the cruft (Makefile.in diff is not interesting) |
| 20:07:19 | rmk | erikm: slippery slope there. |
| 20:08:37 | Russ|werk | ...? |
| 20:08:37 | BZFlag | erikm: ask for clean patches first, when he can handle that, then write access might be the next step. |
| 20:08:55 | erikm | rmk: yeah. right now we have five developers from which I know they can code. |
| 20:09:12 | erikm | BZFlag: good idea. I'll ask him to explain certain points |
| 20:09:13 | BZFlag | with BZ I have a public patch system on SF, and I get people to post there. similar to the rmk approach |
| 20:19:11 | Russ|werk | rmk: have you thought about the jtag accepting x number of bits, and then readinf back x number of bits |
| 20:19:45 | Russ|werk | and when its writing that x number of bits, it can specify whether or not it wants to read back later? |
| 20:20:45 | Russ|werk | that would seem to be the heaviest usage pattern, write a 271 bit register, write (request read) a 271 bit register, read back, etc |
| 20:22:00 | rmk | Russ: that's supported implicitly |
| 20:22:32 | Russ|werk | so I could do... |
| 20:22:52 | Russ|werk | write len=271 10010100101100101..... |
| 20:23:03 | Russ|werk | write(with readback) len=271 010101010101010101010101.... |
| 20:23:22 | Russ|werk | then read do a read back of 271 bits from the second write |
| 20:23:42 | Russ|werk | and with the first write, the jtag hardware wouldn't be doing any reads |
| 20:23:47 | rmk | there's no difference between the two. |
| 20:23:54 | Russ|werk | what do you mean? |
| 20:24:04 | rmk | write len=271 00101010100100010101010101 |
| 20:24:10 | rmk | write len=271 0101010010101010101010101 |
| 20:24:14 | rmk | read |
| 20:24:22 | rmk | write len=271 010100001010101010101010 |
| 20:24:24 | rmk | read |
| 20:24:34 | Russ|werk | with the speed of jtag hardware there is |
| 20:24:50 | Russ|werk | you don't want to do 271 extra reads if you don't have too |
| 20:25:24 | rmk | it won't be 271 though... |
| 20:25:32 | rmk | the data is in 8 bit bytes |
| 20:25:36 | Russ|werk | thats what I'm wanting |
| 20:25:53 | Russ|werk | oh, well, 271 rounded up to mod 8 |
| 20:26:22 | rmk | I think you'll find the cost of the extra cache + code size will outweigh the speed advantage |
| 20:26:49 | Russ|werk | waht I'm saying is |
| 20:27:29 | Russ|werk | I want to do write_jtag(*data, length, NULL) |
| 20:27:34 | Russ|werk | a few of those |
| 20:27:54 | rmk | fine - from userland you call write, but don't call read |
| 20:28:03 | Russ|werk | and then write_jtag(&data, length, &input_buffer) |
| 20:28:33 | Russ|werk | where it will write all length bits, and at the same time, fill the input buffer, unless its NULL |
| 20:28:37 | Russ|werk | tehn don't do any reads |
| 20:29:54 | rmk | _my_ point is that the kernel has to wiggle the TCK anyway, change TDO anyway, and reading TDI into a kernel internal buffer is _minimal_, compared with the cache sizes you'll waste having a separate function that doesn't do the read. |
| 20:29:59 | Russ|werk | because most of the work is writing a big long register, or writing a bit long register while reading it back |
| 20:30:06 | rmk | you'll be _slower_ |
| 20:30:15 | Russ|werk | rmk: not a seperate function |
| 20:30:42 | Russ|werk | if (dest) *dest = read_... |
| 20:31:05 | Russ|werk | the vast majoruty of time on my jtag hardware is waiting for the ISA bus |
| 20:31:21 | Russ|werk | the CPU can go plenty fast, but has to wait for the ISA bus timings |
| 20:31:45 | Russ|werk | and another read means another wait |
| 20:31:51 | rmk | grumbles - that's 2 new commands ;( |
| 20:31:58 | Russ|werk | not really |
| 20:32:09 | Russ|werk | less commands, you don't need a read |
| 20:32:29 | Russ|werk | you just pass in a source area, a destination area, and a length |
| 20:32:39 | Russ|werk | the only ioctl |
| 20:34:03 | Russ|werk | if the destination area is NULL, don't do reads |
| 20:34:29 | Russ|werk | the source area would have to be twice as big, or you would need a TDI area, and a TMS area |
| 20:35:07 | rmk | Russ: if you're not going to look at what's already in place... |
| 20:35:22 | rmk | sighs |
| 20:35:30 | Russ|werk | not looking at whats in the place, just the pointer |
| 20:35:40 | Russ|werk | er |
| 20:35:42 | Russ|werk | sorry |
| 20:40:34 | Russ|werk | oh, you do have tap code (some) |
| 20:47:43 | erikm | OK, only seven questions about the patch. Let's see what happens. |
| 20:49:02 | erikm | (that's an average of one question per pathed file :) |
| 20:51:54 | Russ|werk | jtag_tap_data() is nice, but it needs some way of calling it that has in NULL |
| 20:56:18 | erikm | goes home |
| 20:56:36 | erikm | bye |
| 21:08:29 | Russ|werk | the userspace interaction should probably be broken out into a jtag_generic.c file |
| 21:09:22 | Russ|werk | and then one of the jtag_???.c files can be chosen to be linked in |
| 21:09:29 | Russ|werk | jtag_parpart.c |
| 21:09:36 | Russ|werk | jtag_sa1100gpio.c |
| 21:09:47 | Russ|werk | etc |
| 21:16:33 | rmk | Russ: indeed. |
| 21:18:39 | Russ|werk | I don't know what I'd call my hardware |
| 21:18:56 | Russ|werk | you write TDI & (TMS << 1) to an address |
| 21:19:14 | Russ|werk | then read back (optionally) the aaddress & 1 to TDO |
| 21:19:36 | Russ|werk | it generates TCLK using nCS and nMEMW |
| 21:21:56 | Russ|werk | what about an option to reset the device? |
| 21:24:31 | rmk | Russ: Assabet doesn't give you TRST ;( |
| 21:25:03 | rmk | but we could do that. |
| 21:25:31 | Russ|werk | er, I guess going to test/logic reset does that |
| 21:26:37 | rmk | on some boards, they wire TRST to the real reset line as well |
| 21:27:11 | Russ|werk | I mean just making the CPU do a reset by entering test/logic reset and leaving it there |
| 21:27:47 | Russ|werk | so nm |
| 21:28:56 | Russ|werk | what about ways to change the pin mapping, so the userspace code can autodetect the cable |
| 21:32:10 | rmk | you'll be adding cycles in the critical region ;( |
| 21:32:26 | rmk | note also that I've not considered any smp issues in that driver |
| 21:32:38 | rmk | it will be racy therefore. |
| 21:33:17 | rmk | ie, we currently don't prevent two processes opening the device... |
| 21:47:53 | Russ|werk | I don't think CPU cycles are very critical |
| 21:48:20 | Russ|werk | the max speed that a SA-11x0 is rated for on TCLK is 20MHz |
| 21:49:21 | Russ|werk | and highest frequency a parallel port will produce is much lower than that |
| 21:51:22 | rmk | send me a patch then ;) |
| 21:56:23 | Russ|werk | probably just a configure option to swap tdi and tms and tclk... |
| 22:00:43 | rmk | whee, now have a "lookup chip by name" and "lookup pin by name and type" |
| 22:01:39 | Russ|werk | so...I can just say D23, and its D23 |
| 22:02:28 | rmk | you can say entity_get_cell(<sa1110_entity>, CT_OUT, "D23") |
| 22:02:50 | rmk | feel free to suggest a better name than "cell" or "pin" |
| 22:03:01 | Russ|werk | cell is perfect |
| 22:03:15 | Russ|werk | I don't know what CT_OUT means |
| 22:03:26 | rmk | you also have entity_lookup(<list>, "sa1110") |
| 22:03:56 | rmk | well, sa1110 BS cell listing seems to have 3 cells for most pins - enable, out, in |
| 22:04:21 | rmk | just an extra attribute, but we could integrate it into the name |
| 22:06:20 | Russ|werk | well, for all 32 data lines, there is one enable cell |
| 22:06:38 | rmk | look at the TXD, RXD etc lines. |
| 22:06:49 | Russ|werk | the gpio lines are a good example |
| 22:06:59 | rmk | yep. |
| 22:08:16 | rmk | needs to hide those pesky read()s into the library before moving any further. |
| 22:09:09 | rmk | The first thing I intend to do after that is to re-write Jflash to use this. |
| 22:09:37 | Russ|werk | that will clean up the Jflash code significantly |
| 22:09:57 | rmk | oh, any ideas if/how other jtag stuff automatically detects what's in the chain? |
| 22:09:58 | Russ|werk | rename it to jflash.c while you are at it |
| 22:10:04 | rmk | grins |
| 22:10:17 | Russ|werk | oh, registers |
| 22:10:22 | rmk | It should be either jflash or JFlash |
| 22:10:31 | Russ|werk | like if a chip has a loopback register |
| 22:10:40 | rmk | I can easily detect how many chips there are in the chain... |
| 22:11:00 | Russ|werk | oh, a jtag chain |
| 22:11:19 | Russ|werk | yah, if the use of devices on a chain was seemless, that would be great |
| 22:11:54 | Russ|werk | I always detect if hardware is there by writing a magic number to the loopback register |
| 22:12:18 | rmk | the problem I have is that some chips, the IDCODE instr is 00110 (SA1110), on others the instr is 0001 (CPLDs) |
| 22:12:44 | Russ|werk | whats that 1 bit register called? |
| 22:12:57 | rmk | bypass |
| 22:14:02 | Russ|werk | what does 00001 do to a sa1100? |
| 22:14:11 | Russ|werk | er, sa11x0 |
| 22:14:17 | rmk | sample/preload |
| 22:15:01 | Russ|werk | is bypass a diffrent instuction on them both as well? |
| 22:15:14 | rmk | no - seems to be all ones. |
| 22:15:20 | Russ|werk | bummer |
| 22:15:26 | rmk | note the different instruction lengths as well... |
| 22:15:32 | Russ|werk | oh, bonus |
| 22:15:49 | Russ|werk | you can use bypass to determine a) if its working and b) which one it is |
| 22:16:21 | rmk | yep - I've got the assabet rigged up atm, and it reports: |
| 22:16:21 | rmk | There are 3 devices on the chain. |
| 22:16:39 | rmk | by using the bypass register to count the number of bits with '0's, while shifting '1's in |
| 22:21:31 | Russ|werk | and you can tell which device accepts 4 bit instructions, and which device accepts 5 bit instructions this way? |
| 22:22:17 | rmk | no - I could detect how long the total instruction chain length is, but that doesn't help |
| 22:23:43 | Russ|werk | why not |
| 22:24:09 | Russ|werk | then you would know whether or not to you 00110 for IDCODE, or 0001 for IDCODE |
| 22:24:16 | Russ|werk | er, to use |
| 22:24:32 | rmk | if you have a length of 13, how do you know where the 4 or 5 lengths are? It could be 4, 5, 4 or 5, 4, 4 or 4, 4, 5 |
| 22:24:36 | Russ|werk | oh |
| 22:25:25 | Russ|werk | you talk to the first one, do something that would break the chain if the instruction length is 4, but allow the chain to keep working if it is 5 |
| 22:25:54 | Russ|werk | if it broke, then its 4, if it didn't, then its 5 |
| 22:26:25 | rmk | define "break" when you've got vendor-specific instructions in the mix |
| 22:26:25 | Russ|werk | move to the next device and repeat (if it breaks, you probably have to reset the entire chain) |
| 22:26:38 | rmk | note that you can't remove devices from the instruction chain ;( |
| 22:26:48 | rmk | data chain yes. |
| 22:27:07 | Russ|werk | what is 0000/00000 |
| 22:27:23 | rmk | extest |
| 22:28:00 | Russ|werk | hmm...there has to be a fairly clean way of determining what the instruction length of each device is |
| 22:28:03 | Russ|werk | or not |
| 22:28:24 | rmk | do you know if any jtag equipment does it? |
| 22:28:51 | Russ|werk | i'm not familiar with any chip level jtag equiptment |
| 22:29:21 | rmk | maybe its the case that they have to be told. ;( |
| 22:29:26 | Russ|werk | I suppose you could refer to work if the devices IDCODE isn't in you IDCODE list |
| 22:29:38 | Russ|werk | dammit, refuse to work, not refer |
| 22:30:06 | rmk | that's my intention currently; seems to be the only sane way to go. |
| 22:30:10 | Russ|werk | or, if you can't get an IDCODE from a device, try skipping over it to the next one |
| 22:30:24 | Russ|werk | first, try skipping over 4 bits, then 5 |
| 22:30:49 | Russ|werk | the more unknown devices in the chain, the more guessing is required |
| 22:31:26 | rmk | gets worried - parity bits??? |
| 22:31:31 | Russ|werk | ? |
| 22:31:42 | Russ|werk | I mean, you get to the first device |
| 22:32:04 | Russ|werk | assume that the IDCODE instruction is 0001, feed it that, read the IDCODE |
| 22:32:09 | rmk | ahhhhh |
| 22:32:24 | rmk | reads 16.2 in the sa1100 manual. |
| 22:32:32 | Russ|werk | does it match? yes, move to the next device, we know the about the first one |
| 22:32:39 | rmk | TRST - does two things... |
| 22:32:53 | rmk | firstly, it sets the BS cells to system mode. |
| 22:33:01 | rmk | secondly, it selects IDCODE mode |
| 22:33:31 | rmk | wonders if that's true if you're in test-logic reset state. |
| 22:35:18 | rmk | decides to try an experiment. |
| 22:36:12 | Russ|werk | it doesn't...try 00110, does it match? yes, move on to the next device |
| 22:36:33 | Russ|werk | no, assume its 4 bits and move on to the next device (repeat process) |
| 22:37:01 | rmk | Yes! It works! |
| 22:37:06 | Russ|werk | process worked? then first device is unknown, but has an instruction length of 4 bits |
| 22:37:18 | Russ|werk | no? try again with the assumption of 5 |
| 22:37:25 | rmk | Go to test logic reset, then round to shift-dr, and you read the ID code |
| 22:37:43 | Russ|werk | but do all devices do that |
| 22:37:56 | rmk | well, the CPLDs have as well as the StrongARM |
| 22:37:56 | Russ|werk | (default to IDCODE) |
| 22:38:10 | rmk | wishes he had the IEEE spec |
| 22:39:02 | Russ|werk | us it legal for intel to give you a copy? |
| 22:39:26 | rmk | s/intel/ARM/ maybe. |
| 22:39:59 | rmk | needs to work out how he can string them a line that'll fit into his current contract with them. |
| 22:40:02 | Russ|werk | if you are improving jflash/assabet, they might be willing to give you one |
| 22:40:38 | rmk | I've no business links with Intel, so its legally questionable I think. |
| 22:40:53 | Russ|werk | I imagine you don't want to screw with an NDA |
| 22:41:29 | rmk | I've managed to avoid such nasty things so far... |
| 22:41:59 | rmk | wonders if he can get it from the IEE in London |
| 22:51:08 | rmk | goes zzz |