| 00:21:19 | Sammy | morning ~ all |
| 04:14:24 | Sammy | is also update the LART into blob_2_0_4 |
| 04:14:48 | Sammy | blob> status |
| 04:14:49 | Sammy | Bootloader : blob |
| 04:14:50 | Sammy | Version : 2.0.4 |
| 04:14:51 | Sammy | Running from : internal flash |
| 04:14:52 | Sammy | Blocksize : 0x00800000 |
| 04:14:53 | Sammy | Download speed: 115200 baud |
| 04:14:54 | Sammy | Blob : from flash |
| 04:14:55 | Sammy | Kernel : from flash |
| 04:14:56 | Sammy | Ramdisk : from flash |
| 04:14:57 | Sammy | blob> |
| 04:16:10 | sammy_ | lunch . lunch . |
| 06:33:49 | sammy | Russ : suggest me which debian should I use ? why ? |
| 06:36:17 | sammy | woody or sid ? |
| 06:43:44 | BZFlag | on arm or x86? |
| 06:44:10 | BZFlag | on arm, potato is the only one I've used that works. |
| 06:44:49 | BZFlag | on x86 I use sid everyplace as I submit patches to a lot of developers and I'm sick of hearing "try the latest package out and see if it happens there" |
| 06:45:10 | BZFlag | with sid, I keep fairly close to the latest all the time. |
| 06:45:56 | BZFlag | I don't think I'd recommend that for everybody. testing (woody) might be a better choice |
| 06:59:04 | sammy | thanx BZFlag : ) |
| 06:59:15 | sammy | downloading .... |
| 07:48:05 | erikm | morning |
| 07:57:27 | sammy | morning erikm |
| 10:18:15 | erikm | re |
| 13:50:55 | jeffrey_w | hi erik , i cmpiled a blob-1.0.8-pre2 , may i just put and run it in ipaq's Ramdisk ( don't to replace bootldr)? |
| 13:51:42 | jeffrey_w | just to test running.. |
| 14:03:12 | jeffrey_w | my ipaq have no jtag, so running it have risk ..(will write to flash?) i no courage to do it. ;) |
| 15:14:05 | erikm | sorry, had SIGMANAGEMENT |
| 15:14:33 | erikm | jeffrey_w: ramdisks don't depend on bootloaders |
| 16:05:20 | Russ | morning |
| 16:16:27 | BZFlag | morning. I went to bed last night as well. |
| 16:32:25 | erikm | evening, guys :) |
| 16:34:36 | Russ | what do you think of the code? |
| 16:35:15 | erikm | ehm, which code? |
| 16:35:37 | erikm | ah, wait. |
| 16:35:41 | erikm | cvs updates |
| 16:36:39 | Russ | need to add a protection is the parsing of bootdelay to make sure its not somehow 0 |
| 16:36:59 | Russ | its already there in mkparamblock, but it should be in blob too |
| 16:38:12 | Russ | away |
| 16:45:32 | erikm | Russ: ehm, please no *generated* files in CVS |
| 16:46:02 | erikm | Russ: so utils/mkparamblock/mkparamblock should not be there |
| 17:45:27 | erikm | re, Russ |
| 17:49:09 | Russ|werk | thanks |
| 17:54:27 | erikm | Russ: ehm, please no *generated* files in CVS |
| 17:54:28 | erikm | Russ: so utils/mkparamblock/mkparamblock should not be there |
| 17:54:43 | erikm | (I think you didn't get that because you already left) |
| 17:55:17 | Russ|werk | did I accidentally commit the binary? |
| 17:57:55 | erikm | yes :) |
| 17:59:15 | erikm | hmm. I'll think of a nice way to use something like HOSTCC |
| 18:00:32 | erikm | btw, I was thinking of making the command stuff also a separate ELF section |
| 18:01:24 | erikm | so we can conditionally compile source files with extra commands without having to mess with the command line parser in main.c |
| 18:02:27 | erikm | I'll also have to rewrite the command line parser, but that would mean better modularity which is a Good Thing [tm] |
| 18:03:00 | Russ|werk | you liked rmk's .taglist section? |
| 18:03:30 | Russ|werk | I was bored and adapted tims splash.c, just by adding a tag parser to it and compiling it in |
| 18:03:51 | Russ|werk | not quite working perfect yet |
| 18:04:14 | Russ|werk | I don't think a tag in the paramater block for a splash screen is a paticularly bad idea |
| 18:04:52 | erikm | ehm, but a splash screen would mean that we have the program the LCD controller, which *is* a bad idea |
| 18:05:23 | Russ|werk | thats bad for linux? |
| 18:05:36 | erikm | I mean: what's the point of having a splash screen? it's a boot loader, not an OS |
| 18:06:16 | Russ|werk | right, the amount of bytes it actually takes to implement it is actually *very* small |
| 18:06:21 | erikm | that's also one of the things I don't like about bootldr: it displays a splash screen. for god sake, it's a boot loader! it should boot the OS! |
| 18:06:56 | Russ|werk | set the 4 registers, set the gpio's, copy to DRAM, and you are set |
| 18:07:10 | Russ|werk | I'll show you the patch when I'm done |
| 18:07:15 | erikm | and what functionality would that buy us? |
| 18:07:26 | Russ|werk | a deflated image that just says BLOB! in big white letters is 1.8k |
| 18:07:36 | Russ|werk | its just one of those things.... |
| 18:07:45 | erikm | yes, but that's 1.8K without *any* functionality |
| 18:08:04 | Russ|werk | right, but it doesn't go in the bootloader |
| 18:08:11 | Russ|werk | it goes in the paramater block |
| 18:08:17 | erikm | in the normal case we boot the OS in less than 1 second |
| 18:08:30 | Russ|werk | in which, there is loads of extra space |
| 18:08:43 | Russ|werk | the OS takes 3 seconds to bring up the fb |
| 18:08:53 | Russ|werk | its just a toy |
| 18:09:03 | erikm | forget about toys |
| 18:09:13 | Russ|werk | I'm not recommending that it be integrated, its just a cool example |
| 18:09:48 | erikm | the parameter block is not a bucket in which we dump all our shit. it's small, it only contains parameters for the bootloader. nothing more |
| 18:11:09 | Russ|werk | its 64k |
| 18:11:32 | erikm | yeah, but that doesn't mean that we should waste it |
| 18:12:53 | Russ|werk | its just a gee wizz thing (althogh, it could be used for rudentary debugging, since the tuxscreen doesn't have blob accessable LED's, just write a pixel on and off) |
| 18:13:23 | erikm | the tuxscreen has LEDs. a couple of them, even |
| 18:13:43 | erikm | the only question is which GPIO to use :) |
| 18:14:00 | erikm | (should be easy to find out with a binary search) |
| 18:14:15 | Russ|werk | no, it uses the DSP |
| 18:14:36 | Russ|werk | which is connected through a makeshift SPI bus of GPIO's |
| 18:14:43 | Russ|werk | so you need to send serial command to it |
| 18:14:47 | Russ|werk | (After initializing it) |
| 18:15:13 | erikm | grrr, why couldn't they use the KISS principle when designing it? |
| 18:15:42 | Russ|werk | you should see some source that comes with it |
| 18:15:54 | Russ|werk | the most horrid code you have ever seen |
| 18:16:15 | erikm | I'm told that BSD telnet is the most horrible code the world ever saw |
| 18:16:21 | erikm | :-P |
| 18:16:51 | Russ|werk | actually, its zli |
| 18:16:57 | Russ|werk | er |
| 18:16:57 | Russ|werk | zlib |
| 18:17:13 | Russ|werk | wonder if that thing has won any obfuscation awards |
| 18:17:37 | erikm | looks outside and wonders if the rain will ever stop |
| 18:18:27 | BZFlag | has a thought at the risk of being flamed.... |
| 18:19:06 | BZFlag | the lcd code is useful if and when there are boot choices that device buttons can select. |
| 18:19:17 | BZFlag | as with bootloader, displaying the menu. |
| 18:19:37 | Russ|werk | then you need to talk to the ucb1300 |
| 18:19:51 | Russ|werk | the lcd code is around 100 bytes I thing |
| 18:19:59 | Russ|werk | er, think |
| 18:20:09 | BZFlag | nah, just say press "foo" button. some devices will have readable buttons. |
| 18:20:27 | BZFlag | I'm not suggesting a ts driver in the bootloader. |
| 18:21:07 | Russ|werk | ideally, blob should be under 32k |
| 18:21:19 | erikm | BZFlag: but the normal operation is "plug in tuxscreen and run linux". same as with ipaq: "power on and boot linux" |
| 18:21:35 | erikm | BZFlag: if you want to do more, you connect a serial cable and talk to the device |
| 18:21:35 | Russ|werk | tftp, jffs2, etc will push it up to the 30k range |
| 18:21:39 | BZFlag | and I do feel strongly that any such code has to be a build time option. it should NOT add to the size of a minimal blob |
| 18:21:59 | Russ|werk | although gpio's will probably be considered at boot |
| 18:22:10 | BZFlag | erikm: I'd like to be able to "press foo to reflash from cf" |
| 18:22:41 | Russ|werk | I'm thinking 32 "boot settings", then each tag has a set of options, along with a mask |
| 18:23:05 | BZFlag | though perhaps just the existance of a cf storage card with named files on vfat is enough to decide to take that route. |
| 18:23:19 | Russ|werk | so, (tag.hdr.mask & curr_settings) == tag.hdr.settings then process tag |
| 18:23:40 | Russ|werk | some of the setting bits will be gpio's, others will be other things |
| 18:24:41 | BZFlag | the zaurus has "boot with c and a down to update from cf" |
| 18:24:53 | Russ|werk | failure is doing a paticular tag (ie, netboot), can set a flag, and start the tag parsing over |
| 18:25:18 | Russ|werk | the only problem is, you don't want to get into a loop |
| 18:25:24 | BZFlag | well, headed to work. |
| 18:25:33 | Russ|werk | se you'd probably want to set a tag counter, and for every tag parsed, increment it |
| 18:25:50 | Russ|werk | if it goes over a value, drop to blob |
| 18:26:09 | erikm | Russ: so what's the basic design idea behind the parameter block? |
| 18:26:30 | erikm | Russ: it's like rmk's tagged list for kernels, but what's in it? |
| 18:27:06 | erikm | Russ: (maybe we should add a "doc" directory to CVS and put such documentation in it) |
| 18:29:25 | Russ|werk | well, right now its just a skeleton for what we want it to be |
| 18:30:01 | Russ|werk | I think the option/mask thing can be very powerfull |
| 18:31:10 | Russ|werk | also, there can be a xor, or maybe and mask that should be set if the tag fails, and the parsing can be restarted from the head (maybe optionally) |
| 18:31:48 | erikm | but why would a tag fail? |
| 18:32:14 | Russ|werk | like a netboot tag, or a load kernel from jffs2 tag |
| 18:32:48 | Russ|werk | (the load kernel from jffs2 tag would be tim's "is there a CF card" thing) |
| 18:33:06 | erikm | ok, like that. I thought you meant an error in the tags itself |
| 18:33:16 | Russ|werk | you could even make tags that check simple things, like is there a gzip signiture on bootldr partition x |
| 18:33:51 | Russ|werk | but right now, its all just the skeleton |
| 18:35:43 | erikm | ehm that would mean that we need some kind of scripting language in blob |
| 18:36:06 | erikm | and in that case I think we'd better go directly for OpenProm |
| 18:36:30 | Russ|werk | it wouldn't be a scripting language |
| 18:36:45 | Russ|werk | all of that would be done in mkparamblock |
| 18:37:29 | Russ|werk | there would be 32 "current config flags" |
| 18:37:51 | Russ|werk | maybe 4 or so of them would be set by the gpio's, one could be set by resume maybe |
| 18:38:02 | Russ|werk | so it would be a u32 bitmask |
| 18:38:34 | Russ|werk | each paramater block hdr would have a mask, a config, and a fail mask |
| 18:38:51 | Russ|werk | if the mask is zero, its a global tag |
| 18:39:32 | Russ|werk | when parse_tags looks at a tag, it checks an sees it the (hdr.mask & hdr.config) == the current config mask |
| 18:39:43 | erikm | yes, but checking for gzip signatures would and making decisions based on that would mean that we need if-then-else and that's pretty close to a programming language |
| 18:39:45 | Russ|werk | if it does, it proccesses the tag |
| 18:40:48 | Russ|werk | if the tag returns failure, then it does something with the current config bitmask, and hdr.fail_mask (maybe xor's it, make or it, don't know) |
| 18:41:51 | Russ|werk | then it maybe restarts the parsing of the tags, or continues (don't know that yet either, maybe thats another flag) |
| 18:42:19 | Russ|werk | if the number of tags processes goes over a limit, it drops to blob (to avoid loops) |
| 18:42:58 | erikm | but it won't loop, right? the list is not without boundaries |
| 18:43:18 | Russ|werk | so the only decision would really be whether or not to process the current tag based on the tags masks, and the current config |
| 18:43:33 | Russ|werk | it could if you wanted it to |
| 18:43:49 | Russ|werk | if something fails, and changes the mask, you could restart the parsing of tags |
| 18:43:57 | Russ|werk | I don't know why that would be usefull |
| 18:44:48 | Russ|werk | I don't know why a boot attempt would be anything but linear |
| 18:46:06 | Russ|werk | brb, kernel change |
| 20:38:06 | erikm | hmm, john dorsey released a new bootldr |
| 20:42:18 | erikm | goes zzz |
| 20:42:21 | erikm | 'night |