| 08:06:05 | Sammy | BZFlag: when I mknod inside the rootfs , and after reboot the device node can't be safe , why ? |
| 08:07:03 | BZFlag | Sammy: re make /dev a ramfs (normally) so that permissions etc can be changed without excessive flash writes. |
| 08:07:39 | BZFlag | real path is /boot/var/dev/ which get's copied to /var/dev/ on boot where /var is ramfs |
| 08:08:01 | BZFlag | same is true of any files in /boot/var |
| 08:15:41 | Sammy | BZFlag: sorry forget tell you one thing , that rootfs is in flash (Puppy), can you answer me again , plz ? |
| 08:22:09 | BZFlag | yes, the rootfs is, but if you are using rootfs /dev is a link to /var/dev and /var/dev (after boot) is ramfs |
| 08:22:27 | BZFlag | er if you are using the buildroot to get your fs. |
| 08:23:18 | BZFlag | or did you say you were using devfs? if so I'm not sure how to make it persist. same method should work though, have a /boot/dev and copy it over _after_ mounting /dev |
| 08:23:58 | Sammy | yeap ,I use devfs |
| 08:25:03 | Sammy | but onething bad is in my /boot don't have sub dir /dev :( |
| 08:27:07 | BZFlag | make one |
| 08:27:59 | Sammy | ok, I try that |
| 10:46:23 | erikm | hello |
| 10:47:54 | Sammy | hi erikm :o |
| 10:49:01 | Sammy | iskra ? |
| 10:49:11 | Sammy | have address ? |
| 10:49:19 | Sammy | google ... |
| 11:10:17 | Sammy | dinner time ... |
| 11:10:34 | Sammy | erikm: lunch ? |
| 11:10:44 | erikm | yeah, just got a SIGLUNCH |
| 11:43:15 | erikm | returns |
| 11:47:57 | Sammy | erikm: strange dev ... |
| 11:48:49 | Sammy | I use devfs and mknod at /dev , then after I reboot , that's node I made was gone ... |
| 11:48:52 | Sammy | why ? |
| 11:51:22 | erikm | doesn't do devfs |
| 11:51:37 | erikm | IMHO devfs is seriously broken |
| 11:53:15 | Sammy | Amm...you mean devfs broken or my jffs2 image broken ? |
| 11:53:33 | erikm | I consider devfs broken by design |
| 11:55:31 | Sammy | erikm: do you think devfs is good for big jffs2 file to use ? |
| 11:55:48 | Sammy | or you have better suggest ? |
| 11:56:44 | Sammy | because sometimes in my /dev after download into flash , and find out lost some device ... |
| 11:57:23 | erikm | that's because /dev lives in RAM (more specifically in the page cache) if you mount devfs over it |
| 11:58:18 | Sammy | so..... don't mount ? |
| 11:58:45 | Sammy | just support and don't mount on /dev ? |
| 11:58:47 | erikm | or create the device nodes you want after devfs has been mounted |
| 12:01:02 | Sammy | |o| , but this is inconvenient |
| 12:01:28 | Sammy | if I need fb or ts or etc ... |
| 12:02:50 | erikm | /dev/fb should be created by devfsd |
| 12:03:34 | erikm | anyway, /me reboots into 2.4.17-rc2, brb |
| 12:18:57 | seletz | hi all ... |
| 12:19:23 | Sammy | hi seletz :) |
| 12:19:42 | Sammy | erikm: I use this word ( inconvenient ) correct ? |
| 12:20:16 | erikm | hello seletz |
| 12:20:52 | erikm | Sammy: which word? I just lost the xchat history when I rebooted into 2.4.17-rc2 |
| 12:22:13 | Sammy | [20:03] <Sammy> |o| , but this is "inconvenient" <<= correct ? |
| 12:23:49 | erikm | Sammy: if you mean "giving trouble" , or "giving annoyance" it's correct |
| 12:24:20 | Sammy | ok :) |
| 12:33:54 | seletz | trying out xchat :) |
| 12:43:21 | Sammy | later guys :) |
| 12:43:30 | Sammy | go home ... |
| 12:46:24 | seletz | sammy_wms: bye |
| 13:02:13 | erikm | looks at the jffs2 patch |
| 13:34:11 | seletz | erikm: ahhh! at last some CRC32 function! |
| 13:37:14 | erikm | seletz: yeah, but broken |
| 13:37:28 | erikm | seletz: it does table lookups |
| 13:37:37 | erikm | seletz: which makes it *slow* |
| 13:37:53 | seletz | erikm: well, this patch looks likes some more general |
| 13:38:15 | erikm | seletz: remember that we run with dcache disabled, so every memory access costs you about 60 CPU cycles. |
| 13:38:26 | seletz | erikm: what do you think, could it be integrated with the pcmcia/ide stuff, once it works and is tested? |
| 13:38:51 | erikm | seletz: the icache is however enabled, so computing every value makes it *much* faster |
| 13:39:03 | erikm | seletz: I'm integrating it right npw |
| 13:39:03 | seletz | erikm: _ouch_ |
| 13:39:07 | erikm | now, I mean |
| 13:39:48 | seletz | erikm: normally lookups are a good thing, tough. |
| 13:40:53 | erikm | seletz: quite the contrary |
| 13:41:45 | erikm | seletz: it all depends on cache size/speed/latency, memory size/speed/latency, CPU speed, and amount of work to compute the value |
| 13:42:06 | erikm | seletz: and in this case it really makes sense to compute the CRC value |
| 13:42:40 | seletz | erikm: yes, when one has a setup that has a big speed penalty on mem access then lookup tables are not the best thing to do. |
| 13:43:23 | seletz | erikm: _and_ when computing values does not take too long :D |
| 13:44:08 | seletz | erikm: _yuck_ that table is _BIG_ |
| 13:44:43 | erikm | seletz: yeah, 1K of data. that's serious cache poisoning even with dcache enabled |
| 13:46:10 | erikm | erikm: but I've done several program speedups in my group by just doing a proper analysis of the algorithm |
| 13:46:13 | seletz | erikm: :D comments are a fine thing ... (jffs2.c) |
| 13:47:16 | erikm | seletz: lol :) |
| 13:47:29 | seletz | erikm: well, the best speedup is archieved normally by using a better algorithmus (and implementing it correctly). |
| 13:48:13 | erikm | seletz: *nod* the biggest improvement we got was from an algorithm that used 200ms for processing an image on a PIII 800 to 15ms on a PII 450 |
| 13:49:05 | erikm | seletz: we didn't have a PIII to test it on, but we thought the slower PII was already good enough (they needed < 40ms/image) |
| 13:49:32 | seletz | erikm: qed, so to say. :D |
| 13:52:28 | seletz | erikm: well, scanning through the code i see some "conding horrors" which when i would find/see them in reviews done here would result in quite some, erm, rewriting. |
| 13:53:01 | seletz | erikm: but i must admit that in the linux community the rules are somewhat different. |
| 13:55:22 | erikm | seletz: there are some coding errors, but you also have to remember that linux uses the rules as written down in Documentation/CodingStly |
| 13:57:07 | seletz | erikm: well, ok, we had some arguing about that. I already gave in and I try to use the common style, which makes very much sense. |
| 14:00:30 | seletz | erikm: thats about style. But i was talking about code quality. By quality i mean maintainability, _not_ the functionality, and not the coding style. Stlye does matter, tough, but the linux coding style is ok, IMHO. |
| 14:01:48 | erikm | seletz: using a consistent coding style helps a lot in maintaining the code. there was a large discussion on lkml about that a week ago. it's nicely summarised in the latest KT |
| 14:03:09 | seletz | erikm: ok, I'll read it. |
| 14:04:50 | seletz | erikm: I'ts just sometimes i can't get rid-off my pre-linux SW development work. I keep trying to get the best out of both worlds ... :D Never mind. |
| 14:07:21 | seletz | erikm: lol! KT is _good_ |
| 15:21:33 | erikm | deciced that partition table support should go first |
| 15:21:40 | erikm | decides, I mean |
| 15:21:46 | prpplague | morning erikm |
| 15:22:00 | erikm | hello, prpplague |
| 15:22:29 | prpplague | well the company i work for has agreed to pay andersee to fix the uclibc support for c++ |
| 15:23:06 | erikm | prpplague: that's good news! |
| 15:23:30 | prpplague | andersee thinks he can have it finish by the end of jan |
| 15:24:12 | erikm | prpplague: I really applaud your management for such a wise decision |
| 15:25:26 | prpplague | erikm: no too big of a decision "yes sir, we can use these modification very extensively, and we can get them dirt cheap!" "ok do it" |
| 15:26:03 | prpplague | morning jeffrey |
| 15:31:45 | jeffrey | Hi prpplague |
| 15:32:32 | erikm | prpplague: heh, we did the same a couple of years ago. either hire a programmer to a) first study the linux kernel and b) start writing a device driver for a PCI I/O card, or pay roger wolff to do it instead. the latter was *much* cheaper |
| 16:08:03 | sammy_wms | hello all ... |
| 16:10:38 | prpplague | erikm: i'm hoping i can convince them to spring the $$ for pthreads as well |
| 16:10:58 | erikm | heh, good luck :) |
| 16:13:23 | sammy_wms | is that any point need to be careful with handle touchscreen support ? |
| 16:13:41 | sammy_wms | beside need to know what chip to use .. |
| 16:13:57 | sammy_wms | UCB1300 yes |
| 16:14:49 | sammy_wms | or if make kernel have choose , then it's will support quite well ? |
| 16:16:46 | sammy_wms | any suggest ? erikm ? prpplague ? Russ ? seletz ? |
| 16:17:28 | erikm | you have to make some minor changes to the kernel driver to get it to work on your platform |
| 16:20:25 | sammy_wms | erikm: like ....what ? |
| 16:20:37 | erikm | IRQ, GPIO, etc |
| 16:21:17 | sammy_wms | ||o|| remember that ... |
| 16:21:43 | prpplague | sammy_wms: sorry sammy i'm just now getting into the lcd/ts interfacing myself |
| 16:23:15 | sammy_wms | it's ok , I also like a newbies on this level too , |
| 16:24:27 | sammy_wms | so if you got any problem that I can help you , I'll do the best I can |
| 16:26:02 | sammy_wms | Hope someday I can put something good use stuff on blob, kernel ... etc |
| 16:50:56 | sammy_wms | rain rain rain alllllllll day ............. :( |
| 16:51:25 | erikm | rain with occasionally some snow over here |
| 16:54:32 | sammy_wms | I'd better like snow then rain ... |
| 16:55:04 | sammy_wms | (the voice come from someone never touch the snow ) |
| 16:57:34 | sammy_wms | because here doesn't have any chance to get snow .... |
| 17:03:17 | erikm | this is *scary* |
| 17:03:41 | erikm | I mean the way the kernel parses bootldr partitions |
| 17:08:54 | sammy_wms | erikm: as I know that iPAQ when bootldr define the partition , even the kernel MTD has define different , but still choose what the bootldr say ? right ? |
| 17:09:36 | erikm | sammy_wms: that's right. if there is a partition table, the kernel will prefer that one over the default one |
| 17:11:30 | sammy_wms | is that good ? or jsut like blob partition match with kernel MTD partition is better ? |
| 17:13:10 | erikm | sammy_wms: I don't think it's good, but if there is no partition table in flash, anything can happen |
| 17:15:48 | sammy_wms | Amm...yeah.. |
| 17:16:45 | sammy_wms | btw need some sleep , night erikm & all :) |
| 17:17:02 | erikm | night, sammy |
| 17:18:26 | sammy_wms | Z.z.z |
| 17:53:30 | erikm | considers trading in strcpy() for strncpy() |
| 17:56:47 | erikm | thinks that having strncpy() will force you to think about *what* to copy |
| 17:56:58 | erikm | which is a Good Thing [tm] |
| 18:27:25 | Russ|werk | I just wish it was a true limiting function, and not just a non-null terminated string function |
| 18:29:26 | erikm | Russ|werk: I'm just coding up a strncpy() function |
| 18:30:25 | erikm | Russ|werk: so you'd like to have the destination string null-terminated if n < strlen(src) ? |
| 18:30:58 | erikm | doesn't think that's a good idea |
| 18:34:11 | Russ|werk | it'd be nice if there was a standard str copy that did that |
| 18:34:20 | Russ|werk | like strlcpy (l for limit) |
| 18:34:54 | erikm | Russ|werk: well, for blob, I'd rather stay with the description from the manual pages. principle of least surprise |
| 18:34:55 | Russ|werk | then you wouldn't need a bunch of strncpy(value, buffer, 25); \ value[24] = '\0'; |
| 18:36:00 | erikm | Russ|werk: make it a macro :) |
| 18:42:56 | erikm | also removes strcmp() |
| 18:45:07 | Russ|werk | that would make my code harder to read, so I'd rather just use the kludge |
| 18:46:03 | erikm | Russ|werk: I'll make it an inline function |
| 18:46:37 | erikm | Russ|werk: it makes sense, it's as safe as strncpy(). |
| 18:46:55 | erikm | Russ|werk: but strcmp() could potentially run forever |
| 19:20:59 | Russ|werk | erikm: not to nitpick... |
| 19:21:05 | Russ|werk | but |
| 19:21:06 | erikm | but? |
| 19:21:19 | Russ|werk | strncmp(argv[1], "230k4", 5), should technically be strncmp(argv[1], "230k4", 6) (and etc) |
| 19:21:28 | erikm | hmm |
| 19:21:32 | erikm | yeah, you're right |
| 19:22:50 | Russ|werk | you could always make a macro strequ(a, const_str) strncmp(a, const_str, sizeof(const_str)); |
| 19:23:06 | Russ|werk | although technically, strncmp will never burn you on const strings anyway |
| 19:25:03 | erikm | too late, I already changed everything in main.c :) |
| 19:25:27 | erikm | heya, BZFlag |
| 19:31:02 | Russ|werk | it'll always stop at the NULL in the const string |
| 19:32:00 | erikm | Russ|werk: I'm currently removing strcpy() in favour of strncpy(). is there any maximum length on the kernel cmdline in the param_block? |
| 19:32:41 | erikm | Russ|werk: if not, I'll put it at 1024 in linux.c and put a NOTE comment just above it |
| 19:32:49 | Russ|werk | ya |
| 19:33:02 | Russ|werk | er |
| 19:33:43 | erikm | hmm, wait. |
| 19:34:00 | Russ|werk | lemme see, its been a semester |
| 19:34:10 | erikm | same for me :) |
| 19:34:44 | erikm | wait, the maximum size is COMMAND_LINE_SIZE as defined by the kernel |
| 19:34:57 | erikm | in include/asm-arm/setup.h |
| 19:41:01 | Russ|werk | ya, it would just be that |
| 19:41:35 | Russ|werk | (altough it could technically be longer in the param block (should be limited by the utility for making the param block) |
| 19:42:04 | erikm | it wouldn't make sense, the kernel can't take any longer |
| 19:42:46 | erikm | at the time the ATAG parser runs, kmalloc() isn't yet initialised, so the kernel can only copy fixed size strings |
| 19:52:41 | erikm | done |
| 20:02:48 | erikm | Russ|werk: yeah, strlcpy() is quite neat :) |
| 21:13:19 | prpplague | erikm: besides the tuxscreen, what has been the least expensive arm based board you seen available? |
| 21:14:49 | erikm | prpplague: the ipaq h3600 seems to be quite reasonable. sammy got one for $279 |
| 21:18:43 | prpplague | erikm: what is the creditlart price going to be? |
| 21:20:00 | erikm | prpplague: I really have no idea |
| 21:20:41 | erikm | prpplague: I even wonder if it will ever get there. the commercial consortium is a bit paralised |
| 21:21:24 | prpplague | erikm: hmm what seems to be the problem? |
| 21:22:05 | prpplague | erikm: the reason i ask, this guy over at earthlcd said on the phone they were producing a board based on the arm720t core, target price $99 |
| 21:23:39 | erikm | prpplague: I'm not sure what really is the problem, but I guess part of it is due to the recesion in the US |
| 21:25:05 | Russ|werk | I'm really hoping that the recession starts to end around may |
| 21:25:25 | Russ|werk | so all the companies that laid off their old engineers are looking for new ones |
| 21:25:58 | erikm | Russ|werk: you'll graduate in may? |
| 21:26:57 | prpplague | BZFlag: we accepted andersee's quote on the c++ support for uclibc |
| 21:27:07 | prpplague | BZFlag: going to have to wait for pthreads |
| 21:27:39 | Russ|werk | erikm: yup |
| 21:27:40 | prpplague | Russ|werk: everyone is talking about recession, but aren't seeing it here |
| 21:28:06 | prpplague | Russ|werk: we just hired 5 more ppl, and the entire month of jan is booked with installations |
| 21:28:08 | Russ|werk | prpplague: it looks like a ressecion, smells like one, and greenspan says its one |
| 21:28:17 | prpplague | Russ|werk: lol |
| 21:28:22 | Russ|werk | prpplague: from looking at numbers, they say it started around last may |
| 21:28:25 | erikm | prpplague: it's not everywhere. there is still a lot to do in embedded stuff, but telco is a bit less |
| 21:28:42 | Russ|werk | prpplague: motorola annonced today they are laying off 8.4% |
| 21:28:42 | prpplague | true |
| 21:29:36 | prpplague | Russ|werk: ok point taken, alot of ppl and out of jobs right now, but i think that it'll bounc back soon |
| 21:30:33 | Russ|werk | I hope a lot of it is artifical economic slow down (fears, etc) |
| 21:30:50 | prpplague | i think thats alot of it |
| 21:30:59 | Russ|werk | http://news.ft.com/ft/gx.cgi/ftc?pagename=View&c=Article&cid=FT35AOM7EVC&live=true&tagid=IXLYK5HZ8CC |
| 21:31:01 | prpplague | is not an economic guru |
| 21:31:34 | Russ|werk | I blame clinton for a lot of things |
| 21:32:19 | Russ|werk | he apologised and made peace with the al queda somoli leader after the black hawk down incident |
| 21:35:54 | erikm | Russ|werk: well, the US has made more of those mistakes. iraq's hussein, panama's noriega, etc. |
| 21:39:03 | Russ|werk | noriega was "fixed" |
| 21:39:28 | erikm | Russ|werk: at quite some costs, yes. |
| 21:39:53 | erikm | actually liked the way they got him out of the vatican embassy :) |
| 21:40:02 | Russ|werk | but this war lord attacked and destroyed UN food convoys, when special forces were sent to "remove" him and his leadership, their mission failed because they were attacked by his forces |
| 21:40:31 | Russ|werk | after the incident, clinton apologized to the leader |
| 21:41:32 | erikm | digs into the stack of newspapers |
| 21:41:45 | erikm | there was something about that last saturday... |
| 21:42:08 | Russ|werk | I think there are probably a lot of similar such incedents where clinton could have done something more about al quiada (sp), but didn't, because it would mean american soldiers dying |
| 21:42:48 | Russ|werk | a "no foriegn policy is good foreign policy" approach |
| 21:43:20 | erikm | Russ|werk: well, you have to be honest: one of bush points in his campaign was to decrease the level of foreign policy even further |
| 21:44:01 | erikm | Russ|werk: and the main reason is because foreign policy doesn't give you any votes |
| 21:44:09 | Russ|werk | not really, it was to reduce a lot of the older elements of military, but invest in higher tech stuff |
| 21:44:20 | Russ|werk | (ie, missile defense) |
| 21:44:47 | erikm | Russ|werk: but as the only remaining super power in the world, the US just can't affor not to use it |
| 21:45:05 | Russ|werk | the hope is, if you have some form of missile defense, you no longer need the mutually assured descruction policy, and you can get rid uf your arsenal |
| 21:45:50 | erikm | Russ|werk: wake up. the soviet union is no more. there is no such thing anymore as "mutually assured destruction" |
| 21:46:16 | Russ|werk | *cough*china*cough* |
| 21:46:51 | erikm | Russ|werk: china is not your largest problem. terrorists and rogue states are. |
| 21:47:32 | Russ|werk | I think missile defense is a much more long term plan, ie, 20 years |
| 21:48:42 | erikm | Russ|werk: I'm not against misile defense or "star wars", as long as it's used wisely |
| 21:48:46 | Russ|werk | the world is likely to be as different today 20 years from now as it was 20 years ago |
| 21:48:54 | erikm | no doubt about that |
| 21:49:12 | Russ|werk | I don't think missile defense will do much if anything against terrorism |
| 21:50:01 | erikm | well, the "star wars" missile shield would certainly help against the bin ladens with nuclear missiles in this world |
| 21:50:38 | Russ|werk | I'd think they'd go for something else, like the palo verde plant |
| 21:51:18 | Russ|werk | 6th largest city in the US sitting next to the largest nuculear plant in the free world |
| 21:52:11 | erikm | googles |
| 21:52:47 | erikm | that would indeed be an easy target |
| 21:53:32 | Russ|werk | my dad's been in there (sales) |
| 21:53:42 | erikm | anything within any open country is actually an easy target |
| 21:53:52 | Russ|werk | luke AFB is right next to it though |
| 21:54:26 | erikm | who is luke AFB? |
| 21:55:09 | Russ|werk | largest traininf facility for F16 pilots |
| 21:55:16 | erikm | ah |
| 21:55:41 | Russ|werk | they seem to fall out of the sky quite a bit |
| 21:55:46 | erikm | oh? |
| 21:56:17 | erikm | we didn't have that anymore. they fell out of the sky about 10 years ago, but I haven't heard about it lately |
| 21:57:04 | Russ|werk | it hasn't happened it about a year, but I think there were 8 incidents in a years time |
| 21:57:30 | erikm | last plane that fell out of the sky was a german tornado a month ago. luckily above see, so nobody got hurt |
| 21:58:01 | erikm | s/see/sea/ |
| 21:58:14 | Russ|werk | we had a guy drop his fuel tank when his plane was starting to go down, it landed in the bed of a pickup truck wating at an intersection |
| 21:58:35 | erikm | oops :( |
| 21:59:49 | erikm | well, I remember an F16 crashed in a street. it was a miracle it didn't crash on top of a house, but all houses in the street were severely damaged. again, nobody got hurt because most people were at work |
| 22:00:38 | Russ|werk | http://www.jetsafety.com/images/photo5/nmac.jpg |
| 22:00:40 | Russ|werk | wheee |
| 22:01:42 | erikm | what do I see over there? is that a cessna-ish plane in the upper left corner? |
| 22:01:47 | Russ|werk | yup |
| 22:01:55 | erikm | but what about the rest? |
| 22:02:17 | Russ|werk | its the HUD of an F16 |
| 22:02:32 | erikm | ehm oops. so it's pretty close |
| 22:04:23 | Russ|werk | anyway, if they have a big "LF" on the tail, its from here |
| 22:20:02 | erikm | OK, I coded up an initial bootldr partition table parser. it's nowhere near to functional, but should I commit the code already? |
| 22:20:20 | erikm | (but it compiles without errors) |
| 22:22:24 | Russ|werk | oh, I did a bootldr thing too |
| 22:22:38 | Russ|werk | I made a patch so that there is an offset in blob to the bootldr parition offset |
| 22:22:58 | Russ|werk | so you hardcode the location of a member of the PTAG head into blob |
| 22:23:24 | Russ|werk | and set thet paramater to the offset of the bootldr partition table when you write the tags (the partition table is a tag) |
| 22:23:35 | Russ|werk | its just a small patch to bootldr.c |
| 22:23:47 | erikm | I don't understand the bootldr partition offset thing |
| 22:24:09 | erikm | I mean: I think I know what it does, but I don't like it |
| 22:24:27 | Russ|werk | I do something different |
| 22:24:30 | erikm | is that the patch you send to linux-arm-kernel? |
| 22:24:48 | Russ|werk | http://russ.dhs.org/files/tuxpatches/patch-2.4.16-rmk2-tux1.gz |
| 22:25:00 | Russ|werk | search it for bootldr |
| 22:25:07 | Russ|werk | should be able to stream to your browser |
| 22:25:20 | erikm | already used wget |
| 22:28:22 | Russ|werk | you just make a ptag and boot the bootldr partition table in there |
| 22:28:37 | erikm | hmmm |
| 22:30:04 | Russ|werk | you need to put the bootldr magic at 0x10 in blob or some such address |
| 22:31:01 | erikm | that's what I don't like |
| 22:31:13 | prpplague | later guys, got to go do the christmas party thing |
| 22:31:29 | erikm | I just want to put the partition table at the start of an erase block |
| 22:31:39 | erikm | later, prpplague |
| 22:31:43 | erikm | hmm, too late :( |
| 22:31:55 | Russ|werk | naw, put it in with the tags |
| 22:32:28 | erikm | no, I see them separately |
| 22:32:52 | Russ|werk | they should be in the same erase block |
| 22:33:00 | erikm | yes, that's no problem |
| 22:33:34 | Russ|werk | so you want to put it at the start of the block, and paramaters right after that? |
| 22:33:47 | Russ|werk | it make sense to me just to drop it in as a param |
| 22:34:06 | erikm | no, it makes it much more difficult for the kernel to find the partition table |
| 22:35:08 | Russ|werk | you mean, something like putting a magic in the partition table, and scanning the start of each erase block for that? |
| 22:35:27 | erikm | yes, because the partition table already *has* a magic value |
| 22:37:19 | Russ|werk | then it wouldn't be in a fixed position, which would probably be a good thing |
| 22:37:40 | Russ|werk | but then how do you decide how far to offset the paramater block from the start of the erase block? |
| 22:37:54 | Russ|werk | 0x1000? |
| 22:37:57 | erikm | for example |
| 22:37:59 | Russ|werk | 0x800? |
| 22:38:14 | erikm | anything should be OK, as long as blob knows where to find it |
| 22:38:32 | erikm | the kernel doesn't have to know where to find it |
| 22:39:04 | erikm | besides, having the partition table not in the params stuff makes it possible to put the params on a jffs2 partition |
| 22:39:49 | erikm | thinks he doesn't have to answer the cs89x0 question anymore :) |
| 22:44:07 | Russ|werk | erikm: hows that? |
| 22:44:30 | Russ|werk | erikm: if it was in the jffs2 partition, it wouldn't be at the start of the erase block |
| 22:44:33 | erikm | Russ|werk: cause both you and jdb already answered it :) |
| 22:45:08 | erikm | Russ|werk: no, but if it was in a jffs2 partition, blob had no way to figure that out at all. chicken vs. egg |
| 22:46:35 | Russ|werk | oh, for some reason I thought you said partition, not params |
| 22:46:40 | erikm | anyway, I almost got to go. I'll commit my flash partition stuff, so you can comment on it |
| 22:47:22 | Russ|werk | cya |
| 22:52:39 | erikm | done. cya |
