00:02:52 | Fare | updated his jornada820 patch |
01:08:20 | prpplague | BZFlag: howdy |
01:08:40 | prpplague | BZFlag: gonna make it for all of OLS? |
01:15:33 | BZFlag | yep I get in tuesday at 4:35 and head out... hmm sunday I think. |
01:16:24 | prpplague | BZFlag: same here, i get in around 5:15pm |
01:16:38 | BZFlag | sweet. I'm in the westin |
01:16:44 | BZFlag | back later |
01:17:06 | prpplague | BZFlag: i'm staying the "les suites" , erikm is using the extra room |
01:17:08 | prpplague | later |
02:13:36 | Fare | anyone here? |
02:13:56 | prpplague | no |
02:14:48 | Fare | hum. So I get into the kernel, but once it goes past head-armv.S, I get no output whatsoever |
02:15:45 | prpplague | sounds like a personal problem |
02:15:47 | prpplague | lol |
02:16:09 | prpplague | Fare: not using any leds for debugging? |
02:16:40 | Fare | within linux? |
02:16:44 | Fare | no, not yet |
02:17:03 | Russ|werk | Fare: what is neccessary to flash the lights |
02:17:08 | prpplague | Fare: blob has the ability to blink leads based on different errors |
02:17:08 | Fare | I suppose I could output to wherever I know the framebuffer happens to be |
02:17:49 | Fare | but I don't know how to both map it at the right place and avoid the kernel from putting it up for grabs |
02:17:57 | Fare | no blob works |
02:18:03 | Fare | I'm now in the kernel |
02:18:09 | Fare | and there are no leds on this machine |
02:18:12 | prpplague | ohh your talking about the kernel code? |
02:18:18 | Fare | yup |
02:18:42 | Fare | blob now runs fine |
02:19:24 | prpplague | Fare: ahh, let me get a url for ya |
02:19:41 | Fare | thanks a lot |
02:20:37 | Fare | also, I know the value of the LCD register. How do I compute a pixel clock back from it? |
02:31:26 | Russ|werk | heh |
02:31:39 | Russ|werk | nm |
02:31:59 | Sammy | nm ? |
02:33:10 | Russ|werk | nevermind |
02:33:39 | Sammy | .^______________^. |
02:39:03 | prpplague | Fare: hang on, my web server is giving me issues right now |
02:43:27 | prpplague | Fare: we just upgraded last night due to the apache problem, but i can't seem to get my pages |
02:45:07 | prpplague | Fare: http://www.abcsinc.com/small-linux/printascii.txt |
02:45:53 | prpplague | Fare: that should help ya |
03:11:32 | BZFlag | prpplague: sweet (er suite?) We'll party at your place. ;-) |
03:12:18 | prpplague | BZFlag: lol |
03:12:35 | prpplague | BZFlag: i hope the partying goes on at some cool english style pubs |
03:32:59 | BZFlag | does not drink so he hopes it by computers. ;-) |
03:33:11 | BZFlag | er it's |
03:35:47 | prpplague | BZFlag: lol, thats ok, nothing like beer ladened laptops |
03:42:37 | prpplague | BZFlag: i'm hope to get all of the arm gurus together for dinner/bof |
04:02:26 | BZFlag | I'm interested. |
04:05:27 | prpplague | BZFlag: we make a ton of money off open source, least i can do is buy some of these guys a beers, lol |
04:12:21 | BZFlag | "a ton of money" that must be nice. |
04:17:48 | prpplague | BZFlag: well i know you guys have been a little "lean" lately, but things will work out |
04:18:41 | prpplague | BZFlag: when we went from $8800 per customer costs with sco, down to $200 with linux, profits went through the roof |
04:20:14 | prpplague | BZFlag: when we used to use third party terminals, our tech support center was taking 750-1000 calls a day, with custom thin clients running linux, we now get around 30-50 per day |
04:23:12 | prpplague | BZFlag: we used to use cisco routers for vpn stuff, now we use snapgear(arn't you guys part of the same group?) and have cut our install times down to 1/10 and virtual no support issues |
04:25:45 | BZFlag | sweet. good to hear it's all working for you. nice. |
04:26:04 | BZFlag | snapgear and lineo went our separate ways a few months back. |
04:28:51 | prpplague | BZFlag: well, i'm sure if your new pda with fold out keyboard gets to market, we'll be buying them |
04:31:15 | BZFlag | heh, I'm hoping. ;-) you pick up a Z yet? |
04:32:02 | BZFlag | the builtin keyboard on the Z is actually useful. I use it all the time now. |
04:32:24 | prpplague | not yet, i'm currently playing with a couple of korean prototypes |
04:32:42 | prpplague | the camion from CIIT and the mizi pda sdk |
04:33:00 | prpplague | i sent one of the camions to Russ to port blob to |
04:33:55 | BZFlag | what do you think if the mizi? that's Qt/e as well yes? |
04:34:21 | BZFlag | s/if/of/ |
04:34:27 | prpplague | ya qt/e |
04:34:53 | prpplague | the interface is done well, but the documentation and support on the opensource side is terrible |
04:35:18 | prpplague | i'd never use mizi if i had an important project that was on a time schedule |
04:38:16 | BZFlag | is mizi based on qtopia? ie: is there a libqpe included? |
04:39:34 | prpplague | no i don't believe it is qtopia based |
04:39:44 | prpplague | is not big into qt |
04:40:12 | prpplague | BZFlag: i'm more into X with small widget gui's like fltk |
04:41:18 | | I haven't seen 'the', BZFlag |
04:41:18 | BZFlag | prpplague: seen the yopy interface? it's just tinyx with icewm. it's pretty cool. |
04:41:57 | BZFlag | I'll bring a yopy or two with me to OLS. you planning to bring the mizi and the camion? |
04:42:06 | BZFlag | bring serial cables too if you have them. |
04:42:06 | prpplague | BZFlag: lol, ya i was one of the ppl that worked on that and helped gmate decide to move from w-windows to x |
04:42:40 | BZFlag | I did the initial jffs2 conversion for gmate. |
04:43:49 | prpplague | BZFlag: really? cool |
04:44:12 | prpplague | BZFlag: http://www.abcsinc.com/yopy/ |
04:44:26 | prpplague | BZFlag: sure i'll bring the camion |
04:44:55 | prpplague | BZFlag: i'll have to re-assemble it, i've been having a look at there fabrication techniques |
04:45:05 | BZFlag | http://yopy.org/ <- ok, I don't have anything there yet. ;-) |
04:45:34 | prpplague | BZFlag: but the mizi is spoken for on some tests |
04:45:36 | prpplague | BZFlag: lol |
04:46:04 | BZFlag | surely they can spare the mizi for a week, no? |
04:46:35 | prpplague | BZFlag: well........, its currently doing a field test for two week in barbados |
04:46:50 | BZFlag | ah |
04:47:21 | prpplague | we do inventory control for shipping and customs for almost all of the caribean and bahamas |
04:49:27 | prpplague | BZFlag: are you guys strickly embedded processors or do you do any x86 stuff anymore? |
04:50:45 | prpplague | BZFlag: btw, small-linux.com is mine, but i never can seem to find time to get it running |
04:53:05 | BZFlag | we do all kinds. we do a lot of x86 on settops and routers etc. |
04:53:17 | BZFlag | yeah I have elinux.org too |
04:56:40 | BZFlag | anyone know if wookie is headed to ols? |
04:58:06 | prpplague | BZFlag: not for sure, but seems _rmk_ said something about him attending |
04:59:25 | BZFlag | cool. /me wants to resurrect emdebian |
05:00:18 | prpplague | BZFlag: this was my baby before i switched to learning arm - http://www.linuxdevices.com/products/PD4854992533.html |
05:01:06 | BZFlag | prpplague: yep seen it. cool. |
05:01:44 | BZFlag | woohoo, welcome to irc.opensplits.net |
05:03:14 | prpplague | BZFlag: ya, well, as it was my first design had a few problems, processor ran too hot, so problems with ct chipset, don't get me wrong, it worked well, but sure realized the short falls of x86 |
05:03:23 | prpplague | s/so/some |
05:04:20 | BZFlag | I hear that. |
06:14:43 | Russ | hehe |
06:51:04 | | que tal, mmatten |
06:51:04 | mmatten | hi |
08:51:43 | Sammy | what's this strange problem hang ? |
08:51:44 | Sammy | ExecutiKernel panic: Attempted to kill init! |
08:51:45 | Sammy | g /linuxrc.... |
08:51:46 | Sammy | PATH=/bin:/sbin: bad identifier |
08:52:43 | Sammy | anyone know's ? |
08:53:11 | seletz_ | moin |
08:53:30 | Sammy | hi seletz |
08:54:10 | Sammy | seletz: do you have any suggest ? |
08:57:07 | seletz | Sammy: the path env var? |
08:57:22 | seletz | Sammy: hmm |
08:57:50 | seletz | Sammy: we have had the same problem when we tried to move over to newer libc versions. |
08:58:20 | seletz | Sammy: dont know how to solve it, we stick ATM with old libc versions :( |
08:58:43 | Sammy | :( |
09:14:04 | Fare | prpplague: that was exactly what I needed! Thanks a lot! |
09:14:33 | seletz | Fare: so your jornada boots? |
09:14:44 | Fare | well, it goes as far as head-armv.S |
09:14:55 | Fare | then it dies before a console is registered |
09:15:03 | seletz | Fare: what did the trick? |
09:15:08 | Fare | nothing yet |
09:15:28 | Fare | but prpplague pointed me to http://www.abcsinc.com/small-linux/printascii.txt |
09:15:37 | Fare | which I think should do the trick |
09:15:49 | seletz | ah, the printk() hack? |
09:15:53 | Fare | yup |
09:16:19 | seletz | helped me a lot too ;) |
09:16:37 | seletz | tried splitting the mem range? |
09:16:44 | Fare | I was desperately trying to figure out how to register a serial console early, then realized it wouldn't work because you need a different driver before and after interrupts are enabled. |
09:17:02 | seletz | hmm |
09:17:11 | Fare | seletz: yes I did, but whatever gives, linux dies before the console is enabled. |
09:17:18 | seletz | ok |
09:17:38 | Fare | currently, I called __error just before the end of head-armv.S and it worked |
09:17:49 | seletz | how far does it get, then? |
09:17:56 | Fare | no idea |
09:18:12 | Fare | it calls start_kernel, but never registers a console. |
09:18:31 | Fare | with the printk hack I hope to identify problems more closely. |
09:18:39 | seletz | you have blob running, dont you? |
09:19:02 | seletz | hmm, so you actually havent tried the printk hack yet? |
09:19:24 | Fare | no, I'm just up from bed, and saw what prpplague told me in the logs. |
09:19:47 | Fare | (he was telling me he'd give me a url, but I fell asleep) |
09:19:50 | seletz | Fare: where are you, if you dont mind asking? |
09:22:18 | Fare | Paris, France. |
09:22:41 | Fare | same time zone as you |
09:26:04 | Fare | what do you use to reduce the time spent in kernel diff? |
09:26:16 | Fare | what's this dontdiff thing? |
09:31:13 | Fare | btw, I updated my patch |
09:31:21 | Fare | it's cleaner |
09:31:28 | Fare | touches less files |
09:32:22 | Fare | introduces less #ifdef JORNADA820 |
09:32:52 | Fare | and has a different file name on the patch server, too :) |
09:35:00 | Fare | ok, found diff -X |
09:41:38 | mmatten | x |
09:41:41 | mmatten | X |
09:41:47 | mmatten | ack wrong window |
11:51:18 | Fare | Linux version 2.4.18-rmk5-frr2 (fare@ZhengHe) (gcc version 2.95.2 20000313 (Debian GNU/Linux)) #51 Fri Jun 21 13:48:44 CEST 2002 // Processor: Intel StrongARM-1100 revision 9 // Architecture: HP Jornada 820 // <2>kernel BUG at bootmem.c:125! |
11:51:21 | Fare | yay! |
11:52:54 | Fare | hum. What's PAGE_SIZE on these machines? |
11:54:41 | seletz | 4k |
11:54:54 | seletz | coooool |
11:56:18 | seletz | Fare: i hope you split on page size? |
11:56:27 | Fare | yes |
11:56:39 | Fare | but maybe I did something wrong in the doing |
11:56:46 | Fare | it's not like I double checked the code. |
11:57:31 | Fare | if (!test_and_clear_bit(i, bdata->node_bootmem_map)) BUG(); |
11:57:39 | seletz | hmm |
11:57:39 | Fare | hum, what does that mean? |
12:00:58 | seletz | checking out |
12:01:03 | seletz | on moment |
12:02:06 | Fare | checks bootmem section on lkdp.tk |
12:02:18 | seletz | Fare: are you _sure_ you round up to 4k? |
12:02:30 | seletz | Fare: and got the start addr right? |
12:02:46 | seletz | Fare: what addr did you specify? |
12:03:39 | Fare | oops, my blob/memory.c patch was really fux0red |
12:03:45 | Fare | is ashamed |
12:04:29 | seletz | Fare: just change src/blob/linux.c and specify start=0xc0100000, len=15MB |
12:04:43 | seletz | Fare: just for a test, that is |
12:05:48 | seletz | Fare: ok? |
12:06:36 | Fare | ok |
12:06:54 | Fare | well, first, I'll try to put my head completely out of my ass |
12:07:11 | Fare | if it doesn't work, I'll try what you say |
12:08:21 | seletz | lol |
12:16:37 | Fare | hum. Still the same. |
12:17:54 | Fare | grrr |
12:19:33 | seletz | Fare: you did recompile your kernel, did you? To match its new starting addr, that is. |
12:20:48 | Fare | hum, actually I still load the kernel 0xc0068000 and use 0xc0060000 len=0x00fa0000 |
12:22:50 | seletz | hmm, sounds right. |
12:23:09 | seletz | Fare: do you see the zone allocations? |
12:23:16 | seletz | Fare: at kernel boot, that is |
12:23:21 | seletz | erm, startup |
12:24:16 | Fare | I see nothing more than I pasted |
12:24:46 | seletz | ugh |
12:24:59 | seletz | Fare: actually, i think its LAK time :) |
12:25:12 | seletz | Fare: (i mean ask tha list, man!) |
12:28:07 | seletz | Fare: it may well be that i gave you a _completely_ wrong direction, so i think it's better to ask the list. The're much more competent there. |
12:28:41 | Fare | you've been very helpful |
12:48:02 | Fare | puts printk statements in bootmem.c and retries... |
12:59:17 | Fare | ouch, at first look, it seems that linux BOTH detects 16MB of RAM by itself and then uses the blob memory ma |
12:59:18 | Fare | p |
12:59:22 | Fare | or something similar |
13:01:39 | Fare | yup that's it |
13:02:24 | Fare | help! |
13:03:52 | seletz | Fare: hmm, look at your board code arch/arm/mach-sa1100/jornada.c or similar |
13:04:09 | seletz | Fare: ther watch out to _not_ report memory by yourself, but |
13:04:21 | seletz | Fare: instead trust the ATAG_MEM tag. |
13:04:27 | seletz | Fare: got me? |
13:04:47 | Fare | yup |
13:04:49 | Fare | looking... |
13:04:57 | seletz | the call is ... |
13:05:44 | Fare | damn I feel stupid, at times. |
13:06:11 | Fare | Indeed, I had copied it from jornada720.c, that does not use blob but initializes its stuff by itself. |
13:06:13 | seletz | Fare: what template did you take? Lart? assabet? |
13:06:29 | Fare | I used jornada720 as a template. Maybe I was wrong. |
13:06:46 | seletz | one moment, im looking |
13:07:11 | seletz | line 62: SET_BANK( 0, 0xc0000000, 32*1024*1024 ); |
13:08:03 | Fare | yup, I'm removing that |
13:08:14 | Fare | there's also a BOOTMEM() line. Shall I keep it? |
13:08:17 | seletz | Fare: either remove it, or hack it. :) |
13:08:42 | seletz | one momen |
13:09:40 | seletz | Fare: i'd hack it to BOOT_MEM( 0xc0060000, .... ) |
13:09:53 | seletz | Fare: have corrected the BOOT_PARAMS() too? |
13:11:04 | Fare | I don't need correct it, do I? |
13:11:26 | Fare | I mean, 0xc0000100 looks correct to me |
13:11:38 | seletz | hmm. |
13:11:38 | Fare | and if it did try to map the blob-given map, then it works |
13:11:51 | Fare | I don't have flash |
13:11:59 | Fare | do I need a map_io() function? |
13:12:52 | seletz | Fare: hmm, yust comment it out, but leave in the maps. opne never knows |
13:13:48 | seletz | Fare: as for boot params: i dont know how the kernel will react, because you tell him: hey, i have memory from A-B, and pootparams are not in that range. |
13:14:23 | seletz | Fare: i'd change it to 0xc0060100. |
13:14:33 | seletz | (and change blob too.) |
13:14:41 | Fare | that's ok, I'll map 0xc0000000 to 0xc005c000 :) |
13:14:42 | seletz | but hey, give it a try without .... |
13:15:15 | Fare | map_io worries me a bit |
13:15:19 | Fare | the register_uart, too |
13:15:32 | seletz | Fare: btw, is there a chance that you know about keyboards, console devices etc? |
13:15:42 | seletz | Fare: why? |
13:15:59 | Fare | I know zilch about the keyboard, etc. |
13:16:19 | Fare | I mean, oleg gushev has opened his box and collected datasheets for the parts, but that's all I know |
13:17:13 | seletz | Fare: nah, not related to your jornada project. I thought you could help me with my little prob here... |
13:17:18 | Fare | so I know the keyboard controlled is a spicoder sa01 ur5hcspi-sa01 |
13:17:27 | Fare | seletz: sure |
13:17:34 | Fare | if you think I can be helpful |
13:18:28 | seletz | Fare: well, all i want is to _write_ to the keyboard controller. So i'd like to use some generic interface for that (i.e. like open( "/dev/kbd", ..) ioctl() ). |
13:18:44 | seletz | Fare: but i cant find anything... |
13:24:23 | Fare | maybe because there *isn't* anything. |
13:27:12 | seletz | Fare: thats what i fear |
13:35:30 | Fare | on the PC, such a device was specifically not made |
13:35:57 | Fare | because the same register was used to control many different things including the A20 line, and linus does NOT want any user, even root, to control that |
13:36:25 | Fare | and he didn't care to include a mux to just send commands |
13:37:00 | seletz | argh |
13:37:19 | Fare | there is progress: |
13:37:22 | seletz | ok, i see. I'll end up with copying sa1111_keyboard.c |
13:37:27 | Fare | now it dies right AFTER bootmem.c |
13:37:32 | seletz | lol |
13:37:38 | Fare | but no message whatsoever. |
13:38:01 | seletz | you should _really_ ask at the LOK list. |
13:38:12 | seletz | things sound quite odd. |
13:38:23 | seletz | s/LOK/LAK/ |
13:40:07 | Fare | nah |
13:40:25 | Fare | maybe I get no more message because linux does initialize the serial line at a different speed? |
13:40:44 | seletz | grep SPEED .config |
13:40:56 | seletz | i.e. its a config option. |
13:41:34 | seletz | but IMHO you would see some garbled output in that case. |
13:47:52 | Fare | there is no SPEED in .config |
13:48:27 | seletz | CONFIG_SA1100_DEFAULT_BAUDRATE |
13:48:29 | seletz | sorry |
13:49:18 | seletz | add printk's in your fixup and init routines |
13:51:14 | seletz | and in main() |
13:55:07 | Fare | which main() ? |
13:55:15 | seletz | kernel main |
13:55:17 | Fare | the baudrate is correct (115200) |
13:56:44 | Fare | well, init/main.c has two printk's around setup_arch, and I only see the first |
13:56:49 | Fare | so let's recurse :) |
13:57:12 | Fare | see what I told you about the edit-compile-crash cycle of C as compared to FORTH? |
13:58:05 | seletz | Fare: so add printk to your fixup routines. |
13:58:17 | seletz | Fare: and yes, i see your point. |
13:59:26 | seletz | Fare: This will somewhat go away when we have a kernel debugger. Some folks even use gdb via serial line to debug the kernel (no, i'm not doing so). |
14:03:11 | Fare | that still won't help with initial porting, will it? |
14:08:10 | Fare | ok. I dies in init_paging |
14:08:28 | Fare | I mean, paging_init() |
14:13:16 | seletz | urg. |
14:13:23 | seletz | bad karma. |
14:14:01 | seletz | ok, i'd fill up paging_init() with prink's and try again. |
14:14:03 | seletz | looking |
14:15:35 | seletz | hmmm |
14:15:39 | seletz | mdesc->map_io() |
14:16:07 | Fare | paging_init: memtable_init |
14:16:14 | Fare | there you go |
14:16:19 | Fare | recurse once more |
14:17:06 | Fare | or maybe the mdesc->map_io() |
14:17:15 | Fare | darn. I didn't put enough of those printk's |
14:17:35 | seletz | fill it up. saves time. put _many_ printks in. |
14:18:02 | seletz | especially in your fixup code arch/arm*/*/jornada8*.c |
14:18:10 | Fare | I removed the fixup code |
14:18:31 | seletz | the map_io is still in, is it |
14:19:09 | seletz | have you left in the init routine? |
14:19:17 | seletz | joprnada720_init() |
14:19:47 | Fare | yup |
14:19:50 | Fare | it doesn't print |
14:20:04 | Fare | what's desc->mapio() ? |
14:20:15 | seletz | ok. Beware though, there they do some GPIO stuff. |
14:20:37 | seletz | i guess it comes from jornada*_map_io():iotable_init(jornada720_io_desc); |
14:21:00 | seletz | have a sa1111? |
14:21:04 | Fare | no. |
14:21:07 | Fare | A SA1101 |
14:21:20 | Fare | SA1100 + SA1101 |
14:21:38 | seletz | ok. what mem range does the SA1101 use? |
14:21:47 | Fare | I have no idea |
14:22:00 | Fare | should I put it around here |
14:22:12 | Fare | if it's the jornada*map_io, then it doesn't get called |
14:22:13 | seletz | ok, comment the SA1111, flash and epson fb regions out |
14:22:22 | Fare | I removed them indeed |
14:22:33 | Fare | here's my map io w/o printk: |
14:22:44 | Fare | sa1100_map_io(); |
14:22:57 | Fare | iotable_init(jornada820_io_desc); (but the desc is empty) |
14:23:09 | Fare | sa1100_register_uart(0, 3); |
14:23:17 | Fare | sa1100_register_uart(1, 1); |
14:23:17 | seletz | Fare: you left in the LAST_DESC? |
14:23:20 | Fare | yup |
14:23:32 | Fare | but the printk before each line doesn't show |
14:23:53 | seletz | not one printk from thios func shows up?? |
14:24:01 | Fare | so it must be wrong in memtable_init |
14:25:00 | seletz | Fare: debug the mi ptr, the page_nr and the pte |
14:25:15 | | that is the point you dumb idiot |
14:25:15 | Fare | what's that? |
14:26:16 | | Sorry, seletz, I'll keep my mouth shut. |
14:26:16 | seletz | ibot: shut up |
14:26:27 | | Sorry, Fare, I'll keep my mouth shut. |
14:26:27 | Fare | ibot: shut up |
14:26:40 | seletz | Fare: vars in memtable_init() |
14:26:43 | Fare | ok |
14:26:48 | seletz | i feear its the alloc call. |
14:27:30 | Fare | in FORTH or LISP, it's easy to turn on a trace mode so that all the calls you want are traced. |
14:27:37 | seletz | Fare: but i really have no deep inight into those routines at all, so beware. |
14:27:39 | Fare | without your having to add printk's everywhere |
14:28:03 | seletz | Fare: the're interpreted languages, aren't they? |
14:28:43 | seletz | askins something on kernelnewbies |
14:32:50 | seletz | ugh |
14:33:03 | seletz | man, its sooo hot in here... |
14:33:25 | seletz | is dehydrated |
14:33:48 | Fare | seletz: there are C interpreters, too |
14:33:54 | Fare | and forth and lisp compilers |
14:34:06 | Fare | they are *dynamic*, *interactive* languages |
14:34:15 | Fare | that doesn't mean they are not compiled |
14:35:28 | seletz | yup. once you interactively compile things you can add generic debug code, like in "sh -x script". |
14:36:18 | Fare | recursive debugging: it dies while clearing some entries |
14:36:32 | Fare | yup |
14:36:34 | seletz | Fare: link all my (userspace) progs against a libdebug.a, then i can switch on/off _dynamically_ at _runtime_ trace logs. Nicely indented, with function names, vars etc. |
14:37:01 | Fare | how does it instrument code? |
14:37:11 | seletz | Fare: i have to use some macros, though. That saved a hell lot of time. |
14:37:15 | Fare | you cannot do that just by linking |
14:37:22 | seletz | macros |
14:37:30 | Fare | sure, but you cannot add it like that to an existing program. |
14:37:35 | seletz | no |
14:37:44 | seletz | thats right |
14:37:56 | seletz | thats what strace is for |
14:38:02 | Fare | whereas with lisp or forth macros, you can |
14:38:08 | Fare | strace is only for system calls |
14:38:15 | Fare | ltrace does library calls for you |
14:38:30 | Fare | still |
14:38:45 | seletz | agreed. Btw, you run in open doors .... |
14:39:34 | Fare | the doors are open, but no one seems to care |
14:39:46 | Fare | anyway, I'm through with it for now |
14:39:50 | seletz | I definitely see your arguments. THats why i get used to the following model: 1) program little C core utilities and 2) wrap them with scrips |
14:39:52 | Fare | got other things to do |
14:39:54 | seletz | or |
14:40:31 | seletz | 3) write a big C program with _lots_ of script calling functions (pre/post style scripts). That way you can |
14:40:44 | seletz | tweak things w/o recompiling the core. |
14:41:14 | seletz | anyway, that does'nt help with existing plain C code. |
14:42:33 | seletz | maybe if one tweaked gcc to somehow insert a generic function call on enter/exit of all compiled functions, then you'd come a little closer to what you want. |
14:42:56 | seletz | but that would be a ugly hack at most. sigh. |
14:43:38 | seletz | Fare, ok, so long. I'm off. Sorry i could'nt help more, though. |
14:45:32 | seletz_leaving | see ya |
14:55:34 | Fare | (thanks for all) |
15:40:44 | prpplague | morning all |
15:40:59 | prpplague | Fare: that page on printascii help ya? |
15:42:02 | Fare | very much |
15:42:04 | Fare | thanks a LOT |
15:42:18 | prpplague | Fare: great |
15:42:21 | Fare | now I know better where the kernel dies |
15:42:25 | Fare | unhappily it is very soon |
15:42:31 | Fare | or maybe not |
15:42:42 | prpplague | Fare: i try to document as many things as i can |
15:42:45 | Fare | i.e. maybe printascii also helps it die sooner |
15:43:00 | Fare | prp: this bit was great - just what I was looking for |
15:43:57 | Fare | currently, printk/printascii ceases to work when the kernel unmaps the io in mm/mm-armv.c, and from then on, nothing works anymore :( |
15:44:36 | Fare | what should I do, then? |
16:05:47 | prpplague | Fare: hmm, thats odd, because, printk/printascii should work all the time because its hardcoded output to the serial port |
16:06:20 | prpplague | Fare: sounds like something is being mapped incorrectly and hosing the kernel |
16:27:25 | Fare | maybe |
16:27:32 | Fare | probably |
16:27:54 | Fare | rmk says that it's normal that printascii would fail at that very moment |
16:28:06 | Fare | but not that it wouldn't come back after the end of the function |
16:29:15 | Fare | I have no idea what I hosed and how |
19:26:20 | Russ|werk | has anyone tested the new amd32.c yet? |
19:26:31 | Russ|werk | er, its just fare and prpplague |
19:28:41 | Fare | gimme a board, I'll test it :) |