| 00:26:55 | Fare | indeed DMA channels 4 and 5 are active |
| 00:28:40 | Fare | but the addresses do not match |
| 00:32:20 | Fare | and indeed just disabling the DMA isn't enough to keep this address constant! |
| 00:35:25 | Fare | however, looking at the behaviour of that memory cell, it looks like it increases at regular 1ms rate! |
| 00:38:33 | Russ|werk | are you disabling interrupts? |
| 01:28:43 | prpplague | Russ|werk: you still at work? |
| 01:34:21 | Sammy | morning ~* |
| 01:35:38 | prpplague | knee how mow |
| 01:36:32 | Fare | hey! |
| 01:36:45 | Fare | Russ: yes, interrupts are definitely disabled |
| 01:37:13 | Fare | has anyone of you heard about a device that writes a 16-bit 1ms timer counter to memory? |
| 01:37:23 | Fare | that's what seems to happen to me |
| 01:38:27 | Fare | prpplague: yes, I'm fine, btw. |
| 01:39:13 | Sammy | prpplague: knee how :D |
| 01:39:55 | prpplague | Fare: you speak mandarin? |
| 01:40:47 | Fare | no, but I can understand a very few words. |
| 01:41:19 | Fare | you have a terrible pronounciation, btw |
| 01:43:46 | Fare | I can't imagine why anyone would want to DMA his 16-bit real-time clock counter into memory |
| 01:44:01 | Fare | why not let the cpu read an I/O register? |
| 01:44:21 | Fare | or maybe the counter is computer by a FIQ |
| 01:44:33 | Fare | but then why would it be 16-bit and not 32-bit? |
| 01:44:39 | Russ|werk | prpplague: ya |
| 01:44:41 | Fare | (and I think FIQ is disabled, anyway) |
| 01:44:54 | Fare | this timer seems braindead design, to me. |
| 01:45:00 | Russ|werk | Fare: you think? |
| 01:45:08 | Fare | sometimes, I think |
| 01:45:15 | Fare | or maybe I just think I think |
| 01:45:19 | Russ|werk | I'd be damn sure firq's are disabled |
| 01:45:38 | Fare | Russ: how can you be? |
| 01:45:44 | Fare | mode 0b11111 |
| 01:46:24 | Russ|werk | read the sa-1100 manual, see what registers control that (as well as interrupts) |
| 01:46:32 | Russ|werk | then write to them in the chain loader |
| 01:49:24 | Russ|werk | I would think it would be the sa1100 timer irq |
| 01:49:34 | Russ|werk | what are you doing to disable interrupts |
| 01:50:24 | Fare | I'm letting hpcboot disable them. |
| 01:50:34 | Fare | is goes into mode 600000bf |
| 01:51:58 | Fare | ouch. |
| 01:52:04 | Fare | Looks like FIQs are still there! |
| 01:52:14 | Fare | that might very well explain. |
| 01:52:25 | Fare | Now that I have the ARM ARM, I understand better... |
| 01:54:23 | Fare | thanks a lot for pointing me to this! |
| 01:55:22 | Russ|werk | you are trusting hpcboot to do things for you? |
| 01:55:26 | Russ|werk | I wouldn't |
| 01:56:00 | Fare | wait, why is the T bit set??? |
| 01:56:34 | Fare | bf means, I !F T, System mode. |
| 01:56:48 | Russ|werk | I don't know much about hpcboot |
| 01:57:46 | Fare | I only know it works well enough to boot blob |
| 01:59:09 | Russ|werk | the first think I would do in chain.S, would be to disable interrupts, disable FIRQ's, and disable any DMA transfers |
| 02:06:52 | Fare | no, not in chain.S -- in trampoline.S |
| 02:06:55 | Fare | or maybe both |
| 02:07:16 | Fare | I don't understand why erikm won't do that |
| 02:07:21 | Fare | but I will |
| 02:09:13 | Fare | what is this small device you send me a .jpg of? |
| 02:18:30 | Fare | ouch. Can't disable FIQ mode! |
| 02:18:46 | Fare | I try to put 0xff there and it won't work :( :( :( |
| 02:30:15 | Fare | hum. Anyone here? |
| 02:40:11 | Fare | on the other hand, FIQ better be disabled, because when I read 0x1c, I get different random stuff everytime |
| 02:55:50 | Fare | wait, it's df, not bf -- it's ok, FIQs ARE disabled |
| 02:56:20 | prpplague | Fare: having a spelling problem? |
| 03:22:51 | Fare | yup |
| 03:23:06 | Fare | I spelled bf (incorrect) instead of df (correct) |
| 03:25:18 | Fare | maybe I use brainf*ck too much |
| 06:44:02 | | ibot has karma of 9 |
| 06:44:02 | Russ | ibot: karma ibot |
| 07:04:06 | Russ | dear god, these morons |
| 07:06:53 | prpplague | mmatten: up late? |
| 07:07:10 | prpplague | mmatten: oops, i mean up early? |
| 07:07:27 | mmatten | hmm well 9:09 in the morning :) |
| 07:07:31 | mmatten | not that early :) |
| 07:08:08 | prpplague | mmatten: i just got my dvd player running on my laptop thanks to some help from Russ |
| 07:08:21 | mmatten | think's he'll be pretty messed up with the time diff at OLS x_X |
| 07:09:04 | mmatten | with linux ? |
| 07:09:13 | prpplague | mmatten: yea |
| 07:09:20 | prpplague | mmatten: ogle |
| 07:09:24 | prpplague | mmatten: it rocks |
| 07:09:48 | mmatten | nice, haven't tried that yet with my linux box |
| 07:10:14 | Russ | I just tested major domo for these outlook monkies |
| 07:10:20 | mmatten | (got a tv out card in there so it's worth a try anyway, but that one needs to run fine before that as well) |
| 07:11:11 | mmatten | prpplague: btw we'll be comin up with some numbers for the cpu board soon, maybe even today |
| 07:14:27 | prpplague | Russ: outlook user problems? |
| 07:18:52 | prpplague | Russ: thanks again for the help |
| 07:18:58 | prpplague | heads to bed |
| 07:19:19 | prpplague | mmatten: see ya in a few hours |
| 07:19:24 | mmatten | yeah :) |
| 08:03:10 | mmatten | hehe |
| 12:11:40 | seletz | moin |
| 13:41:49 | Fare | Gakuk! |
| 13:41:56 | Fare | any bootmem.c expert around? |
| 14:32:21 | seletz | prpplague: hi |
| 14:34:05 | seletz | Fare: ported linux to your OpenBoot forth already, have you? |
| 14:34:11 | seletz | lol |
| 14:34:28 | seletz | (just kidding :) |
| 14:35:22 | prpplague | morning/evening |
| 14:36:06 | Fare | seletz: no |
| 14:36:14 | Fare | I' trying to figure out how to use bootmem |
| 14:36:27 | seletz | Fare: whats the prob? |
| 14:36:39 | Fare | or otherwise convince Linux to NOT allocate the zone where something is happening |
| 14:37:12 | seletz | you want to tweak ATAG_MEM settings |
| 14:37:20 | seletz | checking out |
| 14:37:22 | Fare | do I? |
| 14:37:28 | Fare | how should I? |
| 14:37:40 | seletz | hmm. some infos i have: |
| 14:37:47 | Fare | also, how do I define a default command line? |
| 14:37:56 | Fare | especially since I have no parameter block |
| 14:37:57 | seletz | BLOB detects the amount of memory available and reports that |
| 14:38:05 | seletz | via the ATAG chain to the kernel |
| 14:38:15 | Fare | I suppose I should use that |
| 14:38:51 | seletz | so, for ex, i have 2 boards: one 16 mb cs0, 16 mb cs2. another: 32 mb cs0/1 |
| 14:39:07 | seletz | BLOB detects the amount of memory automaticvally (ant the regions) |
| 14:39:25 | seletz | and generates ATAG_MEM infos for the kernel |
| 14:39:46 | Fare | seletz: what about the prefix regions (typically 0xc0000000-0xc0008000) ? |
| 14:39:56 | seletz | Fare: i guess you want to exclude your DMA'd address from the usable mem range? |
| 14:41:15 | Fare | ditto |
| 14:41:24 | seletz | Fare: or is it just that you want to move the kernel image beyond the addr. |
| 14:42:03 | seletz | Fare: for the first one: i'd try to split the mem region. or leave out the lower memory part. |
| 14:42:22 | Fare | seletz: If I move the kernel, is it guaranteed that it won't use the memory below? |
| 14:42:41 | seletz | Fare: if you lie to the kernel, yes. |
| 14:43:16 | seletz | Fare: blob to kernel: no, i dont have memory below c0010000... |
| 14:43:23 | seletz | perhaps |
| 14:43:25 | Fare | seletz: you mean, my only reporting to the kernel the memory after it? |
| 14:43:43 | seletz | yup, thats my idea |
| 14:44:09 | seletz | Fare: OTOH that would mean you loose the memory below |
| 14:44:38 | Fare | well, I could reuse it as a fix-allocated buffer |
| 14:44:44 | seletz | Fare: the other apporach is IMHO: move the kernel up, adjkust the makefiles for that and hope that the kernel |
| 14:44:47 | Fare | if only I can convince the kernel to map it, that is |
| 14:45:01 | seletz | Fare: inits DMA such that your timer DMA is gone ... |
| 14:45:13 | Fare | it's not done by the on-chip DMA |
| 14:45:22 | seletz | Fare: i had a similar problem with my firs board |
| 14:45:29 | Fare | and I have no documentation about who does it and how to configure it |
| 14:45:41 | seletz | Fare: there i had at CS0 16 mb and at CS2. CS1 was empty |
| 14:45:44 | Fare | I've configured the DMA controller, to no avail. |
| 14:46:02 | seletz | Fare: but BLOB reported 23MB from C0000000 up. |
| 14:46:11 | seletz | erm, 32 |
| 14:46:44 | seletz | Fare, si i had to exclude the CS1 range and to include the CS2 range. All i did was to supply the |
| 14:46:54 | seletz | Fare: correct ATAG chain and bingo |
| 14:47:08 | seletz | Fare: maybe your problem may be solved similar. |
| 14:47:49 | seletz | Fare: took the sa11x0 dma code from the kernel? |
| 14:47:57 | seletz | Fare: and did that in BLOB? |
| 14:49:04 | seletz | Fare: hmmm, ok, i see, yur situation is a little different. Youre in a special run mode after hcboot, aren't you? |
| 14:49:22 | Fare | no, I RTFMed the SA1100 docs and disabled DMA |
| 14:49:36 | seletz | ok |
| 14:49:37 | seletz | hmm |
| 14:49:49 | Fare | there were two active DMA channels around there (but not at this precise place), and the write channel had buffers of length 0 |
| 14:49:53 | Fare | I still disabled them. |
| 14:49:55 | seletz | Fare: there are _LOTS_ of spec updates though. |
| 14:50:36 | seletz | Fare: maybe you should look into the kernel source what they do ... |
| 14:51:14 | seletz | Fare: for my sa1111 code in blob i did exactly that. And PCMCIA ditto. |
| 14:54:17 | Fare | the kernel seems to suppose the dma channels are off by default |
| 14:54:53 | seletz | Fare: there is no code that switches from DMAON->OFF? |
| 14:56:46 | Fare | no |
| 14:56:50 | Fare | not in the init |
| 14:57:03 | seletz | no i mean in exit |
| 14:57:06 | seletz | for ex |
| 14:57:11 | Fare | only code to stop an already initialized channel |
| 14:57:14 | seletz | or a shutdown function |
| 14:57:18 | Fare | oh, I know how to stop the channels |
| 14:57:27 | Fare | it's just that the timer is NOT one of them. |
| 14:57:35 | seletz | hmm |
| 14:57:54 | Fare | I have no friggin' idea where that timer is coming from |
| 14:58:00 | seletz | are you absolutely sure that what you see is real |
| 14:58:04 | seletz | i mean |
| 14:58:26 | Fare | probably another chip in the system, that they considered would be better doing DMA that using port (!) |
| 14:58:33 | seletz | is there a chance the addr you see is not real, i.e. a mirrored mem region (because there's no real |
| 14:58:38 | seletz | memory there)= |
| 14:59:02 | Fare | seletz: am I sure that when I peek at that location, I get a new counter every time, at the macroscopic rate of about 1000/s |
| 14:59:04 | seletz | know what i mean? |
| 14:59:05 | Fare | yes |
| 14:59:30 | Fare | I doubt they would introduce logic to unmap memory from 0xc005c080 and map I/O there instead |
| 14:59:42 | Fare | it would have been MUCH simpler to map I/O at a different place |
| 15:00:01 | seletz | not intentionally mapped for example |
| 15:00:12 | Fare | uh? |
| 15:00:22 | seletz | maybe there is no memory at that location (phys. addr) |
| 15:00:27 | Fare | yes there is |
| 15:00:40 | seletz | and you see a mirrored memory range |
| 15:00:46 | Fare | it's right in the middle of the RAM |
| 15:01:02 | Fare | 0xc0000000 is the normal RAM location for the SA-1100 |
| 15:01:12 | seletz | have you a chance of measuring CS0? |
| 15:01:48 | Fare | uh? |
| 15:02:00 | seletz | Fare: ChipSelect 0 line |
| 15:02:01 | Fare | there is RAM, believe me |
| 15:02:07 | seletz | :) |
| 15:02:11 | seletz | ok |
| 15:02:13 | Fare | blob agrees, wince agrees, everyone agrees |
| 15:02:20 | Fare | the sa1100 docs agree |
| 15:02:34 | seletz | got the row adress coloumn address lines right? |
| 15:02:48 | seletz | MD* registers |
| 15:03:08 | Fare | why would they be wrong JUST for c005c080 ? |
| 15:03:22 | seletz | hmm |
| 15:03:23 | Fare | no, its really some DMA going on |
| 15:03:38 | Fare | just not sa1100 standard DMA |
| 15:04:25 | seletz | weird, that is |
| 15:05:56 | Fare | I'm the first one amazed |
| 15:05:56 | seletz | Fare: how much ram does blob reports? |
| 15:06:07 | Fare | understanding that DMA was taking place took *days* |
| 15:06:26 | Fare | once I emitted the hypothesis, however, md5 quickly found me where it took place |
| 15:06:35 | Fare | 16MB just like it should be |
| 15:07:48 | seletz | Fare: why dont you just try to move up 1MB and forget about the lower 1MB |
| 15:08:41 | seletz | look at src/blob/linux.c |
| 15:08:53 | seletz | setup_memory_tags() |
| 15:09:19 | seletz | try to adjust u.mem.start/size |
| 15:10:19 | seletz | Fare: you'll probably have to adjust your kernel Makefile to get that going, so that the adresses are computed right. |
| 15:10:28 | seletz | Fare: what do you mean? |
| 15:11:59 | seletz | Fare: oh, and of course you have to adjust the address you load the kernel to in blob .... |
| 15:12:03 | Fare | ? |
| 15:12:31 | seletz | Fare: does that sound reasonable to you? |
| 15:15:37 | Fare | memory.c is not designed for it |
| 15:15:41 | Fare | nothing is designed for it. |
| 15:15:44 | Fare | grrr |
| 15:16:10 | Fare | I'll hack something else, get some sleep, read some docs, wait for a possible hint on LAK, and decide the way to go |
| 15:16:33 | seletz | wait, whats the problem? |
| 15:17:00 | seletz | forget memory.c |
| 15:17:12 | seletz | just hack it for a quick test |
| 15:18:01 | seletz | set the tags by yourself, you do know the range you have, dont you? its c0000000+1MB-c1000000 |
| 15:18:17 | Fare | seletz: I suppose so. |
| 15:18:23 | Fare | thanks for the tip |
| 15:19:28 | seletz | when it works that way, then think about splitting the range you get from memory.c into 2 ranges, leaving page 92 out (your weird addr is at page 92 of 406 byte pages). |
| 15:19:35 | seletz | erm |
| 15:19:40 | seletz | 4096 bytes |
| 15:20:25 | seletz | the linux kernel will then just dont use the page you left out. |
| 15:21:43 | Fare | yup |
| 15:21:58 | Fare | I'll add an #ifdef JORNADA820 at the end of memory.c |
| 15:23:32 | seletz | hmmm, ok. Dont forget to adjust your kernel load address in your header file. |
| 15:25:25 | Fare | yes I did, thanks :) |
| 15:25:49 | Fare | actually, it's by playing with it that I understood that DMA was taking place under my feet |
| 15:26:06 | Fare | by loading at some addresses, I would crash later than at other addresses |
| 15:42:51 | seletz | prpplague: btw, i now have some details from my manufactorer. I'll have to talk back to him about some flash issues. At OLS we'll have to discuss some details then. What i already have looks promising. |
| 15:43:20 | seletz | prpplague: when will you arrive at OLS? |
| 15:44:12 | sammy_wms | hello all |
| 15:44:21 | seletz | sammy_wms: hi |
| 15:45:19 | sammy_wms | seletz: I am fix most of all problem about rootfs ... |
| 15:45:30 | sammy_wms | but still have some little problem :( |
| 15:45:41 | sammy_wms | will go on fix tomorrow ... |
| 15:49:41 | prpplague | seletz: i'll be arriving on the 25th around 5:15pm |
| 15:50:17 | seletz | prpplague: we'll be probably there a bit late :( |
| 15:50:34 | seletz | prpplague: 8:00 pm i think |
| 15:50:50 | prpplague | seletz: i'll already had 5 or 6 pints by then |
| 15:51:04 | seletz | prpplague: by then i'll definitely need a beer. |
| 15:51:17 | seletz | prpplague: grr |
| 20:57:40 | FareAway | hum |
| 21:34:35 | Russ|werk | hmm... |
| 21:34:37 | Russ|werk | RE: topic |
| 21:35:00 | Russ|werk | I meant the "please remome me" emails, not ibot |
| 21:37:37 | Russ|werk | who was looking for a sa11x0 source? |
| 22:17:39 | Russ|werk | seletz_: were you looking for an sa1100 source? |
| 22:31:11 | Fare | Error: Z |
| 22:31:17 | Fare | there's much progress! |
| 22:54:12 | Fare | which terminal program do you use? |
| 23:12:54 | Russ|werk | minicom |