| 00:27:08 | Sammy | morning |
| 08:10:20 | seletz | Hello? Im new to IRC :) and wondering if i'm connected or not ... |
| 08:12:28 | erikm | hi * |
| 08:12:29 | seletz | |
| 08:12:45 | seletz | Hi, finally mad it to irc :) |
| 08:12:51 | erikm | hehe |
| 08:13:12 | seletz | Wondering if i'n now to be called "nerd" :)) |
| 08:13:48 | erikm | depends on how you use IRC |
| 08:14:11 | seletz | well *this* is my fourth post, anyway .... it works. |
| 08:16:10 | Sammy | hi all :-) |
| 08:17:27 | erikm | gets coffee |
| 08:17:48 | seletz | did anyone read my post about SA1110 power-up on linux-arm-kernel? |
| 08:23:34 | Sammy | about what ? |
| 08:24:34 | seletz | Well, I'm trying to understand the power-up procedure for an SA 1110, and kook BLOB/CVS as an example. |
| 08:25:07 | seletz | Wondered why Section 10.7.1 of SA1110 dev manual is not performed |
| 08:25:15 | seletz | in BLOB i mean |
| 08:41:26 | erikm | seletz: sorry, not yet |
| 08:42:24 | erikm | reads |
| 08:43:35 | erikm | seletz: the answer is simple: not yet done :) |
| 08:44:28 | erikm | seletz: last weekend I did the necessary steps to make the memory setup even more modular |
| 08:45:07 | erikm | seletz: but I couldn't get the assabet up |
| 08:45:21 | erikm | seletz: I think it will work right now with the serial port fix |
| 08:45:55 | erikm | seletz: last weekend I was stuck because I thought it was a memory problem |
| 08:48:20 | seletz | erikm: well, as you probably know, i have problems with my board, probably due to HW errors (which i have to proove first go get my HW guru blamed :^/ ) |
| 08:49:14 | seletz | erikm: now i try to get evrything properly configured during startup and this i _think_ i need |
| 08:49:59 | seletz | erikm: this startup procedure. So i coded a little but my CPU just gave me a no-go :(, perhaps due to my |
| 08:50:17 | seletz | erikm: limited arm asm knowledge .... |
| 08:50:18 | erikm | seletz: no go as in what? |
| 08:50:51 | seletz | erikm: as in "nothing happens", no startup, just _nothing_. No led either. |
| 08:51:51 | seletz | erikm: i _got_ blob/CVS to start and i could see the autoboot starting via serial line (after your patch yesterday) |
| 08:53:19 | seletz | erikm: but when i chage memsetup-sa1110.S to perform power up reset procedure as in 10.7.1 it does not work anymore. |
| 08:54:34 | seletz | erikm: Maybe i'm _completely_ wrong and this procedure is not needed at all? |
| 08:59:03 | erikm | seletz: possible |
| 08:59:16 | erikm | seletz: the sa1110 is a bit cryptic on points |
| 08:59:21 | erikm | sa1100 manual |
| 08:59:28 | erikm | ehm sa1110 manual |
| 08:59:38 | seletz | erikm: yes. :( |
| 08:59:58 | erikm | the tip I got from rmk is to get a micron SDRAM data sheet |
| 09:00:44 | seletz | erikm: sorry, but what for? To verify the state diagram (_yuck_) or what? |
| 09:01:00 | erikm | it explains the states and transitions better, so it makes it easier to understand the sa1110 manual |
| 09:01:37 | seletz | ericm: hrmpf, i'll google it. Lets see if they have some PDF ... |
| 09:01:49 | erikm | and micron is the only sdram supplier I know that has data sheets in proper english |
| 09:01:54 | erikm | www.micron.com |
| 09:02:15 | erikm | I can dcc you the data sheet |
| 09:03:58 | seletz | well, dcc. Hmm. Sorry, i'm new to irc. What's that? |
| 09:04:25 | erikm | oh, sorry. send files via IRC |
| 09:04:57 | seletz | OK, lets see if my client can handle this.... give it a try, please. |
| 09:05:06 | erikm | I offer the file to you with /dcc send <nick> <file>, you can accept it with /dcc get <nick> |
| 09:06:06 | seletz | well, i'rather read a irq FAQ _quickly_. Ok, do i get som info msgs when yoe offer the file? |
| 09:06:27 | erikm | I'll send you the file, you just type /dcc get erikm |
| 09:07:58 | Sammy | is setting his DNS server |
| 09:08:10 | seletz | Woha! Worked! |
| 09:08:21 | seletz | Thak you! |
| 09:08:26 | erikm | np |
| 09:10:37 | seletz | Now i have something to dig through.... 52p phew. |
| 09:13:46 | Sammy | erikm : I do something that you say , do you get it ? |
| 09:23:08 | erikm | yes, but I was on the phone |
| 09:23:52 | erikm | lunch time |
| 09:23:54 | erikm | bbl |
| 09:26:12 | Sammy | is dcc a file to erikm... |
| 10:07:55 | erikm | returns |
| 10:10:08 | Sammy | erikm : do you get my file ? |
| 10:10:36 | erikm | no |
| 10:12:25 | Sammy | do you type /dcc get <sammy> |
| 10:24:50 | erikm | no, because I was on the phone again |
| 11:14:08 | erikm | is soldering some PCBs |
| 11:14:47 | erikm | I switched my laptop to wavelan, let's hope I can still reach the base station |
| 12:22:04 | GiuseppeOttaviano | Hi |
| 12:23:59 | erikm_soldering | hello |
| 12:24:55 | GiuseppeOttaviano | will ever be supported by blob the loading of a kernel on a JFFS2 partition? |
| 12:26:37 | erikm_soldering | GiuseppeOttaviano: yes, Russ has patches for that. |
| 12:26:43 | erikm_soldering | GiuseppeOttaviano: it's just a matter of time before we start integrating |
| 12:27:12 | erikm_soldering | GiuseppeOttaviano: the most important issues right now are proper sa1110 support |
| 12:27:17 | erikm_soldering | and parameter support |
| 12:28:01 | GiuseppeOttaviano | ok, thanks; i noted on the lart mailinglist that were released patches for that for the 1.0.8 version, so I thought there already was 2.0.4 support... |
| 12:28:18 | GiuseppeOttaviano | aren't already tag parameters supported in 2.0.4? |
| 12:28:28 | erikm_soldering | that are kernel parameter tags |
| 12:28:37 | erikm_soldering | which were already in 2.0.3 |
| 12:28:48 | erikm_soldering | I'm talking about blob parameters |
| 12:29:10 | erikm_soldering | like set default-cmdline="root=/dev/ram" |
| 12:29:24 | erikm_soldering | and set timeout=2 |
| 12:30:27 | GiuseppeOttaviano | ok, I understood |
| 12:30:29 | GiuseppeOttaviano | thanks |
| 12:30:32 | erikm_soldering | GiuseppeOttaviano: but if you want to port Russ 1.0.8 patch to 2.0.4, be my guest |
| 12:30:44 | prpplague | morning all |
| 12:30:53 | erikm_soldering | hu prpplague |
| 12:30:55 | erikm_soldering | ehm, hi |
| 12:31:53 | prpplague | erikm_soldering: hmmm, nothing like the smell of hot solder in the morning.... |
| 12:32:05 | GiuseppeOttaviano | erikm_soldering: unfortunately lately my linux box has some problems (i can't manage to connect with my modem :-( so i haven't yet an arm toolchain... and I have no time to solve it (ah, the school...) |
| 12:32:07 | GiuseppeOttaviano | :-(( |
| 12:32:13 | GiuseppeOttaviano | what are you soldering? |
| 12:32:28 | erikm_soldering | gyroscopes |
| 12:32:33 | erikm_soldering | 2.5x2.5 cm |
| 12:32:43 | erikm_soldering | and a KSB |
| 12:33:27 | GiuseppeOttaviano | what's the status of CreditLART? I would be much interested about it |
| 12:34:00 | erikm_soldering | we have two prototypes, which don't work with sa1111 |
| 12:34:13 | Sammy | Amm ,,, what is gyroscopes |
| 12:34:18 | erikm_soldering | so we removed the sa1111, and then jdb got ill |
| 12:34:24 | erikm_soldering | so no testing yet |
| 12:34:44 | erikm_soldering | Sammy: used to measure rotation |
| 12:34:58 | erikm_soldering | Sammy: or actually, speed of rotation |
| 12:35:16 | GiuseppeOttaviano | what gyroscopes do you use? |
| 12:35:30 | Sammy | ya... |
| 12:35:42 | erikm_soldering | Sammy: so you get a voltage out of it which is linear with the speed of rotation (xx degrees/second) |
| 12:35:44 | Sammy | that's what I ask ... |
| 12:35:58 | GiuseppeOttaviano | erikm_soldering: ehm, not so linear :-)) |
| 12:36:13 | erikm_soldering | GiuseppeOttaviano: murata 03JA |
| 12:36:47 | erikm_soldering | GiuseppeOttaviano: linear enough for the range we use them in |
| 12:37:44 | prpplague | erikm_soldering: have you seen this mornings post on the linux-arm mailing list subject:AXF-bootload? |
| 12:37:56 | GiuseppeOttaviano | erikm_soldering: do you use some kind of filtering for very-low frequency noise? |
| 12:38:42 | erikm_soldering | prpplague: I haven't read linux-arm yet |
| 12:39:19 | erikm_soldering | GiuseppeOttaviano: could you specify very-low-frequency noise? |
| 12:39:27 | prpplague | erikm_soldering: ahh, just wanted your $.02 on that, maybe later... |
| 12:40:56 | GiuseppeOttaviano | If I'm not wrong, gyroscopes (and accelerometers) suffer of a very-low frequency noise (IIRC in the order of millihertz), that could affect the measurements. But I'm not sure |
| 12:40:57 | erikm_soldering | prpplague: oh, that post. ignore it. probably some kind of propriatary linux system |
| 12:41:58 | erikm_soldering | GiuseppeOttaviano: oh, ok. yeah, we just did a 8388608 points FFT on our 100 Hz sample data |
| 12:42:15 | erikm_soldering | (that's almost a day of data). we could see it |
| 12:42:31 | GiuseppeOttaviano | ah, ok |
| 12:42:43 | GiuseppeOttaviano | I wanted to know that :-) |
| 12:43:19 | GiuseppeOttaviano | 8388608 points? quite many :-) |
| 12:43:26 | prpplague | erikm_soldering: those guys are working on the same board i am, rather than make the bootloader linux friendly, they are trying to patch/modify the kernel |
| 12:43:27 | erikm_soldering | but the guys who are going to use it can't be bothered with it |
| 12:43:46 | erikm_soldering | (sorry, that was for GiuseppeOttaviano) |
| 12:44:23 | Sammy | about the Russ jffs2 patches , where can find it with some howto ? |
| 12:44:58 | erikm_soldering | GiuseppeOttaviano: because we compensate the noise with input from accelerometer, magneto or inclinometer and GPS |
| 12:45:28 | erikm_soldering | prpplague: well, just tell him to use a standard kernel and use your blob modifications |
| 12:45:33 | GiuseppeOttaviano | well, 100*3600*24 is 8640000, am I missing something? |
| 12:46:08 | erikm_soldering | GiuseppeOttaviano: yes. but for speed up FFT wants the number of samples a power of 2 |
| 12:46:21 | erikm_soldering | GiuseppeOttaviano: so that's 2^23 |
| 12:46:52 | GiuseppeOttaviano | If you have a gps and an inclinometer why don't you use an electronic compass? You have a complete knowledge of the position and everything else |
| 12:47:12 | GiuseppeOttaviano | erikm_soldering ok, I understood |
| 12:47:31 | erikm_soldering | GiuseppeOttaviano: because an eletronic compass gets distorted by other electric equipment |
| 12:47:47 | erikm_soldering | GiuseppeOttaviano: electronic compass == magnetometer |
| 12:48:07 | Sammy | ohh... so deep ... |
| 12:48:33 | erikm_soldering | Sammy: IIRC Russ posted it to the lart list, and there is no howto |
| 12:48:40 | GiuseppeOttaviano | right, I didn't think about it |
| 12:49:06 | erikm_soldering | Sammy: but his patch is not necessary to use JFFS2 with the kernel, it only allows blob to pick up a kernel image from a JFFS2 filesystem in flash |
| 12:49:27 | prpplague | erikm_soldering: they've been less than friendly, anyway it is a dead issue, the manufacture of the board is making changes to the default bootload to support linux properly, AND adding support for blob as a secondary bootloader |
| 12:50:32 | erikm_soldering | prpplague: so they're going to help you? |
| 12:50:46 | GiuseppeOttaviano | erikm_soldering: and it's better to have the kernel in the jffs2 partition :-) it's more pc-like |
| 12:50:55 | Sammy | need's to get more knowledge in study this (kernel , jffs2 ,ramdisk ) |
| 12:51:19 | erikm_soldering | GiuseppeOttaviano: well, it's not better per se. it saves flash space, which may or may not be a good thing |
| 12:51:45 | erikm_soldering | GiuseppeOttaviano: and pc-like is also not always a good thing. see the ACPI crap the PC world just got into |
| 12:52:11 | erikm_soldering | GiuseppeOttaviano: (300k of code only to detect the state of a single power switch is NOT the way to do it) |
| 12:52:12 | GiuseppeOttaviano | erikm_soldering: ok, you're right :-)) |
| 12:52:43 | prpplague | erikm_soldering: ya InHand( board manufacture) has said "we consider the fact that or bootloader doesn't support linux properly, a design flaw. we will make any nessary changes needed to support linux properly." |
| 12:53:39 | erikm_soldering | prpplague: that's the *last* thing we want |
| 12:53:45 | erikm_soldering | prpplague: another boot loader |
| 12:54:25 | GiuseppeOttaviano | How is redboot? |
| 12:54:41 | erikm_soldering | prpplague: in case I didn't tell you, Russ, BZflag and I have a secret goal: to make blob so good that it obsoletes redboot and bootldr |
| 12:54:42 | prpplague | erikm_soldering: true, but the fact they are willing to work with us is a big plus in my book |
| 12:54:52 | GiuseppeOttaviano | what are the advantages/disadvantages vs blob? |
| 12:54:53 | erikm_soldering | prpplague: but: sssssshh :) |
| 12:55:23 | prpplague | erikm_soldering: i main not be guru like you guys, but i plan on adding my support for that goal |
| 12:55:40 | prpplague | s/main/may (not enough coffee yet) |
| 12:55:44 | erikm_soldering | GiuseppeOttaviano: advantage: boots from network. disadvantages: supports less architectures, very complicated setup, bloated |
| 12:56:31 | erikm_soldering | GiuseppeOttaviano: oh, and redboot supports parameters |
| 12:56:41 | GiuseppeOttaviano | Does it mean that I can load kernel/ramdisk via ethernet? I can't tolerate the slowness of serial port :-) |
| 12:56:54 | erikm_soldering | GiuseppeOttaviano: if you can get it to work, yes it does |
| 12:57:33 | erikm_soldering | GiuseppeOttaviano: but that's also on the to do list. I already have dhcp and tftp code from busybox, only have to write a simple networking layer |
| 12:58:02 | GiuseppeOttaviano | uhm, this implies ethernet nic support, tcp/ip stack, other stuff... how is big redboot (sources and compiled code)? |
| 12:59:05 | erikm_soldering | GiuseppeOttaviano: problem is that redboot needs ecos to run and ecos source is... |
| 12:59:08 | erikm_soldering | does du -hs |
| 12:59:12 | erikm_soldering | 61MB |
| 12:59:37 | erikm_soldering | GiuseppeOttaviano: redboot is actually an ecos application |
| 12:59:40 | GiuseppeOttaviano | redboot runs over ecos or it takes source parts from ecos? |
| 12:59:46 | erikm_soldering | GiuseppeOttaviano: yes |
| 12:59:59 | GiuseppeOttaviano | ah, it would be like blob running over linux :-)) |
| 12:59:59 | erikm_soldering | GiuseppeOttaviano: so that's why I consider it bloated |
| 13:00:04 | erikm_soldering | GiuseppeOttaviano: yes |
| 13:00:20 | erikm_soldering | GiuseppeOttaviano: so adding dhcp and tftp to ecos was quite easy |
| 13:00:28 | GiuseppeOttaviano | we could even do loading and root over an hard disk using it :-)) |
| 13:00:30 | erikm_soldering | s/ecos/redboot/ |
| 13:01:16 | GiuseppeOttaviano | so if you don't configure properly ecos.... :-) |
| 13:02:00 | GiuseppeOttaviano | let me understand, if i want to load linux: s/ecos/redboot/linux? |
| 13:02:50 | GiuseppeOttaviano | a kernel supersedes another? :-) |
| 13:04:25 | erikm_soldering | GiuseppeOttaviano: possible in theory, but you forget about the blob paradigm: Keep It Simple, Stupid! |
| 13:04:58 | erikm_soldering | GiuseppeOttaviano: here is my favorite quote about it: |
| 13:04:59 | prpplague | i'm interested in being able to pull kernel/initrd from a fs on a cf/pcmcia card |
| 13:05:04 | erikm_soldering | You know you've achieved perfection in design, not when you have |
| 13:05:04 | erikm_soldering | nothing more to add, but when you have nothing more to take away. |
| 13:05:04 | erikm_soldering | -- Antoine de Saint-Exupery |
| 13:05:54 | erikm_soldering | prpplague: BZFlag plans to work on that |
| 13:05:58 | GiuseppeOttaviano | I think this applies very well to coding :-) |
| 13:06:14 | erikm_soldering | GiuseppeOttaviano: no, it's the golden rule of engineering |
| 13:06:31 | erikm_soldering | GiuseppeOttaviano: but so often people forget about it |
| 13:07:11 | GiuseppeOttaviano | prpplague: it would be very useful if you have a lot of boards to load kern/rd in... |
| 13:08:25 | erikm_soldering | anyway, I was soldering.... |
| 13:08:46 | seletz | hi everyone. Just about RedBoot: heve you ever tried to compile it? |
| 13:09:36 | GiuseppeOttaviano | ok, keep soldering :-)) |
| 13:09:43 | GiuseppeOttaviano | bye, i go |
| 13:12:21 | Sammy | , about reboot ....so reboot it .... |
| 13:13:17 | seletz | redboot is a mess. 1) no makefile 2) arm-elf toolchain 3) they use macros instead of #include |
| 13:14:05 | Sammy | no I say I am reboot now ... |
| 13:15:01 | seletz | is someone here who can answer a question about blob memory layout? |
| 13:16:32 | seletz | i need to know where blob resides & where the stack grows. i believe its @ 0xc0000000 - 0xc0100000 with stack grows top->bottom, right? |
| 13:16:54 | erikm_soldering | seletz: *nod* |
| 13:18:48 | prpplague | seletz: hows the documentation on redboot? |
| 13:20:24 | erikm_soldering | seletz: even russell king couldn't get redboot compiled |
| 13:20:47 | Sammy | is back |
| 13:20:59 | Sammy | but need to go home... |
| 13:21:14 | sammy_ | night all... |
| 13:21:48 | erikm_soldering | night sammy |
| 13:22:07 | sammy_ | erikm : wish you have a good soldering ... |
| 13:22:34 | sammy_ | .......^_^ |
| 13:26:00 | seletz | ericm: yuck. i needed a weekend. |
| 13:26:33 | seletz | well, what i did: followed it _exactly_ about 100 times. _sigh_ |
| 13:26:42 | seletz | the docs, i mean. |
| 13:28:14 | seletz | ericm: well, if you *nod* to me, then i _believe_ my memory test command at las found an error. |
| 13:29:58 | erikm_soldering | seletz: send me the patch with your code and I'll test it tonight on a LART |
| 13:30:47 | seletz | erikm_soldering: ok, mail | sourceforge. patches to config.in also? |
| 13:32:07 | erikm_soldering | seletz: mail would be a little faster. patches to configure.in would be nice as well |
| 13:32:22 | erikm_soldering | seletz: and be sure to do diff -u, that's a lot easier to read |
| 13:32:30 | seletz | erikm_soldering: ok. |
| 13:35:51 | prpplague | erikm_soldering: i've got my yopy, the tuxscreen, the ELF board, a series 700 from intermec, and a viewpad100 from viewsonic |
| 13:38:06 | erikm_soldering | prpplague: right, I have a LART (doh), a pleb, an intel assabet, a compaq ipaq, and a tuxscreen |
| 13:38:58 | erikm_soldering | prpplague: I still need the jtag dongle for the pleb, a proper 220 --> 110V converter for the tuxscreen, and the schematics for the ipaq |
| 13:39:54 | prpplague | erikm_soldering: i'd like to get a LART, just haven't had time to get one on order |
| 13:40:12 | erikm_soldering | prpplague: I do have some code for an ADS thinclient, but it's too ugly to use |
| 13:40:43 | erikm_soldering | prpplague: the thinclient needs chain loading as well |
| 13:41:10 | erikm_soldering | hmm, I have to bug jim gettys and jamey hicks about the ipaq schematics |
| 13:41:32 | erikm_soldering | I expect to have to sign an NDA for that, but that's no problem |
| 13:43:04 | prpplague | erikm_soldering: lol, you the man! |
| 13:46:24 | erikm_soldering | prpplague: the NDA is only needed to solder a jtag connector to the ipaq. I'm sure I *will* make a brick out of an ipaq |
| 13:48:00 | seletz | erikm_soldering: mail sent. |
| 13:48:59 | erikm_soldering | seletz: mail received |
| 13:49:49 | seletz | erikm_soldering: i used test method 0 and 1. Method 2 not yet implemeted :^) 2 found an error. |
| 13:50:08 | seletz | erikm_soldering: ehh. 1 found it. |
| 13:54:19 | erikm_soldering | seletz: ok, will look after soldering |
| 14:09:45 | seletz | shlashdoting |
| 14:10:18 | seletz | reading irc fac :) |
| 14:11:03 | erikm_soldering | seletz: openprojects.net also hosts #kernelnewbies, which is very nice if you have kernel questions |
| 14:11:20 | prpplague | erikm_soldering: arm related too? |
| 14:11:52 | erikm_soldering | prpplague: well, if rmk or me are there to answer them: yes |
| 14:13:58 | erikm_soldering | seletz: at first sight your code looks OK |
| 14:14:15 | erikm_soldering | seletz: do you object if I add it to the blob CVS version? |
| 14:16:36 | seletz | erikm_soldering: would be a honour to me :^) |
| 14:22:30 | erikm_soldering | seletz: I just got this memory test URL from ralph siemsen (who wrote the netwinder firmware): http://www.qcc.sk.ca/~charlesc/software/memtester/ |
| 14:27:38 | seletz | erikm_soldering: link dead |
| 14:28:27 | erikm_soldering | seletz: oh? I'm reading it right now |
| 14:29:57 | seletz | ericm: hmmm. using cut&paste. Securirty? Permissions? |
| 14:30:19 | seletz | erikm_soldering: get 404 |
| 14:33:14 | erikm_soldering | seletz: and what about this page: http://www.qcc.sk.ca/~charlesc/software/ |
| 14:38:01 | seletz | erikm_soldering: nada. 404 |
| 14:39:07 | seletz | erikm_soldering: i reach the main page, but neither harlesc nor harlesc/software |
| 14:40:35 | erikm_soldering | not harlesc, charlesc |
| 14:44:55 | seletz | erikm_soldering: ahh. |
| 14:47:49 | erikm_soldering | got the pages? |
| 14:48:06 | seletz | erikm: i tried charles/software charlesc/software no way. 404. feeling quite deaf now :^( |
| 14:48:41 | erikm | http://www.qcc.sk.ca/~charlesc/software/ doesn't work for you??? |
| 14:49:00 | erikm | I mean: if I can get it, I don't see why you can't |
| 14:49:54 | seletz | ericm: no. "harlesc" or "charlesc". i use cut&paste in X. |
| 14:50:25 | seletz | erikm: i'll try another machine. |
| 14:50:41 | seletz | bugging a co-worker |
| 15:07:41 | erikm | seletz: I think your strtol is basically the same as GetHexValue in src/clock.c, right? |
| 15:09:26 | erikm | seletz: so if it's all the same to you, I want to move that into a single function |
| 15:10:35 | seletz | erikm: yes. sorry, i did not search hard enough. i hate re-implement the wheel :( |
| 15:11:17 | seletz | erikm: btw: supplied url does not work. period. :^) |
| 15:13:48 | erikm | let me just dcc you the source |
| 15:14:08 | erikm | don't know how good it is, though |
| 15:14:37 | seletz | Ill check it out |
| 15:15:53 | erikm | anyway, dinner time |
| 15:15:58 | seletz | erikm: you want to s/1024/(1<<14)/gc in chkmem.c :^) gets faster |
| 15:16:19 | seletz | erikm: dinner? yum! |
| 15:16:36 | erikm | I'll make it a define |
| 15:16:43 | erikm | even easier |
| 15:16:51 | seletz | erikm: :^) |
| 15:17:10 | erikm | or even better: an option to the command |
| 15:17:59 | seletz | erikm: :D |
| 15:18:13 | seletz | erikm: I'll send a patch |
| 15:20:17 | erikm | also ok |
| 15:37:30 | seletz | Ok, folks, thats it for today. I'll try if i can get my mac@home to IRC. |
| 15:41:44 | prpplague | seletz: later |
| 16:16:35 | prpplague | BZFlag: what are the top three reasons that blob would show that it moved the kernel image to ram, however will not boot the kernel? |
| 16:17:57 | BZFlag | 1) bad kernel image 2) bad blob 3) bad upload |
| 16:22:06 | erikm | returns |
| 16:24:33 | erikm | hey, didn't know blob was a member of the linux kernel foundry on sourceforge |
| 16:28:20 | prpplague | whoo, making progress... |
| 16:29:18 | prpplague | erikm: do you think when i'm done i need to document this and create patches? i mean how many other people do you think are going to use blob as a secondary bootloader? |
| 16:29:43 | erikm | prpplague: I think it will be useful |
| 16:30:10 | erikm | prpplague: the ADS boards also have an evil bootloader |
| 16:31:36 | erikm | prpplague: so if blob supports chain loading, it will make it easier to assimilate other sa11x0 boards |
| 16:34:24 | prpplague | erikm: right, then when i get things stable and docs (next week i hope) i'll forward them to you |
| 16:34:51 | erikm | prpplague: good |
| 17:00:08 | erikm | hi BZFlag |
| 17:00:23 | prpplague | the __phys_to_virt(value) takes the value as the physical memory address and returns the virtual address as paged by the mmu, right? |
| 17:00:31 | erikm | BZFlag: yes |
| 17:00:36 | erikm | sorry, prpplague: yes |
| 17:00:52 | erikm | BZFlag: jamey didn't really like me porting blob to ipaq |
| 17:01:00 | BZFlag | why not? |
| 17:01:06 | erikm | <jamey> wouldn't you rather work on bootldr? |
| 17:01:11 | erikm | <jamey> I have no desire for us to have different firmware on the ipaq |
| 17:01:19 | BZFlag | <BZFlag> if you GPL it, sure. |
| 17:01:29 | erikm | that's what I said |
| 17:01:36 | erikm | and jim gettys already OK'ed it |
| 17:01:43 | BZFlag | you mentioned the bad licensing issues they have now? |
| 17:01:48 | erikm | no |
| 17:02:04 | BZFlag | IMHO they are GPLed they just don't know it. |
| 17:02:12 | erikm | yes, they use GPL code |
| 17:02:24 | erikm | don't they also use Russ' GPL code? |
| 17:03:01 | erikm | if so, the only one with a legal right to complain is Russ |
| 17:03:42 | BZFlag | Have not checked the latest, but I thought they added jffs2 support no? |
| 17:03:47 | erikm | BZFlag: btw, I'm just merging blob supported architecture #8 :) |
| 17:04:01 | BZFlag | which is? |
| 17:04:04 | erikm | BZFlag: IIRC yes. and IIRC that's RUss' code |
| 17:04:23 | BZFlag | slaps Russ|werk and Russ |
| 17:04:26 | erikm | PT system3, seletz send me the patch |
| 17:04:38 | BZFlag | nice. |
| 17:04:49 | erikm | BZFlag: now see what you do, you missed Russ and slapped sammy out :) |
| 17:05:27 | erikm | oh, and prpplague will send me architecture #9 somewhere next week |
| 17:05:48 | prpplague | erikm: hopefully |
| 17:06:07 | erikm | prpplague: send it when you feel it's ready |
| 17:06:48 | erikm | ROFL, brilliant post on the linux-kernel list: [PATCH] Linux 0.01 disk lockup |
| 17:06:50 | erikm | :))) |
| 17:06:58 | prpplague | erikm: i'm going to have to clean it up, i don't you guys making fun of my nasty hacks |
| 17:07:57 | erikm | BZFlag: and I'm also merging seletz' memory tester right now |
| 17:11:28 | BZFlag | so when are we going to stop considering ourselves LARTed? ;-) |
| 17:11:49 | erikm | BZFlag: never :) |
| 17:12:01 | BZFlag | feels blobbed |
| 17:13:01 | prpplague | brb |
| 17:37:30 | erikm | ah, hi seletz_athome |
| 17:38:13 | prpplague | seletz_athome: you got you mac aworkin? |
| 17:38:32 | seletz_athome | erikm: hi. phew. got it to run on my iMAC :) |
| 17:39:32 | seletz_athome | yes, download & install. then get confused by whacky UI. :) |
| 17:40:12 | seletz_athome | ericm: hows my code doing? got my update? |
| 17:40:41 | seletz_athome | damn. always misspell "erik" as "eric". Sorry. |
| 17:40:58 | erikm | seletz_athome: yes, got your update |
| 17:41:04 | erikm | I'm integrating right now |
| 17:41:30 | seletz_athome | erikm: always working, eh? |
| 17:41:48 | erikm | seletz_athome: I just start late in the morning |
| 17:42:00 | Russ | erikm: I see what you mean by the init/exit section, and the tags that set values |
| 17:42:23 | erikm | Russ: sorry, return from subroutine... :) |
| 17:42:27 | Russ | erikm: but in that system, how would you use a different command line based on whether or not the kernel came from flash or tftp |
| 17:42:45 | erikm | Russ: oh, but that could still be used |
| 17:42:55 | erikm | Russ: that == the parameter tags |
| 17:43:04 | erikm | Russ: it can be used together |
| 17:43:23 | Russ | what would be the prefered method of accomplishing "variable/smart booting" |
| 17:43:45 | erikm | Russ: well, first of all every subsystem that has to be initialised should be initialised |
| 17:43:55 | erikm | Russ: so that's where the init section is for |
| 17:44:16 | Russ | ok |
| 17:44:32 | erikm | Russ: (serial port setup, i-cache, etc) |
| 17:44:48 | Russ | ala __init? |
| 17:44:50 | erikm | Russ: next we run the parameter list |
| 17:44:52 | erikm | exactly |
| 17:45:01 | erikm | that's where I got the idea from |
| 17:45:32 | erikm | only difference is that I want to add a parameter in which you can set the level |
| 17:45:45 | Russ | "the level"? |
| 17:45:56 | erikm | you can select that the serial code has to be initialised first, so it gets level 0 |
| 17:46:08 | erikm | next comes level 1 (the i-cache, for example) |
| 17:46:08 | Russ | oh, right |
| 17:46:18 | Russ | __init0, __init1, etc? |
| 17:46:31 | erikm | for example, or just __init(function, level) |
| 17:47:44 | erikm | some subsystems don't need an exit function (like serial), but others do (like i-cache) |
| 17:47:51 | Russ | but again, what would the mechanism be for implementing boot policy |
| 17:48:57 | erikm | still your parameter list, which will run after the init functions. and if that somehow fails, we'll fall back to the command line |
| 17:49:16 | Russ | like, maybe I want to have one kernel/command line if a gpio is set, a different one if it is clear |
| 17:51:43 | erikm | that should still be possible. I've thought about it, and on second thought it isn't as evil as I thought :) |
| 17:52:15 | Russ | or an attempt to boot to CF, then stock flash |
| 17:52:32 | erikm | it == your parameter list |
| 17:53:02 | Russ | maybe just a minimal set of 2 or three paramater lists |
| 17:53:24 | erikm | that means three ways to boot, right? |
| 17:53:30 | Russ | right |
| 17:53:49 | Russ | its just, how do you decide that, and what do you do when you switch (clear all paramaters)? |
| 17:54:14 | Russ | because by the time you are loading a kernel from CF, you're already done parsing the paramater list |
| 17:54:32 | erikm | hmm |
| 17:54:33 | Russ | (unless tags actually do things, as if they were macros) |
| 17:54:39 | erikm | ok, what about this: |
| 17:54:58 | erikm | first list contains the command "boot from CF" |
| 17:55:19 | erikm | we try to do that, if it fails, we fall back to the second command list |
| 17:55:33 | Russ | right |
| 17:55:40 | Russ | maybe a sort of reblob'ing |
| 17:55:45 | erikm | not necessary |
| 17:55:59 | Russ | why not start over? |
| 17:56:01 | erikm | we just start at the second command list, boot from network (for example) |
| 17:56:26 | erikm | why should we start over? in that case you'll find out that booting from CF still doesn't work |
| 17:56:51 | Russ | maybe a register, like r0 would hold the action |
| 17:56:57 | Russ | start.S would clear it |
| 17:57:29 | Russ | also, paramaters could be split into two types, global blob defaults, and boot stuff |
| 17:57:47 | Russ | blob defaults would be things like the partition table, serial number, and baud rates |
| 17:58:12 | erikm | Russ, that was also my idea, yes |
| 17:58:33 | erikm | but I don't think we need to reboot in case the first boot method doesn't work |
| 17:58:49 | prpplague | Russ: would these defaults be store as a seperate flash block? |
| 17:59:12 | erikm | prpplague: yes. or we could put them in the same flash block as blob itself, we have plenty of room |
| 17:59:42 | Russ | so blob paramater parsing is level 0 |
| 17:59:56 | Russ | serial init, etc is level 1 |
| 18:00:12 | Russ | boot parsing might be level 2 |
| 18:00:31 | seletz_athome | what do you do when two functions are on the same level? |
| 18:00:55 | prpplague | erikm: on new flash of blob the defaults would not exist and they'd be writen clean, then on later boots they'd be read from the block? |
| 18:01:10 | erikm | prpplague: yes |
| 18:01:43 | erikm | Russ: for example |
| 18:02:05 | erikm | Russ: but in my opinion you should see the init different from the parameter parsing |
| 18:02:43 | erikm | Russ: IOW: don't put too many things into the parameters |
| 18:03:19 | Russ | <Russ> so blob paramater parsing is level 0 |
| 18:03:19 | Russ | <Russ> serial init, etc is level 1 |
| 18:03:19 | Russ | <Russ> boot parsing might be level 2 |
| 18:03:45 | erikm | yes, you said that :) |
| 18:03:45 | Russ | and then the carrying out of these boot paramaters would be level >=3 |
| 18:03:54 | Russ | I timed out |
| 18:03:55 | erikm | you lost me there |
| 18:04:17 | Russ | which part |
| 18:04:30 | erikm | the "and then carrying" part |
| 18:04:37 | Russ | like if there is a boot paramater to load a kernel from jffs2 |
| 18:04:49 | Russ | there would be something __init level3 that would try to do that |
| 18:05:05 | Russ | or the command line would be used in __init level 9 when it booted the kernel |
| 18:05:25 | Russ | or maybe a gpio would be tested in __init level 3 |
| 18:05:27 | erikm | I think I made you confused. in my opinion we should have three tables: the __init, __exit, and __param tables |
| 18:05:52 | Russ | didn't you want various init steps? |
| 18:06:58 | erikm | Russ: ahh, *now* I see what you mean |
| 18:07:13 | Russ | like, kernel paramater block stuffing, and the actual booting of the kernel would be done in the last steps |
| 18:07:38 | erikm | that's pretty kinky, isn't it? |
| 18:07:47 | Russ | heh |
| 18:08:15 | Russ | a lot of the kernel paramater blocks come directly from blob paramater blocks (cmdline, serial, rev, ramdisk) |
| 18:08:22 | Russ | so I just consider it stuffing |
| 18:09:27 | erikm | Russ: I'm not sure if we really want the parameter list also be started from the init list |
| 18:09:43 | prpplague | i'm heading out to lunch, have a good evening erikm |
| 18:09:56 | erikm | prpplague: heh, we're going too fast for you? :) |
| 18:09:57 | Russ | suppose I might be extending this init thing too far |
| 18:10:29 | Russ | making everything that blob does at some boot level, suppose I'm a little attached to sysvinit |
| 18:10:38 | prpplague | erikm: no i follow what you want to do, i've create something similiar in concept for my thinclient |
| 18:11:05 | erikm | Russ: I think so, because the parameter list parsing is not really initialising the system |
| 18:11:24 | erikm | Russ: but the parallels with sysvinit are clear indeed |
| 18:12:30 | Russ | I don't know, I would think blob parameters, basic hardware init, parse first paramaters, hardware init (restart if failure), autoboot (blob> prompt if interrupted), load kernel/ramdisk, stuff tags, boot kernel |
| 18:13:24 | erikm | basic hardware init should go first, no question about that |
| 18:13:45 | Russ | but you don't know what baud rate (or maybe even serial port) until you've parsed the blob tags |
| 18:14:04 | erikm | hmm |
| 18:14:17 | erikm | so we want some kind of hardware parameter tags |
| 18:14:28 | Russ | which would be the blob tags |
| 18:14:38 | prpplague | Russ: how are you going to get the blob tags if the ram hardware hasn't been initialized? |
| 18:14:49 | Russ | prpplague: this is after start.S |
| 18:14:59 | Russ | so blob is running from ram at this point |
| 18:14:59 | erikm | prpplague: this is second stage bootloader, so the ram is initialised |
| 18:15:05 | prpplague | Russ: ahh, i'll shutup now |
| 18:16:05 | erikm | gets something to drink, brb |
| 18:16:47 | prpplague | is away: lunch |
| 18:17:08 | seletz_athome | even if its not running from ram, bank0 should be configured right after HW reset. |
| 18:19:26 | BZFlag | blob initial serial rate is decided at compile time. if a new rate is to be set, it just needs to happen before the autoboot. |
| 18:20:13 | BZFlag | blob parameters cannot be saved to the blob flash block. defaults can be read from there though. |
| 18:20:37 | BZFlag | blob parameters _should_ be able to be saved right on the jffs2 rootfs |
| 18:20:53 | erikm | returns |
| 18:21:02 | BZFlag | so part of boot decisions needs to be looking for jffs2 partition |
| 18:21:13 | Russ | BZFlag: I don't know about the jffs2 partition |
| 18:21:34 | BZFlag | this allows boxes with large flash blocks (ipaq for example) to have 2 256k blob block and then the rest for jffs2 root. |
| 18:21:45 | BZFlag | er 1 256k.... |
| 18:21:57 | Russ | hmm...I think that would be a future extension |
| 18:22:04 | Russ | loading a paramater block from a location |
| 18:22:20 | BZFlag | Tux and others with small start blocks will have 64k blob 64k parameter and then 128k rootfs blocks. |
| 18:22:21 | Russ | I don't even want to really think about that right now |
| 18:22:23 | erikm | BZFlag: we could very easily put blob and the parameters in the same flash block |
| 18:22:46 | Russ | erikm: do you really want to erase blob to write paramaters? |
| 18:22:53 | BZFlag | erikm: the defaults, yes. but I do not want to be rewriting blob when we save parameters. |
| 18:23:11 | erikm | Russ: it *is* dangerous, yes :) |
| 18:23:20 | BZFlag | to dangerous IMHO. |
| 18:23:24 | Russ | I see what you mean though |
| 18:23:34 | BZFlag | s/to/too/ eep. |
| 18:23:47 | Russ | there would be enough paramaters to tell blob the basic flash layout, what baud to use, etc and to load a paramater block from jffs2 |
| 18:23:50 | erikm | but getting them from a jffs2 partition would also be nice |
| 18:24:01 | Russ | this would be some future extension I would think |
| 18:24:18 | erikm | but you had jffs2 code, right? |
| 18:24:26 | Russ | right, to load any file from jffs2 |
| 18:24:42 | erikm | well, just look for the file /blobparams, for example |
| 18:24:54 | Russ | could be /boot/parms too |
| 18:25:05 | BZFlag | or /boot/blobrc |
| 18:25:06 | erikm | whatever turns you on :) |
| 18:25:24 | Russ | ever think about putting the arch number in a tag? |
| 18:25:34 | BZFlag | why? |
| 18:25:50 | BZFlag | you expect a user to change it? ;-) |
| 18:25:51 | erikm | overkill |
| 18:25:53 | Russ | for someone developing a new board |
| 18:26:05 | BZFlag | they best have a compiler too. ;-) |
| 18:26:15 | erikm | someone developing a new board would have to change the memory setup as well |
| 18:26:25 | Russ | true enough |
| 18:26:56 | BZFlag | I do think a peek/poke/dump option would be nice. |
| 18:27:02 | erikm | BZFlag: ah! |
| 18:27:11 | Russ | nap |
| 18:27:31 | erikm | BZFlag: you're in luck, seletz memory tester contains that kind of functions :) |
| 18:27:44 | erikm | BZFlag: peek and poke at least |
| 18:28:16 | BZFlag | nice! |
| 18:28:28 | BZFlag | peek/poke wil suffice. |
| 18:29:04 | erikm | let me finish the merge, and I'll cvs commit it |
| 18:35:25 | seletz_athome | Well, getting some sleep, then. Bye, and happy hacking... |
| 19:06:18 | prpplague | is back (gone 00:49:30) |
| 19:08:01 | prpplague | ok guys, i've got problem with my initrd... |
| 19:08:08 | prpplague | RAMDISK: Couldn't find valid RAM disk image starting at 0. |
| 19:08:08 | prpplague | Freeing initrd memory: 4096K |
| 19:08:08 | prpplague | MSDOS: Hardware sector size is 1024 |
| 19:08:08 | prpplague | fatfs: bogus logical sector size 65535 |
| 19:08:08 | prpplague | Kernel panic: VFS: Unable to mount root fs on 01:00 |
| 19:08:27 | prpplague | any ideas on what i'm missing? |
| 19:09:12 | erikm | try ext2fs |
| 19:09:25 | BZFlag | why not use jffs2 root instead without an initrd? |
| 19:09:46 | BZFlag | or perhaps it's minixfs? |
| 19:09:58 | erikm | that's also a possibility, but in that case you need MTD support for your architecture first |
| 19:10:08 | BZFlag | true, true. |
| 19:10:55 | prpplague | thats what is confusing, i created my ramdisk using ext2 |
| 19:11:11 | prpplague | where's this MSDOS stuff coming from? |
| 19:11:11 | erikm | yes, but it looks like your kernel doesn't have ext2fs support |
| 19:11:20 | prpplague | hmm |
| 19:11:39 | erikm | you virtually never need msdos fs support for arm |
| 19:12:22 | prpplague | ya, i've got ext2fs in the config |
| 19:12:41 | erikm | hmm, try to get rid of msdos fs and fatfs |
| 19:12:51 | prpplague | ok i'll start there |
| 19:12:53 | prpplague | thanks |
| 19:13:44 | erikm | it could be possible that the msdos fs corrupts the ramdisk image so ext2 can't work with it anymore |
| 19:14:58 | prpplague | i'll re-make without msdos fs and re-test |
| 19:34:14 | prpplague | setup_initrd( __phys_to_virt(0xc0400000), 4*1024*1024 ); |
| 19:34:19 | BZFlag | uses msdos (well, vfat) on arm to read CF cards from cameras. |
| 19:35:00 | erikm | BZFlag: I *knew* you had some kind of use for vfat on arm :) |
| 19:35:29 | BZFlag | heh |
| 19:35:39 | prpplague | that line setups up an initrd, pulling the image from physical 0xc0400000 and assumes the image is a 4096k in size, right? |
| 19:36:32 | erikm | skip the __phys_to_virt() stuff |
| 19:36:53 | prpplague | setup_initrd(0xc0400000, 4*1024*1024 ); |
| 19:36:57 | erikm | yes |
| 19:37:02 | erikm | but it is misleading |
| 19:37:20 | erikm | setup_initrd() is actually point_kernel_to_compressed_ramdisk_image() |
| 19:37:46 | erikm | the first parameter is the physical start address, the second one the compressed size |
| 19:38:04 | erikm | you also want to have a call to setup_ramdisk to it |
| 19:38:22 | erikm | setup_ramdisk(1, 0, 0, uncompressed_ramdisk_size); |
| 19:38:33 | erikm | and ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0); |
| 19:39:59 | prpplague | the compressed size doesn't have to exact, just as long as it doesn't excede the allocated size? |
| 19:40:20 | erikm | yes |
| 19:41:45 | erikm | prpplague: but be careful if your kernel also picks up BOOT_PARAMS |
| 19:42:25 | erikm | prpplague: because in that case the BOOT_PARAMS will overwrite the values from the the fixup function |
| 19:43:30 | prpplague | so the ROOT_DEV would be overiden by a ROOT= in the BOOT_PARAMS ? |
| 19:44:05 | prpplague | as well as other options... |
| 19:45:01 | erikm | yes |
| 19:45:54 | erikm | and if your fixup also contains SET_BANK() calls, your kernel will also pick up the ATAG_MEM nodes from blob, in which case every memory bank will be accounted twice |
| 19:47:18 | erikm | cleans up the memory check code |
| 19:47:23 | prpplague | erikm: thanks for your patience, its all sinking in a little at a time... |
| 19:51:34 | erikm | grmbl |
| 19:51:41 | erikm | ctrl-alt-backspace is *not* the way to undo in emacs |
| 20:08:29 | prpplague | whoo, success |
| 20:09:17 | prpplague | brb, need fresh cup of coffee to celebrate! |
| 20:09:47 | erikm | cool |
| 20:21:26 | prpplague | ahh, the smell of success, or is that my powersupply... |
| 20:22:17 | erikm | hehe :) |
| 20:22:38 | erikm | fixes the last obvious bugs in the memory tester |
| 20:22:46 | erikm | it just needed a couple of memory barriers |
| 20:29:58 | erikm | starts commiting sources |
| 20:39:03 | erikm | BZFlag: the memory tester is in CVS |
| 20:43:56 | BZFlag | sweet. I might try it out tonight. |
| 20:47:57 | erikm | spots an obsious bug |
| 20:57:42 | erikm | goes zzz |
| 22:15:47 | prpplague | well guys, i'm blobed out for today |
| 22:16:26 | prpplague | see ya'll later |