**** BEGIN LOGGING AT Wed Sep 21 02:59:56 2005 Sep 21 03:00:01 I need to compare results between different slugs Sep 21 03:01:08 <[cc]smart> aha, how would i do it ? Sep 21 03:01:41 adjtimex -c on your UNPATCHED slug Sep 21 03:01:47 so i can compare with the patched one Sep 21 03:04:26 <[cc]smart> that in ntp package ? Sep 21 03:04:46 <[cc]smart> and with UNPATCHED, do you also mean the earlier patch to the topic ? Sep 21 03:05:02 mmm.. i use debian and have it in the adjtimex package Sep 21 03:05:06 adjtimex is in its own package Sep 21 03:05:07 <[cc]smart> :) Sep 21 03:05:09 I mean a standard openslug Sep 21 03:05:34 <[cc]smart> so standard openslug, as it is right now, with the patch that has been applied already Sep 21 03:06:09 <[cc]smart> from monotone that is Sep 21 03:07:19 yep Sep 21 03:07:54 <[cc]smart> so the only thing left is finding out where adjtimex sticks... lemme see what package db says.... Sep 21 03:08:23 please also do an adjtimex -p Sep 21 03:09:01 <[cc]smart> hmmm... for now i cant find it... let's see what ntp includes Sep 21 03:11:44 <[cc]smart> no good. no adjtimex. can /proc be used to get the values ? Sep 21 03:14:03 mm.. haven't found them in /proc yet Sep 21 03:14:38 <[cc]smart> in that case adjtimex would have to become a new package i guess Sep 21 03:16:35 if you have the time, it could probably be useful. Sep 21 03:16:35 03ph5 07org.openembedded.dev * r4d90ab5d... 10/packages/bluez/ (3 files in 2 dirs): bluez-utils-dbus: work around some alignment issues in hcid Sep 21 03:18:08 <[cc]smart> i could try, but tonight, that is in about 6 hours i'm off for holidays and i've not packaged up yet... Sep 21 03:18:13 dwery: running adjtimex -c on debianslug now ... Sep 21 03:18:21 rwhitby: thx Sep 21 03:18:36 cmos time system-cmos error_ppm tick freq tick freq Sep 21 03:18:46 -624205843 1754215434.762858 1862141.9 10000 0 Sep 21 03:18:57 -624205843 1754215453.364132 1860127.4 10000 0 -8602 4757825 Sep 21 03:19:06 -624205843 1754215471.992229 1862809.6 10000 0 -8629 5923775 Sep 21 03:19:09 that enough? Sep 21 03:19:23 yes. it's comparable to my results. Sep 21 03:19:30 adjtimex -p please Sep 21 03:19:39 buildd@debianslug:~$ sudo /sbin/adjtimex -p Sep 21 03:19:40 mode: 0 Sep 21 03:19:40 offset: 0 Sep 21 03:19:40 frequency: 0 Sep 21 03:19:40 maxerror: 16384000 Sep 21 03:19:41 esterror: 16384000 Sep 21 03:19:42 status: 64 Sep 21 03:19:44 time_constant: 2 Sep 21 03:19:46 precision: 1 Sep 21 03:19:48 tolerance: 33554432 Sep 21 03:19:50 tick: 10000 Sep 21 03:19:52 raw time: 1130009665s 300021us = 1130009665.300021 Sep 21 03:19:54 return value = 5 Sep 21 03:19:58 anything else? Sep 21 03:20:04 ok. thanks. Sep 21 03:20:21 np Sep 21 03:20:23 it seems thjose slugs have a very hight drift... or maybe i'm missing something Sep 21 03:20:32 it's the least I can do as a mere user .... Sep 21 03:21:17 the openntp guy awarded NAiLzZz's nslu2 "device with the worlds wonkiest clock" a couple months ago Sep 21 03:22:07 slugs don't need precise time ... whether you traverse 5 cm in a minute or 2 minutes is neither here nor there .... Sep 21 03:23:50 <[cc]smart> dyoung: but if it was a couple months ago, he probably neither applied tickadj nor the earlier patch Sep 21 03:24:02 <[cc]smart> so it wouldn't surprise me Sep 21 03:24:37 That was one of the test cases for doing the tick patch. Sep 21 03:24:38 <[cc]smart> this is me slug mailserver with ntp: Sep 21 03:24:40 <[cc]smart> root@mail:~# cat /etc/ntp.drift Sep 21 03:24:40 <[cc]smart> 7.447 Sep 21 03:25:26 the hardware clock seems ok to me Sep 21 03:25:34 I need to understand if the software is failing Sep 21 03:25:39 <[cc]smart> ah you mean system clock Sep 21 03:25:59 <[cc]smart> well in that case, you might remember another issue with IRQ26 iirc Sep 21 03:26:21 <[cc]smart> dunno, but i'd guess this plays a role just as well Sep 21 03:26:47 <[cc]smart> afaik IRQ26 issue is cosmetically masked but still there Sep 21 03:27:59 <[cc]smart> http://www.nslu2-linux.org/wiki/OpenSlug/NobodyCaredIrqErrs Sep 21 03:28:18 <[cc]smart> http://www.nslu2-linux.org/wiki/OpenSlug/OpenSlugChangeLog Sep 21 03:28:21 deepak said something about that a while ago Sep 21 03:28:53 the hwclock seems fine to me Sep 21 03:29:18 the system clock is too slow Sep 21 03:29:41 can you guys syncronize the clocks using hwclock --systohc Sep 21 03:29:43 and then Sep 21 03:29:45 using date Sep 21 03:29:49 and hwclock --show Sep 21 03:29:52 to check it? Sep 21 03:30:00 <[cc]smart> tickadj corrects that Sep 21 03:30:26 yes, but if the corrections is 16000 secs per day there must be a problem :D Sep 21 03:30:44 <[cc]smart> i'd guess what you are looking at is this difference in some driving frequency thatw as detected some weeks ago Sep 21 03:31:24 <[cc]smart> sth. of type frequency expect is 2/3, frequency driven is 0.66666 Sep 21 03:32:51 is this the 33Mhz patch youre working with? Sep 21 03:33:06 <[cc]smart> afaik, this is in openslug Sep 21 03:33:12 Yes. Sep 21 03:33:13 <[cc]smart> and before we used tickadj Sep 21 03:33:15 I know. Sep 21 03:33:39 The main thing about that kernel patch is the master clock crystal is 33.00Mhz Sep 21 03:33:49 and NOT the 33.33Mhz that is expected. Sep 21 03:34:06 <[cc]smart> this is the topic that dwerys patch improves upon i guess Sep 21 03:34:15 dyoung: bu i thought that by changig FREQ this would have been compensated Sep 21 03:34:55 Thats what I'm wondering about. If that is the patch you are working with now, I'm confused as to why the drift is so high. Sep 21 03:35:17 the options were change the internal clock freq or tickadj to 10101 Sep 21 03:35:40 Me too. I'll got eating my launch and do more tests Sep 21 03:35:47 <[cc]smart> good idea Sep 21 03:35:52 <[cc]smart> out for meat Sep 21 03:35:57 bye Sep 21 03:37:19 btw.. I'm testing the kernel with my latest patch against timex.. it could be that my patch is wrong and the proper value for tick_per_usec is not loaded. Sep 21 05:08:33 <[cc]smart> three manual merges... what the heck Sep 21 05:09:25 <[cc]smart> NAiL: i think bogofilter is ok to be part of openslug-dev now Sep 21 05:11:29 03ccsmart 07org.openembedded.dev * r26c9a4c6... 10/packages/bogofilter/bogofilter_0.96.0.bb: bogofilter: Adding RDEPENDS Sep 21 05:48:08 dwery: pong Sep 21 05:48:18 yvasilev: hi. Sep 21 05:48:44 yvasilev: did some more tests but nothing changed Sep 21 05:51:05 dwery: ok, I was thinking I'll try with montavista, so we can be sure le works at all, and maybe even look at the endiannes if there is a way to read the microcode back in a reasonable way Sep 21 05:52:17 yvasilev: ok. i tried with a non swapped microcode and the driver rejected it, so I gues it's loading it correctly. Sep 21 05:55:20 dwery: no, the thing that it rejected it or not is just that it matches it's first 4 bytes against that magic number, and the problem is that I think it can't start it, load fine but npe does not run Sep 21 05:55:50 understood. Sep 21 05:56:20 also, have you found where is that mysterious ixNpeDlTestRegWrite defines/implemented? Sep 21 05:58:57 yvasilev: it's something used when the component is emulated on a standard pc. I used the macros down below the same file. Sep 21 06:05:38 yvasilev: yes, looks I was mistaken in thinking this function was being used to load the npe Sep 21 06:26:18 <[cc]smart> NAiL: in ? Sep 21 06:30:49 new question for you guys... Sep 21 06:30:57 i've splitted the rtc part from the x1205 part Sep 21 06:31:26 since the rtc part is called before the i2c goes in, is not possible to setup the system clock immediately. Sep 21 06:31:36 the i2c driver shouldn't do it, it's not his task./ Sep 21 06:31:41 what to do? Sep 21 06:32:43 <[cc]smart> dunno 'bout kernel internals... but is this initial rtc call blocking or can you return and wait ? Sep 21 06:33:02 <[cc]smart> that is wait Sep 21 06:33:53 i can wait. but where to se it then? Sep 21 06:34:59 <[cc]smart> ah, you mean this initial call is the request for current time ? Sep 21 06:35:15 <[cc]smart> not the initialisation call Sep 21 06:36:19 no, the initial call is simply a general initialization of the nslu2/ixp4xx Sep 21 06:36:33 then the system gets loaded Sep 21 06:36:40 and the i2c subsytem initialized Sep 21 06:36:49 <[cc]smart> but then if you say that it's not blocking this would mean that you can wait for i2c to finish Sep 21 06:36:50 but i don't know how can we have acall after that Sep 21 06:37:03 <[cc]smart> ah ok Sep 21 06:37:04 <[cc]smart> dunno Sep 21 06:37:07 sorry, it's blocking in that sense. Sep 21 06:37:15 [g2]: ping Sep 21 06:37:24 [g2]: what rtc do you have on your board? Sep 21 06:53:02 regardin the timer problem, we could have an option of x1205 which tells the driver to initialize the system clock when loaded... and put that option on the command line. what do you think about it? Sep 21 07:13:16 <[g2]> dwery there's an RTC on the proto, but I'm not planning on having an RTC on boards Sep 21 07:13:27 <[g2]> NTP works fine Sep 21 07:13:29 :( Sep 21 07:13:42 what if your network is down? :D Sep 21 07:14:03 <[g2]> well my networks don't go down :) but that's a different issue :) Sep 21 07:14:17 <[g2]> basically you'll have clock drift Sep 21 07:14:32 <[g2]> depending on how long it's down Sep 21 07:14:51 <[g2]> I mean there's serial, usb, and I2C available Sep 21 07:15:11 <[g2]> a GPS, RTC on the I2C or usb are many options Sep 21 07:15:32 <[g2]> If enough ppl want/need the RTC it could be added I'm sure Sep 21 07:15:56 <[g2]> I've been trying to keep the cost a low as possible Sep 21 07:15:57 ack. Sep 21 07:16:17 <[g2]> dwery what are you and yvasilev doing for the libc-headers on your build ? Sep 21 07:16:36 [g2]: me, nothin. what needs to be done? Sep 21 07:16:44 <[g2]> I'm to the point of building CSR/IAL for 1.4 outside of OE Sep 21 07:16:47 <[g2]> with crosstool Sep 21 07:17:20 <[g2]> dwery are you buiding native or cross ? Sep 21 07:18:20 [g2]: cross Sep 21 07:18:37 <[g2]> with crosstool ? Sep 21 07:26:41 [g2]: I downloaded it from Jacmet's page Sep 21 07:27:09 regarding the x1205 issue, I added an hctosys option to the driver. Sep 21 07:32:44 <[g2]> Ok.. got it Sep 21 07:53:19 I'm confused. adjtimex -c suggest correction values of -8xxx, while adjtimex -h ntphost and then adjtimex --review says the time is quite correct... Sep 21 08:21:41 uh oh.. i suspect adjtimex does not use /dev/rtc ... Sep 21 08:39:24 [g2]: ping Sep 21 08:39:30 <[g2]> dwery, poing Sep 21 08:39:42 [g2]: poing? what kind of ball are we using ? :D Sep 21 08:40:04 <[g2]> ball ? Sep 21 08:40:08 [g2]: if you don't have an rtc on the loft, the system will start in 1970, right? Sep 21 08:40:38 <[g2]> until NTP runs Sep 21 08:40:54 [g2]: you know what happens when fsck notices it is in 1970, isn't it? :D Sep 21 08:41:46 <[g2]> there are lots of options Sep 21 08:42:08 <[g2]> A ramdisk could load the IXP modules and setup the time before going to init Sep 21 08:42:31 <[g2]> I could probably add the RTC Sep 21 08:42:44 <[g2]> there are lots of options Sep 21 08:43:33 RTC means battery? Sep 21 08:43:43 <[g2]> right Sep 21 08:43:54 <[g2]> that's the issue Sep 21 08:44:20 <[g2]> dwery, what happends in 10 years when the battery has run out ? Sep 21 08:45:11 [g2]: technically, the chip should tell the system the battery as failed. the system will then restart in 1970 too. Sep 21 08:45:43 <[g2]> right so you back to the same situation Sep 21 08:46:35 but less often :D Sep 21 08:46:40 <[g2]> actually... Reboot/bootloader could just setup the time from the network Sep 21 08:46:45 yep Sep 21 08:46:58 <[g2]> that's probably a better solution Sep 21 08:47:03 [g2]: how? Sep 21 08:47:28 <[g2]> NAiL, I've got the Redboot sources with the driver compiled in Sep 21 08:47:46 <[g2]> it'd just be a little function to read the time from network Sep 21 08:48:02 what's that little function? :) Sep 21 08:48:15 <[g2]> it tiny version of something like ntpdate Sep 21 08:48:15 you don't know anything about the network you're connected to Sep 21 08:48:43 or if any of the sources are anywhere near reliable ;) Sep 21 08:49:07 <[g2]> and you don't know that the RTC is reliable either Sep 21 08:49:33 <[g2]> MTBF is low but there are still failures Sep 21 08:49:42 of course Sep 21 08:49:58 <[g2]> so it's a question of cost and degree of accuracy Sep 21 08:50:22 but when the RTC fails, it will probably fail reliably... eg. every bootup you end up in 1970 Sep 21 08:50:38 <[g2]> and you need to solve for that problem correct ? Sep 21 08:50:45 if you set the clock from a random network source, who knows what kinda dates you get? Sep 21 08:51:40 <[g2]> NAiL, there wouldn't be anything random about it Sep 21 08:51:52 ... Sep 21 08:52:08 then how do you get the time from a network, unrandomly? Sep 21 08:52:28 <[g2]> the bootloader reads the CF/Microdrive for the kernel and rootfs Sep 21 08:52:46 <[g2]> is can read into the rootfs or another partiton for comfig Sep 21 08:52:49 <[g2]> config Sep 21 08:52:58 <[g2]> furthermore there's 4KB eeprom Sep 21 08:53:33 <[g2]> right now only the MACs are in the eeprom Sep 21 08:53:52 <[g2]> leaving nearly 4KB for anything Sep 21 08:54:06 <[g2]> I'll probably reserver the 1K Sep 21 08:54:22 <[g2]> first 1K and define how it's used Sep 21 08:54:39 <[g2]> maybe I'll put a RTC on Sep 21 08:55:02 <[g2]> these are exactly the kind of issues I love to have Sep 21 08:55:10 I'm asking out of curiosity Sep 21 08:55:26 <[g2]> I _want_ feed back from potential users Sep 21 08:55:43 because I cannot see how to get the date "reliably" from a network. If you know how to, I'd love to know ;) Sep 21 08:56:04 <[g2]> NTP is reliable right ? Sep 21 08:56:33 incase you have an internet connection, or a local ntp-server Sep 21 08:56:53 (un-firewalled) internet connection Sep 21 08:56:54 <[g2]> putting the NTP setting in EEPROM/flash/rootfs and using them in the bootloader isn't any less reliable than from an OS right ? Sep 21 08:57:19 I wouldn't say so Sep 21 08:57:31 <[g2]> there's also the I2C and serial Sep 21 08:57:37 I've just made a post on nslu2-developers about nslu2 detection, I appreciate comments :) Sep 21 08:57:56 [g2]: you Loft looks a very nice board anyhow... Sep 21 08:58:04 dwery: waiting ;) Sep 21 08:58:41 <[g2]> dwery you probably have'nt seen the real pictures have you ? The 6MP ones ? Sep 21 08:58:54 neither have I :p Sep 21 08:59:05 [g2]: Well not.. better you scale them down :) Sep 21 08:59:47 <[g2]> dwery, I'm serving them up on a T1 Sep 21 08:59:58 <[g2]> I doesn't take that long Sep 21 09:00:05 :D ok, let me see them! Sep 21 09:00:19 <[g2]> soon Sep 21 09:01:03 <[g2]> I'm updating the web site, I'll be adding lots of stuff soon Sep 21 09:02:12 [g2]: ok Sep 21 09:02:43 <[g2]> dwery, I'll let you know when I update the content Sep 21 09:03:03 <[g2]> and thx for the input Sep 21 09:03:16 * [g2] note to self.... start a FAQ Sep 21 09:03:44 <[g2]> well back to building ixp425_eth Sep 21 09:03:50 [g2]: great :) Sep 21 09:03:57 <[g2]> ixp400 is built Sep 21 09:04:09 <[g2]> v1.5 Sep 21 09:04:13 <[g2]> DOH! Sep 21 09:04:20 <[g2]> v1.4 Sep 21 09:04:52 ! Sep 21 09:07:47 uh oh.. just received my new gps.. I think I will take some tame to play with it :) Sep 21 09:16:42 <[g2]> lunch Sep 21 09:39:15 [g2]: a question for when you will be back.. do you think that by analyzing redboot at run time is there a way to determine if it is an NSLU2? Sep 21 09:41:28 dwery: doesn't work on one of my nslu2's Sep 21 09:41:35 since it's got APEX instead of RB Sep 21 09:41:37 NAiL: what? Sep 21 09:41:46 oh Sep 21 09:42:33 NAiL: If APEX correctly sets r7 you will have no problems. Sep 21 09:42:48 possibly... I dunno Sep 21 09:43:31 NAiL: well, since you managed to get APEX in I'm sure you can set r7 correctly :D Sep 21 09:43:40 hehe Sep 21 09:43:43 I didn't compile that image Sep 21 09:43:59 but yeah, APEX users should be able to set r7 correctly Sep 21 09:44:04 i think so. Sep 21 09:58:28 <[g2]> dwery back Sep 21 09:58:39 <[g2]> I'm not sure I understand your question Sep 21 09:58:50 <[g2]> there are two situations Sep 21 09:58:59 <[g2]> 1) The current Redboot Sep 21 09:59:05 <[g2]> 2) A different bootloader Sep 21 09:59:19 <[g2]> a new Redboot falls into category 2 Sep 21 09:59:24 1) Sep 21 09:59:45 <[g2]> well 1 is only setup for the nslu2 Sep 21 09:59:53 exactly. I woudl like to know if Sep 21 10:00:11 by analyzing the redboot and other characteristics of the board at runtime Sep 21 10:00:18 we can recognize an nslu2 Sep 21 10:00:26 <[g2]> I'll bet is trivial Sep 21 10:00:46 <[g2]> just md5sum/sha1sum the first 250K Sep 21 10:00:55 <[g2]> I'll bet they are identical for all nslu2s Sep 21 10:01:02 <[g2]> running the redboot Sep 21 10:01:32 <[g2]> actually all but the last < 100 bytes are the same Sep 21 10:02:11 ok. any other distinctive characteristics? Sep 21 10:02:46 <[g2]> the sercom trailer, lots of stuff Sep 21 10:02:53 at runtime? in redboot's console? Sep 21 10:03:26 <[g2]> bullet isn't chksum in the reboot ? Sep 21 10:03:35 <[g2]> you can chksum the first 250K Sep 21 10:03:49 <[g2]> probably the first 4K would do Sep 21 10:04:00 <[g2]> 250K would be worse probably Sep 21 10:04:04 <[g2]> more collisions Sep 21 10:04:05 yah, should be. and also, only nslu has do_move command Sep 21 10:04:49 <[g2]> well you could find a million signatures in the Redboot block Sep 21 10:05:11 <[g2]> the real question is what do you do on something like my FatSlug running APEX Sep 21 10:05:22 APEX sets r7 correctly, isn't it? Sep 21 10:05:38 bullet: tell me about do_mov Sep 21 10:05:39 <[g2]> the Redboot doesn't pass the cmd line parameters Sep 21 10:05:40 e please. Sep 21 10:06:13 <[g2]> I can pass Redboot cmdline paramters with the 2.01 version on the loft and APEX Sep 21 10:06:17 later, gotta go.. Sep 21 10:06:25 <[g2]> cheers Sep 21 10:06:55 <[g2]> the machine ID isn't set at all with the current Redboot Sep 21 10:07:27 <[g2]> so to get than we'll need to go to 2) and then it's a whole new game Sep 21 10:07:35 [g2]: what is in r7 with the current bootloader? Sep 21 10:07:54 <[g2]> dunno Sep 21 10:08:11 regarding 2, how difficult and how risky is to change the bootloader? Sep 21 10:08:16 <[g2]> I think our patches set it Sep 21 10:10:26 <[g2]> dwery I think with a proper boot loader the kernel could be built supporting nslu2, Loft, and other hw all at runtime. Sep 21 10:10:45 <[g2]> that's the kernel I'd like to build. Sep 21 10:10:54 I agree. But I want to evaluate how many failed NSLU2s we will have Sep 21 10:10:57 also ds101 ;) Sep 21 10:11:02 <[g2]> and run it on the NSLU2, Loft, and RV series Sep 21 10:11:05 <[g2]> ds101 too Sep 21 10:11:12 if the user will not be able to complete the upgrade procedure. Sep 21 10:11:19 <[g2]> "One kernel to unite them all" Sep 21 10:12:05 that'd be brilliant Sep 21 10:12:31 but the GPIO stuff would be a PITA, I guess ;) Sep 21 10:13:22 <[g2]> NAiL, the kernel just looks at the machine id and configures for the proper machine Sep 21 10:13:41 how do you upgrade? via jtag? via software? Sep 21 10:13:46 watch out, a sleepwalker... Sep 21 10:14:03 <[g2]> dwery testing with jtag is important Sep 21 10:14:25 <[g2]> but later, dd works great Sep 21 10:14:35 [g2]: so you canupgrade redboot with dd? Sep 21 10:14:36 <[g2]> I've done it probably hunderds of times Sep 21 10:14:57 <[g2]> I don't even have jtag on the slug Sep 21 10:15:11 I don't have jtag on the slug either Sep 21 10:15:24 <[g2]> I've only had one bad load and it's a compiler issue I think Sep 21 10:15:33 [g2]: what happens if the upgrade procedure fails ? how do you recover? Sep 21 10:15:41 <[g2]> JTAG Sep 21 10:16:02 <[g2]> the situation is this Sep 21 10:16:07 if flashing bootloader, jtag. If flashing kernel it's not worse that using redboot Sep 21 10:16:21 <[g2]> exactly Sep 21 10:16:23 although, on the ds101, using redboot requires serial Sep 21 10:16:34 <[g2]> well... almost exactly Sep 21 10:16:53 hmm? Sep 21 10:17:03 <[g2]> it testing the bootloader one should have JTAG Sep 21 10:17:24 <[g2]> I and JTAG on my Avila board and did all the testing there and from RAM in the slug Sep 21 10:17:26 can you update only some bytes of the bootloader? Sep 21 10:17:40 <[g2]> and dyoung had JTAG and verified it worked Sep 21 10:17:53 I tested apex from redboot Sep 21 10:18:04 through serial Sep 21 10:18:15 <[g2]> so for a know good config, flashing is pretty safe Sep 21 10:19:02 <[g2]> and really, APEX supports serial, so if you've got serial there's a good chance you could recover from serial Sep 21 10:19:25 <[g2]> if that doesn't work then adding the JTAG is required Sep 21 10:19:33 <[g2]> it's only a $80 investment Sep 21 10:20:05 <[g2]> or buy a Loft that some with serial, a sane bootloader (probably it's source), and has a JTAG connector Sep 21 10:20:22 <[g2]> s/some/comes/ Sep 21 10:20:43 <[g2]> anybody playing with this stuff is gonna spend some time on it Sep 21 10:20:50 <[g2]> the cost delta is really trivial Sep 21 10:21:22 03mickeyl 07org.openembedded.dev * rfbf5d9c0... 10/packages/rtaudio/ (librtaudio_3.0.1.bb rtaudio-tests_3.0.1.bb): Sep 21 10:21:22 add librtaudio + tests Sep 21 10:21:22 rtaudio is a highly efficient and portable C++ sound abstraction layer supporting OSS, ALSA, JACK. Sep 21 10:21:38 I agree, but I was thinking about an average user Sep 21 10:21:54 I we can only update a few bytes of the current bootloader... Sep 21 10:23:52 I don't like the idea of updating anyone's bootloader Sep 21 10:24:00 not as part of an automatic process Sep 21 10:24:39 It surely will not be automatic Sep 21 10:24:50 I just want to know if it's possible to update part of it Sep 21 10:25:02 via software Sep 21 10:27:59 ok, i guess we'll have to stick with some checksum+ other characteristics. Sep 21 10:31:02 dwery: about do_move. it's actually move. and well, thats a custom nslu2/sercomm function in the redboot loader. as is upgrade, assign and boot. Sep 21 10:31:22 so it can easily detected i guess Sep 21 10:31:40 think so Sep 21 10:32:26 what's about the r7 stuff you were talking? Sep 21 10:33:02 We know redboot doesn't set r7 with the mach type, right? Sep 21 10:33:30 you mean, register r7? i don't know anything about it Sep 21 10:34:24 yes, register r7. nor I. I just know a good bootloader places the mach type in r7, redboot does not Sep 21 10:34:33 so we havce to workaround Sep 21 10:34:55 ah Sep 21 10:35:08 if we can recognize the nslu2 Sep 21 10:35:12 analyzing other features Sep 21 10:35:16 we can then set r7 Sep 21 10:35:17 reliably Sep 21 10:38:00 ah Sep 21 10:38:17 * NAiL just got a spare 64mb cf card. That's should be plenty Sep 21 10:38:59 I need a new keyboard... this one is writing typos all the time Sep 21 10:53:33 <[g2]> re Sep 21 10:53:56 <[g2]> dwery whether you update a "few" bytes or not, it's a block erase Sep 21 10:54:01 <[g2]> for the most part Sep 21 10:54:18 <[g2]> so the first block gets erase and reprogrammed Sep 21 10:55:15 <[g2]> if you're erase the block, then it's not much different changing 1 byte versus putting APEX in which fits in the first block Sep 21 10:56:01 <[g2]> and with an APEX configured to load the kernel from jffs2 (as my does) change which kernel loaded is just writing the /initrd Sep 21 10:59:12 dwery: in packages/hal/arm/arch/current/src/redboot_linux_exec.c you'll find function "do_exec", which does: Sep 21 10:59:18 " mov r0,#0;\n" // Set board type Sep 21 10:59:20 ... Sep 21 10:59:25 " mov r1,%3;\n" // Machine type Sep 21 10:59:46 [g2]: understood, thanks. Sep 21 11:00:21 bullet: thanks, i'll give a look Sep 21 11:00:22 <[g2]> dwery np... I'm glad ppl are learning about the fun stuff :) Sep 21 11:00:24 right before jumping to linux, that is. so, r1 get's set Sep 21 11:04:24 r1? Sep 21 11:05:19 mhm. the value put in there looks to be 245, according to hal_arm_xscale_ixdp425.cdl Sep 21 11:05:37 which is correct IIRc Sep 21 11:07:03 or.. "correct" Sep 21 11:07:31 bullet: where I can download that file? Sep 21 11:08:05 do you have nslu2-2.3R29.zip from linksys.com? Sep 21 11:08:48 no, but i can download it Sep 21 11:09:22 in there, there's the source of a rather old version of redboot, plus a patch adding the nslu2/linksys specific changes Sep 21 11:10:22 73mb coming down the wire... Sep 21 11:10:47 there's also an R63 Sep 21 11:11:00 yeah, but it's completly different Sep 21 11:11:25 what is? Sep 21 11:12:03 is based on snapgear, afaik. one big tar.gz inside, basically Sep 21 11:12:27 and i'm not sure redboot is in it Sep 21 11:13:08 ok Sep 21 11:16:21 out of linux/Documentation/arm/README: The machine is selected by the value of 'r1' on entry, which must be kept unique. Sep 21 11:16:33 so that looks perfectly correct to me Sep 21 11:18:58 well, the only problem is the nslu2 identifying itself as an ixdp425 - but that's because the linksys people screwed redboot up :) Sep 21 11:22:16 why is there a MACH_NSLU2 defined as 597 in the linux kernel (reffering to openslug patch) anyway? Sep 21 11:24:01 <[g2]> bullet the NSLU2 machine id is 597 Sep 21 11:24:03 ah, now i see what you were talking about r7... Sep 21 11:24:34 i know, but the original redboot does not pass it, right? it passes 245 Sep 21 11:25:19 the NSLU2 machine id was registered by someone here, wasn't it? Sep 21 11:25:36 at least not by linksys, i think :) Sep 21 11:25:50 nope Sep 21 11:26:01 they should've, though Sep 21 11:26:16 yep Sep 21 11:26:38 849 is Loft, I see ;) Sep 21 11:29:17 <[g2]> NAiL, nod. Sep 21 11:39:23 that was a short night Sep 21 13:07:29 Hi, sorry to bother, but I'm trying to build lart_netboot with the sarge release of d-i and I get the following error: Sep 21 13:07:33 argh, wce Sep 21 13:33:33 <[g2]> Jacmet hey Sep 21 13:34:41 <[g2]> Jacmet, which version of the CSR/IAL are you running ? Sep 21 13:36:22 [g2]: none ;) Still using debian/arm with my usb ethernet Sep 21 13:40:30 <[g2]> Jacmet ah.. are you planning on building the CSR/IAL for LE ? Sep 21 13:43:15 [g2]: well, I'm rather waiting for dwery to do it for me ;) Sep 21 13:45:35 <[g2]> Ok... so you're mostly staying out of the module building business :) Sep 21 13:46:13 <[g2]> beewoolie and I are looking to get a debain kernel package put together Sep 21 13:46:29 <[g2]> I'd imagine you could use that on the LE Sep 21 13:46:32 [g2]: yes - sorry, but I'm really busy at the moment, so I don't have much time to hack on it Sep 21 13:46:57 <[g2]> nod. Sep 21 13:46:58 [g2]: yeah, I'm doing a bit of work on getting the debian-installer running without serial Sep 21 13:47:11 (for LE) Sep 21 13:47:27 <[g2]> the debian-installer should be endian agnostic right ? Sep 21 13:47:56 [g2]: pretty much I guess yes Sep 21 13:48:47 <[g2]> well I've just finished building the CSR/IAL modules outside of OE for the Loft Sep 21 13:49:08 [g2]: what version? Sep 21 13:49:15 <[g2]> 1.4 for now Sep 21 13:49:44 <[g2]> I've go a full kernel build cross Sep 21 13:49:54 <[g2]> including the ixp modules Sep 21 13:50:03 <[g2]> s/go/got Sep 21 13:50:09 nice Sep 21 13:50:21 <[g2]> I just need to test the ixp modules Sep 21 13:50:27 but I'm obviously more interested in v2.0 for LE Sep 21 13:50:46 <[g2]> I think 1.5 is supposed to support LE also Sep 21 13:50:53 <[g2]> I'm running the 1.5 version in Redboot Sep 21 13:51:17 <[g2]> I think someone could do a 2.01 Redboot LE build Sep 21 13:51:17 yes, it might - but it doesn't officially support 2.6 kernels afaik Sep 21 13:51:30 or I might be mixing it up with something else Sep 21 13:51:36 <[g2]> I'm running my 2.6 kernel from it Sep 21 13:51:43 <[g2]> BE of course Sep 21 13:52:11 <[g2]> but I've got my 2.6.11.12 + ixp all built and running from that Sep 21 13:52:11 I mean, v1.5 doesn't work with 2.6 - it works fine in redboot Sep 21 13:52:32 <[g2]> non of the versions were 2.6 compatible Sep 21 13:52:36 <[g2]> none Sep 21 13:52:42 It could also be interesting to upgrade to Redboot cvs - lot's of stuff has been added since 2.0 Sep 21 13:53:09 [g2]: hmm, I think v2.0 supports 2.6 kernels Sep 21 13:53:39 <[g2]> well if V2.0 support 2.6 then we should be "downtown" Sep 21 13:54:03 Jacmet: You've seen the recent LE IAL/CSR discussion here, right? Sep 21 13:54:06 Jacmet: there's redboot-2.02 available from intel. it's also a bit newer. but yes, cvs would be nice Sep 21 13:54:09 [g2]: But I haven't spent much time on the intel stuff Sep 21 13:54:14 NAiL: yes, most of it Sep 21 13:54:38 bullet: does the intel one contain anything not in CVS? Sep 21 13:54:41 <[g2]> I know dwery and yvasilev have been working hard to get some LE running Sep 21 13:54:59 [g2]: yes, I helped dwery a bit in the beginning Sep 21 13:55:08 Jacmet: yes. a few things in ixdp425/ixp425 are newer on intel's version Sep 21 13:55:09 The discussion lately has been very interesting Sep 21 13:55:17 bullet: ok Sep 21 13:55:45 <[g2]> I've been catching up to the point where I can do the same thing with BE Sep 21 13:55:50 <[g2]> on my Loft board Sep 21 13:56:19 the fixing-up of all the patches together with the intel 2.0 stuff. I'm looking forward to when this is figured out, so I can start working on the ds101 stuff ;) Sep 21 13:57:17 NAiL: ;) Sep 21 13:57:58 <[g2]> NAiL are you working on the IAL 2.0 BE patches ? Sep 21 14:00:21 [g2]: That is a bit above my head Sep 21 14:00:53 I'm no kernel hacker ;) Sep 21 14:01:10 <[g2]> Ok.. so it's just dwery yvasilev dyoung beewoolie and me working on the CSR/IAL ports and maybe a little jbowler Sep 21 14:03:00 sounds like a nice team of guys to me Sep 21 14:03:29 and afaik, Deepak has been helpful as well Sep 21 14:03:55 hmm Sep 21 14:15:37 VoodooZ_Log: ping? Sep 21 14:41:15 03rpurdie 07org.openembedded.dev * r42b169fa... 10/packages/linux/ (2 files): linux-oz-2.6: Add patch to mark ide-cs devices as none removable. Add some pcmcia ids from hrw. Sep 21 15:57:24 hi Sep 21 15:57:40 I saw a little bit of interesting discussions :) Sep 21 15:58:19 if 1.5 supports LE we may just try to build that. Sep 21 15:58:30 2.0 is giving some troubles Sep 21 15:58:56 I also gave alook to the redboot sourcecode Sep 21 15:59:10 and it seems it uses NPEB with PHY1, which does make sense Sep 21 15:59:26 since PHY1 is the one that effectively detects media status Sep 21 16:02:38 so if someone manages to build 1.5 BE, yvasilev and I will probably try to do it LE. Sep 21 16:03:16 deeoak is being very helpful in answering my arch related questions. Sep 21 16:03:27 deepak :) Sep 21 16:04:15 dwery: be should work with the patches we use, someone just needs to test them Sep 21 16:04:41 have you been able to build be? Sep 21 16:05:09 dwery: don't have where to boot/test it Sep 21 16:05:36 if you have the .ko we can just send them to someone be Sep 21 16:05:58 it needs to be the exact kernel version Sep 21 16:06:07 2.6.13.. isn't it? Sep 21 16:06:49 the offer to test was for 2.6.12.2 Sep 21 16:07:38 who offered? Sep 21 16:07:47 but I don't have that nor the patches for nslu2 Sep 21 16:07:55 I have them all. Sep 21 16:08:37 (btw the patches are the same of those for 2.6.11.12 iirc) Sep 21 16:10:21 NAiL offered Sep 21 16:11:31 i'm not sure i'm able to build be Sep 21 16:11:55 i can build the kernel le Sep 21 16:11:58 verify the patches Sep 21 16:12:02 and send them to you Sep 21 16:13:17 to test the kernel is easy, just tftp upload it to redboot Sep 21 16:14:08 well, we always can make a be initrd with the modules Sep 21 16:15:15 so I guess It'll may prove easier to test locally than to send modules until we build a working one Sep 21 16:15:27 is there interest for be 2.0? Sep 21 16:15:36 if it works, yes :D Sep 21 16:16:17 idid you read my comment about phy1 and redboot? Sep 21 16:16:25 1.4 work Sep 21 16:16:27 yes Sep 21 16:18:19 quite curious.. they fixed it in redboot and not in th ekernel Sep 21 16:18:32 [g2]: ping Sep 21 16:18:37 dwery: I just had an idea, how about building redboot in le with the linux head.S patch to switch to le so we can test it Sep 21 16:18:42 <[g2]> dwery ping Sep 21 16:18:44 <[g2]> pong Sep 21 16:19:01 <[g2]> pong Rocked in the 70's Sep 21 16:19:01 yvasilev: it sound dangerous :) Sep 21 16:19:05 [g2]: :D Sep 21 16:19:08 [g2]: true Sep 21 16:19:09 and according to intel it should work and there is no deps we need to satisfy Sep 21 16:19:24 [g2]: you are able to build 1.4 BE, right? Sep 21 16:19:25 dwery: no need to flash it, we can just tftp boot it Sep 21 16:19:40 yvasilev: yep.. I had forgot it.. never tried Sep 21 16:19:50 ja prishol.. g'nite all Sep 21 16:19:51 <[g2]> Up and running now with 2.6.11.12 on the loft with CSR 1.4 and NFS Sep 21 16:20:01 [g2]: does mii-tool work? Sep 21 16:20:04 <[g2]> nite lennert Sep 21 16:20:18 lennert: gnight Sep 21 16:20:19 <[g2]> mii-tool did work on the Debian root fs Sep 21 16:20:43 <[g2]> which happens to be my nfs mount :) Sep 21 16:20:47 <[g2]> that's convient Sep 21 16:20:55 [g2]: on my system, it works inverted: you need to use it on eth1 to obtain real status Sep 21 16:21:07 [g2]: on yours? Sep 21 16:21:09 <[g2]> I'm on E1 Sep 21 16:21:11 <[g2]> eth1 Sep 21 16:21:35 can you try to see if it works on both interfaces? Sep 21 16:21:44 [g2]: packets moving over eth0 also? Sep 21 16:22:00 <[g2]> mii-tool Sep 21 16:22:00 <[g2]> eth0: negotiated 100baseTx-FD, link ok Sep 21 16:22:00 <[g2]> eth1: no link Sep 21 16:22:12 ok.. now plug something in eth12 Sep 21 16:22:13 <[g2]> yvasilev yeah.. Just like the slug Sep 21 16:22:16 eth1 Sep 21 16:22:46 <[g2]> Oh yea I've got two interfaces Sep 21 16:23:04 <[g2]> should I run mii-tool -w ? Sep 21 16:23:10 <[g2]> it worked the other day Sep 21 16:23:19 just run it plain Sep 21 16:23:37 <[g2]> and plug into eth1 Sep 21 16:23:46 yes Sep 21 16:23:49 <[g2]> done Sep 21 16:24:01 <[g2]> mii-tool Sep 21 16:24:01 <[g2]> eth0: negotiated 100baseTx-FD, link ok Sep 21 16:24:01 <[g2]> eth1: negotiated 100baseTx-FD, link ok Sep 21 16:24:19 i wonder if the slug has been built inverted :) Sep 21 16:24:38 <[g2]> or connected to the second NPE Sep 21 16:24:42 [g2] thanks Sep 21 16:24:48 the npe in use is NPEB Sep 21 16:24:49 <[g2]> I didn't do much Sep 21 16:25:06 redboot sources are interesting Sep 21 16:25:17 did you also built 1.4 for your slug? Sep 21 16:25:41 <[g2]> no but that'd be trivial Sep 21 16:26:00 I curious to see if it shows the inverted behaviour Sep 21 16:26:32 <[g2]> it'd be the aggregated patch and the defconfig plus the CSR stoff Sep 21 16:26:35 <[g2]> stuff Sep 21 16:27:02 <[g2]> Since I strarted from that patch, I'm quite positive it'll work Sep 21 16:27:13 it's not urgent.. if you try and it's inverted, i'd be happy to try to fix it Sep 21 16:27:39 <[g2]> it'd be interesting to find out Sep 21 16:27:59 <[g2]> getting the CSR/IAL 1.4 running is a good step for the day Sep 21 16:28:00 at least we will know for sure which NPE and PHY are in use Sep 21 16:28:06 dwery: so, do you think you could try to build le redboot? Sep 21 16:28:16 well, why not Sep 21 16:28:22 have you already tried that? Sep 21 16:28:53 no, don't know a thing abou redboot Sep 21 16:29:04 neither do I :) Sep 21 16:29:09 :-D Sep 21 16:29:13 if we build it le Sep 21 16:29:28 do we need to swap it before sending via tftp, isn't it? Sep 21 16:29:30 <[g2]> I may be building it BE Sep 21 16:29:41 <[g2]> then it might be a config option for LE Sep 21 16:29:52 <[g2]> plus a tool chain Sep 21 16:29:54 yes Sep 21 16:30:28 <[g2]> it's a couple items down on the "todo" Sep 21 16:30:47 is there any howto we can read about testing redboot via tftp? Sep 21 16:31:16 <[g2]> I think you can build the ramrom an then just load it and jump to it Sep 21 16:31:52 * dwery don't know how :) Sep 21 16:32:01 <[g2]> really, If I were you guys I'd get JTAG enabled and then build APEX LD Sep 21 16:32:03 <[g2]> LE Sep 21 16:32:15 <[g2]> I think it might already be in there Sep 21 16:32:21 :) Sep 21 16:32:29 at which address should redboot be loaded? Sep 21 16:32:33 there was a howto load the other (asomething) bootloader over tftp to nslu, should be identical with redboot Sep 21 16:32:51 [g2]: what was the name of the other bootloader? Sep 21 16:32:52 <[g2]> I think it gets loaded at 0x0 in flash Sep 21 16:33:00 <[g2]> APEX ? Sep 21 16:33:05 yes, that one Sep 21 16:33:25 it can be executed form any address, it just need to be at 0x00 to boot form flash Sep 21 16:33:36 <[g2]> http://wiki.buici.com/twiki/bin/view/Main/ApexBootloader#IXP42x_and_the_Linksys_NSLU2_aka Sep 21 16:33:45 ok, going to read that Sep 21 16:33:53 but actually flash gets mapped at higher address Sep 21 16:35:06 it seems easy to read it in ram Sep 21 16:35:08 load it. Sep 21 16:35:48 <[g2]> right you can load it into ram in run it from redboot Sep 21 16:35:54 yes, that's the the point, no need to kill your nslu2 + quick testing ;-) Sep 21 16:36:15 <[g2]> well with JTAG there's no killing involved Sep 21 16:36:36 yvasilev: i'm still missing a point.. by doing that we should gain knowledge about what exactly? Sep 21 16:38:43 that le mode works + that we can have a natively le slug + there is no need to do much byteswapping and may help us with le kernel/ial/npe Sep 21 16:39:03 ok. so we should have a redboot with 1.5 Sep 21 16:39:23 2.0 I would say Sep 21 16:40:42 <[g2]> redboto 2.01 with CSR 1.5 Sep 21 16:41:16 2.02 is for csr 2.0? Sep 21 16:41:19 <[g2]> dwery the point is you'd probably have a working LE with 1.5 Sep 21 16:41:26 <[g2]> yvasilev, dunno Sep 21 16:41:28 [g2]: has this redboot ever tested on nslu2 Sep 21 16:41:32 ? Sep 21 16:41:38 <[g2]> nope Sep 21 16:41:54 <[g2]> but I have JTAG on the Loft and it runs BE on the loft Sep 21 16:42:03 <[g2]> so it's just a LE compile Sep 21 16:42:37 wait, you have built 2.01/CSR1.5 on the loft? Sep 21 16:52:43 [g2]: ? Sep 21 16:58:05 yvasilev: are you there? Sep 21 16:58:09 yes Sep 21 16:58:26 i thought I had network problems :) Sep 21 16:58:48 * yvasilev is trying to find a pdf by intel about building le redboot Sep 21 17:02:35 looks like redboot 2.01 has many bugs Sep 21 17:03:02 :( Sep 21 17:15:12 dwery: take a look at http://www.intel.com/design/network/swsup/IXP400-RedBoot-2_0-relnotes.pdf Sep 21 17:15:17 ok Sep 21 17:16:27 seems interesting Sep 21 17:18:09 it can auto byteswap the kernel ;-) Sep 21 17:19:42 wow Sep 21 17:26:22 i have to go now, se ya tomorrow Sep 21 17:26:40 bye Sep 21 17:36:31 have somebody dbd::mysql build successfully? Sep 21 17:38:10 I got lots of "warning: Please check that you local settings: ...LC_ALL... are supported..." Sep 21 17:49:44 sorry connection problems Sep 21 17:50:02 was there an answer to my question? Sep 21 17:51:31 no Sep 21 17:53:17 is my question still here? Sep 21 17:53:21 yeah Sep 21 17:53:51 is there another way to usa a database on the nslu? Sep 21 17:54:22 I wanted to use mysql with the build in webserver, but dbd is missing Sep 21 17:54:30 and cant compile it Sep 21 17:54:41 ok, are you using unslung or openslug? Sep 21 17:54:48 unslung Sep 21 17:54:55 mysql is installed Sep 21 17:55:25 and apache needs too much resources Sep 21 17:55:39 <[g2]> cheef_daniel, got a URL for the Dacal Storage Box ? Sep 21 17:55:55 yes I see it Sep 21 17:56:05 there is a point at the end of URL Sep 21 17:56:38 http://www.itechcds.com/ Sep 21 17:57:40 can I modify my text in the groups? Sep 21 17:58:43 <[g2]> does the unit eject a CD/DVD ? Sep 21 17:58:52 <[g2]> or just spin to the proper spot ? Sep 21 17:59:18 both Sep 21 17:59:45 <[g2]> does the lid have to be off Sep 21 17:59:49 first it rotates, and then its eject Sep 21 18:00:02 <[g2]> or is the an opening in the top Sep 21 18:00:26 there a 3 models, I have the smallest with 150 CDs Sep 21 18:00:49 got it at ebay for 30-40 20ac Sep 21 18:03:14 here is some sheet about the box:http://www.produktinfo.conrad.com/datenblaetter/950000-974999/970235-da-01-en-CD-Archiv-Box_f_150_CDs_de-en-fr-nl.pdf Sep 21 18:04:55 and a documentation: http://www.produktinfo.conrad.com/datenblaetter/950000-974999/970235-da-01-en-CD-Archiv-Box_f_150_CDs_de-en-fr-nl.pdf Sep 21 18:05:05 (3MB) Sep 21 18:06:49 g2: you mean with the lid the frontal drawer? Sep 21 18:07:30 no you must open the lid manually, but you can it get opened Sep 21 18:07:37 all the the time Sep 21 18:08:43 the opening is ath the front, so you can stuck multiple of it Sep 21 18:12:46 here is some better pic: http://www1.conrad.de/xl/9000_9999/9700/9700/9702/970235_BB_00_FB.EPS.jpg Sep 21 18:13:38 NAil: do you know how can I acces a database from the built in webserver? Sep 21 18:20:31 no, sorry... I only use OpenSlug Sep 21 18:21:54 How do it with OpenSlug? Sep 21 18:23:07 [g2]theroicaly you can use 127 librarys: 150 * 127 = 19050 CDs ;-) Sep 21 18:24:15 but then you must use another software that tells you in which room the library is Sep 21 18:33:22 hmm Sep 21 18:33:46 Audio CDs? :) Sep 21 18:34:23 if you like Sep 21 18:34:28 I figure I can encode some 13000 audio CD's and put on my various NAS'es ;) Sep 21 18:35:50 I hardly ever use any CD's though Sep 21 18:36:19 is openlslug better? Sep 21 18:36:20 anyway... No, I don't know how to access a db on either openslug nor unslung actually Sep 21 18:36:33 openslug is better for customisation Sep 21 18:36:44 but it removes the webinterface Sep 21 18:37:32 hm, is it normal that the free ram is only 800kb? Sep 21 18:37:50 between 500 and 5000 Sep 21 19:17:48 does someone have intel's redboot 2.02 sources? Sep 21 22:27:46 03jbowler * 10upslug2/configure.ac: Sep 21 22:27:46 Changed to insist on automake 1.9 and to use CONFIG_HEADERS - i.e. to be Sep 21 22:27:46 as up to date as possible. Sep 21 22:39:40 03jbowler * 10upslug2/configure.ac: Change the version number to '4' Sep 21 23:00:55 03jbowler * 10upslug2/Makefile.am: Sep 21 23:00:55 Fix make dist-gzip (etc) to actually include the header files in the Sep 21 23:00:55 distribution. **** ENDING LOGGING AT Thu Sep 22 02:59:56 2005