16:03:06 | erikm | seletz: it's really nonsense |
16:03:15 | seletz | i have to admit that i never used / seen a stripped down X system. |
16:03:32 | erikm | jim gettys and keith packard developed X on a 2MB VAX |
16:03:52 | seletz | Ok, big point. |
16:03:52 | erikm | so what's the problem with your 32MB handheld? |
16:04:38 | seletz | one gets distracted by some linux distros, i suppose. There X _is_ big. |
16:04:45 | seletz | most distros, i think. |
16:04:51 | erikm | the X server *looks* big |
16:05:13 | erikm | that's because it mmaps the complete framebuffer, which is indeed accounted to the X server |
16:06:00 | seletz | but, OTOH, when i dont need a window manager, when i just need some buttons, some text and a drawing container for displaying data, would i use X? |
16:06:28 | erikm | no |
16:07:05 | erikm | but lots of people want more than that: multiple windows, window stacking order, iconify, etc. |
16:07:16 | seletz | Well, there you have it. Our app will run in one window. No other windows. No window at all in fact. |
16:07:24 | seletz | Yes. i know. |
16:07:30 | seletz | Then X is great. |
16:08:07 | seletz | you can set DISPLAY and work remote. _thats_ great. One can use VNC. Great, too. |
16:08:56 | erikm | btw, I'm going to move the USE_SERIAL[13] stuff into the architecture dependent header files |
16:09:12 | seletz | makes sense. |
16:09:42 | seletz | well, I got to eat something now. had no lunch at all. |
16:10:18 | seletz | bye guys! |
16:10:20 | erikm | hmm, yeah |
16:10:24 | erikm | SIGDINNER, I think |
16:10:35 | seletz | yes. so to speak :) |
18:18:45 | erikm | BZFlag! |
18:18:50 | prpplague | howdy BZFlag |
18:19:14 | prpplague | i talked to john lombardo today and mentioned the tuxscreen to him |
18:22:16 | prpplague | BZFlag: he said he was going to buy one |
18:23:05 | BZFlag | http://www.johnandmary.net/ ? |
18:24:02 | erikm | BZFlag: spooky idea to support a 40MB TuxScreen: we binary patch blob |
18:24:37 | BZFlag | or http://www.2cbagents.com/johnlombardo.htm, or even http://www.nudework.com/ wow. |
18:24:47 | BZFlag | erikm: yeah, what cha think? |
18:25:01 | prpplague | BZFlag: how about this http://www.linuxdevices.com/news/NS8950125895.html |
18:25:02 | BZFlag | erikm: I'd like to see a memdebug dump in a 40M phone. |
18:25:29 | BZFlag | perhaps we could find other aliases the would work for the onboard memory. |
18:25:31 | erikm | BZFlag: IIRC the only difference is the memory setup, right? |
18:26:00 | erikm | (so the stuff that goes in MDCNFG etc) |
18:26:07 | BZFlag | erikm: oh, I guess it could be that John Lombardo |
18:26:19 | BZFlag | erikm: right. |
18:27:04 | erikm | BZFlag: what happens with the memory map if you run a blob for a 16MB TuxScreen on a machine with 40MB? |
18:28:20 | BZFlag | ah, http://www.embeddedlinuxbook.com/ that looks like the right place. ;-) |
18:28:39 | BZFlag | erikm: 16M shows up. |
18:28:48 | erikm | BZFlag: hmm. duh. |
18:29:00 | erikm | BZFlag: so we can't autodetect it. |
18:29:10 | erikm | BZFlag: shouldn't be a problem, though |
18:29:21 | BZFlag | Inferno autodetects, but the existing register settings in blob won't |
18:29:22 | Russ|werk | I like the idea of putting mirrors together, instead of apart |
18:29:47 | erikm | Russ|werk: that's also a solution |
18:29:49 | BZFlag | Russ|werk: agreed. that's why I want to see a map. |
18:30:18 | BZFlag | if the 40M setting has workable aliases, then I suspect that memcnfg could be used for all configs. |
18:30:31 | prpplague | BZFlag: sorry didn't mean to be obtuse, just thought you might want to know about him being interested in the tuxscreen |
18:30:55 | BZFlag | prpplague: no problem. thanx. it's the book John right? |
18:30:57 | erikm | Russ|werk: cause the other solution I was thinking about was to binary patch blob. |
18:31:11 | BZFlag | erikm: patched to do what? |
18:31:36 | erikm | BZFlag: make a command that binary patches the blob memory setup and write it back to flash |
18:31:47 | erikm | BZFlag: tricky, but works |
18:32:19 | BZFlag | no, it should be detectable. just add some code to deal with it that is ifdef SHANNON. |
18:32:29 | BZFlag | see the inferno code for examples. |
18:32:32 | prpplague | BZFlag: yes, he said he was interested in doing some research on how you guys implmented the buildroot and how you guys have been working on getting linux running |
18:32:44 | erikm | BZFlag: ok, if there is *some* way to autodetect it, we could do that as well. |
18:32:47 | BZFlag | http://TuxScreen.net/download/inferno/inferno.lst |
18:33:04 | erikm | BZFlag: problem is that we do autodetection from C, not from assembly |
18:33:11 | BZFlag | prpplague: have him join #TuxScreen and all shall be revealed. ;-) |
18:33:25 | prpplague | BZFlag: i did |
18:34:23 | BZFlag | erikm: ah. yes. this would be easier in memsetup.S |
18:34:48 | erikm | oh, btw, now I moved the stack into the .bss section, we do have a problem when you configure with --eneable-all-features: the .bss overlaps with the kernel at 0xc0008000 |
18:34:59 | BZFlag | ELJ wants me to do an article. |
18:35:31 | BZFlag | erikm: so what's the long term plan to fix that one? |
18:35:37 | erikm | the short term solution is to make the stack 4K instead of 8K, the long term solution is that I'm going to move blob to 0xc0000000 +1MB |
18:35:58 | erikm | or actually, I'm going to make the entry point for the second stage loader a configure time variable |
18:36:08 | BZFlag | erikm: not on a 40M tux you aren't. ;-) |
18:36:28 | Russ|werk | why not let blob figure out where to put itself based on a memory map? |
18:36:46 | BZFlag | Russ|werk: it's not relocatable at present, right? |
18:36:56 | erikm | Russ|werk: possible, but in that case you would need a complete ELF relocator |
18:37:03 | BZFlag | right |
18:37:03 | Russ|werk | o |
18:37:08 | erikm | Russ|werk: and I'd like to avoid that |
18:37:22 | Russ|werk | what if you just did -fPIC |
18:37:26 | erikm | doesn't work |
18:37:40 | BZFlag | Russ: that's only half the issue. |
18:37:45 | erikm | already tried that: there is *no* difference between code with and without -fPIC |
18:38:11 | BZFlag | erikm: really? hmmm. I would have expected to get a jump table with -fPIC |
18:38:28 | Russ|werk | so....the only easy way to relacet blob would be with the MMU |
18:38:47 | erikm | Russ|werk: and *that's* something I would like to avoid |
18:38:57 | BZFlag | agrees |
18:39:19 | erikm | BZFlag: if there a 1MB memory region that a 16MB and a 40MB tuxscreen share? |
18:39:39 | erikm | BZFlag: if so, that would become the entry point for the TuxScreen |
18:39:40 | BZFlag | GPSFan says 0x00c8993f in MDCNFG does the trick. |
18:40:04 | BZFlag | erikm: there is, but there are no larger blocks. |
18:40:18 | erikm | BZFlag: blob doesn't need anything larger :) |
18:40:27 | BZFlag | ah, but the kernel will. |
18:40:40 | erikm | the zImage only needs 1MB |
18:41:02 | erikm | in theory you can create much larger zImages, but in practice that never happens |
18:41:05 | BZFlag | but it needs to decompress and run someplace. |
18:41:14 | erikm | *nod* |
18:41:17 | BZFlag | well, the tux zImage is like 900k now. |
18:41:22 | erikm | *blink* |
18:41:30 | erikm | what do you put in the kernel? |
18:41:37 | BZFlag | but that's just cause that's how big the MTD partition was. |
18:41:55 | BZFlag | so I compiled pcmcia vfat ext2 reiserfs, etc all static. |
18:41:57 | erikm | BTW, any chance to feed the TuxScreen changes to rmk? |
18:42:27 | BZFlag | erikm: yes. I need to clean them up and send em in now that we have dsp code and such too. |
18:42:44 | BZFlag | Russ: you going to have some time for that? or should I do it? |
18:42:52 | Russ|werk | erikm: I gotta do that |
18:42:56 | erikm | BZFlag: just send him the basic stuff for the CPU |
18:42:58 | BZFlag | ok |
18:43:10 | Russ|werk | wanted to find out why the newer kernel were locking on remount before I did though |
18:43:15 | erikm | he won't take larger diffs anyway :) |
18:43:16 | Russ|werk | also need to integrate with non-np |
18:43:52 | erikm | lock on remount.... is that with a jffs2 image? |
18:44:01 | Russ|werk | yah |
18:44:09 | erikm | hmm, I've seen that as well |
18:44:10 | Russ|werk | it happens in mtd code |
18:44:15 | Russ|werk | so its not just me |
18:44:28 | Russ|werk | I guess I'll go to the latest rmk/non-np and feed that |
18:45:20 | erikm | rmk spend some time with alan cox, and it turns out to be infectuous: he now also releases seven kernels a week ;) |
18:45:44 | BZFlag | cool -> http://sllug.org/meetings/2001/november.html debIAN at SLLUG. |
18:46:28 | erikm | BZFlag: btw: I signed an the compaq NDA, so if I really need, I know what wires to solder to my ipaq |
18:46:55 | BZFlag | cool. progress on that? |
18:47:14 | erikm | BZFlag: the chain loader works |
18:47:23 | erikm | BZFlag: so I can chain boot blob from bootldr |
18:47:37 | BZFlag | sweet. flash writes yet? |
18:47:41 | erikm | not yet |
18:47:54 | erikm | I need to extend the flash driver for that |
18:48:15 | erikm | because you need to enable the programming voltage on the ipaq |
18:49:11 | erikm | and while I'm at it I'll also make flash lock&unlock functions |
18:50:42 | BZFlag | nice. now if we only had 12v input in the tux. ;-) |
18:50:49 | erikm | eh, why? |
18:51:45 | Russ|werk | needs 12V to unlock |
18:52:18 | erikm | BTW, I think I'm going to steal the memory setup values from bootldr. there is no way to find out what memory chips the ipaq has without physically damaging the PCB :( |
18:53:09 | erikm | (the memory chips are hidden under a metal cover to reduce the amount of noise) |
18:53:26 | Russ|werk | can't get that with the NDA? |
18:53:52 | BZFlag | erikm: check the ipaq archives. I'm sure it's been said there. |
18:54:16 | BZFlag | also check the ipaq hardware upgrade folks. they should know too. |
18:54:31 | prpplague | erikm: have you added a new section to blob for chain booting? |
18:54:32 | erikm | no, I'd need another NDA for that. the NDA I have right now only covers the location of the JTAG test pins |
18:54:57 | erikm | BZFlag: I now realise I can also get it from a running linux kernel ;) |
18:56:25 | BZFlag | cool |
18:58:59 | erikm | BZFlag: btw, try compiling a kernel with -Os. makes it about 5% smaller and it still works |
18:59:29 | erikm | BZFlag: but ssssh! don't tell rmk! ;) |
19:00:02 | Russ|werk | how about that thumb port then? |
19:00:38 | erikm | I think that would make the kernel larger |
19:00:44 | BZFlag | http://TuxScreen.net/wiki/view/Main/InfernoSODIMM |
19:00:59 | erikm | thumb has smaller instructions, but is not as expressive as arm |
19:01:47 | erikm | BZFlag: could you also put the blob output with an 8MB SODIMM on that page? |
19:01:50 | BZFlag | try a thumb blob then. ;-) |
19:02:27 | prpplague | erikm: nice, i hadn't looked at the new blob code in a while, the chain looks really good |
19:02:55 | erikm | prpplague: I think the chain loader should work with your platform as well, right? |
19:03:23 | prpplague | erikm: almost, i need a small section of code to return the mmu to 1-1 and turn it off |
19:04:08 | BZFlag | erikm: added the 16M output |
19:05:04 | erikm | prpplague: I think we can combine that |
19:05:17 | erikm | BZFlag: /me looks |
19:05:36 | BZFlag | erikm: the output from current blob is the same for 16M and 40M setup. |
19:05:46 | BZFlag | 8M just has the first 2 regions |
19:06:10 | erikm | BZFlag: right, so putting blob at 0xC8000000 works for all tuxscreens |
19:06:13 | BZFlag | I have not tried the new config on 8M or 16M |
19:07:07 | BZFlag | erikm: assuming that's not a block where the kernel would go due to aliases. |
19:07:20 | BZFlag | oh, I suppose the uncompressed kernel could go there, ;-) |
19:07:38 | erikm | no, the uncompressed kernel goes at 0xc0008000 |
19:07:57 | BZFlag | I meant later pieces of it do to aliasing. |
19:08:08 | prpplague | erikm: ok to send you and email with the details? |
19:08:10 | erikm | oh, ok |
19:08:24 | erikm | prpplague: ok |
19:08:29 | prpplague | erikm: thanks |
19:08:36 | BZFlag | but once the kernel boots we don't need the blob code in ram. ;-) |
19:08:53 | BZFlag | what's the blob apm status now? |
19:09:08 | erikm | BZFlag: that's right. once we start the kernel at 0xc0008000 we can overwrite blob |
19:09:18 | erikm | apm status? |
19:09:51 | BZFlag | does blob support apm resume on any hardware now? |
19:10:19 | erikm | oh, resume. well, I've heard both positive and negative stories |
19:11:51 | BZFlag | I have not gotten to testing that yet, but some of the new bids Lineo is doing will need it. If we get one I'll test it and fix it if I find issues. perhaps I'll add tux suspend support too. ;-) |
19:12:50 | erikm | BZFlag: not all EDODRAMs support it |
19:13:02 | erikm | BZFlag: you need EDO RAM that can do self refresh |
19:16:21 | erikm | BZFlag: SDRAM supports it though, so if you have an SA1110 system with SDRAM you can test it |
19:35:46 | prpplague | erikm: just a email with some details, don't feel obligated to work on anything |
19:36:22 | erikm | just got email and looks |
19:55:29 | erikm | oooh! |
19:55:41 | erikm | marcj rendered a blob logo: http://historia.et.tudelft.nl/~marcj/blob/blobje.png |
19:58:04 | erikm | or the greyscale version: http://historia.et.tudelft.nl/~marcj/blob/blobjezw.png |
20:01:01 | prpplague | needs a different background otherwise looks good |
20:01:31 | Russ|werk | just make the grey transparent |
20:01:58 | erikm | this was only a first shot |
20:02:20 | erikm | we need a splash screen for the ipaq |
20:02:31 | erikm | otherwise that will be the first thing that people are going to ask |
20:02:44 | Russ|werk | I got my splash screen code |
20:02:52 | Russ|werk | set the registers, deflate the image |
20:03:11 | erikm | Russ: what kind of compression do you use? |
20:03:16 | Russ|werk | deflate |
20:03:33 | erikm | ok, so how do I compress that? |
20:03:39 | Russ|werk | with zlib |
20:04:32 | erikm | hmm, I was actually thinking about some kind of run length coding |
20:04:52 | Russ|werk | defalte will end up being used in other places.... |
20:04:59 | erikm | like? |
20:05:04 | Russ|werk | jffs2 |
20:05:12 | erikm | ok, in that case it makes sense |
20:05:14 | Russ|werk | and deflate does RLE anyway |
20:06:58 | Russ|werk | a simple RLE scheme would be less code though |
20:09:00 | erikm | but I thought that your jffs2 code didn't use zlib? |
20:11:56 | Russ|werk | it uses my own deflate code |
20:12:00 | Russ|werk | much smaller |
20:12:12 | Russ|werk | little slower, and a little less error checking though |
21:33:30 | erikm | goes home |
21:56:32 | erikm | has a day off tomorrow |
21:56:33 | erikm | bye |
22:35:52 | prpplague | howdy russ |
22:36:07 | prpplague | werking hard or hardly werking? |
22:37:43 | Russ|werk | getting a new kernel and ups set up |
22:38:57 | prpplague | still working on fs problems |
22:40:32 | Russ|werk | on your box? |
22:41:06 | prpplague | on my sa-1100 board |
22:42:53 | Russ|werk | which problems would those be? |
22:43:26 | prpplague | i keep getting problems with sig4 "Illegal instruction" |
22:43:43 | Russ|werk | hh.org toolchain? |
22:44:09 | prpplague | erikm toolchain from rmk website |
22:44:40 | Russ|werk | do you have a floating point emulator in your kernel? |
22:45:42 | prpplague | should be, i'll using the standard brutus config |
22:47:39 | prpplague | Russ: whats that CONFIG_ listed as? |
22:49:15 | Russ|werk | either NWFPE |
22:49:24 | Russ|werk | or the fast fpe |
22:49:31 | Russ|werk | just do make xconfig and check for it |
22:50:05 | Russ|werk | CONFIG_NWFPE |
22:50:08 | prpplague | doh! |
22:50:15 | prpplague | that must be it.. |
22:50:28 | prpplague | i wonder why the default brutus config didn't grab it |
22:50:33 | Russ|werk | CONFIG_FASTFPE |
22:50:42 | Russ|werk | er, maybe CONFIG_FPE_NWFPE |
22:50:43 | prpplague | neither configured |
22:50:56 | prpplague | ya they are listed just not configured |
22:52:17 | prpplague | Russ: i'll try again |
22:56:03 | prpplague | Russ: i swear this 1.7 gets slower the longer you leave it on |
22:56:19 | Russ|werk | 1.7GHz? |
22:56:21 | Russ|werk | P4? |
22:56:28 | prpplague | ya |
22:56:43 | Russ|werk | once it gets to a certain temp, it switches to half speed iirc |
22:56:49 | Russ|werk | might need a bigger fan |
22:57:48 | prpplague | hmm, brb , reboot |
23:00:39 | prpplague | ohh ya much better |
23:01:14 | prpplague | Russ: thanks for the help of |
23:01:26 | prpplague | on the problem |
23:02:13 | prpplague | Russ: i'll be sure and put you on the "thanks here's a free steak and beer" list |
23:06:06 | Russ|werk | coo' |
23:18:44 | prpplague | Russ: hot darn, i owe you a round of really good beer |
23:19:19 | prpplague | Russ: is that documented anywhere or is that suppose to be common sense? |
23:21:27 | Russ|werk | probably, its mainly on the linux-arm list |
23:22:07 | prpplague | i though i went through the list, but i'm going write this down on my web site |
23:24:35 | prpplague | thanks again, i'm off to home to jump between reading dr.seus and sa-11xx ref manuals |