01:13:30 | Sammy | morning all... |
03:46:58 | Sammy | Russ :help me some doc or place to know about download kernel and ramdisk in flash ... still indistinct |
04:00:42 | BZFlag | Sammy: define mtd partitions in blob and in the kernel. blob is in the first, normally the kernel is in the second and the ramdisk/ramfs is in the third. |
04:01:33 | BZFlag | the kernel and ramdisk get loaded by blob into memory and then a kernel parameter struct is created. it is passed into the kernel when the kernel is started. |
04:01:59 | BZFlag | it contains the location of the initrd (ramdisk, if any) and the rootfs device to mount. |
04:03:09 | BZFlag | the kernel is normally run from ram, but stored in flash. so blob copies it into ram. |
04:03:29 | BZFlag | if you are using an initrd, it to would be normally stored in flash, but copied to ram. |
04:03:56 | BZFlag | if you just have a rootfs, then no initrd is copied, the kernel just mounts the rootfs. |
04:26:39 | Sammy | thanx BZFlag , but some phrase still don't get what it mean , let me find out first and ask you later ...^_^ |
07:57:52 | erikm | morning |
13:59:08 | prpplague | howdy |
14:03:28 | erikm | hi |
14:06:39 | prpplague | thanks for the help yesterday, got blob booting up, still some kinks to work out, but i'm on the right path |
14:07:51 | erikm | cool. already got a blob> prompt? |
14:08:35 | prpplague | ya, looks good |
14:09:45 | erikm | heya Russ |
14:10:12 | erikm | Russ|werk: prpplague over here chain booted into blob :) |
14:12:00 | prpplague | erikm: i was going to ask about doing a DEFINE on the default baud rate for the blob console, was there reason that wasn't done? |
14:12:52 | erikm | no reason. the 9600 baud has a rationale, though |
14:13:36 | prpplague | the lack of flow control on some of the sa uarts? |
14:13:52 | erikm | easier: it's the de facto unix standard |
14:14:17 | erikm | every unix compatible terminal will work with it |
14:14:32 | erikm | even old VT100 terminals (yes, we *do* use that) |
14:14:53 | prpplague | i see your point |
14:16:34 | erikm | as soon as we get proper param block support, we will support different terminal speeds, but default will always be 9600 baud |
14:17:31 | prpplague | well i sure have to hand it to you, i really like blob |
14:18:05 | prpplague | how far off is support for flash partitioning? |
14:18:58 | erikm | we certainly want support for it, but I'm not yet sure how to do it |
14:21:10 | erikm | we currently have bootldr and redboot partitioning. |
14:21:47 | erikm | I usually don't favor the bootldr way of solving problems. most of the time they don't think before implementing |
14:22:10 | erikm | I haven't looked at redboot partitioning, though |
14:23:13 | prpplague | ya, i've seen those options in the kernel config, thats one thing i like about this native bootloader on the ELF, is that it seems to have a nice partitioning scheme |
14:24:03 | erikm | if you can figure out how it works we might be able to use it |
14:24:12 | erikm | if it is sane, though |
14:26:23 | prpplague | got all the specs |
14:26:42 | prpplague | and initital permission to turn it into GPL |
14:27:06 | erikm | that helps a lot |
14:28:19 | prpplague | i plan on learning as much as i can about blob, so i hope i don't drive you guys too crazy... |
14:37:05 | erikm | no problems so far |
14:37:18 | erikm | at least you know what you're doing |
14:38:01 | erikm | I've had questions from people who really didn't understand what they were doing but were just given the assignment to port blob |
14:41:54 | prpplague | thanks, i appreciate the compliment |
16:38:20 | prpplague | erikm: got a question... |
16:39:32 | Russ|werk | ask away |
16:39:55 | prpplague | erikm: in the main.c file under the Reload function the variables "src" and "dst" are assigned and then MyMemCpy is called |
16:40:15 | erikm | yes |
16:40:58 | prpplague | from what i'm reading src is actually the ram location being copied to, and dst is the flash location being copied from |
16:41:09 | erikm | looks |
16:43:40 | erikm | uhm, yes, that's confusing |
16:43:54 | erikm | src and dst should be swapped |
16:44:17 | erikm | I'll fix it in CVS |
16:45:43 | prpplague | thanks, just wanted to make sure i wasn't crazy |
16:48:55 | erikm | fix is in CVS |
16:50:15 | erikm | prpplague: you might want to check out the latest CVS version to see what we're doing right now |
16:51:11 | erikm | prpplague: it has a completely new command line parser, and the start of the parameter blocks |
16:51:56 | Russ|werk | nice commit |
16:52:26 | erikm | Russ|werk: yeah, thanks to prpplague |
16:53:05 | erikm | Russ|werk: I really didn't see it, I think I wrote that function two years ago |
16:54:30 | prpplague | erikm: thanks, i'll probably stick with the stock 2.0.4 for a week or so, until i have a better feel for things |
16:55:44 | erikm | prpplague: hey, I didn't say that you should immediately use the CVS version :) |
16:55:53 | erikm | Russ|werk: another crazy idea I got: |
16:55:59 | Russ|werk | good |
16:56:41 | erikm | make an init ELF section into which components can register their init function |
16:56:43 | erikm | an an exit ELF section as well |
16:57:01 | Russ|werk | what functions would do that |
16:57:28 | erikm | for example the i-cache functions |
16:57:35 | erikm | or the serial init |
16:57:52 | Russ|werk | it didn't seem to cluttered to me, yet |
16:58:04 | erikm | that's right |
16:58:27 | Russ|werk | but it might help other arch's/boards that need special init functions |
16:58:40 | erikm | but suppose we add bootp+tftp |
16:58:49 | Russ|werk | I don't know what those functions would be |
16:59:05 | Russ|werk | I was thinking bootp/tftp would be done by paramater blocks |
16:59:14 | erikm | not all boards want that. so instead of making #ifdef WANT_BOOTP init_bootp() #endif, we just call it |
16:59:42 | erikm | somehow the network card needs to be initialised for that |
16:59:53 | erikm | and that's where the init call could come in handy |
17:00:33 | erikm | or suppose somebody wants framebuffer support with a splash screen |
17:00:34 | Russ|werk | yah, special hardware on a board |
17:00:53 | Russ|werk | erikm: splash screen is handled *very* well by a paramater block |
17:01:07 | erikm | parameter blocks don't execute code |
17:01:18 | erikm | s/don't/shouldn't/ |
17:01:26 | Russ|werk | erikm: they have associated code that excecutes when a tag is found |
17:01:39 | erikm | doesn't like that |
17:01:45 | Russ|werk | like when a splash screen is found, its loaded |
17:02:02 | Russ|werk | or when a option to load a kernel from tftp is found, its loaded from tftp |
17:02:08 | erikm | it should be a pure parameter list, not some kind of java |
17:02:26 | Russ|werk | its not really java, but it is an instruction list |
17:03:00 | erikm | that's the part I don't like about it |
17:03:06 | Russ|werk | hmmm |
17:03:23 | Russ|werk | it seemed a much cleaner and expandable implementation that way |
17:04:23 | Russ|werk | with it being all setting variables, if you want to add something, you have to add the global, add a initization for it, add a function that sets it when the block is read, and a function that does whatever it is |
17:04:46 | Russ|werk | with the paramater blocks actually "doing things" you just need one function |
17:05:25 | erikm | well, then rename the stuff into "macro blocks" |
17:05:32 | erikm | because that's what it is |
17:05:44 | erikm | a parameter is different |
17:05:47 | Russ|werk | its what the kernel seems to do with some of the blocks |
17:05:57 | erikm | not really |
17:06:00 | Russ|werk | (ie, setup mem zones) |
17:07:18 | Russ|werk | might make it more difficlut to implement a dynamic configuration based on just variables |
17:07:22 | erikm | brb, hooking up the netwinder |
17:07:33 | Russ|werk | (ie, if a gpio is set, or if tftp fails) |
17:09:30 | prpplague | is away: need more coffee |
17:15:34 | prpplague | is back (gone 00:06:04) |
17:41:15 | prpplague | is away: lunch |
17:54:28 | Russ|werk | morning tim |
17:54:41 | Russ|werk | did you get a chance to see if those extra options were what you needed? |
17:56:08 | erikm | returns |
17:56:16 | BZFlag | nope. crazy weekend. sorry. I will test it soon. |
17:56:58 | erikm | netwinder hooked to keyboard switch, new NeTTrom flashed |
18:20:54 | jpdmarques | Hi guys, |
18:21:28 | erikm | hi |
18:21:29 | jpdmarques | I was reading the Blob source code to see if I could port it to the CerfBoard ... |
18:21:54 | erikm | Cerf is sa1100, IIRC, right? |
18:22:04 | jpdmarques | The main problem concerns the registers for the SDRAM and Flash ... whta's the best approach to find the proper values? |
18:22:18 | jpdmarques | Cerf is SA1110 |
18:23:08 | erikm | well, I'm currently working on proper SA1110 support for assabet. once that's up, other archs should be easier |
18:23:20 | jpdmarques | The file in question in memsetup.S (mdcas00, mdcas20) |
18:23:39 | Russ|werk | just read your data sheets |
18:23:47 | Russ|werk | its very well documented |
18:23:51 | erikm | Russ|werk: that's what I'm doing right now :) |
18:24:10 | erikm | Russ|werk: and putting debian-arm on the netwinder at the same time |
18:25:24 | jpdmarques | Humm, ok, the StrongArm developers Guide? |
18:25:41 | erikm | yes, the sa1110 guide |
18:25:56 | erikm | and having a micron SDRAM data sheet also helps |
18:26:04 | jpdmarques | Damn, 5MB ... :) |
18:26:33 | erikm | (micron data sheets are written in plain english, while asian stuff is usually written in jinglish) |
18:38:36 | prpplague | is back (gone 00:57:21) |
18:40:59 | prpplague | jpdmarques: what kinda of bootloader does the cerfboard linux sdk ship with? |
18:41:41 | jpdmarques | Hi don't know ... |
18:41:58 | jpdmarques | The boads they shipped me came with Windows CE preloaded |
18:43:33 | erikm | hmm, BZFlag might have a clue about that |
18:44:16 | jpdmarques | Intrinsyc Software uCErfSA1110 Linux Loader, Executing at 0xC07D003C, Setting stack to 0xC0800000, ... |
18:44:43 | jpdmarques | They promessed that they would release the source code one month one, still nothing. |
18:49:10 | prpplague | jpdmarques: ya i don't see anything on their web site about downloads |
18:49:42 | jpdmarques | They have a group at yahoo.com (CerfCube). |
18:50:01 | jpdmarques | Downloads, try www.cerfcube.com. |
19:00:52 | prpplague | thanks i'll have a look |
19:01:15 | prpplague | i'm working on the ELF from www.inhandelectronics.com |
19:01:32 | prpplague | brb |
19:06:44 | jpdmarques | Nice board! |
19:14:33 | prpplague | jpdmarques: ya i like it, it just needs a little work to get it running linux smoothly |
20:49:01 | prpplague | erikm: i don't suppose you guys have a tarbar with all the info on producing a the lart boards, or do i have to download each individual doc? |
20:49:28 | erikm | prpplague: no tarballs, sorry |
20:50:33 | prpplague | ok thanks, my pcb sub-contractor is interested in looking at the lart stuff for production |
20:52:52 | erikm | talk to jdb |
20:53:51 | erikm | jdb == jan-derk bakker |
20:54:01 | erikm | you'll find his email address in the blob sources |
20:54:48 | prpplague | ya, i was just looking at his page "I am notoriously slow in answering letters" |
20:56:05 | erikm | depends if they're on topic |
20:56:37 | erikm | just CC your question to me |
20:56:43 | erikm | so I can remind him |
20:56:46 | erikm | goes zzz |
20:56:48 | erikm | bye |
21:44:08 | prpplague | later |