#ubuntu-arm 2009-02-03 <rc55> As rediculous as it may seem, I think the fact that you guys are working on an ARM port rocks! <ogra> nothing ridiculous on that :) <Stskeeps> kozak: good news :) <kozak> Thats mer on beagle??? <Stskeeps> yup <Stskeeps> it was pretty easy <Stskeeps> you have a usb hub and such and keyboard? i don't <kozak> Cool <kozak> I dont either :( <kozak> not yet... <Stskeeps> k <kozak> I am having a difficult time working on Android with this set up <ScriptRipper> hi guys. <Stskeeps> evenin' <ScriptRipper> how are you? <Stskeeps> good. i booted ubuntu jaunty on a pocket loox 720 earlier today :> <ScriptRipper> hopefully, i get tomorrow a first look at the beagleboard with 256 MB RAM... not sure though if i get one .... <ScriptRipper> will check how well 9.04 works on it :D <Stskeeps> hehe <Stskeeps> base system is fine with 128mb, it's the GNOME stuff that hurts :) <ScriptRipper> i know .... <ScriptRipper> but the fun begins with 256, when firefox and the like wants to run ... <ScriptRipper> i want to see it with my own eyes... <Stskeeps> hehe <ScriptRipper> i ll tell you if its worth ... <Stskeeps> mm, i have two beagleboards in my office <ScriptRipper> the 128 MB or 256 MB version? <Stskeeps> 128 <ScriptRipper> aha. 2x beagleboard has also 256 MB RAM :) <ScriptRipper> dual core <ScriptRipper> i ll ask when the 256 MB versions will be distributed... <ScriptRipper> any questions from you for the TI guys? <Stskeeps> not personally :P <ScriptRipper> nothing not already asked at beagleboard already I guess #ubuntu-arm 2009-02-04 <Stskeeps> http://www.daimi.au.dk/~cvm/mer-pocketloox720.jpg <- ubuntu userland + maemo platform stuff on top, on a pocket loox 720 :> <ScriptRipper> hi all <ScriptRipper> back from my TI meeting :) <Stskeeps> how did it go? #ubuntu-arm 2009-02-05 <ScriptRipper> hi guys. <ScriptRipper> got a beagleboard now with 256 MB RAM <ScriptRipper> did any of you try that already out? <Stskeeps> hehe, no, sadly ;) <ScriptRipper> ok, after configuring u-boot correctly, got it working now. <ScriptRipper> Who knows why all this gnome stuff is running when I run xfce? <ScriptRipper> Even 256 MB get eaten away fast #ubuntu-arm 2009-02-08 <jldugger> Processor : ARM926EJ-Sid(wb) rev 0 (v5l) <jldugger> im assuming that's too old for ubuntu <Stskeeps> nah, it's armv5te <Stskeeps> which works with ubuntu <jldugger> interesting <jldugger> unfortunately, ive got 64 megs of RAM on it <Stskeeps> can probably run the base system :P which device is it? <jldugger> D-Link DNS 323 <Stskeeps> well 64 mb can probably take the base system, definately :P <jldugger> theres a gig of swap <Stskeeps> we have a ubuntu base system on nokia 770's, which are 64mb ram so <jldugger> for the moment i'll stick with ipkg and see how that goes <jldugger> there's two guides out there for running debian on this thing; one is chroot and the other is not <ogra> hmm <ogra> i wonder how debian does that ... htop on the nslug actually reports only 6M of 30 being used <ogra> on an idling system <suihkulokki> ogra: no UI, no memory problems ;) <ogra> suihkulokki, well, i havent seen an ubuntu kernel running with 6M yet <ogra> we even had probs booting 32M x86 systems in ltsp 48M was the bare minimum to unpack and execute the initramfs, its pretty impressing to see a 30M system booting and then running with only 6M userspace being used <ogra> and i really wonder how to achieve that whithout trashing the ubuntu defaults to much <ogra> hmm, so running an ubuntu userspace on the nslu2 immediately kicks me out after showing motd :( <suihkulokki> ogra: I guess this extra ubuntu stuff is installed after debootstrap ? <ogra> suihkulokki, https://wiki.ubuntu.com/ARM/RootfsFromScratch ... calls debootstrap, switches to qemu, does the second stage, sets up a user, locales and timezone and install the set of packages you give it ... (in this case only ubuntu-minimal) <ogra> and yes, its a bunch more stuff being started than in the d-i lenny slug install <ogra> but not enough to prevent a login, i think there shoud still be enough spare ram to run bash <suihkulokki> because I was under the impression that debootstrap for ubuntu and debian are almost identical <ogra> right <suihkulokki> so I guess the bloat is in ubuntu-minimal <ogra> well, the seond stage simply installs the ubuntu-minimal metapackage in ubuntu <ogra> i wouldnt call it bloat :) <ogra> its console-setup, klogd and some other essential settings <ogra> the fun is that i actually see motd ... but then get bunped to login again <ogra> *bumped <ogra> http://paste.ubuntu.com/115708/ <ogra> thats the ubuntu boot after leaving initramfs <ogra> not actually a lot more than the debian boot .... and no MTA <suihkulokki> indeed <suihkulokki> perhaps there is some too funky bash config there <suihkulokki> ie. try changing the user shell to dash <ogra> yeah, i'll do that <ogra> though it works fine on all other arms i tried it on yet .... <suihkulokki> slug is a bit stretch on what makes sense for running a general purpose distro <ogra> heh, yeah, 30M is something i havent seen in quite some time <ogra> nope, dash doesnt help ... * ogra kills the startup links for syslog and klogd <ogra> aha, an error message <ogra> init: ttyS0 main process ended, respawning * ogra checks his serial console setup again <ogra> heh <ogra> ok, its just me having been silly setting up the proper upstart stuff <ogra> putting -L into the getty line somewhat helps :P <ogra> hrm, but still doesnt let me in <ogra> sigh ... apex doesnt let me set init=/bin/bash ? pfft <ogra> grrr, what a crappy HW <ogra> oh <ogra> readonly fs ... hmm * ogra adss lots of swap to exclude ram issues <ogra> GRRRRR <ogra> no go :( <Stskeeps> how much ram does the slug have anyway? <ogra> 30M <ogra> but it has 256M swap now <ogra> so its not ram thats the issue * ogra curses ... i'd so love to know what that is <ogra> and that shitty bootloader doesnt let you change the cmdline on boot, you can only change it with apex-utils <ogra> from the running system ... to which i cant log in to <ogra> so booting with init=/bin/bash literally means to replace init each time i test something and need eth live HW <ogra> *the <ogra> hmm, so unsetting the rootpw gets me in as root <ogra> but still no way to do it as user <ogra> ah, well, so the ubuntu basic system with additionally running sshd uses up 7M <ogra> nt to bad <ogra> *not <ogra> root@nslu2:~# sudo -u ogra ls <ogra> Killed <ogra> hmm #ubuntu-arm 2009-02-09 <ogra> lool, in fact it migth not even matter which endianess the kernel is, seems its a simple switch in apex * ogra wonders if he can flip that without re-rolling the whole image <lool> ogra: We should use the same endianess as Debian otherwise multiple places will have to diverge <lool> e.g. flash-kernel, d-i <ogra> ah, indeed <Stskeeps> how's the kernel project going btw? <ogra> slow, we might not see omap kernels for jaunty <Stskeeps> alright <ogra> there is still hope though... 10 days to go until FF <Stskeeps> jaunty is freezing in 10 days? k <ogra> https://wiki.ubuntu.com/JauntyReleaseSchedule <Stskeeps> ah <Stskeeps> ta <playya> 10 days = at least 200h for working. no family. no sleep. and sitting on a big basket :) * ogra wonders why playya describes his day to day work * ogra lifts the cover of the basket and sees that it snows outside <playya> i sit on a very comfortable chair. but the rest: yes :D <playya> but atm i have a few exams. so sometimes i have to learn ;) <NCommander> ? <ogra_> ! #ubuntu-arm 2009-02-10 <Ramon_Valdez> someone knows if GNAT will be available with Ubuntu ARM ? <ogra> lool, so just not byteswapping the kernel doesnt solve the nslug bootprob <lool> ogra: Does it help booting the Debian kernel? <ogra> you mean i should dump the debian kernel into d-i during build ? <lool> (just curious) <lool> ogra: No, serve it over HTTP and boot <lool> ogra: Cause it was simply hanging in my tests <ogra> oh, i would have to reflash to redboot again <lool> ogra: I guess it's the apex partition then <ogra> which is a bit tricky without a bootable system atm <lool> Reflash to redboot? just load it from redboot over HTTP and exec it <lool> You don't have redboot in your current image?! <ogra> its using apex <ogra> di-nslu2.bin has apex .... <lool> APEX is loaded by RedBoot <lool> di-nslu2.bin wont touch your redboot... <lool> I hope you didn't erase the full flash, but the default in upslug is not to <ogra> oh, right, it scrolled off screen :P silly me <ogra> well, i'm ore intrested in why our kernel just dies ... <ogra> its not even uncompressing <ogra> and i would it to do so now that i have a di-nslu2.bin without changed byteorder <ogra> *would expect it to <lool> ogra: From the nslu2 README: <lool> In practice, this means that there is only 1 MB of space for <lool> the kernel because the initrd starts 1 MB after the kernel. <ogra> meh <lool> Might be why our initrds don't work with plain redboot <ogra> -rw-r--r-- 1 ogra ogra 1,9M 2009-02-10 12:34 vmlinuz-2.6.28-7-ixp4xx <lool> That's ok <lool> It's just when you use plain redboot <ogra> - A partition for the kernel: the kernel is split in two and each parts <ogra> have a header <lool> However our redboot tests are useless <ogra> right <ogra> i want a working binary blob * ogra wonders off reading http://www.nslu2-linux.org/wiki/Info/BootFlash <lool> ogra: Would be nice to have the nslu2 firmware for the ethernet device in restricted and build with it <ogra> lool, definately <ogra> i dont get where they put the second half of the kernel <lool> ogra: There's a single partition for the kernel, but it's written in two parts <ogra> how does a >1M kernel fit in there ? <ogra> debians is 1.3M, also bigger than 1M <lool> [part 0 <RedBoot>][part 1 config][part 2 <APEX> <kernel part 1/2> <magic> <kernel part 2/2>][part 3 <initrd>] <lool> The problem is that RedBoot looks at part 2 + 1M to find a special magic <lool> We don't care about what it loads except that it loads apex fine <lool> But it needs to find its magic <ogra> oh, so the whole device is 8M in any case, we just need to set the magic mark at the right point * ogra slowly gets it <ogra> what a silly design <lool> It's due to the restrictions of linksys' redboot <ogra> ah, right http://tech.groups.yahoo.com/group/nslu2-linux/message/33 doesnt talk about mtdblock3 at all <lool> Wow the make foo in build/config/armel/ixp4xx/netboot.cfg is awful <ogra> heh <ogra> yeah <lool> ogra: So how did you try to revert the endianess of the kernel? <lool> I see nothing wrong with Colin's changes <ogra> i just commented the devio line and didnt use .swapped at the bottom <ogra> which should make it use the kernel 1:1 <ogra> but the behavior is identical, swapped or not <ogra> its just hangs after "copy -s fis://kernel 0x00008000" in both cases <ogra> hmm, though shouldnt that be 0x00010000 ? <ogra> ah, no, its right <lool> This skips APEX <ogra> no <ogra> that is apex output * ogra re-flashes the debian di binary to compare <lool> I'm saying this offset is to skip APEX, but actually it's not <ogra> # copy -s $kernelsrc $bootaddr <ogra> # copy -s fis://kernel 0x00008000 <ogra> 1441760 bytes transferred <ogra> ok, thats the debian output <lool> So this is in the APEX package which is built specifically for the NSLU2, how inelegant <ogra> complain to martin michlmayer :) <ogra> i think he rlled most of these packages initially <ogra> *rolled <lool> No, Marc Singer did <ogra> he wrote apex <lool> Well I'm complaining about apex <ogra> ah <ogra> i thought about how it was used <ogra> i mean apex is only a bootloader in the end, like uboot, no ? <lool> Yes, my problem is that its script is hardcoded in the apex package <ogra> hmm, looking at the debian d-i code: <ogra> util/pad $(TEMP)/initrd.gz.nslu2 6291440 # size of partition - 16 for header <ogra> i wonder if colin didnt pick to high values <ogra> hmm, no the sum is identical <ogra> so what about raising the kernel partition size by 1 block <lool> ogra: Do you have debian installed? <lool> Could you run apex-env in it? <ogra> i.e. to 2228192 <lool> I'd like to confirm that the script is like "copy -s $kernelsrc $bootaddr; copy -s $ramdisksrc $ramdiskaddr" <ogra> no, i dont, and it takes 8h to do so <ogra> yes, it is <lool> actually: <lool> copy -s $kernelsrc $bootaddr; copy -s $ramdisksrc $ramdiskaddr; wait 10 Type ^C key to cancel autoboot.; boot <ogra> i can see that by using the di binary blob <ogra> its executed exactly in that order <ogra> Use the command 'help help' to get started. <ogra> # copy -s $kernelsrc $bootaddr <ogra> # copy -s fis://kernel 0x00008000 <ogra> 1441760 bytes transferred <ogra> # copy -s $ramdisksrc $ramdiskaddr <ogra> # copy -s fis://ramdisk 0x01000000 <ogra> 6291440 bytes transferred <ogra> # wait 10 Type ^C key to cancel autoboot. <ogra> Type ^C key to cancel autoboot. <ogra> # boot <ogra> there is a semicolon missing though, it doesnt wait at all <StevenK> ogra: I wonder if this is an overrun ... <ogra> thats why i said we should probably give the kernel one more block <lool> CONFIG_RAMDISK_LMA=0x01000000 <lool> ogra: really? I think it does wait one second <lool> I had the apex prompt more than once <ogra> it doesnt here <lool> CONFIG_AUTOBOOT_DELAY=10 * ogra tries again ... i might just be to slow <lool> prompts the user and waits a specified number of 10ths of a second. <lool> So it's 10th of a secnd <ogra> ah, yeah, constantly hitting ctrl-c while the ramdisk loads helps <ogra> i was expecting 10 secs :P <ogra> silly <lool> I know <ogra> so while i'm at the apex prompt, anything you want from printenv ? <ogra> startup *= copy -s $kernelsrc $bootaddr; copy -s $ramdisksrc $ramdiskaddr; wait 10 Type ^C key to cancel autoboot.; boot <lool> ogra: Yeah, all values <ogra> apex> printenv <ogra> fis-drv *= nor:0x7e0000+4k <ogra> cmdline *= console=ttyS0,115200 rtc-x1205.probe=0,0x6f noirqdebug <ogra> cmdline-alt *= console=ttyS0,115200 rtc-x1205.probe=0,0x6f noirqdebug <ogra> startup *= copy -s $kernelsrc $bootaddr; copy -s $ramdisksrc $ramdiskaddr; wait 10 Type ^C key to cancel autoboot.; boot <lool> for bootaddr ramdiskaddr <ogra> ramdisksrc-alt *= fis://ramdisk <ogra> ramdisksrc *= fis://ramdisk <ogra> kernelsrc-alt *= fis://kernel <ogra> kernelsrc *= fis://kernel <ogra> ramdiskaddr *= 0x01000000 <ogra> bootaddr *= 0x00008000 <ogra> apex> <ogra> there you go <lool> nor:0x7e0000+4k hmm <lool> ogra: is this from debian or ubuntu? <ogra> debian <ogra> i cant get to the apex prompt on ubuntu <lool> really? that's suspicious <ogra> no, thats logical <lool> why so? <ogra> the prompt comes after loading <lool> loading of apex <ogra> it gets stuck loading the kernel <lool> Oh right <ogra> i can get into the redboot prompt <ogra> but not apex <lool> the wait should be at the beginning <ogra> yeah <ogra> silly design <ogra> though you dont gain anything being in apex anywa <ogra> y <ogra> the whole config is readonly ... <ogra> you can only modify it from the running system via apex-env <lool> Yes <lool> ogra: setenv doesn't work? <ogra> so i dont know why it has a prompt at all <ogra> nope <ogra> i tried to change the cmdline parameter before ... doesnt apply <ogra> apex> setenv cmdline 'console=ttyS0,115200 noirqdebug' <ogra> Environment region is unwritable <ogra> so having a prompt is just fake <lool> You can type commands <ogra> right, the ones that are executed anyway <ogra> the only most intresting thing, changing the cmdline doesnt work <lool> ogra: You can pass cmdline to boot <lool> "boot [-g ADDRESS] [COMMAND_LINE]\n" <ogra> oh, i didnt know that <lool> ogra: Perhaps you should read apex <ogra> that makes it a bit more useful then <ogra> yeah <lool> So the fis://kernel works even with a split kernel <lool> Because APEX has an extension to RedBoot partitions <lool> To skip some areas <lool> Check README_fis in apex' source <lool> I don't understand why it's not copy fis://kernel@16 $bootaddr <lool> ogra: It might be best to not rely on byteswapping the kernel but rebuild it though <lool> amitk: Hey <ogra> i'm just doing a build in the background with one more block shifted to the kernel <lool> amitk: CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y is set in debian/config/armel/config.ixp4xx, but not in Debian <lool> amitk: This needs fixing in all cases (even if that's correct) <lool> amitk: Basically the hardware supports both, but we're an armel port and the debian tools assume a LE kernel which gets byteswapped at various places (flash-kernel, d-i) <ogra> swapped or unswapped, it doesnt load <lool> amitk: So it's easier to have the same type of kernel in Ubuntu <ogra> so i expect we are exceeding the size <ogra> hrm, the other loic suddenly hunts me in #edubuntu ... i wonder what he wants <lool> ogra: I think I'll drop the ball here on NSLU2; if you are stuck, you could try mailing Marc Singer, he helpfully replied to me when I asked about the shim's COPYING file being missing <amitk> lool: ack. We will stick to one type for the kernel. <lool> ogra: If you show that you researched it that far, he might be willing to help !Debian <lool> amitk: thanks; do you need a bug? <amitk> lool: I guess that CONFIG option automatically gets set on selecting ixp4xx, let me check <amitk> lool: if ARCH_IXP4XX <amitk> config ARCH_SUPPORTS_BIG_ENDIAN bool default y <amitk> in Kconfig <lool> amitk: Ack; the device can do both so the upstream bit doesn't make any sense to me, but please force it to LE <lool> amitk: Did you get your NSLU2 to work BTW? <amitk> lool: -EOUTOFSOLDER, will head to store a bit later * ogra hopes amitk has a pump to get the solder out of the holes <ogra> its really painful without <lool> amitk, ogra: I'd love if you two could sort this out quickly; I think I understand most of it, but can't usefully research without a device <ogra> well, let me builod a kernel if you think thats the solution <ogra> and inject it into the di binary <ogra> i still suspect its a size issue though <amitk> lool: I can give you a kernel if you need <amitk> ogra: size issue for initramfs? <lool> amitk: I wouldn't have much use of it without a device :) <ogra> amitk, no issue with the apex partition shufflung we do to make our kernel fit <ogra> amitk, gimme kernel :) <lool> amitk: The way the NSLU2 firmware is built is quite complex <lool> amitk: Do not rely on RedBoot to do regular stuff, it hardcodes plenty of stuff and wont work correctly (can't pass cmdline, expects initrd at specific address etc.) <ogra> amitk, the prob is that our kernel is nearly 2M big, debians is only 1.3 <lool> amitk: Debian/Ubuntu use APEX as a second state loader with some special partition mappings for redboot to be happy <ogra> so the apex partitioning for the di binary blob needs adjustment <lool> ogra: You could try building an image with Debian's kernel to see if that boots <lool> ogra: It might be that one of our binaries is broken <amitk> lool: so it was confirmed that redboot cmdline doesn't work <amitk> ? <ogra> lool, well, if amit has a kernel for me i'll try that first <lool> amitk: Yes <lool> ogra: You can try both :) <ogra> lool, well, the kernel loads if you load it from redboot via http <ogra> i'll try everything that can get me towards a solution indeed :) <lool> ogra: Exactly my point, we know the Ubuntu kernel works and the Debian kernel as well; but the Debian one is smaller and not swapped <ogra> since thats our only arch we target for jaunty ;) <lool> ogra: You could see if that helps, if amitk's kernel doesn't work and Debian's does, then you know that the partitioning changes are wrong <lool> If both work, then we're done :) <ogra> well, amits kernel wont be smaller <lool> ogra: Err yes, that's my point <lool> ogra: Which is why I'm hinting at the Debian one? :) <lool> Both are useful tests <amitk> ogra: It could be with allnoconfig I guess <ogra> oh, so you mean keep the shuffled partitions and just use debians kernel <lool> ogra: No, you revert the partition shuffling and confirm that our d-i + apex + debian kernel and initrd work <lool> ogra: or you keep the partition shuffling and confirm that our d-i + apex + debian kernel and initrd work <ogra> right, but then i need to change two aspects to try out ours <lool> ogra: or you keep the partition shuffling and confirm that our d-i + apex + amitk's kernel and initrd work <ogra> which doesnt tell me much mor than i already know <lool> doubt amitk will hand you an initrd though * amitk agrees, he hates initrds <ogra> right, i need to do the tests both with a shuffled partitioning scheme to keep the same env <lool> Anyway, use your logic <ogra> i dont care about initrd atm * lool moves his brain to something else <ogra> lool, so it is definately partitioning scheme it stops with the exact same symptoms using debians kernel <ogra> i'll try to confirm by using their scheme with their kernel <lool> ogra: it could be our APEX or whatever; you might want to try the debian kernel with the debian partitioning scheme <lool> in our d-i with our apex etc. <ogra> yes, thats what i'm currently fiddling with <ogra> lool, yep. debian kernel and debian partitioning scheme works <lool> ogra: Ok <ogra> even with our initrd.gz <lool> ogra: Might be slugimage not liking this change then <ogra> yeah <ogra> sigh ... i have to dig out my perl foo i fear <lool> Ah got it <lool> my($kernel_offset) = 0x00060000; <lool> my($kernel_size) = 0x00100000; <lool> my($ramdisk_offset) = 0x00160000; <ogra> oh <lool> That's likely the issue <lool> IMO <ogra> shouldnt the first one be 80000 <ogra> (additionally to the size mistmach) <lool> Hmm be careful, these are redboot partitions, not apex partitions * ogra goes to try with 2M <ogra> yeah, i wont change the kernel offset <ogra> only size and ramdisk offset <lool> You have a debug flag for slugimage <ogra> hrm, just changing to 0x00200000 and 0x00260000 respectively doesnt work <ogra> it doesnt have a ramdisk_size parameter <lool> The kernel_size is just where to split the kernel <ogra> oh, so just bumping ramdisk_offset should suffice <lool> Not sure, you could try <lool> Bump it by 5 blocks <ogra> i will luckily the script is freindly nough to tell me if it breaks :) <lool> 0x00200000 <ogra> oh i used 22 <lool> Perhaps I miss computed <ogra> Ran out of flash space in <Ramdisk> - 0xA0000 bytes too large. <ogra> nope <lool> That's what we added <lool> ogra: Do you have a debug run? <ogra> http://paste.ubuntu.com/116488/ <lool> Hmm it doesn't list the skip partitions <ogra> oh, wait i made a mistake i think ... i padded initrd twoce <ogra> yay <ogra> didnt choke * ogra waits for upslug <ogra> ogh <ogra> that trashed apex <ogra> nope, no way <ogra> what if we just cut down our kernel ? <ogra> lool, i think slugimage is the wrong attempt <ogra> it just makes sure the redboot markers are in the right place <lool> ogra: I'd like to see the final partition table <lool> it's missing from your paste <lool> print "after buildPartitionTable():\n"; <lool> ogra: Ideally, compare the output from debian layout wiht debian kernel with ubuntu layout with debian kernel <ogra> because it failed :) <ogra> it didnt get to that point, you asked for a debug output when i did a failed attempt ... one sec <lool> I know, but the most interesting output is when the image builds.. <ogra> http://paste.ubuntu.com/116497/ <ogra> thats with unmodified slugimage but our sizes <lool> Loader 0x00060000 0x00020000 [0x00000/0x00010] <lool> Kernel 0x00080000 0x00200000 [0x00000/0x00010, 0xE0000/0x00010] <lool> The right part are skips <lool> ogra: Would be nice to have a "normal" run with debian's configs <ogra> lool, http://paste.ubuntu.com/116499/ <ogra> comparing the two it seems to DTRT <ogra> it properly recognizes the different blocksizes and adjusts itself <ogra> i start to suspect its an apex limitation <ogra> hrm, d-i fails at the hw detection step without the firmware <ogra> which makes it pretty useless <lool> Ok, now I know why it doesn't use fis://kernel@16 but just fis://kernel <lool> Erf don't set ibase before obase in bc <lool> The 0xE0000 skip is exactly on the initrd, that seems alright hmm <lool> ogra: kernel size is too small <lool> Kernel 0x000800000x00160000[0x00000/0x00010, 0xE0000/0x00010] <lool> 0x00160000 is too small <lool> our kernel is 1977064 <ogra> right <ogra> but kernel size needs to cooperate with ramdisk offset, no ? <ogra> or do you think just bumping it helps ? <ogra> hmm, slugimage doesnt complain <lool> ogra: The kernel is presumably truncated; it seems to be a bug in the perl script <lool> ogra: Oh was looking at the Debian output <lool> So that's correct for Debian crap <ogra> lets see, i just bumped kernel size blindly to 0x00200000 <ogra> and padded the two files with our values * ogra is upsluggin ... * ogra has to go shopping soon, will be out for 1-1.5h <lool> IIUC, you shouldn't have to touch slugimage; it's meant to be generic <ogra> yeah <ogra> and it didnt work anyway <lool> ogra: So APEX hangs where exactly? <ogra> same symptoms as always <lool> After the load? <ogra> # copy -s $kernelsrc $bootaddr <ogra> # copy -s fis://kernel 0x00008000 <ogra> / <ogra> the fan animation below does oen or two rotations and then stops <ogra> *one <lool> I'll shoot an email to the apex maintainer <lool> ogra: Hmm I don't understand how you achieve the ubuntu call to apex <lool> ogra: Why does slugimage detect a changed kernel size when you're passing vmlinuz-2.6.26-1-ixp4xx.swapped in both cases <lool> Oh nevermind, I get it <lool> It's padded by d-i <ogra> grr <ogra> yes, as i suspected kernel_size has no influence at all <ogra> no matter what value i set for it it works <ogra> but as soon as i change the padding it breaks <ogra> i will find out how big the kernel partition can grow by adjusting it block by block after shoppin <ogra> g <ogra> we'll see where it chokes then <ogra> lool, hmm, are you aware that the apex version we use is ancient ? <ogra> heh, the version we use doesnt even exist upstream <lool> ogra: ohhh <ogra> 2007.01.29 (apex-1.4.13) <lool> ogra: Try adding one block more <ogra> 2007.02.15 (apex-1.4.16) <ogra> there are no .14 or .15 ones <lool> apex | 156.14.161.142ubuntu1 | jaunty | source <lool> ogra: Could you try adding one more block to the kernel and one less to the initrd? <ogra> and we use 502.619.2016 according to the bootmessage <ogra> oh, you found out already :) <lool> 1.4.15 works on Debian <lool> and on Ubuntu with debain kernel <ogra> one more to our scheme or debians ? <lool> ogra: To our scheme <ogra> ok <lool> I think we're hitting a corner case with our value <ogra> flashing <ogra> now that would be cool <ogra> what got you the idea ? <lool> Well it seemed the ramdisk would write exactly on top of the kernel's skip <ogra> ah * ogra twiddles thumbs <ogra> resetting <ogra> nope :( <ogra> same symptoms <ogra> as i said, i'll start changing it block by block until it hits the fan if i'm back <ogra> so we see the exact limit <ogra> lool, hmm <ogra> lool, i dont get why colin cuts off 21bytes from the initrd instead of thw 16 debian does <ogra> *the <ogra> til/pad $(TEMP)/initrd.gz.nslu2 6291440 # size of partition - 16 for header .... thats debian ... <ogra> util/pad $(TEMP)/initrd.gz.nslu2 5636080 # size of partition - 21 for header .... thats ours <ogra> lool, sooo ... making the kernel partition one block smaller works fine <ogra> though it panics ... * ogra tries if he can fit the ubuntu kernel into that <ogra> hmm, no * ogra dances !! <ogra> err <ogra> hrm <ogra> argh <ogra> ok, its officially not my day ... <lool> ogra: He didn't cut 21 bytes but 16 and I made him fix that comment in bzr already <lool> ogra: (earlier this morning) <ogra> yeah <ogra> lool, so i think what we want is CONFIG_RAMDISK_SIZE=0x004CCCC0 in the apex config <lool> Hmm <ogra> that gives us 5033152 bytes for the initramfs and leaves more than 1.9M for the kernel <ogra> if my HEX foo isnt to wrong <ogra> i'm convinced its debian bug 451882 that gets in our way <ogra> bah, no bugbot <ogra> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451882 <lool> ogra: Isn't it 0x0055FFF0? <ogra> it is <lool> It's currently 0x005FFFF0, I think we should have 0x0055FFF0? <ogra> we have 8M ... 6291440 bytes of that get reserved for initrd <ogra> we do <ogra> thats the prob <ogra> if you have 8M, cut off 6M for initrd and additionally a bit for apex and the redboot tags you end up with a bit less than 1.9M for the kernel <lool> Why do you say CONFIG_RAMDISK_SIZE=0x004CCCC0? <ogra> that should be 5033152 bytes <ogra> which means we have 1258288 bytes more for the kernel partition <lool> ogra: That's not a block multiple <ogra> 6291440 isnt one either <lool> ogra: We changed the size of the initrd by 5 blocks of 131072 <lool> ogra: So we need to change it by 655360 bytes, 5FFFF0-A0000 = 55FFF0 <lool> Where did you find 6291440? <ogra> read the bug <lool> ogra: It's certainly not our bug as we hang in the kernel copy * lool curses at bc <lool> 55FFF0 is 5636080 but 005FFFF0 is 6291440; piece of crap <ogra> i'm able to boot with a kernel area of 15 blocks with the debian kernel <ogra> it stops working if i go up to 16 blocks which is the first time i get over 1.9M for the kernel partition <lool> But we don't want CONFIG_RAMDISK_SIZE=0x004CCCC0 but 0x0055FFF0 <ogra> thats what we currently have <ogra> and which results in 6291440 bytes <ogra> as the reserved flash space for the ramdisk <ogra> which in turn limits the free space we have for the kernel to less than 2M <ogra> since the overall space we have is 8M <ogra> and we lose space for apex and the redboot tags in the image <lool> ogra: I don't understand <lool> ogra: What we have right now is 005FFFF0 <lool> I say we want 0055FFF0 <ogra> oh ... sorry, my eyes saw to many HEX today <ogra> :P <lool> hmpf <ogra> i didnt see the second 5 <ogra> ok, i'll do a testbuild of apex with the change lets see if i get it booting then <ogra> sorry for being so dense ... i really cant see any hex anymore #ubuntu-arm 2009-02-11 <lool> ogra: So this smells the overflow if 15 -> 16 blocks don't work <lool> It's not, it's APEX being clobbered by the kernel! :-) <lool> ogra: Quick, try Marc's suggestion! <ogra> lool, if my eyes are open enough :) * ogra yawns and goes to look for coffee <lool> ogra: Dude why did you mail debian-arm@? <lool> I told you I would mail him and I Cc:ed you <ogra> whats wrong with asking in multiple places ... <lool> It creates duplicate work? <ogra> and brings more ideas in in case the solution isnt clear <lool> I absolutely hate IRC users coming to multiple channels I'm in and copy-pasting the same question <lool> Sorry but it's resource abuse <lool> I value the high quality of the responses I get so far, I don't think Marc will give us much attention if we keep asking at multiple places <lool> It's exactly like researching before asking <ogra> well, to me it wasnt clear it was apex <ogra> apart from that the next guy having this prob will find it in the ML archive <lool> That's an issue I created, but your fix is worse than the disease <lool> It's like these cross-posts spanning multiple lists, but it's worse in that these are separate threads <ogra> well, sorry for that if you feel like that, but i still think it was okayish to have it on a public ML my questio was different and contained other information than yours, but i'll keep away from such things in the future now that i know you dont like it <lool> I basically don't want to take any chance to piss off valuable people we rely on (how would we move forward if we lose help from these folks?) <lool> And here Marc had to reply to both and said he did <lool> Probably he doesn't mind much, I'd hate if we'd do that again <lool> s/doesn't/didn't <ogra> right, i'll be more cautious about that in the future ... <lool> Thanks, I appreciate your effort <ogra> lool, hmm changing CONFIG_KERNEL_LMA=0x00008000 to 0x01000000 means that it will have the identical address CONFIG_RAMDISK_LMA has ... <ogra> i suspect we need to do some more math with that ... but will test first * ogra goes to rebuild apex <ogra> lool, well, it doesnt boot ... <ogra> ... but it get kernel and ramdisk loaded <ogra> lool, http://paste.ubuntu.com/116755/ * ogra starts shuffling the ramdisk address around <ogra> hmm, so moving the ramdisk to 0x011FFFE0 les it panic but the kernel unpacks .... <ogra> *lets <ogra> bah and our kernel stops after uncompressing <ogra> (using it unswapped, else it doesnt work at all) <ogra> hrm <ogra> lool, any idea ? the kernel is 0x00200000 big, so i add that to CONFIG_RAMDISK_LMA (making it 0x01200000) that makes the kernel load but apparently it doesnt find the initramfs and panics now <ogra> intrestingly it seems to find the start of the ramdisk ... "[42949378.630000] RAMDISK: Compressed image found at block 0" <lool> ogra: Sorry didn't follow; do you have an idea of the memory map since the board powers up down to apex calling into the kernel? <lool> I would start by writing that down <ogra> well, when i move the kernel from 8000 to 1000000 i need to move the ramdisk up by the size of the kernel <ogra> since the ramdisk used to live at 1000000 <ogra> so the kernel occupies 1000000 to 1200000 (as its 200000 big) <ogra> so naturally the ramdisk load address needs to be 1200000 <ogra> HA ! lool !! got it :) indeed we also need to adjust the max size of the ramdisk, it boots with CONFIG_RAMDISK_SIZE=0x00400000 <ogra> i'll try to bump that up bock by block now to find the possible max limit, then we should be done ... only a fixed eb kernel is missig <lool> Right, kernel is being loaded at 0x00008000, ramdisk at 0x01000000 <ogra> right, now kernel is 0x01000000, ramdisk is at 0x01200000 and ramdisk size is 0x00400000 ... with these values it boots just fine <lool> ogra: That's only 2M for kernel <lool> ogra: Where is the kernel unpacked? * lool lunch & <ogra> erm, its unpacked in ram, these values are flash <ogra> its only about the flash partitions apex uses <ogra> err, strike that <ogra> apex assigns 8M in ram it seems and then copies itself and the flash partitions to that area <ogra> why would you want more than 2M for the kernel ? <ogra> all former debian kernels are below 1.5M and i expect us to still drop some bload from the 1.9M we have now <ogra> *bloat <lool> ogra: ?? <lool> ogra: isn't 0x00008000 the address where to copy to? <lool> ogra: The flash read address is fis://kernel, the RAM write address 0x00008000 <ogra> yeah, ignore me <lool> ogra: "why would you want more than 2M for the kernel" well we just hit the case where the preceeding assumptions were not enough <ogra> i thought we had the 8M limit in ram as well, but that doesnt seem to be the case at all <lool> Why not make sure we cover all cases and solve the problem once and for all? <lool> slugimage works no matter what sizes you pass to it for instance <ogra> yes, i just booted with a ramdisk at 0x01400000 <lool> So if the contents are discarded, I'd recommend loading apex, kernel, and initrd at 0, 8M, and 16M <lool> that way we shouldn't ever have to worry about them <ogra> i'm just trying with 6M for the kernel <lool> The flash is 8M right? <ogra> i'll do 8 next <ogra> yes <ogra> so the bigger the kernel gets the more we limit ourselves on the ramdisk wrt flash ... <ogra> lool, ok, seems the max limit for the ramdisk size is actually 5636080 bytes (our flash ramdisk partition size ...) if i go above it it corrupts the initrd ... <ogra> and it seems it doesnt matter where i load it to so 0 and 8M wont be an issue, but 16M wont be possible due to the 8M flash constraint <lool> ogra: I want us to plan the apex script to accept any theoritical initrd or kernel sizes <lool> And apex' builtin defaults <ogra> not for jaunty though <lool> Why not? <ogra> that really requires deep apex tinkering and a proper spec imho <ogra> feature freeze is in 8 days <lool> So you prefer learning it all, implementing a workaround, then having to learn it all again to fix it properly or simply not bother to fix it properly? <ogra> no, i prefer to have sane defaults for now and to add additional features if we have time for that <ogra> i havent touched the touchscreen issues at all yet, we dont even have a working kernel for the slug etc etc ... <lool> Why would a ramdisk size larger than 5636080 corrupt the initrd? <lool> I hate leaving things half fixed when we can fix them properly <lool> This is seriously not fun for me to invest so much time on an issue and then look back and think "I didn't really fix it" <ogra> i guess thats a question for marc ... using any bigger size than the one we padded it to simply results in a panicking kernel <lool> I think I shouldn't have looked at this issue at all, it's too frustrating, we don't have the same goals <ogra> right, so do you want me to drop all my specs for supporting an arch nobody uses ? <lool> I guess it depends how much time you think you need to fix it properly versus implementing a workaround <ogra> the only committment i have atm is to get a working d-i image for that thing <ogra> which i have now module a decision on the proper default values for apex <ogra> and a working kernel ... which isnt in my hands <ogra> lool, moving the apex VMA adress to 3MiB seems to work as well as shuffling kernel and rmadisk adresses, given that we differ in only one value from debian here (and will likely be able to convince tham to accept that as default) i'll g with that ... the ramdisk size propblem persists though and i think its likely due to the fact that apex tries to assign a memory area but the ramdisk image itself doesnt fill that up with zeroes as soon as the apex va <ogra> lue is bigger than the actual partition ... values between the actual initrd.gz size up to the padded partition size do work well, i'll ask on debian-arm to get a confirmation from marc about the theory #ubuntu-arm 2009-02-12 <pwnguin> is there a list of ftbfs for arm? <pwnguin> the wiki has one last updated in like november <prpplague> davidm: ping <prpplague> Mirell: greetings <Mirell> 'allo <ogra> jldugger, http://qa.ubuntuwire.com/ftbfs/ <amitk> ogra: just finished reading the massive scrollback from yesterdays apex debugging. Impressive work! <amitk> ogra: So it seems it isn't a kernel problem? * amitk starts to read up on apex a bit <ogra> amitk, well, upstream answered my last mail on debian arm ... where i said "hello, my kernel panics if i choose more than 5M for the ramdisk size" ... with "yes, you can use up to 8M for the ramdisk" <ogra> its not all solved yet, but i have a workaround for now <ogra> whih i intend to upload so we get working daily builds as soon as there is a kernel ... but its something we surely need to revisit <ogra> *which <amitk> ogra: re: as soon as there is a kernel? <ogra> the kernel corruption thing itself is solved ... <ogra> amitk, our endiness is wrong <ogra> *endianess <amitk> ogra: ah right, i'll get that fixed <amitk> anything else you need in the ixp4xx image for this upload besides endianness? <ogra> and if i use the kernel not swappped with devio it stops after unpacking (not sure thats related to endianess mistmatches with apex, kernel and initramfs but i suspected so <ogra> only the NIC firmware ... doing a netinstall without NIC is quite tricky ;) <amitk> and that will be required for d-i too <ogra> right, but d-i builds udebs from linux-firmware <ogra> just a matter of adding the right udeb to the netinstall image <ogra> i might have kernel changes afterwards though, i couldnt test our kernel at all yet <ogra> (i.e. i dont know how it bevhaves in an installed system ...) <ogra> lool got it to boot directly from redboot during the sprint (which is why i suspect the non booting to just be an endianess issue in d-i) but we werent able to change the cmdline in redboot as everything at that stage is readonly <ogra> amitk, did you get your serianl port to work ? <ogra> *serial <amitk> ogra: removing the solder blobs is being a problem, i've got to go and get a desoldering braid <ogra> yeah, though davidm managed to just blow it out of the holes, i had to use a pump <amitk> blowing it sounds dangerous, though he has a ton more experience than I do <alesan> hi <alesan> I have this board with an ARM, 128MB of memory, USB, ethernet, serial, VGA, audio, PS/2; I wrote all the drivers. Can I run Ubuntu on it? <ogra> sure <ogra> see the last link in the topic <alesan> well <alesan> I think my board is not a ready target <alesan> it will require the proper drivers for example <alesan> even an headless image would require my ethernet drivers <alesan> or - maybe I'm mistaken and this rootfs does not contain the kernel <ogra> right, its only the userspace <ogra> if yu have a kernel, use that, if you can push your drivers upstream to kernel.org we can fully support your board in jaunty+1 <alesan> yeah :) that would be nice <alesan> just as an information, when is likely to be the "freeze" for j+1 ? <ogra> hard to predict, the j+1 schedule will only be finalized at the next developer summit ... which is in may <ogra> jaunty releases in april ... feature freeze for jaunty is next week <ogra> feature freeze is usually the point where stuff like that needs to be in ... given that j+1 will happen in october it might be around august <alesan> yeah but it is hard by that time my drivers will be in an official kernel release <alesan> it's a lot of stuff in many subsystems <ogra> well, if you can get them into .29 or .30 we'll get them for free from upstream <ogra> then supporting your HW is a non issue, just a matter of enabling the .config <alesan> yeah <alesan> listen as a side question <alesan> openoffice is actually running on ARM? <ogra> on some HW, yes <ogra> i doubt you will get it running properly on 128M though <alesan> do you have an idea of the requirements? <ogra> it will *run* but not be fun <alesan> or an hardware that is known to run it? just as comparison with what I have here on this board <ogra> if you want to support ubuntu-desktop including firefox and openoffice your HW should have above 256M and above 500MHz <alesan> yeah :) it's a pity, I remember when I was able to run office97 on a 16MB PC :( nowadays 128MB are too little <ogra> i doubt there is any HW public yet <alesan> ah ok <ogra> http://www.notebooks.com/2009/01/07/new-generation-of-netbooks-199-and-299-eight-hour-battery-sexy-design/ <ogra> something like that will likely run ubuntu-desktop incl. openoffic fine <alesan> by the way, what about Koffice, it used to be lighter than OOo * ogra hasnt tried any QT based stuff on arm yet <ogra> i know xubuntu and gcoffice work fine though <ogra> even on the beagleboard i have if i add some swap and a USB disk <ogra> (so that IO times are not to huge) <alesan> gcoffice = ?? I only found a german cheese office with that name :) <ogra> abiword and gnumeric <ogra> the actual so called "gnome office" <alesan> the moment you create this rootfs... what format is that? it is likely the way to mount it is with a USB key right? <ogra> alesan, its a tgz that you csn untar on any kind of partition (given it has the right size) <ogra> *can <ogra> if you use the --notarball option it will create a qemu image instead <ogra> so you can play with it in qemu-system-arm #ubuntu-arm 2009-02-13 <Meizirkki> KDE 4.2 on Nokia n810: http://picasaweb.google.com/meizirkki/MerOnN810#530084148502.619.2016 <Meizirkki> it runs "ok", but is there any tricks to make it faster? <persia> Meizirkki, The usual recommendation is to add more memory, but that's not easy for that device. Is it thrashing, or is there some specific part that is slow? <Meizirkki> well, it runs somehow without swap, and 256mb swap makes it usable... it's just slow to use. <persia> Hard to say if it's too many instructions, or not enough working space. <persia> You might try asking in #kubuntu to see if anyone has any general KDE speed-up tricks. <Meizirkki> ok, thanks :) <Meizirkki> i'm surprised that it kde itself only takes about 110 mb memory.. but it's just hungry for cpu-power <persia> There's been a lot of work with KDE to try to keep the footprint down: it's not just for handhelds that it makes it feel faster :) <Meizirkki> yes, i remember how ugly kde 4.0 ran on my old pc <Meizirkki> kde 4.2 is a lot faster <Meizirkki> :P <Meizirkki> is jaunty using Qt 4.5?? <persia> 4.4.3 <Meizirkki> k <Meizirkki> ppl @ #kubuntu said Qt 4.5 would make things a lot faster <persia> Well, they should get the kubuntu-ninjas to upload it if they think so :) <Meizirkki> yeah, they also said it's a bit crashy ;) <persia> Ah, that explains why :) #ubuntu-arm 2009-02-15 <ian_brasil> just ran build-arm-rootfs and it worked but gave a couple of error messages <ian_brasil> arm_script build-arm-rootfs build.sh Setting kernel variables (/etc/sysctl.d/10-network-security.conf)... [80G error: "net.ipv4.tcp_syncookies" is an unknown key <ian_brasil> [74G[[31mfail[39;49m] <ian_brasil> arm_script build-arm-rootfs build.sh Setting kernel variables (/etc/sysctl.d/10-process-security.conf)... [80G error: "vm.mmap_min_addr" is an unknown key <suihkulokki> no hwcap-optimized libs in ubunut-arm yet? <Stskeeps> debian moving anywhere in that area yet? <suihkulokki> Stskeeps: now that lenny is out, it a good time to lauren32@example.com. I was looking if I were lucky and ubuntu had already done it, but no such luck today ;) <Stskeeps> i'm eagerly awaiting any work :P <ogra> well, lets take that here :) <ogra> running KDE or GNOME on less than 256M is really adventurous :) and there isnt much arm HW yet with more ram out there <ScottK> Tscheesy_: ^^^ <ogra> though the 256M beagleboard is due soon <ScottK> Dunno what he has excatly... <ogra> (on the 128M version even xubuntu is painful) <ScottK> Tscheesy_: What are you running? <ScottK> Also we haven't made any armel specific changes to our desktop, so there may be stuff we're flat out missing. <Tscheesy_> re <Tscheesy_> actually i'm trying to build kubuntu-desktop on Jaunty <ogra> probably <ogra> NCommander cared most of the time for KDE on armel <ogra> i dont know much about it nor did i test it yet <ogra> Tscheesy_, why ? isnt the version in the archive not working that you try to build it yourself ? <ogra> the only think i see on http://qa.ubuntuwire.com/ftbfs/ is kpackagekit <Tscheesy_> ogra: i need the Root-Fs because i can't get it on my Openmoko otherwise <ogra> see the topic ;) <ogra> last link <Tscheesy_> yes - there i got following fatal <Tscheesy_> FATAL: Could not load /lib/modules/2.6.28-6-versatile/modules.dep: No such file or directory <ogra> thats fine <ogra> all stuff you need for the versatile kernel is builtin <ogra> so modules arent needed <Tscheesy_> hmm.. computer ist szcuk for a while <ogra> (you can indeed install linux-versatile in the rootfs if you feel like, but that wont run on any real HW anyway, its
{'channel': 'ubuntu-arm', 'month': 2}