| 01:51:24 | sammy | that's greet ....!! what's amazing ....!! |
| 01:56:19 | sammy | Russ : BZFlag == Tim Riker .... ? |
| 01:56:24 | Russ | yah |
| 01:57:25 | sammy | now I am watching the page about his little child , so cute ....!! |
| 08:17:24 | erikm | good morning |
| 08:17:43 | sammy | Good Morning erikm ...!! |
| 08:38:58 | sammy | hi !! lxrbot good to see U again ....!! |
| 08:40:18 | erikm | lxrbot: have a botsnack |
| 08:40:19 | lxrbot | thanks erikm :) |
| 11:35:52 | erikm | woohoo! blob correctly detects the 64MB expansion board: |
| 11:35:55 | erikm | Memory map: |
| 11:35:55 | erikm | 0x00800000 (8 MB) @ 0xC0000000 |
| 11:35:55 | erikm | 0x00800000 (8 MB) @ 0xC1000000 |
| 11:35:55 | erikm | 0x00800000 (8 MB) @ 0xC8000000 |
| 11:35:55 | erikm | 0x00800000 (8 MB) @ 0xC9000000 |
| 11:35:55 | erikm | 0x04000000 (64 MB) @ 0xD0000000 |
| 13:24:37 | Russ | erikm: yah |
| 13:25:06 | Russ | I was all set to write that so I could figure out the tuxscreen memory may |
| 13:25:25 | Russ | erikm: the ramdisks are messed up and I don't know why though |
| 13:26:33 | Russ | just hangs at decompressing ramdisk |
| 13:29:04 | erikm | hi Russ |
| 13:31:32 | erikm | Russ: hmm. is the memory setup correct? |
| 13:31:48 | erikm | Russ: look at the brutus setup, it also has 4MB in each bank |
| 13:44:09 | Russ | Memory map: |
| 13:44:09 | Russ | 0x00400000 (4 MB) @ 0xC0000000 |
| 13:44:09 | Russ | 0x00400000 (4 MB) @ 0xC8000000 |
| 13:44:09 | Russ | 0x00400000 (4 MB) @ 0xD0000000 |
| 13:44:09 | Russ | 0x00400000 (4 MB) @ 0xD8000000 |
| 13:44:29 | Russ | /* The Shannon has 2 banks of 4M on board */ |
| 13:44:30 | Russ | SET_BANK( 0, 0xc0000000, 4*1024*1024 ); |
| 13:44:30 | Russ | SET_BANK( 1, 0xc8000000, 4*1024*1024 ); |
| 13:44:30 | Russ | /* And an add-in card with 2 banks of 4M */ |
| 13:44:30 | Russ | SET_BANK( 2, 0xd0000000, 4*1024*1024 ); |
| 13:44:30 | Russ | SET_BANK( 3, 0xd8000000, 4*1024*1024 ); |
| 13:44:32 | Russ | /* Set to 2 if you don't have the RAM card in */ |
| 13:44:35 | Russ | mi->nr_banks = 4; |
| 13:44:43 | Russ | ROOT_DEV = MKDEV(RAMDISK_MAJOR,0); |
| 13:44:43 | Russ | setup_ramdisk(1, 0, 0, 8192); |
| 13:44:43 | Russ | setup_initrd(0xc8000000, 3*1024*1024); |
| 13:45:05 | Russ | BOOT_MEM(0xc0000000, 0x80000000, 0xf8000000) |
| 13:45:45 | Russ | the brutus setup differs slightly |
| 13:45:52 | Russ | setup_initrd( __phys_to_virt(0xd8000000), 3*1024*1024 ); |
| 13:46:05 | Russ | why is the __phy_to_virt there? |
| 13:46:46 | erikm | that's what I asked myself as well |
| 13:47:39 | erikm | wait. it just hangs at compressing the ramdisk? |
| 13:47:51 | Russ | RAMDISK: Compressed image found at block 0 |
| 13:48:06 | erikm | try to relax the memory timings |
| 13:48:25 | Russ | its already pretty relaxed |
| 13:48:32 | erikm | the decompress stuff stresses the memory bus quite seerely |
| 13:48:52 | Russ | the kernel decompresses fine |
| 13:49:15 | Russ | btw, I should use ttySA0, correct? |
| 13:49:36 | erikm | I think so yes |
| 13:49:38 | erikm | hmm, wait |
| 13:49:41 | erikm | that can be it |
| 13:49:58 | erikm | if you're using the wrong tty you won't see anuthing at all and the system appears to hang |
| 13:50:19 | Russ | could just all be puts |
| 13:50:27 | Russ | (maybe) |
| 13:50:51 | Russ | Memory: 11720KB available (1003K code, 219K data, 44K init) |
| 13:50:54 | Russ | ... |
| 13:51:04 | Russ | plenty for an 8M ramdisk |
| 13:52:34 | Russ | and sysrq doesn't want to work |
| 13:52:58 | erikm | what kernel? |
| 13:53:08 | Russ | 2.4.6-rmk2-np1 |
| 13:53:24 | erikm | tries sysrq on LART |
| 13:53:31 | erikm | works |
| 13:53:53 | Russ | maybe whatever happens to the ramdisk is so bad, sysrq breaks |
| 13:54:02 | erikm | maybe it disabled sysrq |
| 13:54:46 | Russ | hmm.....I had it as console=ttySA0,9600 |
| 13:55:04 | Russ | I changed it to console=/dev/ttySA0,9600, and it stopped working |
| 13:55:30 | erikm | should be console=ttySA0,9600 |
| 13:56:24 | Russ | anyway, it gets stuck after the call to gunzip |
| 14:00:13 | erikm | btw, don't include linux/irq.h |
| 14:00:45 | erikm | (I'm compiling the cs89x0 driver) |
| 14:01:21 | Russ | any paticular reason? |
| 14:01:44 | erikm | linux/irq.h is only for the code in arch/* |
| 14:01:51 | erikm | and ARM just doesn't use it |
| 14:02:00 | erikm | the header file is never used in drivers |
| 14:02:57 | Russ | leaves |
| 14:04:24 | erikm | hohum. kernel oops |
| 14:18:51 | erikm | #ifdef SA1100_ARCH |
| 14:18:51 | erikm | ioaddr += PCMCIA_IO_0_BASE; |
| 14:18:51 | erikm | #endif |
| 14:19:00 | erikm | ugly hack, Russ. |
| 14:19:24 | erikm | just tell the driver that you *want* 0xe0008300 |
| 16:55:04 | erikm | hi BZFlag |
| 17:14:22 | BZFlag | hey. been a busy weekend. |
| 17:14:30 | BZFlag | got 4 new Yopys to play with. |
| 17:14:51 | BZFlag | hacked friends systems for fun and pleasure. ;-) |
| 17:15:50 | erikm | hehe |
| 17:15:59 | erikm | pretty lazy weekend over here |
| 17:16:41 | erikm | read lots of newspapers, visited a couple of friends, and decided to do some blob hacking last night |
| 17:18:10 | BZFlag | send me your mail address and I'll "loan" you a couple of phones to hack on? |
| 17:18:25 | erikm | BZFlag: *blink* |
| 17:18:56 | erikm | BZFlag: it's not that I don't want to pay for it or don't have the money, it's just quite hard to get money to the US |
| 17:19:46 | BZFlag | I know, I'd just like you to get started as soon as possible. ;-) I figure the old saying: |
| 17:20:03 | BZFlag | whatever is on a linux engineer's desk, will soon run linux. |
| 17:20:41 | BZFlag | I figure I should not let money transfer issues get in the way. |
| 17:20:57 | BZFlag | and this way I can mark the boxes as "gifts" too. ;-) |
| 17:21:28 | erikm | ah, ok |
| 17:21:28 | BZFlag | Russ and I have been hacking, I'd just like to get you started too. |
| 17:21:51 | BZFlag | so let's dig in and figure the money out when we can. |
| 17:22:01 | erikm | ok, I'll email my address |
| 17:22:04 | BZFlag | the sooner linux is up, the sooner I get my basement back. |
| 17:22:08 | erikm | hehe |
| 17:22:22 | BZFlag | sweet. tim@rikers.org, but you knew that. |
| 17:26:43 | erikm | looks for the correct zip code of his work address |
| 17:28:17 | erikm | found it |
| 17:28:45 | erikm | work address is easier, otherwise the parcel service will just find a closed door at home ;) |
| 17:29:40 | BZFlag | no prob, whatever you like. |
| 17:30:05 | erikm | mail is on its way |
| 17:38:15 | BZFlag | got it. 2 units ok? you have stuff for cabling and dongles I presume? |
| 17:38:50 | BZFlag | I figure you want one with inferno still on it and one for blasting blob/linux so you can compare register settings etc. |
| 17:39:04 | | Russ was last seen on #blob 3 hours, 36 minutes and 7 seconds ago, saying: leaves [Mon Jul 23 15:02:57 2001] |
| 17:39:04 | BZFlag | ibot: seen Russ |
| 17:40:01 | erikm | BZFlag: sorry, was to the vending machine |
| 17:40:25 | BZFlag | no prob. /me is talking on like 6 channels now. |
| 17:40:50 | erikm | BZFlag: one with inferno on it would be nice, yes. |
| 17:41:08 | erikm | BZFlag: and we have enough stuff over here to make *any* dongle you want :) |
| 17:41:54 | BZFlag | they will both have inferno, I figure you will jtag and blast one of them till blob is stable anyway. I have like 4 different inferno images too if you want to play with that. |
| 17:42:18 | erikm | I actually never played with inferno |
| 17:42:39 | BZFlag | sweet, I'll get em mailed tomorrow then. probably usps gem (us postal service, global express mail) |
| 17:43:15 | BZFlag | inferno is nice, but I do not have full source, and would much prefer a complete open source solution. |
| 17:43:22 | erikm | ok. so they will be here somewhere end of the week or so? |
| 17:44:06 | BZFlag | I think they say like 2-4 working days. I mail ya after I send em with a better estimate. |
| 17:44:12 | erikm | ok |
| 18:35:34 | Russ|werk | BZFlag: did you notice blob now works and flashes? |
| 18:35:46 | Russ|werk | and I also have kernel diffs up? |
| 18:36:25 | erikm | Russ|werk: your IRQ autoprobing in the cs89x0 driver can't work |
| 18:36:32 | Russ|werk | erikm: could you change the mach-types on arm.linux.org.uk for tuxscreen from ARCH_SHANNON to SA1100_SHANNON? |
| 18:36:35 | Russ|werk | erikm: why not? |
| 18:36:45 | erikm | Russ|werk: no, I can't. ask rmk |
| 18:37:43 | erikm | Russ|werk: because you first need to make the GPIO an input and make it a rising edge sensitive IRQ |
| 18:38:02 | Russ|werk | right, and I do that for each listed possible IRQ |
| 18:38:45 | erikm | oh, wait that gets compiled |
| 18:38:52 | Russ|werk | erikm: how does the kernel know where to decompress to? |
| 18:39:13 | erikm | Russ|werk: rmk just posted some nice story about that on linux-arm-kernel |
| 18:39:25 | Russ|werk | erikm: the adding of PCMCIA_IO_0_BASE came from the diffs you passed me |
| 18:40:06 | erikm | oh, that's why. I already changed that in my version |
| 18:40:39 | Russ|werk | easy to fix |
| 18:40:55 | erikm | I already did so |
| 18:41:08 | erikm | hmm, the driver doesn't listen to the irq= argument |
| 18:41:17 | Russ|werk | I just figured there might be a good reason for it, like the networking subsystem not being u32 for ioport in all places |
| 18:41:20 | erikm | cs89x0: No EEPROM, relying on command line.... |
| 18:41:21 | erikm | IRQ 892627570, programmed I/O, MAC 00:00:00:00:00:00 |
| 18:41:54 | erikm | the IRQ part scares me |
| 18:42:02 | Russ|werk | erikm: I don't know if I've even specified an IRQ... |
| 18:42:17 | Russ|werk | erikm: I always just let it probe one |
| 18:42:39 | erikm | Russ|werk: that doesn't work, so I just said irq=0, and that gives the same results |
| 18:43:31 | Russ|werk | { IRQ_GPIO0, IRQ_GPIO1, IRQ_GPIO2, IRQ_GPIO3, 0 }; |
| 18:43:37 | Russ|werk | still 0 terminated? |
| 18:43:52 | erikm | and IRQ_GPIO0 == 0 |
| 18:44:03 | Russ|werk | you sure its not ~0 or something? |
| 18:44:33 | erikm | #define SA1100_IRQ(x)(0 + (x)) |
| 18:44:33 | erikm | #defineIRQ_GPIO0SA1100_IRQ(0) |
| 18:45:20 | erikm | so yes, IRQ_GPIO0 == 0 |
| 18:45:39 | erikm | I'll make it an -1 terminated list |
| 18:45:50 | Russ|werk | good idea |
| 18:46:47 | erikm | actually, the IRQ list is a little bit different from what you think it is |
| 18:47:23 | erikm | it is not a list of IRQs for all cards, but a list of four IRQs for a single card |
| 18:47:23 | Russ|werk | I know |
| 18:47:48 | Russ|werk | Its completely different from teh with eeprom setup |
| 18:48:07 | erikm | so just making it count from 0 to 4 should also fix it |
| 18:49:02 | Russ|werk | I was at the time thinking stop after 2 chips, so I added the zero, then the lart config just extended on that |
| 18:49:52 | erikm | hmm |
| 18:50:00 | erikm | whatever we do, it will be broken |
| 18:50:39 | Russ|werk | It is possible that the embedded cs89x0 driver should be pulled off and seperate from the ISA card cs89x0 driver |
| 18:51:17 | Russ|werk | I do like the mii-tool hack though |
| 18:51:42 | Russ|werk | where'd BZFlag go? |
| 18:52:01 | erikm | chatting on other channels ;) |
| 18:58:15 | Russ|werk | erikm: news on rmk's site? |
| 18:58:22 | Russ|werk | the demise of rebel.com? |
| 18:58:48 | erikm | Russ|werk: yeah, I knew about that |
| 19:08:43 | Russ|werk | erikm: how does the kernel know where to decompress to? |
| 19:10:21 | BZFlag | Russ|werk: I'm here now. you booted!? |
| 19:10:28 | Russ|werk | wonders why someone always complains when their bogomips value drops |
| 19:10:40 | Russ|werk | BZFlag: it gets stuck at decompressing ramdisk |
| 19:10:56 | Russ|werk | BZFlag: but blob is fully functional, and I have kernel patches |
| 19:11:38 | erikm | Russ|werk: rmk just posted some nice story about that on linux-arm-kernel |
| 19:11:48 | Russ|werk | the first problem I noticed was that kernel start was at 0xc0008000 |
| 19:11:52 | BZFlag | sweet! reg blob or ts blob? |
| 19:11:59 | Russ|werk | and length was 0xf8000 |
| 19:12:16 | Russ|werk | then the stack was put at 0xc0010000 - 4.... |
| 19:12:23 | Russ|werk | BZFlag: regular blob |
| 19:12:24 | erikm | Russ|werk: it tells exactly where the kernel decompresses ramdisks, etc |
| 19:12:29 | Russ|werk | BZFlag: no code from AMD |
| 19:12:45 | Russ|werk | erikm: still getting through my email box |
| 19:12:51 | BZFlag | nice! in cvs now? |
| 19:12:59 | Russ|werk | yup |
| 19:13:08 | erikm | thinks BZFlag should subscribe to blob-cvs-commit |
| 19:13:17 | erikm | BZFlag: it has been a busy weekend for blob |
| 19:13:20 | Russ|werk | then I noticed that BLOB_RAM_BASE was at 0xc0000000 + 16M... |
| 19:13:28 | BZFlag | hehe, I suppose I could procmail it... ;-) |
| 19:13:34 | erikm | BZFlag: it also has memory probing |
| 19:13:42 | Russ|werk | then, erikm commited some memory map detection code, and I saw the memory map |
| 19:13:50 | Russ|werk | was going to do that code next |
| 19:13:56 | BZFlag | you two are awesome! |
| 19:14:08 | erikm | BZFlag: here is your procmail rule: |
| 19:14:09 | erikm | :0: |
| 19:14:10 | erikm | * ^X-BeenThere:\ blob-cvs-commit@lists\.sourceforge\.net |
| 19:14:10 | erikm | blob-cvs-commit |
| 19:14:13 | Russ|werk | so I was able to move everything around to the memory map |
| 19:14:29 | Russ|werk | BZFlag: oh. you don't get blob-cvs-commit? |
| 19:14:47 | erikm | the memory map code also correctly detects the 64MB expansion board |
| 19:15:04 | erikm | gets the dmm |
| 19:16:08 | Russ|werk | BZFlag: more work to be done on the kernel patches, keyboard, lcd, ucb, handling of a mem= paramater, etc |
| 19:16:55 | Russ|werk | also, I asked rmk to change ARCH_SHANNON to SA1100_SHANNON |
| 19:17:49 | BZFlag | Russ|werk: whatever is the norm for naming is fine by me. |
| 19:18:16 | erikm | Russ|werk: ucb sound support should be easy to do |
| 19:18:37 | Russ|werk | erikm: I figure, I saw only two ifdef LART's in the driver |
| 19:18:49 | Russ|werk | it uses the same serial port on all sa1100's? |
| 19:18:57 | erikm | yes |
| 19:19:31 | erikm | Russ|werk: look in a recent kernel for drivers/char/ucb1200_sa1100.c |
| 19:19:45 | erikm | Russ|werk: I added LART a week ago over there |
| 19:20:00 | erikm | damn. farnell gave us the wrong connectors |
| 19:20:23 | erikm | wants the bloody male connectors |
| 19:20:54 | Russ|werk | erikm: I know, I grepped the kernel source for a few of the SA1100 boards with similar hardware |
| 19:21:02 | Russ|werk | (2.4.6-rmk2-np1) |
| 19:21:16 | erikm | damn |
| 19:21:17 | Russ|werk | erikm: connector to what? |
| 19:21:19 | erikm | aargh! |
| 19:21:24 | erikm | etherboard |
| 19:21:34 | erikm | I took the wrong example ether board! |
| 19:21:42 | erikm | the connectors are wrong *again* |
| 19:21:56 | erikm | s/connectors/resistors/ |
| 19:22:02 | erikm | no wonder it doesn't work |
| 19:23:15 | Russ|werk | routed wrong? |
| 19:23:21 | Russ|werk | oh, resistors |
| 19:23:32 | erikm | silk screen is wrong |
| 19:23:44 | Russ|werk | not wrong, "misleading" |
| 19:23:50 | erikm | ehm, yes |
| 19:24:06 | erikm | the 10k and 4k99 were mixed up |
| 19:24:13 | Russ|werk | but it depends on what your definition of the word 'is' is |
| 19:27:52 | Russ|werk | just curious, are navaho code talkers well known outside of arizona? |
| 19:28:23 | erikm | not really. never heard about them over here |
| 19:30:00 | Russ|werk | the US military used indians as code talkers in the pacific theatre, because all other forms of code were quickly broken |
| 19:30:11 | Russ|werk | navaho was never broken |
| 19:31:12 | erikm | ah, yes, I remember |
| 19:32:09 | Russ|werk | is it well known that the US kept japanese citizens in camps? |
| 19:32:40 | BZFlag | wonders why the ww2 conversation all of a sudden? |
| 19:33:04 | erikm | Russ|werk: japanese citizens? or US residents of japanese origin? |
| 19:33:06 | Russ|werk | dunno, there is that codetalker movie coming out, or was that a tv movie I dunno |
| 19:33:10 | Russ|werk | er |
| 19:33:29 | Russ|werk | yes, US citizens of japanese orign |
| 19:34:44 | Russ|werk | prints rmk's faq and starts using it as wallpaper |
| 19:35:36 | Russ|werk | so __virt_to_phys does nothing if your physical start of ram and virtual start of ram is the same adress |
| 19:35:41 | Russ|werk | (which is the case) |
| 19:38:09 | erikm | that also explains why some archs use __virt_to_phys() for the base address and others don't |
| 19:38:17 | Russ|werk | erikm: that guy asking about the assabetized lart is the sameone that rewrote my patches in "c++" |
| 19:38:31 | erikm | patches for what? |
| 19:39:24 | Russ|werk | jffs2, he changed all the coding styles, and changed all the pre/post incremement/decremnts to |
| 19:39:28 | Russ|werk | i = i + 1 |
| 19:39:36 | erikm | ah, that one |
| 19:39:45 | Russ|werk | and made no distinction between pre and post |
| 19:40:01 | Russ|werk | and then emailed me saying he found a bug in my code |
| 19:40:49 | erikm | problem over here is that the students only learn C++. and doing low-level UNIX things requires quite some C knowledge. *very* steep learning curve ahead |
| 19:42:16 | Russ|werk | the comp.os.c faq is very handy for such students |
| 19:43:03 | Russ|werk | c++ is being replaced by java in schools |
| 19:44:04 | erikm | hmm, I'll point them to it next time |
| 19:44:08 | erikm | good idea |
| 19:44:22 | erikm | they usually ask me because I am the C guru over here |
| 19:44:30 | erikm | and the unix guru |
| 19:45:01 | Russ|werk | the gcc.gnu.org manuals are also helpfull, as well as the glibc manual/info pages |
| 19:55:15 | Russ|werk | how come the strongarm processor I have isn't as pretty as the ones who have |
| 19:55:42 | Russ|werk | mine has very small, barely visable lettering |
| 19:56:01 | Russ|werk | the ones I see in other pictures have big bright white letters... |
| 20:01:03 | Russ|werk | ok, machine registry is updated |
| 20:04:46 | erikm | good |
| 20:05:27 | Russ|werk | suppose I should hand out cvs write access to my kernel? |
| 20:05:34 | Russ|werk | or does that not work well with kernels |
| 20:06:22 | erikm | Russ|werk: what do you mean? |
| 20:06:41 | Russ|werk | I have a cvs kernel that I make my diffs from |
| 20:06:49 | Russ|werk | for the tuxscreen |
| 20:07:04 | Russ|werk | I suppose submitting patches is the traditional method |
| 20:07:05 | erikm | and you want to give us write access to it? |
| 20:07:11 | Russ|werk | yad |
| 20:07:12 | Russ|werk | er |
| 20:07:13 | Russ|werk | yah |
| 20:07:33 | erikm | Russ|werk: well, rmk and nico are certainly not going to pull patches from CVS trees |
| 20:07:46 | Russ|werk | ? |
| 20:08:01 | Russ|werk | I use the tree to make -tux patches |
| 20:08:05 | erikm | Russ|werk: rmk does for two CVS trees: cpufreq and mtd |
| 20:08:13 | Russ|werk | at -rmk2-np1-tux1 right now |
| 20:08:37 | erikm | Russ|werk: don't make it as ugly as the handhelds CVS tree... |
| 20:08:48 | Russ|werk | hows that? |
| 20:09:04 | erikm | http://www.arm.linux.org.uk/developer/patches/?action=viewpatch&id=597/1 |
| 20:09:53 | erikm | yes, that's a PCMCIA driver with two integrated MTD drivers |
| 20:19:27 | Russ|werk | adds || defined NESA to the arm flash code |
| 20:20:56 | erikm | ethernet works *much* better with the resistors on the correct place |
| 20:21:13 | BZFlag | Russ: so I never heard what the jtag issue was on your end. |
| 20:21:16 | erikm | apt-get upgrades the LART |
| 20:23:47 | Russ|werk | BZFlag: still dunno |
| 20:24:01 | Russ|werk | BZFlag: got it working with jflash though |
| 20:26:43 | Russ|werk | now I don't need jtag |
| 20:27:03 | erikm | Russ|werk: because blob flashes itself ;) |
| 20:27:09 | Russ|werk | at least until I screw up blob |
| 20:27:24 | Russ|werk | the jumping to a downloaded blob is a cool idea |
| 20:28:00 | Russ|werk | the startup.S stuff would have to be position independant |
| 20:28:09 | erikm | Russ|werk: *very* hard |
| 20:28:17 | erikm | Russ|werk: I tried it |
| 20:28:23 | Russ|werk | er, start.S |
| 20:28:33 | Russ|werk | the rest of the stuff wouldn't have to be |
| 20:28:49 | Russ|werk | because start.S would recopy everything to the correct location |
| 20:28:59 | erikm | Russ|werk: jus make a separate start.S that copies blob-rest to 0xc0000000 |
| 20:30:39 | Russ|werk | but then you aren't testing start.S |
| 20:30:57 | erikm | no, but usually you don't change that |
| 20:31:13 | erikm | and when you change it you want to test it for a bare system |
| 20:31:18 | Russ|werk | but you might... |
| 20:31:44 | erikm | changing memory timings, for example. so you would need to run from flash for that |
| 20:32:22 | Russ|werk | start.S changes the memory timings |
| 20:32:54 | erikm | yes, but currently you would only like to test things like JFFS2 support, which is in blob-rest |
| 20:34:02 | Russ|werk | so having a start.S appended to the end would work for that |
| 20:34:21 | Russ|werk | jump to BLOB_RAM_BASE+the offset |
| 20:34:34 | Russ|werk | copy it back, and jump to it |
| 20:34:35 | erikm | for example, yes |
| 20:34:51 | erikm | I'll make it tomorrow |
| 20:34:57 | Russ|werk | I still think making start.S position independant would be better |
| 20:35:05 | erikm | Russ|werk: been there, done that/ |
| 20:35:10 | erikm | Russ|werk: it just doesn't work |
| 20:35:22 | Russ|werk | like the memory test? |
| 20:35:30 | Russ|werk | oops, tested blob |
| 20:35:34 | erikm | what about the memory test? |
| 20:35:44 | Russ|werk | the memory testing stuff would test blob |
| 20:36:24 | erikm | no, that's not what's wrong. you just can't get it to work. the manual says "use -fPIC" etc. but the point is that you need to have an ELF capable run-time linke |
| 20:36:26 | erikm | are |
| 20:36:46 | Russ|werk | I don't know arm code that well |
| 20:36:47 | erikm | and I refuse to put an ELF linker into a boot loader |
| 20:37:02 | Russ|werk | I could do it in m6800 |
| 20:37:19 | erikm | it's not worth it for debugging code |
| 20:37:37 | erikm | I'll just make some blob-debug-start code |
| 20:37:38 | Russ|werk | skims through his arm quick reference sheet |
| 20:38:31 | Russ|werk | I can see doing blob-debug-start if only for the needed memory test special case |
| 20:39:01 | Russ|werk | other schemes invlove enabling the MMU and making it think it is at 0x00000000 |
| 20:39:15 | Russ|werk | but that leads to other problems |
| 20:40:01 | erikm | turning MMU is a big nono for me. it is a boot loader, not an OS |
| 20:40:21 | erikm | anyway, debug-start.S will do this: |
| 20:40:30 | erikm | - it turns on the LED |
| 20:40:32 | Russ|werk | I suppose if a user is hacking on start.S, they would have JTAG hardware |
| 20:40:47 | erikm | - it zeros the first 1MB |
| 20:40:56 | erikm | - it copies blob-rest to 0xc0000000 |
| 20:41:02 | erikm | - it sets up a stack pointer |
| 20:41:10 | erikm | - it jumps to 0xc0000000 |
| 20:41:20 | erikm | I think it even won't turn on the LED |
| 20:41:27 | Russ|werk | the only question is where do you put it in blob |
| 20:41:35 | Russ|werk | turn off the LED before you jump to it |
| 20:41:36 | erikm | Russ|werk: we just don't |
| 20:41:47 | Russ|werk | that way its easy to detect a bogus download |
| 20:41:56 | erikm | Russ|werk: it's a separate download target |
| 20:42:04 | Russ|werk | hmm.... |
| 20:42:33 | Russ|werk | I dunno about that, I think it can be in the same target |
| 20:42:35 | erikm | maybe even only enabled with an extra configure flag |
| 20:42:46 | erikm | Russ|werk: it's dead code for most situations |
| 20:43:00 | erikm | Russ|werk: it's only nice for developers, not for average users |
| 20:43:06 | Russ|werk | hell, it could possibly be c code, since it doesn't have to return |
| 20:43:23 | Russ|werk | er, but c code can't quite setup a stack pointer |
| 20:45:05 | Russ|werk | don't forget you can pass addresses to it in registers |
| 20:45:28 | erikm | Russ|werk: assembly is the easiest way. |
| 20:45:40 | erikm | Russ|werk: I'll work on it tomorrow morning |
| 20:56:42 | erikm | goes home |
| 20:56:46 | erikm | see you tomorrow |