[01:47] rcn-ee, do you know if there was any zippy changes pulled in on rc4 or rc5? I'm getting null pointer dereferences on most network activity on the zippy's ethernet [04:12] Hey cwillu_at_work i need to still rework the zippy patches that were in 2.6.34 they don't apply cleanly to 2.6.35 yet (and they fix a lot of problems) [04:23] ah, k [04:23] did .33 have working zippy2? === ApOgEE__ is now known as ApOgEE [04:32] does anyone know if ubuntu lucid works properly on the beagleboard C3 ? [04:33] pcacjr_at_home, as far as c3's work properly, yes [04:33] cwillu_at_work, thanks mate [04:33] there's some remaining instability on the ehci port, although it can be managed [04:33] pcacjr_at_home: yep :-) [04:33] pcacjr_at_home: trying ubuntu now? [04:33] rsalveti, yeah :-) [04:34] pssst, buddy, wanna try a btrfs root? :) [04:34] rsalveti, afaik you used to install ubuntu lucid on that beagle you gave me [04:34] rsalveti, right ? [04:34] pcacjr_at_home: yep [04:35] but that's not a c3, it's a b5 I believe [04:35] rsalveti, great. so i'll give it a shot! [04:35] thanks [04:35] hm [04:35] you can still try lucid, but will be very slow [04:35] recommend you to try without gui [04:35] ok then [04:35] ;-) [04:36] the b's only had 128mb ram, right? [04:36] yep [04:36] and just the usb otg [04:36] so no GUI though [04:36] it might be livable if you put swap on a usb disk [04:37] with gui, I mean [04:37] cwillu_at_work, but it'll get slow though... [04:37] anyways i don't even need GUI ;-) [04:37] pcacjr_at_home, it gets slow even with 256mb :p [04:37] D'oh [04:37] :-) [04:37] if you don't need gui, then that's ok [04:37] depends entirely on your working set [04:39] i see [04:39] thanks folks === kmargar is now known as markos_ === Termana_ is now known as Termana [07:57] rcn-ee: just to let you know that I pushed some commits at rootstock, and this will probably break your script and patches [07:57] will look at other bugs tomorrow [07:57] time to get some sleep now === hrw|gone is now known as hrw [08:20] morning [08:26] Morning hrw [08:51] hrw: Do you remember the SD -110 error bug? [08:52] timeout [08:53] iirc [08:55] Was there a bug raised? [08:56] I had that few years ago in Zaurus [08:57] and at that time it ended with problematic card sent to RMK for checking on his hardwares. patches landed in kernel, card started working [09:01] I'm getting it on Beagle [09:01] It was a problem a few weeks ago [09:01] I think mpoirier was working on it [09:01] ogra: Can you remember if there was a bug report raised? [09:13] Found it: bug 591941 [09:13] Launchpad bug 591941 in linux (Ubuntu Maverick) (and 1 other project) "SDHC card not recognized (affects: 2) (dups: 1) (heat: 135)" [High,In progress] https://launchpad.net/bugs/591941 [10:10] + * Append ${SUBARCH:+-$SUBARCH} to LOG filename for consistency. [10:10] + [10:10] + -- Loïc Minier Wed, 02 Sep 2009 09:23:59 +0200 [10:10] lool, did you ever check what happened after that change ? ^^^ [10:26] amitk: i am looking at tony's linux-omap tree, do you know which branch shall i take a look [10:27] amitk: if i wanna cherry pick some patches to enable panda in our Ubuntu master tree -omap flavor [10:27] * ogra wonders why you want to do that [10:28] it will work only half i guess and we have a properly working omap4 kernel on the omap4 images [10:29] ogra: because I want a mainline-only version of omap4 [10:29] ogra: and because that is the future [10:29] ogra: i also wanna ask amitk that question. [10:30] amitk, but what do we gain from it beyond confusion ? [10:30] amitk: i think we can build a pure mainline omap4 version for our panda boards. [10:30] you wont be able to run the -omap images on -omap4 HW [10:30] since the boorloaders differ [10:30] amitk: oh, sorry, not mainline, tony's upstream kernel [10:31] and -omap4 images will always install the -omap4 kernel by default [10:31] ogra: bootloader issue will be fixed upstream [10:31] amitk, it cant [10:31] ogra: I don't plan to use your images [10:31] there are HW constraints you cant work around in SW [10:31] it will only start working if DT is fully integrated [10:32] multiomap kernels were omap2/3 only? [10:32] and i'm not even sure about that for pandas vs blaze [10:32] cooloney: Tony's for-next branch is usually the one (I see it has support for Panda) [10:32] hrw: no, multiomap is omap2,3,4 [10:32] * ogra guesses omap4 support is very rudimentary [10:33] ogra: I am not sure what the reach problem is with supporting panda with the mainline kernel? [10:33] ogra: could you expand? [10:33] amitk, 700 patches ? [10:33] ogra: here is where you don't understand what I'm trying to do [10:33] amitk, i doubt all the changes and patches we have on the current omap4 tree are in tonys branch [10:34] so the omap4 support will suck in the -omap kernel [10:34] ogra: I DONT CARE ABOUT YOUR DESKTOP IMAGE WITH ITS BELLS AND WHISTLES :) [10:34] amitk, i understand that [10:34] amitk: working serial is enough ;D [10:34] ogra: DONT CARE from the POV of what I'm trying to achieve. I do care about it otherwise, great work :) [10:34] but i fail to see any benefit before omap4 is properly integrated in -omap [10:35] hrw: exactly === XorA|gone is now known as XorA [10:35] ogra: amitk just wanna a Ubuntu M 2.6.35 kernel which can supports omap4 hw [10:35] amitk, what do you gain by that if you *only* have a serial console [10:35] like you dont have MMC, USB, NIC or any other HW support [10:35] amitk: ok, i am looking at it [10:36] ogra: that is where you are wrong. Mainline already supports basic omap4 features (uart, i2c, mmc). [10:36] ogra: once you got omap4 usb you will have nic support [10:36] stragne since not even our omap4 tree properly supports many of these [10:36] ogra: It helps us with device tree work, as one example [10:36] ah [10:36] that was an answer i was looking for :) [10:37] *some* kind of near future benefit :) [10:38] ogra: for linaro purposes it doesn't have to work perfectly - that is what your omap4 image is for. Having a mainline-only version allows us to experiment [10:39] so any development happening against mainline won't have to be thrown away [10:39] amitk, right, i did see more benefit from merging the omap4 branch step by step, thats why i was wondering about having a second code path [10:40] amitk: and we need pandas to have HW for tests [10:40] hrw, arm team is happy to help [10:41] if xyou need any verification that costs us just a "play around SD card" :) [10:41] amitk: just a quick look at for-next branch of tony's tree. [10:41] ogra: we'll even supply dedicated SD cards for OMAP4 work ;) [10:41] ogra: plug card, reboot, pastebinit serial output [10:41] it seems like tony merged several branches there and prepare it for next .36 merge window [10:41] amitk, you mean you send me one ? [10:41] cool ! [10:42] :) [10:42] cooloney: right [10:42] writing 1.7GB to SD card takes eons [10:42] hrw, use a proper bs= value in dd [10:42] speeds up a lot [10:42] 20K is enough? [10:42] bs=1M works for me [10:42] * ogra uses 4k [10:42] i'd say the Panda board patch is the same from our -omap4 branch [10:42] i found thats the fastest on my laptop [10:43] ah you laptop users... [10:43] I do dd from tmpfs to sd card [10:43] well, builtin SD reader is unbeaten :) [10:43] 77,698 s, 6,5 MB/s [10:43] cooloney: in any case, please pull from tony's tree rather than -omap4 tree (so we have the commit id) [10:43] ogra: my tower has builtin cf/sd/ms/something [10:44] ah [10:44] s/^7/27 [10:44] and I use usb one anyway ;D [10:44] * ogra dislikes if his SD cards are named /dev/sdX [10:44] way to error prone if you have a /dev/sdX HDD [10:45] amitk: that's not very hard. i can do that. but i found several serial port patches for omap2/3/4 [10:45] I have sdh usually for sd card [10:45] cooloney: do only the minimal necessary to get serial port on panda with master branch [10:45] accidentially typo that tp /dev/sda and you have fun with restoring backups :) [10:46] cooloney: it should only be 2-3 patches at most [10:46] s/tp/to [10:46] lunch time === amitk is now known as amitk-afk [10:47] ogra: how to regenerate boot.scr? [10:47] needed to change res [10:47] do it from your desktop [10:47] I know - need command [10:47] copy it over, remove header, change cdmline and run mkimage [10:47] ah [10:47] got [10:48] mkimage -A arm -T script -C none -n "Ubuntu boot script" -d boot.scr [10:48] I2C: ready [10:48] and beagle stopped [10:49] in the installed system there is /boot/boot.script ... change it there and run sudo flash-kernel [10:49] ogra: http://hrw.pastebin.com/si5pstv6 [10:49] sounde like you use a wrong x-loader or u-boot [10:49] I had 1.4.4 xloader before [10:50] yeah, you dont use MLO from the card [10:50] 1.4.4ss is thats in the archive [10:50] ok, user button helped [10:50] :) [10:50] 1.4.4ss is needed for XM support [10:50] so we default to that one [10:50] http://hrw.pastebin.com/c6piMtqb [10:51] huh ? [10:51] reading /casper/uImage ?!? [10:51] whats that ! [10:51] http://hrw.pastebin.com/hMJ9kSrH is printenv [10:52] hrw, are you sure you used the shipped boot.scr from the SD vfat as a source ? [10:52] yes [10:52] printenv is ignored [10:52] we only use boot.scr [10:52] can you paste your original boot.scr ? [10:53] sure moment [10:54] http://hrw.pastebin.com/z0aTDHFk [10:54] booted script from memory now [10:55] it is resizing now [10:55] that boot.scr doesnt have any /casper/uImage in it [10:55] ogra: so it looks like boot.scr was ignored [10:56] oh, you had lucid installed before [10:56] ogra: where is progressbar? I see "Resizing root filesystem please wait, this will take about ten minutes ..." [10:56] below that you should see dots appearing after a while+ [10:56] ok [10:56] not sure how long that takes, i did my tests for the code with an image file [10:56] real SD might be slower [10:57] ogra: btw - "Resizing root filesystem. Please wait, this will take about ten minutes ..." would be better [10:57] ogra: 3x "sh: closing paren expected" and then there are dots shown [10:57] i need to rephrase it anyway [10:57] ouch [10:57] damned [10:57] ogra: would be nice to have [ 0/100% done] ........ [10:58] thats rather complex code [10:58] ................shproblem\n...........shproblem\n........ [10:58] for now i'm happy to have *anything* [10:58] yeah, thats busted [10:58] ogra: do you know how many dots will be printed? [10:58] yes [10:59] still it needs a math function [10:59] python has nice itertools [10:59] currently i'm just using the output of resize2fs directly [10:59] and i dont have much time to care for more [10:59] no pythin in initramfs [10:59] needs to be shell [11:00] ogra: resize2fs with "-p" option? [11:00] shproblem\n..... [11:00] yeah [11:03] 4th line of dots ended without shproblem [11:05] and nothing now [11:10] uf. [11:10] [932] mounted ext3 rootfs [11:11] http://paste.ubuntu.com/463956/ ... i dont see where a parenthesis is missing :/ [11:14] i dont see where "shproblem\n" could come from [11:15] its a really dumb function that should parse the output 1:! [11:15] *1:1 [11:16] hrw, if you are done i'd like to have /var/log/jasper.log from the system [11:16] [1313] oom killer [11:17] ureadahead ? [11:17] or plymouthd ? [11:17] and plymouth [11:17] both are normal [11:17] and udev shouts "no space left on device" [11:17] and are hopefully fixed already (not uploaded yet) [11:18] yeah, thats one i still have to resaerch [11:18] it writes to a tmpfs [11:18] and doesnt happen on second boot anymore [11:18] i suspect its caused by ureadahead eating all ram [11:18] ogra: how much time since boot to login? 1h or more? [11:19] which will be fixed with next ureadahead upload [11:19] 20min or so [11:19] depends on the size of your SD [11:19] the resizing actually takes 10min per 4G [11:19] 4GB card [11:19] right [11:19] 1489 segfaiult [11:19] i would have guessed so [11:19] oops from kernel [11:20] since you said you see the resizing msg at 11:57 [11:20] now its 12:20 [11:20] last sysfs: /sys/module/parport/initstate [11:20] yeah, known and fixed already [11:20] or in the process to be fixed [11:20] lag is working on it [11:20] fix commited but not fix released? [11:20] cups forcefully loads parport_pc [11:21] What can I do you for? [11:21] the module code needs fixing to not segfault [11:21] A have sent a patch upstream [11:21] lag you are already doing :) [11:22] hrw, any trace of oem-config already ? [11:22] i know its not fast but you should see some X by now [11:23] text console disappeared so maybe x11 tries to start [11:23] ah, great [11:23] got ugly x11 background [11:23] heh [11:23] looks like 3bit or few more [11:24] you changed the display defaultsd [11:24] from 1280x720 to 1280x800 [11:24] my monitor is 16:10 [11:24] should soon swithc to 24bit, the first one is 16 [11:24] right before oem-config shows up it switches over [11:27] looks like mouse and keyboard were not detected in x11 [11:27] hmm [11:27] C4 ? [11:27] or your old C3 [11:27] C3 with working usb [11:27] I used keyboard in text console to unblank monitor [11:28] * ogra hasnt seen any kbd mouse issues in the maverick images on C4 yet [11:28] wait a bit, its probably just busy with swapping [11:29] ogra: how much ram omap3/4 needs to have to get normally working UNE? 2GB? 4GB? [11:30] htop shows about 200M used usually [11:30] we add a 512M swapfile [11:30] so you should have >700M [11:30] I would fetch/unpack/boot-to-x11/installirc/gettoirc/discusshere with angstrom/gnome in shorter time then I got here [11:30] actually more like 160-180 used [11:30] it took 35 minutes so far and still nothing usable [11:31] well, its like 15 with omap4 [11:31] masacre [11:31] omap3 is just something thats nice to have [11:31] omap4 is the target arch we work for [11:31] * hrw wants omap5 with 4GB ram and 20MB/s storage [11:31] heh [11:32] on omap4 only the resizing is slow and thats caused by the bad MMC driver [11:32] bbc3 feels insanely slow when rootfs is on usb [11:32] i have some hope that will be solved for final [11:32] bbxm will give better behaviour due to more ram [11:33] and faster cpu [11:33] yeah, i'll still have to test that [11:33] panda will again give faster cpu and more ram [11:33] i havent had the time yet, i'll do some test installs at the sprint on XM [11:33] my lcd just blanked out. touching keyboard does not bring it back [11:33] while C3 and C4 should be "supported" i'd rather recommend a cmdline install for such users [11:34] i.e. install lucid netinst image and dist upgrade to maverick [11:34] may I reboot? === amitk-afk is now known as amitk [11:34] hrw, try it, it should kick you into oem-config again [11:36] mmc init; fatload mmc 0 0x82000000 boot.scr; source 0x82000000 [11:36] for your uboot prompt :) [11:36] bootscr got not loaded [11:36] thx [11:36] i'll provide a tool to blank NAND config for such cases [11:36] so it falls back to defaults [11:37] as soon as we have the NAND driver back in the lucid kernel [11:37] got plymouth [11:37] good [11:38] i wonder if we should force a reboot after resizing [11:38] though with screwed NAND that will be problematic [11:40] but would be a) good to verify the new partition table works fine and b) likely be faster to bring up oem-config [11:41] plymouth disappeare [11:41] got ugly x11 [11:41] mouse works ? [11:42] nope [11:42] * ogra blames the maverick kernel [11:42] sorry, works but very slowly [11:42] works for sure on C4 [11:42] phew [11:43] * ogra blames I/O [11:43] now works normally - probably oom killed something [11:43] i guess it just swapped [11:43] while reading from SD at the same time [11:45] nicer background on screen (did not noticed when changed) [11:45] o... language chooser [11:46] but why 1280x720... [11:46] it does not fit on screen ;( [11:46] default cmdline param [11:48] the bad part is that this is ubuntu - I need to wait to end of oem-config to get possibility to login on vt1 ;( [11:48] hrw, jasper resets the resolution again, please file a bug that it should pick that up from an existing cmdline instead [11:48] ogra: bug on jasper? [11:48] hrw, not to the end, only to the end of the config tool [11:48] hrw, jasper-initramfs [11:49] hrw, you can switch to tty and log in once it started removing stuff [11:50] jasper? [11:50] hrw, how else than through something like oem-config would you set up the system ? [11:50] amitk, yes [11:50] what is it? [11:50] amitk, the little brother of casper AKA the "douchebag ghost" :) [11:51] amitk, it does the resizing of the rootfs partition and enables oem-config [11:51] ogra: oem-config has to fight against other processes to get some spare ram [11:51] and sets up fstab [11:51] press "Next", wait minute or two... [11:51] hrw, yes, its not fast [11:51] huh! and it is run on every install? [11:52] amitk, on first boot [11:52] aah I see, i missed the keywork: oem-config [11:52] oem-config == ubiquity witout partitioner [11:52] jasper does the partitioning step [11:52] ogra: when are we getting preinstalled images for arm this cycle? [11:53] amitk: we have them [11:53] amitk, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/ [11:53] since some weeks :) [11:53] nice! [11:53] * amitk hugs ogra [11:53] amitk: you need 1.5h to get omap3 pass first boot [11:53] amitk, but they are no fun on beagle [11:53] why? [11:53] they are great on panda though [11:53] they are not really pre-installed? [11:53] amitk, resize2fs is slow, it swaps a lot for oem-config (which runs under X) [11:53] amitk: because they suxx if you do not have 1GB ram and 20MB/s read/write from rootfs [11:54] hrw, nonsense [11:54] 512M are plenty [11:54] i expect the XM to be nearly as good as panda [11:54] but 256M is definitelly far far far far too small [11:54] agreed [11:54] and I have 128MB beagleboard somewhere... [11:54] ogra: seems like my definition of a pre-installed image differs from what is provided. Why does it need to resize? [11:54] if i find the time i'll do preinstalled cmdline images [11:55] or rather, what? [11:55] amitk, because users dont want to download 4G [11:55] the rootfs is as small as possible on that image [11:55] and gets expanded to the full size of the SD [11:55] so it doesnt matter what SD card you use [11:55] ogra: Bug #605831 [11:55] Launchpad bug 605831 in jasper-initramfs (Ubuntu) "[omap3] Resolution should be taken from /proc/cmdline if provided (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/605831 [11:56] thanks [11:56] eeeks [11:56] amitk, ?? [11:56] amitk: but do not use card larger then 4GB - you will wait too long [11:56] the uncompression of rootfs [11:56] amitk, not uncompression [11:56] its just resizing [11:56] to use up all the spare space on the SD [11:57] amitk, a simple resize2fs [11:58] ogra: ok, and no chance of a 4G image for people that have the BW? [11:58] Scheiße [11:58] amitk, no, that would be a waste [11:58] this feels like 2 steps froward and 3 steps back [11:58] amitk, why [11:58] creation of users should be before 'configuring keyboard' [11:59] hrw, complain at the ubiquity maintainers [11:59] because it still takes 2 hrs to get ubuntu on a beagle [11:59] not my area :) [11:59] amitk, it takes 15min on a panda [11:59] ogra: which only 3 people have in this world outside TI :) [11:59] amitk, its not the design of jasper that makes the beagle slow [12:00] amitk, or the design of the image [12:00] i understand it is the IO [12:00] amitk, its the fact that beagle is to slow for a desktop image [12:00] its not even the IO [12:00] IO is fine for cmdline images [12:00] ogra: so you're saying it is memory-bound? [12:00] heh ubuntu got too fat for the beagle :-) [12:00] the fact that we dont special case omap43 images but build the same image for omap3 and 4 is what hits us [12:01] XorA: it would seems so [12:01] if we would provide cmdline images for omap3 that would be fine [12:01] but the XM will be as good as the panda here [12:01] so just for Cx boards i wont trash the netbook image [12:02] if i find the time to hack them up i'll provide special cmdline Cx images [12:02] ogra: wouldn't it be easier to partitions the SD card to use up the extra space? [12:02] if i dont, people have to live with that on Cx boards [12:02] amitk, surely faster but error prone [12:02] ogra: and some magic with aufs to unionise them [12:03] eeek ! [12:03] lol [12:03] amitk, the prob is that i would need separate partitions for /tmp and the like [12:03] its not as easy as it seems [12:03] and the ten mins for the resizing are really not the prob [12:04] the prob is oem-config and the X session [12:04] ogra: IMHO, they are. It doesn't make for a great 1st experience [12:04] even the 10mins [12:04] on an OMAP4 board that nobody has [12:04] amitk, partitioning in ubiquity is a lot slower [12:05] like 20min on the C4 [12:05] so i dont let that argument count [12:05] the lucid install takes over 2h [12:05] having a 10min resize action at bootup is really not a biggie [12:06] ogra: ok, let me restate my problem (I've been bitching out this for a long time, almost 2 years, you already know that) [12:06] having oem-config running for >1h is though [12:06] but thats improvable due to using a cmdline image [12:06] re [12:06] or at least oem-config in cmdline mode [12:07] (which is ugly but a possibility for C4 boards) [12:07] ogra: I want an image that I can dd onto a SD card (make assumptions of 4G card!), insert it in beagle and see it boot ubuntu. In under 5 mins. [12:07] amitk, go to linaro :P [12:07] though you have to manually partition the card etc [12:07] ogra: why? the dd image should take care of it. Make it a fixed 4G image [12:08] i wont maker assumptions and i wont get allowance to spend 32G on the builder machine for kubuntu and ubuntu images [12:08] why would i waste the space on an 8 or 16G card ? [12:08] ogra: provide tarballs of rootfs [12:08] hrw, thats not what ubuntu does ... go to linaro for such stuff [12:09] so I/amitk will grab tarball, unpack to card and boot [12:09] that all was discussed to an extend at UDS [12:09] kk [12:09] its a bit late to change an implemented spec now :P [12:09] *sigh* [12:09] * amitk prepares to wait another year [12:09] problem with UDS was 99% of people couldnt get that embedded != smaller PC [12:10] the choice we had was eithet debian-installer/ubiquity with a 2h installation or the current setp [12:10] so ubuntu requires: bbxm, igep2/512M, panda, blaze, touchbook/512M and nothing smaller [12:10] XorA, ubuntu doesnt do embedded [12:10] XorA, thats linaro [12:10] Linaro didnt exist then (apart from in the worlds worst kept secret) [12:10] hrw, if i dont provide cmdline images [12:10] I wonder if lool is interested in investigating this in Linaro [12:10] XorA, linaro did exist ... just not the name [12:11] I would not call beagleboard embedded - I have more embedded hardware [12:11] XorA, in fact the arm team wasnt allowed to have its own track at UDS because of linaro [12:11] XorA: there were Linaro meetings during uds [12:11] hrw: I know, but I didnt have an NDA that allowed me to know about them [12:11] even though I did [12:11] XorA, they were just called differently [12:12] XorA, all arm tracks at that UDS were linaro tracks [12:12] next UDS we'll have linaro and arm tracks and you will notice the difference between the approaches [12:12] ubuntu-arm is to bring ubuntu images onto arm devices that are powerful enough to run ubuntu [12:13] linaro is to make that restriction go away some day ;) [12:13] bah all this division makes my head hurt :-) [12:14] linaro does upstram and core work ... ubuntu-arm just operates in the limitations of ubuntu [12:14] if you look at the min reqs for installinf ubuntu on a PC, the same restrictions apply for ubuntu.arm for example [12:14] i.e. 384M and 600MHz or so [12:15] and a GL capable videocard [12:15] at least for the maverick netbook release [12:15] ogra: so omap3/4 does not fit - no 3d driver in ubuntu [12:16] none of these restrictions apply to linaro [12:16] linaro req armv7 [12:16] and linaro works on getting ubuntu off these restrictions [12:16] hrw: they have a GL capable GFX card, ogra didnt say he needed drivers :-) [12:16] XorA: ah... right ;D [12:16] XorA, we'll have drivers at some point [12:17] GLES drivers yes [12:17] for sure for the panda ... and likely also for the beagle [12:17] they are on my desk at the moment [12:17] right [12:17] X11 just died here [12:17] linaros job is it to improve ubuntu in a way that it can run with these drivers [12:17] 1h23 minutes so far [12:17] like making clutter/unity work [12:18] clutter works :-) [12:18] or like making it work in less ram [12:19] amitk, give me a resize tool that operates faster than 10min per 4G [12:19] amitk, then you wont have to wait for another year ;) [12:19] or s/year/release/ [12:20] ogra: will isntaller work if card will be in usb card reader? [12:20] ogra: it is probably worth an extension to ext4 fs to treat sparse files in a special way [12:20] hrw, only if the device manes persist [12:20] *names [12:20] ogra: so it is hardcoded to /dev/mmcblk0*? [12:21] amitk, we use ext3 ctrrently [12:21] hrw, yes, atm [12:21] sux [12:21] hrw, patches accespted [12:21] my SD card does 14MB/s in beagle usb [12:22] hrw, jasper can handle it, asac patched it to use usb, you will need the SD to boot though [12:22] thats tricky [12:22] ogra: boot from sd is easy. plug card, uboot reads kernel/initrd, unplug card, plug into card reader [12:22] inbetween initramfs died [12:23] ogra: unplug card *before* 'bootm' [12:23] you can indeed do that [12:23] but where would bootm come from then ? [12:23] resize would be much faster [12:23] in any automated way [12:23] ogra: did I said 'automated'? [12:23] note that we cant use NAND [12:24] XM, panda, blaze all dont have NAND [12:24] installing fbset on beagle = 5 minutes [12:24] including 1s to fetch package [12:24] right, thats something linaro can do [12:25] swithc to fbset if you like [12:25] i'm restricted to debian-installer functionallity which means wither to run debian-installer, ubiquity or oem-config [12:25] *either [12:25] * ogra gets tired of that discussion [12:26] we wont switch to something like fbset, we cant use amitk'S approach of using a fixed size image since it will not speed up oem-config, all discussions around the topic are moot [12:27] and i can only point out again that resizing isnt the slow part on the C4 [12:27] now I have x11 with nice 80's X pointer and nice background [12:28] time to reboot [12:28] hrw, at gdm ? [12:28] I choosed to autologin [12:28] ah [12:28] which jasper version do you have installed [12:28] safer when keyboard will not work [12:29] ogra: the one which was in 'current' image [12:29] will tell more after reboot [12:29] (and please complain to the desktop team for forcefully using unity without even checking if there is GL support) [12:29] hrw, also i still need the jasper log :) [12:30] ogra: can I just ignore fact that I had someting on BB? I prefer to use it headless [12:30] sure [12:30] just install openssh-server [12:31] and enable autogetty [12:31] btw, japer 0.12 has a fix for the enforced unity session [12:31] if you have an older one, edit ~/.dmrc [12:31] Does anyone know any documentation for getting ubuntu installed for i.MX25 from Freescale? I googled a lot but couldn't find anything. [12:31] desktop team ignores all non GL systems [12:32] Taalas: you need 9.10 for it [12:32] no.. 9.04 [12:32] and your own kernel/bootloader [12:32] right, 9.04 [12:32] 9.10 require i.mx3x [12:33] I **need** to enable serial console [12:34] boot takes eons without anything other then moving dots in plymouth [12:34] I have Ubuntu 9.04 on my dev pc but I want to get Ubuntu on the i.MX25. Is there any possibility. For BeagleBoard I found some documentation which is working properly. But want it on i.MX25. [12:34] hrw, edit /boot/boot.script, run flash-kernel to change boot options [12:35] ok [12:35] Taalas, get a properly built kernel and bootloader setup, then see the channel topic for rolling a rootfs [12:36] argh... solaris machine which I used by serial terminal in 1995 was faster then beagleboard... [12:37] * ogra wonders why [12:37] Taalas: there is no out-of-box support for i.MX25 in ubuntu. You'll have to get your own kernel/bootloader and you could use the old 9.04 version of ubuntu on arm to create a rootfs [12:38] I enter "hrw" as login and half minute to get password prompt... [12:38] fun [12:38] lovely IO [12:38] Oh perfect. Thank you for this. I will work through the documentation. [12:39] hrw, check if bootchart is installed, could be that the desktop team put it into the default seed :P [12:39] that will nearly grind your system to a halt [12:39] there is [12:39] heh [12:39] uninstall it [12:40] at least 'dpkg -l' lists is but I cant see status [12:40] ls /var/log/bootchart [12:40] I have about 8-10 chars outside of left frame of monitor [12:40] see if it captured [12:40] moment... I/O [12:40] and also check the processlist [12:41] dpkg --purge bootchart needs 20 minutes [12:41] there might be other crap running you dont really want [12:41] erm, you still have autologin enabled ? [12:41] it will likely still try to start unity [12:41] ogra: so can you check on panda (as it is a bit faster) what crap needs to be dropped and drop it from arm images? [12:41] sudo service gdm stop [12:42] sudo stop gdm [12:42] hrw, thats on my list [12:42] i havent touched the session stuff at all yet [12:42] waiting for the DX team to provide the new minimal panel [12:42] then i'll start shuffling seeds [12:42] eglibc cross build with all tests/chaeck/binary generation will end sooner then I will get bb working [12:43] heh [12:43] and eglibc tests needs eons [12:43] dont complain about alpha software ! [12:43] :) [12:44] yep.. golden rule of ubuntu [12:44] install last release if you want to complain [12:44] the 2D session will be a lot lighter once i have removed everything we dont need [12:45] prob is that we still need to ship the unity session [12:45] but last release complains usually can go directly to /dev/null because devel release changes too much [12:45] we dont have a per subarch seed possibility and omap4 will use unity on the panda [12:45] complaining to dev release ends with "this is dev release, do not complain" [12:45] right [12:45] do not complain, file bugs :) [12:46] so as a developer I have to use maverick but as a user I need lucid. [12:46] * ogra uses lucid everywhere [12:47] apart from the dev boards i work with [12:47] ogra: I used sid since it was created [12:47] and it was better to use then maverick^Wubuntu-devel [12:47] sure [12:48] ubuntu development works differently than debian development [12:48] I know [12:48] lets get beta versions of everything, get it more or less working and pray^Whope for official stable releases before release [12:48] ans long as you develop features that are working acrtoss package sets it will always be more broken until a certain point [12:49] anyway - I have a board in basement which has 250KB/s rootfs [12:49] using the dev version of ubuntu after feature freeze is usually ok [12:49] i tend to wait until then to upgrade my systems [12:49] anyway [12:50] * ogra takes a break [12:50] and if you have the jasper.log at some point i'll try to find out why you had the weird output during resize [12:50] hrw: ubuntu is also a lot more aggressive wrt to the kind of changes in the core (e.g. rework of the entire boot sequence, plymouth, upstart, etc.) [12:50] debian takes a long time to get these (for good reasons, btw) [12:54] ogra: The log file changes had been backed out [12:54] Because they needed synchronisation in 3 places [12:54] ogra: If these were pushed again, yes, I expect they need adaptations in other places === dmart is now known as Guest15895 [12:56] amitk: I'd be happy to discuss image formats; asac did more work on this though; I'd like to understand how we stand nowadays, cause I was a bit at a loss with both our Ubuntu and Linaro images; I'd like to dig a bit deeper into this [12:57] lool: amitk: whats the discussion on formats? [12:58] asac: pre-installed images for beagle, etc. [12:58] amitk: want to have a call on that? [12:58] asac: IMHO, what is being provided in maverick doesn't give a good first experience to users [12:58] enough is enough! [12:58] asac: sure, mumble? [12:58] time to hack rootfs on desktop [12:58] amitk: yes. can we do that in 1h? [12:59] asac: sure, ping me [12:59] will do [13:03] bootchartd and gdm killed from rootfs, card plugged into BB, boot [13:03] plymouth oom again [13:08] lool, well, it was syncronized in the other direction ... subarh is only added to the dir now, slangasek made that change,k what i was wondering was if you had ever tested that change, it cant have worked in lucid [13:08] -k [13:09] amitk, in linaro you dont have such images [13:09] ogra_cmpc: I'm pushing for them there too ;) [13:09] so you wont have the resizing [13:10] ah [13:11] I don't like our single minded devotion to 'installation' for everything. debian-installer is just not suitable for some devices. [13:11] amitk, note though that you need to repartition the SD on boot in any case no matter if you resize or not [13:11] why? [13:11] amitk, because of the CHS restriction x-loader/u-boot put on us [13:12] (I don't understand the science behind our installer, but it seems like rocket science) [13:12] that needs to be adjusted to the actual values of the card to be proper [13:12] Can anyone point me at a list of ARM boards supported by the maverick kernel? [13:12] ogra_cmpc: can't that be handled before we let the user dd the image? [13:13] our installer is all built around dpkg which enfoces the debconf database on us to which the installer is a frontend (among other things it is) [13:14] amitk, no, becuse the CHS value for an img file might totally differ from the physical setup of an SD card [13:14] mdz was talking about how the package manager we have currently is not suitable for distributing everything. Perhaps now is the time ;) [13:15] ogra_cmpc: even if we make severe assumption e.g. 4Gb SDHC card only? [13:15] well, you would have to give that value in bytes :) [13:16] 4GB isnt the point, the CHS value is attached to the exact size of the card [13:17] ogra_cmpc: sounds like some that can be programtically detected and programmed before we dd an image. [13:17] *something [13:17] it will work but you will have a) an unclean partition table b) if the user ever touches the partition table your system will not boot anymore [13:18] but it will only take 5 minutes to redo it vs. 1.5hrs currently :) [13:18] amitk, 1.5h ?? [13:19] hrw's numbers [13:19] amitk, how do you come to that value [13:19] *resizing* takes 10min [13:19] I haven't tried the pre-installed image yet [13:19] per 4G [13:19] i was talking about resizing and partitioning above [13:19] amitk: 1.5h takes installation process. resizing ~10 minutes [13:20] you are talking about oem-config slowness [13:20] I don't even want that [13:20] why do we want to configure usernames and timezones in that extremely slow way [13:20] amitk, we dont [13:21] amitk, on omap4 its a few min [13:21] amitk, for omap3 we could switch to the cmdline version of OEM config [13:22] amitk, but the final truth is that you simply do not want to use such a netbook image on HW like the C4 [13:22] i havent tested it yet but i'm pretty sure it will work similar well on the Xm as on the panda [13:22] ogra_cmpc: yet we provide those images :) [13:23] amitk, we also provide minimal spec for running ubuntu on HW [13:24] ogra_cmpc: Would you have a list of boards which are supported in maverick right now? [13:24] the C4 simply doesnt match these specs [13:24] ogra_cmpc: This is for ppearse [13:27] lool, all beagles above rev B. (not fun with Cx but works as you can see in the dicssion above), and panda ... for final we plan blaze through changing the bootloader in the omap4 image, and we're about to anble dove images again [13:28] lool, if you have an requirement for more omap3 boards, tell me and i'll look what i can do [13:29] *enable [13:38] ogra_cmpc: available? [13:40] asac, for a call ? [13:40] one sec [13:40] ogra_cmpc: yep ... i will call you in 5 ;) [13:40] we need to sync on something :- [13:40] P [13:46] ogra_cmpc:Thanx [14:00] ogra_cmpc: thanks [14:00] ogra_cmpc: I think IGEPv2 would be nice [14:01] lool, i'll check if it needs anything special then (bootloader/kernel) [14:02] ogra_cmpc: rtg is on it [14:02] yep, i know === ogra_ is now known as ogra [15:39] I created a rootfs with rootstock and my i.MX25 is booting into the system and now I have the login prompt on the LCD Touchscreen. But neither I can get a prompt on my serial console nor a keyboard plugged into the usb port is working. Anybody knows how to go on? [15:40] I used following parameters to get it work sudo rootstock --fqdn imx25 --login hctm --password temppwd --imagesize 4G --seed build-essential, openssh-server, tsconf, ssh --dist jaunty --serial ttyS0 [15:41] also connecting via ssh is not working. The ethernet device is up [15:41] Taalas: --serial ttymxc0 maybe? [15:42] Also, I don't think you want spaces in the --seed list. [15:44] Hmm that might be the reason why the image size isn't increasing after I added some seeds... [15:44] Ok rebuilding it one more time. [15:58] Hey everyone. I am involved in a good deal of native ubuntu compilation on the ARM, and I was wondering if anyone had suggestions for a multi-CPU ARM board I could use as a build machine. Right now I'm compiling on my actual target, and would like to speed up the process as much as possible while sticking to the native arch. [16:00] Haven't heard of any on the market as a released product yet. TI Omap4 should be out in the near future, nVidia tegra is available on a limited developer basis (1 per, haven't heard of how well it works). Don't know off hand of others that have public announcements. [16:00] awayfar: Depends of your budget [16:01] awayfar: I think the versatile express boards are nice, but they are really expensive [16:01] lool: A9 ones? [16:01] the dove ones were nice in theory, but the early ones I got were unstable, I don't know if that's fixed, nor whether these are publicly available [16:01] awayfar: /me likes http://www.qnap.com/pro_detail_feature.asp?p_id=127 [16:01] hrw: Yes [16:02] ukleinek: armv5 though [16:02] awayfar: that's a good question, what architecture baseline do you need? [16:04] awayfar: which cpu/board you target? [16:05] Death by a hundreds replies [16:05] we flooded his input buffers [16:05] Wow, THANKS for all the replies! [16:06] I read slow ;) [16:06] awayfar: now your time to answer ;D [16:07] My budget is negotiable, since this is a corporate project, and my absolute ideal board would be multiple A9/OMAP4. [16:08] My target is an OMAP4 [16:08] awayfar: ok [16:08] pandaboard is not on market yet, no idea about blaze [16:10] awayfar: OMAP4 isn't really widely available yet; versatile express has quad A9 + 1 GB of RAM, so quite a nice starting point [16:10] and good for build machine === Guest15895 is now known as dmart [16:11] hi prpplague dmart [16:12] hrw: greetings earthling [16:13] hrw: That sounds great. Now, for a not-so-bright question; If I were to install Ubuntu on an A9, is that close enough to the OMAP4 to maintain compatibility? I know the OMAP4 uses the A9, but I may as well ask... [16:13] awayfar: What compatibility are you after? [16:13] Everything but the kernel "should" work. [16:14] ukleinek and GrueMaster thanks for your help. Worked out perfect [16:15] Taalas: Good to hear. [16:15] gm all [16:25] All, thanks for the information. I spoke with prpplague offline, and he helped sort me out. Thanks again! === amitk is now known as amitk-afk === amitk-afk is now known as amitk === hrw is now known as hrw|gone === amitk is now known as amitk-afk === JaMa is now known as JaMa|Away [19:27] ogra: Don't think https://bugs.launchpad.net/bugs/605972 is armel (it's jasper), right? [19:27] Launchpad bug 605972 in jasper-initramfs (Ubuntu) "Need to set hostname to ubuntu during first boot. (affects: 1) (heat: 8)" [Medium,New] [19:29] lool: It is jasper-initramfs. Since it is only used on omap (currently) I tagged it as armel. [19:29] It would be nice to keep the list of ubuntu-armel/armel bugs identical to the bugs specific to armel [19:29] Anyways, the tag would have been put there by apport if I had filed using it. [19:30] Yes, but I remove it when it's not armel specific [19:30] Not a big deal, but since random other people (cough Linaro) will look at ARM bugs, I'd like them not to see jasper bugs [19:32] If this bug can be shown to be reproducible on other architectures, I'll agree. Until then, if it is seen on armel first, it gets tagged on armel. Just following bug posting procedures laid out to me from earlier cycles. [19:33] https://wiki.ubuntu.com/MobileTeam/BugWorkflow [20:18] Taalas: you're welcome === XorA is now known as XorA|gone === JaMa|Away is now known as JaMa === JaMa is now known as JaMa|GoNe === fta_ is now known as fta === bjf is now known as bjf[afk]