**** BEGIN LOGGING AT Thu May 21 02:59:57 2009 May 21 07:03:16 okay, that took some time... I cannot use ubifs with my sd-card... May 21 07:03:42 what's the 2nd best choice for an sd-card? (I'm planning to run debian from it) May 21 07:52:41 digger3: ubifs is intended for the internal flash of the plug. with SD card (the same as USB stick) all the wear leveling and bad block managament is don't on the card itself May 21 07:53:08 digger3: for SD card I recommend EXT2 or any other filesystem that doesn't have journalling May 21 07:53:15 (minimizes writes to the SD card) May 21 07:53:23 rabeeh: I'm curious: why not yaffs2? May 21 07:54:20 digger3: same reasons. jffs2/ubifs/yaffs2 are all intended to be run on the hos Linux when there is a bare NAND flash connected to it. So all wear leveling is done on host Linux May 21 07:55:11 rabeeh: ah, okay, thanks May 21 08:27:05 ubifs is just better :-) May 21 09:41:00 hi, I'm getting loads of: http://pastebin.com/m3339eb9 errors when booting debian from the sd-card, any advice on what could be the problem? May 21 09:44:39 ah, now the complete filesystem is trashed.. fascinating May 21 09:46:56 digger3: which kernel are you using? May 21 09:47:52 I copied all the files with the stock 2.6.22 kernel which came pre-installed -> no worries, I installed debian with the usual instructions (kernel version 2.6.29) and end up with a corrupt fs May 21 09:48:28 which usual instructions? May 21 09:48:37 I'm planning to try and reboot into the NAND flash, unzip debian on the sd-card again, and replace the 2.6.29 kernel with the 2.6.30-rc6 one, does this make sense? May 21 09:48:38 are you applying the mvsdio patch? May 21 09:48:46 rabeeh: http://www.cyrius.com/debian/kirkwood/sheevaplug/unpack.html May 21 09:49:40 rabeeh: nope, it's my first day trying this plug May 21 09:53:00 rabeeh: are there precompiled kernels that will allow me to quickly test this 'mvsdio' patch or do I need to compile it? May 21 09:53:29 digger3: http://plugcomputer.org/plugforum/index.php?topic=298.0 May 21 10:25:55 rabeeh: okay, I'll try that as soon as I get it to boot from the NAND-flash again May 21 10:26:00 rabeeh: thanks May 21 10:26:22 digger3: i'll be posting a new recovery tool on the forums (today) May 21 10:26:53 the new recovery tool will install the plug with kernel 2.6.30-rc6, uboot with SD card support (patch from the forums) and ubuntu 9.04 the release version May 21 10:30:21 rabeeh: sounds good May 21 10:30:54 rabeeh: will it allow me to install ubuntu to the SD, or to the NAND? May 21 10:31:05 NAND May 21 10:31:17 can be easily modded to install on SD May 21 10:31:37 that's true, I like the fact that I have a recovery system installed, comes in handy now... May 21 14:24:59 http://plugcomputer.org/plugforum/index.php?topic=323.0 May 21 14:53:14 rabeeh: I suppose that this kernel too lacks crypto acceleration, doesn't it? May 21 14:54:18 Md: crypto driver is supported on the 2.6.22.18 kernel only. Lately crypto driver was posted for Orion support; but I don't know what is their status. May 21 14:56:20 do you have a URL? May 21 14:56:32 a friend of mine is interested in porting it to mainline May 21 14:57:52 http://marc.info/?l=linux-arm-kernel&m=124173065908928&w=2 May 21 14:58:03 Sebastian? May 21 14:58:13 the same guy? May 21 14:58:27 no May 21 14:58:53 does he have orion or a plug? May 21 15:06:20 why don't you use OCF layer? May 21 15:06:46 zumbi: that's what kernel 2.6.22.18 use May 21 15:09:55 rabeeh: ok - we had been using OCF with an AES hardware crypto engine on the 2.6.28 May 21 15:10:47 also with openssl support May 21 15:49:55 I do not like much the idea of using OCF, because this means that there are about zero changes for the driver to be merged in mainline... May 21 15:49:59 rabeeh: a plug May 21 15:51:15 there's no mainline crypto framework that is usable from userspace, is there? May 21 15:51:37 on x86 it's all just instructions built into the cpu itself May 21 15:52:07 s/changes/chances/ May 21 15:52:25 lennert: no mainline, but out-of-tree, http://ocf-linux.sourceforge.net/ May 21 15:52:48 zumbi: this is what the existing driver is using May 21 15:54:04 Md: yes, that is what rabeeh said above May 21 15:54:46 i'm reading the FS on sdio. page 260 mentions the sdio registers at being at offset 0x80000, while the register descriptions at page 714 at 0x90000. May 21 15:55:03 describe them at* May 21 15:55:11 rabeeh: are new versions of the FS being made? May 21 15:56:05 zumbi: i'm not talking about OCF May 21 15:56:35 lennert: then i misunderstood, sorry May 21 20:11:51 ping lennert.... May 21 20:39:00 lennert remember the n1200 (the one with the 10/100 marvell switch chip) May 21 20:39:28 we still have the issue where we need to plug in one of the switch ports and it has to be up for the other ones to work May 21 20:39:51 if we can get you one at some point wanna fix that? :) May 21 20:40:11 bbradley is going to get other bits mainline soon May 21 20:40:28 (woo i get my name in the kernel somewhere then finally...) May 21 20:41:21 if we get you one its obviously for keepsies. thats if marvell wont spank you for owning a mpc based ppc device :D May 21 20:41:56 back in a bit... May 21 20:46:30 I installed the 2.6.30-rc6 kernel, and tried to boot from the sd card, but all I'm getting is: http://pastebin.com/m758013fe and it then just hangs, any tips? May 21 21:07:10 timtimred: that's the phy issue May 21 21:07:21 timtimred: you should be able to say in the dts that giantfart needs to use a 'fixed' phy May 21 21:07:33 timtimred: ask afleming how to do that if you can't figure it out May 21 21:07:40 timtimred: should be straightforward i guess May 21 21:07:51 timtimred: i think i have enough devices :) May 21 21:12:52 afleming noted ta May 21 21:13:01 hmm, i think i know ho to do that already. May 21 21:13:36 okay :) May 21 21:13:47 um, maybe. May 21 21:13:47 i fixed a bug in gianfar the other day... afleming owes me :) May 21 21:13:48 :) May 21 21:13:51 so feel free to bother him ;) May 21 21:14:00 cool will do :) May 21 21:15:10 will try it out this weekend May 21 21:15:26 ping bbradley_ your changes in our git repo? :) May 21 21:15:48 not yet, just sorting out a defconfig and splitting my changes into two patches May 21 21:16:18 okies. i think OE pulls that repos head so lets put it in a branch to test? May 21 21:16:35 (maybe im wrong there) May 21 21:17:03 yeah, I'll put it on a for-mainline branch or something May 21 21:17:23 sweet May 21 21:57:59 lennert did you find out more about that device May 21 21:58:43 timtimred: which? May 21 22:00:02 440 May 21 22:00:04 based May 21 22:00:17 sorry? May 21 22:00:24 some powerpc thing May 21 22:00:30 what is this in? May 21 22:01:16 you said someone might have a device for a mainline port May 21 22:01:26 i dont know what it is :) May 21 22:01:54 and were going to get more info :) May 21 22:02:14 ah! May 21 22:02:20 yea, that was from TS May 21 22:02:27 i should follow up with the guy actually, haven't done yet May 21 22:02:28 sorry May 21 22:02:40 heh np... May 21 22:04:31 i can see a couple of other devices in 2.6.23 have fixed phy thing happening May 21 22:04:35 using vitesse May 21 22:06:00 as specified in some dts May 21 22:58:29 night all :) May 22 00:38:49 can someone clarify 0x400000@0x100000(uImage) is > 2MB is it not? May 22 00:42:07 is it size@base or end@base May 22 00:42:46 size@base **** ENDING LOGGING AT Fri May 22 02:59:57 2009