| 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 |