| === fta_ is now known as fta | ||
| === fta_ is now known as fta | ||
| === fta_ is now known as fta | ||
| === fta_ is now known as fta | ||
| === fta_ is now known as fta | ||
| === fta_ is now known as fta | ||
| === fta_ is now known as fta | ||
| === bjf is now known as bjf[afk] | ||
| === fta_ is now known as fta | ||
| ukleinek | zumbi: the story is over, Linus pulled :-) | 07:45 |
|---|---|---|
| === fta_ is now known as fta | ||
| === hrw|gone is now known as hrw | ||
| hrw | morning | 08:30 |
| ogra | cooloney, urgh, please ship vmlinuz in the linux packages | 08:31 |
| ogra | we use flash-kernel on all arm platforms to do special stuff to the binaries (i.e. running mkimage to create uImage) | 08:32 |
| ogra | i dont want to special case flash-kernel for certain platforms | 08:32 |
| ogra | cooloney, we need to create uInitrd anyway on each update-initramfs trigger so it makes no sense to ship uImage in the package (and we had that discussion before several times) | 08:33 |
| * cooloney nods to ogra | 08:35 | |
| cooloney | ogra: great, understand. | 08:35 |
| ogra | :) | 08:37 |
| === amitk-afk is now known as amitk | ||
| lag | mythripk: Hi | 09:13 |
| fjrivash | Hello, I created a rootfs using this command sudo rootstock --fqdn qemu-test --login qemu --password qemu -d karmic --notarball, I compiled a kernel in the standard way (make, make modules, make zImage) and try this command sudo qemu-system-arm -M versatipb -cpu arm11mpcore -kernel ./zImage -hda qemu-armel-201007121813.img -m 256 -append "root=/dev/sda rootwait", but I got just a black screen. | 09:26 |
| fjrivash | thanks in advanced for any comment about this. | 09:26 |
| fjrivash | other thing is : is this the right way to cross compile my kernel ? make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- | 09:27 |
| fjrivash | thanks again in advanced | 09:27 |
| ogra | if you got a binary thats likely the right way :) | 09:27 |
| ogra | i would suspect you are missing some console settings | 09:27 |
| lag | fjrivash: Which board are you using? | 09:28 |
| fjrivash | ogra, I got it after make zImage | 09:28 |
| ogra | try with -nographic | 09:28 |
| ogra | (on the qemu cmdline) | 09:28 |
| ogra | that should at least show some kernel messages | 09:28 |
| fjrivash | lag, a CNS3410 (it is an arm11mpcore which is compatible with armv6kz) | 09:29 |
| fjrivash | ogra, thanks I will try it right now | 09:29 |
| ogra | (note that you cant ctrl-c qemu then, you need to close the terminal to stop it) | 09:30 |
| ogra | or kill it from another term | 09:30 |
| fjrivash | jejejeje I see! it was so funny, I thought that was something else bad | 09:30 |
| lag | Well done ogra | 09:31 |
| fjrivash | ogra, I got nothing :S. it think it must be the kernel | 09:31 |
| lag | I take it back ;) | 09:31 |
| lag | Does qemu not have pre-boot messages | 09:32 |
| lag | Similar to a bootloader? | 09:33 |
| fjrivash | actually yesterday I built a new image using karmic. lag AFAIK you must install a bootloader if you want to use it to load a kernel image | 09:33 |
| lag | Do you need one? | 09:33 |
| lag | Or will qemu be the bootloader too? | 09:34 |
| fjrivash | well to be honest I trying to avoid that. but it seems that I need one, for example u-boot | 09:34 |
| lag | Ask ogra | 09:35 |
| lag | ogra: Do you need a bootloader when you use qemu? | 09:35 |
| fjrivash | lag thank you very much. :D | 09:35 |
| ogra | lag, nope | 09:35 |
| lag | Okay | 09:35 |
| lag | I might install it and have a play | 09:35 |
| sebjan | ogra: coming back to uImage creation - how to make update-initramfs generate the uImage? Is there a script to update in the kernel package or somewhere else? | 09:36 |
| ogra | lag, i think you *can* use a bootloader ... i think lool does that in his qemu-maemo experiments, but specifying the kernel should be enough to get a booting system | 09:36 |
| ogra | sebjan, flash-kernel does it | 09:36 |
| ogra | sebjan, have a look at update-initramfs and the flash-kernel source | 09:36 |
| ogra | sebjan, since my last update to flash-kernel that should happen automatically on ubuntu images | 09:37 |
| ogra | for omap3 and 4 at least | 09:37 |
| sebjan | ogra: it does not for our omap4 kernel packages at least, this is why I came up with this dirty hack :) | 09:38 |
| fjrivash | ogra, lag thank you very much I will recompile the kernel because I think that is the problem, I will let you know | 09:38 |
| ogra | sebjan, flash-kernel requires /etc/flash-kernel.conf on omap4 (thats created during first boot of the image) | 09:39 |
| lag | fjrivash: Where did you get qemu-system-arm from? | 09:40 |
| fjrivash | from repositories | 09:40 |
| ogra | sebjan, and you need at least flash-kernel 2.28ubuntu2 for panda support | 09:40 |
| fjrivash | actually I did a qemu-system-arm --cpu ? and there is an arm11mpcore support- | 09:40 |
| ogra | sebjan, and also a /boot/boot.script file as input for the used boot.scr | 09:41 |
| lag | It's not in my repository | 09:41 |
| ogra | lag, qemu-kvm-extras | 09:41 |
| lag | ogra: Thanks | 09:42 |
| ogra | iirc | 09:42 |
| ogra | rootstock pulls it in automatically | 09:42 |
| ogra | together with qemu-arm-static | 09:42 |
| ogra | for arm chroot handling | 09:42 |
| fjrivash | that is right | 09:42 |
| sebjan | ogra: ok, I was far from it :) thanks! Could you please send me an example flash-kernel.conf file? | 09:42 |
| ogra | sebjan, UBOOT_PART=/dev/mmcblk0p1 | 09:43 |
| ogra | sebjan, thats all :) | 09:43 |
| ogra | sebjan, flash-kernel only needs to know where the bootloader partition is (and you need the /boot/boot.script as input) | 09:44 |
| * ogra takes a break | 09:46 | |
| sebjan | ogra: thanks! | 09:46 |
| fjrivash | in which cases do I have to use a ramdisk? | 09:46 |
| fjrivash | I mean I have read that you can specify a initrd in qemu command but I am not pretty sure if I need it. | 09:47 |
| fjrivash | (figuring out) | 09:48 |
| === XorA|gone is now known as XorA | ||
| lag | lool: Ping | 10:04 |
| lag | fjrivash: Did you build the kernel yourself? | 10:06 |
| fjrivash | yes | 10:07 |
| lag | fjrivash: Do this from the root of your kernel tree: "find . | grep vmlinuz" | 10:07 |
| fjrivash | there is no vmlinuz, there is a zImage which is in a boot directory, I am compiling the kernel (again) | 10:08 |
| fjrivash | the first time I got a zImage of 40mb | 10:08 |
| lag | You must have debugging symbols turned on | 10:08 |
| lag | And all your drivers built into the kernel | 10:09 |
| lag | fjrivash: Use this: http://www.aurel32.net/info/debian_arm_qemu.php | 10:10 |
| lag | And slowly supplement its components for your own | 10:10 |
| lag | I've just tried one of my kernels, but it doesn't support omap out of the box | 10:10 |
| fjrivash | mm I see. let me check that url. | 10:11 |
| lag | mythripk: ping | 10:11 |
| mythripk | yes lag | 10:19 |
| lag | Good morning | 10:19 |
| lag | Or afternoon where you are | 10:19 |
| lag | How are you/ | 10:19 |
| lag | ?* | 10:19 |
| fjrivash | I found this one http://wiki.debian.org/ArmEabiHowto which is based on that one lag but with new kernel images. | 10:20 |
| mythripk | lag : ya good afternoon, fine thank you , did you see the mail i sent on the code sequence for sysfs and bootargs | 10:20 |
| lag | fjrivash: Good. Use that and slowly supplement its components for your own | 10:21 |
| lag | mythripk: I did | 10:21 |
| lag | mythripk: I am seeing some odd behaviour | 10:21 |
| mythripk | ie ? | 10:21 |
| fjrivash | lag thank you very much I am working on it right now, I will let you know. | 10:21 |
| lool | lag: pong | 10:22 |
| lag | mythripk: When the monitor goes to sleep after a time - when it wakes up, the setting have gone back to fuzzy | 10:22 |
| mythripk | lag: even with the sysfs u mean | 10:22 |
| lag | mythripk: So: Boot up -> Fuzzy | Use sysfs -> Good | Sleep-Wakeup -> Fuzzy | 10:23 |
| lag | The board is still awake | 10:23 |
| lag | It's just the monitor which is put to sleep | 10:23 |
| mythripk | lag: with fuzzy you mean the out of range | 10:23 |
| mythripk | lag: how do you get the display out of sleep , if you set fb black it would not go to sleep | 10:24 |
| mythripk | lag: Ping ping echo "0" > /sys/class/graphics/fb0/blank this command would not suspend the TV . | 10:27 |
| lag | mythripk: I get the display out of sleep by pressing the keyboard | 10:30 |
| lag | mythripk: Yes, I mean 'out of range' | 10:30 |
| lag | Why would I want to do that command? | 10:30 |
| mythripk | lag: even with the out of range block appearing at the centre , you can still see the commands ? | 10:31 |
| lag | Yes | 10:31 |
| mythripk | lag: That command will not blank the TV , ie the TV will not go to sleep | 10:31 |
| mythripk | have you tried a different HDMI cable ? | 10:31 |
| lag | I didn't use that command | 10:31 |
| lag | That cable works fine on my Beagle | 10:31 |
| mythripk | you could use that command in case you dont want the TV to sleep | 10:32 |
| lag | We have to put our displays to sleep | 10:32 |
| lag | We are an Operating System | 10:32 |
| lag | Well a distribution | 10:33 |
| mythripk | that is fine , you need not , that was just in case it was not expected. | 10:33 |
| lag | That is not the problem | 10:33 |
| lag | The problem is that it does it and it's not meant to | 10:34 |
| lag | So needs fixing somehow | 10:34 |
| lag | That is not the only odd behaviour | 10:34 |
| lag | When you told me to boot with less arguments, it worked perfectly on start-up (with the cmdline args) | 10:35 |
| lag | But on a subsistent boot it was 'out of range' again | 10:35 |
| lag | With the same settings | 10:35 |
| mythripk | one reason from your log i have seen is that there are too many bootargs and thus hdmimode is not effective , thus it is going to a wrong non desired setting | 10:36 |
| lag | But I have reduced the number of bootargs | 10:37 |
| lag | And the behaviour is the same | 10:37 |
| mythripk | and now the timing is correctly set? can you pastebin the log since bootargs | 10:37 |
| mythripk | because i dont see this behaviour on viewsonic or samsung TV that i have | 10:38 |
| lag | They are not correctly set | 10:43 |
| lag | It was, once | 10:43 |
| lag | But on subsequent reboots they reverted to incorrect | 10:44 |
| mythripk | ok , I have an RFC for autoboot of HDMI , i will be posting on OMAPPEDIA , that would atleast remove your bootargs problem | 10:46 |
| lag | Can I follow that? | 10:47 |
| mythripk | yes , Please | 10:47 |
| lag | How? | 10:48 |
| mythripk | lag:I will be putting it on http://omappedia.org/wiki/Display_Drivers_Domain_Wiki | 10:49 |
| mythripk | once i'm done with sanity testing | 10:49 |
| lool | lag: Hey you pinged me, I ponged, but then I didn't hear anything anymore? :) | 10:50 |
| === amitk is now known as amitk-afk | ||
| mythripk | lag: But one confirmation , it is only in your LG make TV you are seeing this issue right , not in any other monitors | 10:55 |
| lag | lool: Everything came alive at the same time - can you give me a minute please? | 10:59 |
| lag | mythripk: I don't have any other monitors to test | 10:59 |
| lag | mythripk: If you want to send me other monitors to test, I'd be more than happy to | 10:59 |
| lag | lool: Do you use qemu to boot omap images? | 11:00 |
| lool | lag: I do | 11:13 |
| lool | lag: They need a bootloader on the images, and that apparently doesn't work with current Ubuntu images, but it should in theory work | 11:14 |
| lool | lag: https://launchpad.net/~lool/+archive/ports-dev/+packages has maverick packages of qemu-maemo | 11:14 |
| lag | lool: Okay, that explains a lot | 11:14 |
| lool | lag: something like qemu-maemo-system-arm -M beagle -m 256 -sd ubuntu.img -serial stdio | 11:14 |
| lool | That works more or less with Angstrom ATM, it boots well into the kernel, but then I get some divide by zero in the kernel which I didn't lookinto | 11:15 |
| ogra | lool, hmm, we had that with the omap kernels too | 11:15 |
| ogra | (division by zero errors) | 11:15 |
| lag | Yes we did | 11:15 |
| ogra | smells like a kernel prob, not like qemu | 11:15 |
| lag | I can't remember what the cause was though? | 11:15 |
| * ogra neither | 11:16 | |
| ogra | but i remember some oopses that had such an error in front of them | 11:16 |
| lag | I think I had them when I tried to boot the XM with Lucid | 11:16 |
| lool | I tried an older Angstrom kernel, I'd be surprized if it had divide by zero errors | 11:17 |
| * ogra thinks he saw them together with the ureadahead OOMs too | 11:17 | |
| lool | Anyway | 11:17 |
| lool | First thing with Ubuntu images would be understanding why it doesn't work in qemu-maemo | 11:17 |
| lag | Ogra likes to blame everything on the kernel | 11:17 |
| lag | It's an easy scapegoat | 11:17 |
| ogra | indeed :) | 11:17 |
| lag | :) | 11:17 |
| lool | ogra: Let's just blame everything straight to lag then? | 11:17 |
| ogra | lool, can only be the bootloader/x-loader | 11:18 |
| lool | ogra: it could be the partition layout | 11:18 |
| * lag == scapegoat No1 | 11:18 | |
| ogra | lool, else you would at least see u-boot messages | 11:18 |
| ogra | lool, we use the angstrom script to create our bootloader partition | 11:18 |
| markos_ | lool: fwiw, I've officially sent a request to rejoining Debian, I intend to work on the armelhf -or whatever it's called- in a much more official -or semi-official- way now | 11:18 |
| markos_ | no idea how long it takes, but it won't take as long as a full NM application | 11:18 |
| lool | markos_: did you follow linaro-dev discussions? | 11:19 |
| markos_ | (this after reading most mails on linary and debian-arm lists) | 11:19 |
| markos_ | yes | 11:19 |
| lool | About NOT doing a new port :-) | 11:19 |
| ogra | lool, well, the OE script which angstrom uses as well :) | 11:19 |
| lool | markos_: I find the discussion very interesting, but I find it a hard sell for the bunch of people interested in working on the port | 11:19 |
| markos_ | still reading, haven't finished yet :) | 11:19 |
| lool | markos_: I've personally written to zumbi to tell him I would like to semi-officially work on that port | 11:19 |
| lool | as in, with my Debian hat on and on a best effort basis | 11:20 |
| lool | but I expect to help as much as I can | 11:20 |
| ogra | linaro goes debian ? :) | 11:20 |
| markos_ | well | 11:20 |
| lool | Sure, we're not tightened to Ubuntu | 11:21 |
| lool | we're helping all distros out there if we can and know how to | 11:21 |
| * ogra was joking, i know that | 11:21 | |
| lool | But we're also splitting our time wisely ;-) | 11:21 |
| markos_ | there is nothing to prevents us (Genesi) from working on an unofficial hardfp port just as we are now, with no new port name, because on our cpu (a8), there is a lot to gain and it can give us a competitive advantage -and of course to others that choose to use our repository | 11:22 |
| markos_ | at the very least we can provide testing and patches for packages that fail to build for hardfp | 11:23 |
| markos_ | I'd really hope for a new port though | 11:23 |
| markos_ | it would make things easier -and- provide a new optimized port for newer cpus | 11:23 |
| markos_ | with no new port -regardless of the toolchain changes- it's guaranteed that performance will always be sub-optimal | 11:24 |
| markos_ | other arches don't have such a big problem | 11:24 |
| * zumbi confirms lool's wanting to help on Debian port | 11:25 | |
| markos_ | eg. on ppc, the abi is the same always, if someone wants more performance they can always install a -altivec version of the package -if available of course | 11:25 |
| ogra | markos_, depends ... look at ubuntu, we still call what we have "armel" even though its totally not what you get in debian | 11:25 |
| mythripk | lag: I shall send the link to the RFC to solve your bootargs problem , it would do an autodetect , but for your out of range problem i have contacted the hardware and power management folks i shall get back once i get a reply , as it doesnt appear to be a HDMI s/w issue. | 11:26 |
| ogra | we could as well just default to hardfp | 11:26 |
| zumbi | ogra: debian is upstream, linaro, ubuntu, mint, .. all of them will fork | 11:26 |
| ogra | since we dont support any of the old CPUs anymore | 11:26 |
| ogra | zumbi, indeed and its surely the better move to have what we have in ubuntu in our upstream already | 11:26 |
| ogra | will save us a lot of work | 11:27 |
| ogra | i'm just pointing out that armel != armel if you look at it today | 11:27 |
| lag | mythripk: Thanks, I'll look forward to it | 11:27 |
| ogra | and to be honest i'm not really lookinf forward to all the script changes we have to do based on a name change | 11:27 |
| markos_ | ogra: yes, that's exactly what I did as well, if I waited for toolchain fixes, I still wouldn't be able to test a single package :) | 11:28 |
| hrw | 12:19 < ogra> lool, well, the OE script which angstrom uses as well :) | 11:29 |
| hrw | ogra: thats Ångström script which is stored in OE repository | 11:29 |
| hrw | ;D | 11:29 |
| ogra | hrw, heh, well, whatever way you want it around, our boot partition is created the same way :) | 11:30 |
| lag | sebjan: ping | 11:30 |
| ogra | so it cant be poartitioning imho | 11:30 |
| ogra | -o | 11:30 |
| zumbi | ogra: so do you suggest 3 different "armel" flavours: debian, ubuntu and genesi's | 11:30 |
| markos_ | zumbi: if ubuntu decides to go hardfp themselves, there would be need for only 2 | 11:31 |
| ogra | zumbi, no, the opposite | 11:31 |
| zumbi | ogra, ok, i misunderstood :) | 11:31 |
| ogra | zumbi, if hardfp shows up in debian (and also uses our current defaults v7 etc) it would be the logical choice for me to switch ubuntu over | 11:31 |
| ogra | zumbi, i'm just fearing all the script changes for scripts that look at $arch+$subarch we currently use in ubuntu | 11:32 |
| lool | markos_: The point Mark is making is that they are other ways to rip (most?) of the benefit of hardfp, a new port adds permanent fragmentation though | 11:32 |
| zumbi | ogra: but ubuntu will keep maintaining two different armel ports? or just one? | 11:32 |
| ogra | zumbi, preferably just one optiomized for cortex-a8 and bigger | 11:33 |
| lool | markos_: Costs such as doing the validation twice, or costs such as for ISVs trying to provide binaries are quite high | 11:33 |
| ogra | zumbi, thats what our current armel already is | 11:33 |
| lool | markos_: Consider that we don't have a flash plugin for 64-bits after all this time | 11:33 |
| ogra | zumbi, for me it would just be a name change plus a different fpu | 11:33 |
| markos_ | lool: I don't see that as necessarily a bad thing, why should a router developer care for neon optimizations or vfp stuff that a desktop distro developer would insist upon? | 11:33 |
| lool | markos_: flash might just land on arm soon, and now we will require two versions? | 11:33 |
| markos_ | and vice versa | 11:33 |
| lool | markos_: Fragmentation | 11:34 |
| lool | markos_: You might release an android phone build on vfp or non-vfp hardware | 11:34 |
| lool | suddenly, you have to use a different stack | 11:34 |
| lool | and people have to provide different native builds | 11:34 |
| markos_ | lool: by the time it arrives, lightspark might work on arm already and even surpass official flash | 11:34 |
| markos_ | important as it is, flash is not the driving force behind a distro | 11:34 |
| lool | markos_: Eh it was just an example obviously | 11:35 |
| markos_ | lool: I'm not aware of any important non-free software that would act as a show-stopper, apart from flash | 11:35 |
| hrw | lool: many android/winmo phones with armv6 cpu do not have vfp | 11:36 |
| zumbi | lool: how much is codesourcery, ARM and linaro to make those compiler changes? -- are they worth it? | 11:36 |
| ogra | lool, what ? you are not working on fixing a 64bit flash ? | 11:36 |
| lool | markos_: Even for Debian, it means new buildd network, new images to validate, packages to change, the work will eventually be distributed on a bunch of DDs, but the sum of it is HUGE | 11:36 |
| lool | hrw: precisely, thanks for mentionning it | 11:36 |
| lool | markos_: Consider the market place use case | 11:36 |
| lool | markos_: I ship an OS, and ISVs can offer apps for it | 11:36 |
| hrw | lool: qualcomm msm armv6 cpus to be exact | 11:36 |
| XorA | hrw: the msm72XX CPUs tend to lack VFP | 11:37 |
| markos_ | also, android is totally irrelevant to ubuntu/debian, they already have totally separate binaries | 11:37 |
| lool | markos_: Suddenly, this OS might come in two incompatible flavors and ISVs have to provide builds for the two flavors and test the two | 11:37 |
| markos_ | and totally incompatible | 11:37 |
| ogra | markos_, its not ... there are hacks that make android work in ubuntu | 11:37 |
| ogra | not officially in the archive but you can use them | 11:37 |
| markos_ | exactly that, hacks, it even has a different libc | 11:37 |
| lool | These are just example | 11:38 |
| lool | I could have said MeeGo and made the same point | 11:38 |
| markos_ | I understand your point | 11:38 |
| markos_ | but in my experience, users will very rarely pick a package from another distro -eg. a meego user from an ubuntu netbook for example and try to make it work | 11:39 |
| ogra | there might be a meego ubuntu image at some point, who knows | 11:39 |
| lool | markos_: It's not about other distros, it's about ISVs | 11:39 |
| markos_ | so compatibility is not really important here, Adobe for example, will most likely have a single instance of most important distros and build on each one separately -I don't know if that's the case, but I imagine it's a logical scenario | 11:39 |
| lool | markos_: In Android, Maemo, MeeGo, Ubuntu, you get to add packages and software from ISVs | 11:40 |
| ogra | and these users would surely want to be able to use all of the ubuntu archive on their systems | 11:40 |
| lool | markos_: heck, that's even true for Ubuntu, vmware provides binary .debs | 11:40 |
| lool | Or Adobe Acrobat Reader | 11:40 |
| lool | or many others | 11:40 |
| ogra | or flash :) | 11:40 |
| lool | (that was covered already) | 11:40 |
| markos_ | yes I totally understand your point | 11:40 |
| * ogra was referring to adobes flash package :) | 11:40 | |
| lool | markos_: Once you create the port, and you have a somewhat popular userbase | 11:40 |
| lool | Debian derivatives will appear (probably including Ubuntu I'd guess) | 11:41 |
| lool | and products will ship based on it | 11:41 |
| lool | and the ARM world will be fragmented a bit more | 11:41 |
| lool | So I'm /very/ split on this point | 11:41 |
| markos_ | my point is, if Adobe would provide the same package with just rebuilding it on the same hardware -and no other extra development- why should they not do that, | 11:41 |
| lool | markos_: they need to port it, validate it twice etc. | 11:41 |
| markos_ | lool: ARM is way beyond unification :) | 11:41 |
| === fta_ is now known as fta | ||
| lool | markos_: You think adobe flash would work without any tweaks on hradfloat calling conventions? I bet not | 11:42 |
| ogra | the opposite is the case thanks to linaro | 11:42 |
| markos_ | lool: it's the most fragmented architecture out there : | 11:42 |
| lool | I bet upcoming ones have NEON opts and stuff | 11:42 |
| markos_ | lool: neon works just fine on hardfp | 11:42 |
| lool | markos_: And fragmentation is the main issue, and initiatives like Linaro fight fragmentation towards consolidation | 11:42 |
| lool | markos_: My point is, there is manual assembly in flash player, so they will have to adapt | 11:42 |
| markos_ | if done using pure asm, maybe, if done using C intrinsics, they most definitely not | 11:43 |
| markos_ | s/they/then | 11:43 |
| lool | markos_: I think it's a large body of code with assembly, and has good chances of hitting the issue | 11:44 |
| lool | markos_: In any case, I think the main problem is that the alternate plans being discussed are far away | 11:45 |
| lool | markos_: Both because they need long developments and because they need a certain class of people (experienced toolchain devs) | 11:45 |
| lool | markos_: So I currently suspect the port will happen by virtue of being atteinable now | 11:46 |
| ogra | we could switch M+1 to hardfp in ubuntu and act as a testbed for debian | 11:46 |
| ogra | debian would just have to take our armel defaults then | 11:46 |
| ogra | and we would rename to armelfp in M+2 | 11:47 |
| ogra | without having to do more changes than renaming | 11:48 |
| markos_ | ogra: I could act as a testbed for Ubuntu myself, I could rebuild Maverick for example for hardfp and provide testing/patches | 11:48 |
| markos_ | my goal ofc would be to have a hardfp maverick build | 11:49 |
| lool | ogra: "switch" | 11:49 |
| ogra | well, we wont do a hardfp build in maverick but test results would surely be appreciated | 11:49 |
| lool | ogra: you dont switch | 11:50 |
| lool | it's binary incompatible | 11:50 |
| ogra | lool, its a full rebuild, i'm aware of that | 11:50 |
| lool | you can introduce a new port, deprecate armel, and them move to the hard-float one | 11:50 |
| lool | ogra: No, it's incompatible | 11:50 |
| lool | it's a new bootstrap | 11:50 |
| lool | ogra: You can't "upgrade" to it | 11:50 |
| ogra | oh, indeed | 11:50 |
| lool | ogra: I think you need to read the debian-arm@ discussion | 11:51 |
| ogra | lool, i do | 11:51 |
| ogra | not extensively but i have read some of the thread | 11:51 |
| markos_ | brb | 11:51 |
| ogra | lool, indeed we would have to make a cut, but we will become the best optimized v7 distro in the end so i dont think its a bad thing | 11:52 |
| ogra | lool, what i wont do is maintain two arm arches | 11:53 |
| lool | ogra: See that's the main issue | 11:53 |
| lool | ogra: You dont want to maintain two arm arches | 11:53 |
| lool | Nobody wants | 11:53 |
| lool | well Debian is ready to start that | 11:53 |
| ogra | debian does already, no ? | 11:53 |
| ogra | they would get a third | 11:53 |
| zumbi | debian is discussing it! not ready for anything, just Genesi is ready | 11:54 |
| lool | but in practice, ARM Cortex-A class CPUs with VFP are the high-end ones, and many devices will ship with A-class CPUs without VFP, including phones and netbooks | 11:54 |
| ogra | ir is the arm oabi port completely gone ? | 11:54 |
| lool | ogra: Debian only has an armel port right now | 11:54 |
| ogra | ah, i thought arm was still existing | 11:54 |
| lool | That said, Ubuntu already excludes non-VFP hardware | 11:54 |
| ogra | right | 11:54 |
| ogra | for us its not such a big step apart from upgradeability | 11:55 |
| sebjan | lag: pong | 11:55 |
| === amitk-afk is now known as amitk | ||
| markos_ | lool: anything new reg. soyuz release as standalone? | 12:09 |
| lool | markos_: I'm not tracking that personally, ping salgado on #linaro | 12:10 |
| lool | .br time | 12:10 |
| lag | sebjan: Good morning | 12:14 |
| lag | Afternoon even - doesn't time fly? | 12:14 |
| sebjan | lag: yes indeed :) | 12:14 |
| lag | sebjan: Do you have any documentation you can send me for OMAP3 and OMAP4? | 12:15 |
| lag | sebjan: A developer's manual or such | 12:15 |
| lag | sebjan: Containing memory maps, register addresses and definitions etc | 12:16 |
| sebjan | lag: the technical data manual for omap3 shall be available publicly... | 12:17 |
| sebjan | lag: it is not out yet for omap4 | 12:18 |
| sebjan | lag: regarding the beagle, there seem to be good links here: http://elinux.org/BeagleBoard#Manuals_and_resources | 12:21 |
| lag | But nothing for the XM? | 12:22 |
| lag | Or Panda? | 12:22 |
| lag | The two boards I own :D | 12:22 |
| markos_ | lool: does gcc-linaro include hardfp patches from CS? I'm pulling the 4.4 branch now to test | 12:23 |
| sebjan | lag: I have never looked for the XM, if it exists, it shall be reference on the wiki? For panda, it will come when it is release ;) We shall have omap4 data manual soon I hope. | 12:24 |
| lag | sebjan: Perhaps I need to be a little more specific | 12:30 |
| lag | sebjan: Do you have the developers reference for the OMAP3630 | 12:30 |
| sebjan | lag: you shall ask this on the #linux-omap channel, they shall be able to provide you clear answers regarding public documentation and where to get it | 12:32 |
| ogra | should be on ompazoom.org | 12:33 |
| lag | Thanks sebjan | 12:33 |
| ogra | (if it exists) | 12:33 |
| lool | markos_: Yes | 12:33 |
| ogra | though there is likely no XM docs yet since XM isnt sold yet | 12:33 |
| lool | markos_: We're rolling a test tarball if that makes testing easier for you | 12:33 |
| markos_ | cool | 12:36 |
| === fta_ is now known as fta | ||
| mythripk | lag: others: http://omappedia.org/wiki/RFCs please have a look at it and provide comments if you have any , it is for the Autodetect feature for HDMI | 13:17 |
| ogra | mythripk, could it be a higher default than 640x480 or would that break on to many screens ? | 13:21 |
| ogra | (800x600 would be a bit better for X driven distros) | 13:21 |
| lag | mythripk: That system for RFC is weird | 13:23 |
| ogra | mythripk, what also would be cool would be if custom_edid_timing could seed the available framebuffer modes (and xrandr) | 13:23 |
| ogra | lag, you mean using powerpoint ... ? :) | 13:23 |
| lag | Yeah | 13:25 |
| lag | Naff! | 13:25 |
| lag | ogra: My Maverick install falls into a initramfs shell | 13:26 |
| ogra | did you fiddle with boot.scr ? | 13:26 |
| ogra | manually i mean | 13:27 |
| lag | Yep | 13:27 |
| ogra | aha :P | 13:27 |
| lag | It's the only way I can see the screen at all | 13:27 |
| ogra | must be the kernels fault then *g* | 13:27 |
| lag | Jerk | 13:27 |
| ogra | did you update the system recently ? | 13:27 |
| ogra | flash-kernel changed a bit and expects a clear text /boot/boot.script file as input now | 13:28 |
| ogra | (which jasper now creates by default) | 13:28 |
| lag | It's the current build from last week | 13:28 |
| mythripk | ogra: it would break many screens and the only compliant resolution is 640 480 | 13:29 |
| ogra | well, if you didnt upgrade and your root=UUID line in boot.scr is still correct i dont see how you could end up in a busybox | 13:29 |
| ogra | mythripk, ok, no choice then i guess | 13:29 |
| mythripk | but it would read EDID , and set it to the timing supported by TV | 13:30 |
| ogra | lag, show me your boot.scr :) | 13:30 |
| ogra | mythripk, right, i only think about the fallback default | 13:30 |
| mythripk | so only reason why it would set 640 480 would be if EDID is not read correctly | 13:30 |
| ogra | yeah | 13:30 |
| mythripk | ogra,lag , so does the design look ok ? | 13:31 |
| ogra | yes, looks ok to me, did you look how the kms drivers do it btw ? | 13:31 |
| ogra | i guess there is a lot overlap | 13:31 |
| mythripk | kms? | 13:31 |
| ogra | kernel mode setting | 13:31 |
| ogra | it is what all distros use nowadays | 13:31 |
| ogra | i'm pretty sure there is code that reads EDID in all of them | 13:32 |
| mythripk | ogra , i shall have a look | 13:32 |
| ogra | :) | 13:32 |
| ogra | eventually we would like to have KMS working on omap4 | 13:33 |
| * ogra thinks robclark knows some background here | 13:33 | |
| ogra | as i'm not a graphics guy and only scratch the surface of such technology | 13:34 |
| robclark | gm mythripk, gm ogra | 13:34 |
| ogra | heya, morning | 13:34 |
| mythripk | gm rob, the discussion is on the redesing of HDMI edid for auto detect | 13:34 |
| robclark | ahh | 13:34 |
| * lag feels left out of robclark's gms | 13:34 | |
| mythripk | http://omappedia.org/wiki/RFCs | 13:34 |
| ogra | robclark, i was just wondering if there isnt possible overlap with KMS stuff that could be used | 13:34 |
| robclark | gm lag | 13:34 |
| robclark | probably is | 13:35 |
| lag | mg robclark :) | 13:35 |
| * lag is happy now | 13:35 | |
| sumitsemwal | gm robclark, ogra :) | 13:35 |
| ogra | heh, gm sumitsemwal | 13:35 |
| sumitsemwal | gm amitk | 13:36 |
| robclark | I suspect the gfx team will need some API for 3rd party display driver for KMS.. but I've not looked at their xf86-video driver yet.. so not sure the details of how it will work.. | 13:36 |
| robclark | (that is on my todo list for the week) | 13:36 |
| ogra | robclark, no hurry, but its probably easier to steal there than reinventing the wheel :) | 13:37 |
| robclark | indeed | 13:37 |
| === Termana_ is now known as Termana | ||
| * robclark needs coffee | 13:37 | |
| === sumitsemwal is now known as sumits | ||
| === dyfet is now known as dyfet_away | ||
| robclark | mythripk: fwiw, I think we need somehow some callback when monitor is detected... | 13:41 |
| robclark | I'm not sure if that would be exposed to userspace thru omapfb, or thru gfx driver.. | 13:41 |
| robclark | but somehow xserver needs to find out when you, for example, plugin 2nd monitor | 13:41 |
| amitk | hey sumits! :) | 13:42 |
| amitk | how are you doing? | 13:42 |
| sumits | amitk: doing good! and you? | 13:43 |
| amitk | sumits: I'm good. Good to see you on here :) | 13:43 |
| sumits | amitk: been here, mostly silently though. | 13:46 |
| amitk | sumits: I hope you've 'met' lag, mpoirier and cooloney who're spearheading the omap enablement efforts on the Ubuntu-side | 13:47 |
| === fta_ is now known as fta | ||
| sumits | amitk: have met lag, [i think have met cooloney and mpoirier at UDS?] | 13:48 |
| sumits | gm cooloney, mpoirier | 13:48 |
| markos_ | lool: the subarch/capabilities concept might be the right solution | 14:37 |
| lool | markos_: Not here, no | 14:37 |
| lool | It's an incompatible ABI, and that needs a new port | 14:37 |
| markos_ | here = ubuntu? | 14:37 |
| lool | well unless we go for Mark's proposal | 14:37 |
| markos_ | or in this case? | 14:37 |
| lool | markos_: No, here == hard float port | 14:37 |
| lool | markos_: Happy to move to #linaro BTW | 14:37 |
| markos_ | oh I see you're discussing it there? | 14:38 |
| markos_ | or not.. anyway I joined to actually follow what's going on | 14:38 |
| lool | markos_: we're discussing many things there ;-) | 14:45 |
| lool | markos_: I just dont think the new armhf port is an Ubuntu problem right now | 14:45 |
| markos_ | it isn't | 14:45 |
| lool | It's a Debian and Linaro topic mostly, so seemed sensible to move it over | 14:45 |
| ogra | lool, x-loader 1.4.4 is uploaded, next successfull image build should have it (for your qemu testing) | 14:49 |
| === dyfet_away is now known as dyfet | ||
| rsalveti | ogra: when opening armel related bugs, should just including Ubuntu armel porters and the tag armel be enough? | 14:52 |
| ogra | lag, ^^^ can you test one of the next omap3 images on your XM too ? | 14:52 |
| ogra | everything after 20100713 on http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/ | 14:52 |
| lag | ogra: I can | 14:54 |
| ogra | thanks | 14:55 |
| ogra | just want to know if it regressed | 14:56 |
| lool | ogra: Thanks | 14:57 |
| ogra | GrueMaster, seems the kernel team added some fixes to urwadahead, might be that the OOMs are fixed | 15:00 |
| ogra | *ureadahead | 15:00 |
| GrueMaster | I'll test them when I get them. | 15:00 |
| ogra | GrueMaster, https://bugs.edge.launchpad.net/ubuntu/+source/ureadahead/+bug/501715 smells like the father of ours :) | 15:02 |
| ubot2 | ogra: Error: Bug #501715 is private. | 15:02 |
| ogra | huh ? | 15:03 |
| ogra | it definately isnt | 15:03 |
| ogra | rsalveti, so looking at your code i like most of it ... | 15:20 |
| rsalveti | ogra: so, what you didn't like? :-) | 15:21 |
| ogra | rsalveti, what i dont like is that you use genex2fs even if root is used | 15:21 |
| ogra | better create an image, mount it and cp the contents | 15:21 |
| rsalveti | ogra: I decided to try only genext2fs to have just a single solution, avoiding supporting two possible paths | 15:21 |
| ogra | that will be much faster, genext2fs first allocates the full image size in ram | 15:21 |
| ogra | so it eats tons of ram for bigger images | 15:22 |
| rsalveti | ogra: yeah, I noticed that | 15:22 |
| ogra | and gets very slow | 15:22 |
| ogra | so in that case i think a second code path is a valid solution | 15:22 |
| rsalveti | ogra: that's what I realized when testing here, I thought about moving back root to the old solution also, but didn't integrate into the code | 15:22 |
| rsalveti | ogra: ok | 15:22 |
| rsalveti | ogra: I can move the root path to the old solution again, np | 15:23 |
| rsalveti | it's actually faster | 15:23 |
| rsalveti | if you get 2,3 G image, it's *much* faster | 15:23 |
| ogra | yeah | 15:23 |
| rsalveti | ogra: that's fine, I can change it here | 15:24 |
| rsalveti | ogra: any other comment? | 15:24 |
| === fta_ is now known as fta | ||
| ogra | rsalveti, the rest looks ok | 15:25 |
| rsalveti | ogra: nice, will move the root solution back to what we currently have for rootstock and send the link for you to review again | 15:26 |
| ogra | great | 15:28 |
| === bjf[afk] is now known as bjf | ||
| lag | <ogra> lag, ^^^ can you test one of the next omap3 images on your XM too ? | 16:20 |
| lag | ogra: Crashes and burns | 16:20 |
| === XorA is now known as XorA|gone | ||
| ogra | lag, <ogra> everything after 20100713 on http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/ | 16:28 |
| ogra | :P | 16:28 |
| ogra | asac, i'm planning to add a call to "/usr/lib/gdm/gdm-set-default-session une-efl" to jasper (only if the .desktop file for that session exists) so that it always defaults to the 2D session if thats installed | 16:49 |
| ogra | asac, any objections ? | 16:50 |
| prpplague | ogra: is usbfs no longer available with ubuntu 10? | 16:58 |
| ogra | prpplague, thats obsolete since two years or so ?!? | 16:58 |
| lag | ogra? | 16:58 |
| ogra | lag, i dont care about todays image :) | 16:59 |
| prpplague | ogra: problem is openocd uses usbfs | 16:59 |
| ogra | lag, only about future images, after 20100713 | 16:59 |
| * lag tuts | 16:59 | |
| ogra | prpplague, fix it to work with something more recent than 2.6.18 then :) | 17:00 |
| ogra | (me is exaggerating, i dont know the exact version when usbfs vanished, but its quite a while ago) | 17:00 |
| prpplague | hehe, or just use fedora, hehe | 17:00 |
| lag | I've had OpenOCD work on later kernels than 2.6.18 | 17:00 |
| prpplague | lag: yes it works fine with later kernels, just needs to have usbfs turned on | 17:01 |
| * prpplague can use openocd and usbfs with ubuntu 9 | 17:01 | |
| lag | On the debugging machine? | 17:01 |
| === hrw is now known as hrw|gone | ||
| lag | prpplague: Do you have an openocd.cfg that works with OMAPx | 17:03 |
| prpplague | lag: with omap3, yes, see the beagle openocd page on elinux | 17:04 |
| lag | I don't know where these places are | 17:04 |
| lag | Link! | 17:04 |
| ogra | prpplague, heh, that means you used a non ubuntu kernel | 17:04 |
| lag | Googled it | 17:04 |
| ogra | so dont say you used usbfs with ubuntu 9 :) | 17:05 |
| prpplague | ogra: i did a straight ubuntu install | 17:05 |
| ogra | how, we only started supporting omap in lucid | 17:05 |
| prpplague | ogra: hunh? | 17:06 |
| * prpplague is refering to x86 ubuntu install | 17:06 | |
| ogra | ah | 17:07 |
| ogra | i thought omap3 | 17:07 |
| prpplague | ogra: openocd is a jtag utility to debug ARM devices | 17:09 |
| ogra | prpplague, if the ubuntu package doesnt work in ubuntu because of usbfs that definitely deserves a bug | 17:09 |
| prpplague | hmm, don't know if there is an ubuntu package for it | 17:10 |
| * prpplague looks | 17:10 | |
| ogra | there is a debian one since ages, so i'd expect the ubuntu package to exist as long | 17:10 |
| prpplague | ogra: i'll have a look this evening, but from past experience the one that is usually included as package(for any distro) is usually way out of date | 17:14 |
| ogra | Version: 0.3.1-1 on lucid | 17:15 |
| lag | prpplague: My device's voltage is to high to work with OMAPx? | 17:16 |
| lag | :( | 17:16 |
| prpplague | lag: what jtag device do you have? | 17:17 |
| lag | Amontec Tiny | 17:17 |
| lag | 2.8v -> 5vv | 17:17 |
| prpplague | ahh | 17:17 |
| prpplague | lag: should have purchased a flyswatter, hehe | 17:17 |
| prpplague | lag: *cough* | 17:17 |
| lag | It wasn't about when I bought this | 17:18 |
| lag | And dev-boards weren't so weak ;) | 17:18 |
| prpplague | lag: actually i released the flyswatter before the amontec tiny was release | 17:18 |
| lag | Really? | 17:19 |
| prpplague | indeed | 17:19 |
| lag | How long has the Flyswatter been around? | 17:19 |
| * prpplague checks the actual dates | 17:20 | |
| lag | prpplague: Do you do work for? | 17:21 |
| prpplague | lag: TinCanTools but i am currently contracted out to TI | 17:22 |
| prpplague | lag: june 5, 2007 was the release date for the flyswatter | 17:22 |
| lag | And for Amontec? | 17:22 |
| lag | I think I've had it ~3-4 years | 17:22 |
| * lag checks | 17:23 | |
| prpplague | the earliest entry i see is august of 2007 | 17:26 |
| prpplague | i know they had the amontec jtagkey but i didn't think they released the tiny until later | 17:26 |
| prpplague | lag: ahh i stand corrected | 17:28 |
| prpplague | lag: looks like the jtagkey-tiny was released in nov 2006 | 17:28 |
| davidm | lag, do you want a flyswatter? | 17:29 |
| davidm | prpplague, do you think I can get a flyswatter by Thursday if I order today? | 17:30 |
| prpplague | davidm: yea, should be able to | 17:30 |
| davidm | OK thanks | 17:31 |
| prpplague | davidm: it will ship today most likely | 17:31 |
| prpplague | davidm: and since you are in the dfw are it should arrive pretty quick | 17:31 |
| davidm | OK let me run this down, with my kernel folks and then I'll place an order if they want them | 17:31 |
| prpplague | davidm: dandy | 17:31 |
| === amitk is now known as amitk-afk | ||
| prpplague | davidm: grab some trainer boards as well hehe | 17:32 |
| davidm | I just got in a Zippy2 so that should be good | 17:32 |
| davidm | lag, mpoirier do you need flyswatters? | 17:37 |
| mpoirier | flyswatters ? | 17:38 |
| ogra | to splat bugs :) | 17:38 |
| davidm | http://www.tincantools.com/product.php?productid=16134 | 17:38 |
| davidm | Jtag for beagle | 17:38 |
| mpoirier | haven't looked at it - hold on. | 17:38 |
| robclark | prpplague / davidm: chris or myself could probably carry to prague if shipping is not fast enough to reach you before you leave (just fyi) | 17:38 |
| prpplague | davidm: make sure you order the BeagleBoard adapters as well | 17:39 |
| davidm | prpplague, yea, it's in my shopping cart now, I'll commit if I get a go ahead from mpoirier and/or lag | 17:40 |
| prpplague | okie dokie | 17:40 |
| ogra | asac, did you see my ping above wrt default gdm session ? | 17:42 |
| lag | I would love to have a Flyswatter | 17:47 |
| lag | My Amontec Tiny is to manly for OMAP | 17:47 |
| * ogra just uses bugspray | 17:47 | |
| === fta_ is now known as fta | ||
| === zyga is now known as zyga_ | ||
| prpplague | davidm: rusty at TCT is ready to ship your flyswatters when you are ready | 18:12 |
| === fta_ is now known as fta | ||
| === fta_ is now known as fta | ||
| lag | davidm: Did you see my comment? | 18:42 |
| davidm | lag nope | 18:43 |
| === robclark_ is now known as robclark | ||
| === fta_ is now known as fta | ||
| === zyga is now known as zyga_ | ||
| === fta_ is now known as fta | ||
| prpplague | davidm: you get your flyswatters ordered? | 20:34 |
| davidm | prpplague, the guys decided there was no rush so I'll place a standard order while I'm overseas and time delivery for my return. | 20:35 |
| prpplague | davidm: ahh np | 20:35 |
| loluengo | hi everyone! | 20:52 |
| === zyga__ is now known as zyga | ||
| loluengo | hello | 21:26 |
| loluengo | i have a noob question | 21:26 |
| loluengo | does ubuntu on arm need somthing like a screen to work? | 21:27 |
| loluengo | can i use it as an OS over a UART terminal? | 21:28 |
| loluengo | (i mean a console-only system) | 21:28 |
| GrueMaster | Yes, you can. What hardware are you working with? | 21:30 |
| loluengo | i haven't defined my hardware yet | 21:33 |
| loluengo | but looking to get an evaluation kit for an ARM920T micro | 21:35 |
| rsalveti | loluengo: just pay attention on what board you want to get if you want to test ubuntu on it | 21:37 |
| GrueMaster | Just be aware that Ubuntu lucid+ images only support Armv7 | 21:37 |
| rsalveti | karmic supports armv5, if that's enough for you | 21:38 |
| rsalveti | you can use openembedded if ubuntu doesn't run on your board, but it's quite different | 21:38 |
| GrueMaster | Actually, karmic is armv6+vfp. | 21:45 |
| loluengo | and how can i know which "V" is the board i'm looking? | 21:46 |
| GrueMaster | The arm version. If at all possible, I would recommend something with Cortex-A8 or A9 as they are the latest and will be the best supported. | 21:47 |
| GrueMaster | What is your goal for this project? | 21:47 |
| rsalveti | GrueMaster: oh, right | 21:47 |
| rsalveti | and depending on the price the beagleboard could be the best choice for you | 21:48 |
| rsalveti | it's fast, supported and not that expensive | 21:48 |
| GrueMaster | That was going to be my suggestion as well, although personally I would wait for the BeagleXM. Double the memory, faster, built in ethernet, some other features. | 21:49 |
| GrueMaster | And not much more expensive. | 21:49 |
| rsalveti | yeah, better option | 21:50 |
| rsalveti | loluengo: you can get the correct arm version of your cpu at http://en.wikipedia.org/wiki/ARM_architecture | 21:50 |
| rsalveti | take a look at the big table | 21:50 |
| loluengo | ok | 21:52 |
| loluengo | hmm i hadn't heard of BeagleBoard | 21:52 |
| GrueMaster | It has been around for a while, so most of the kinks have been worked out. | 21:53 |
| loluengo | what do you think of this board? | 22:00 |
| loluengo | http://www.olimex.cl/product_info.php?products_id=207 | 22:00 |
| loluengo | is it a good one to get started with ubuntu on ARM? | 22:00 |
| GrueMaster | It looks rather old. 200mhz? 32M sdram? | 22:04 |
| GrueMaster | Checkout http://beagleboard.org | 22:04 |
| loluengo | oh... i see | 22:05 |
| rsalveti | loluengo: checkout beagleXM | 22:06 |
| rsalveti | is much much better than this one :-) | 22:06 |
| GrueMaster | Should be about the same cost (if I am translating the currency correctly). | 22:06 |
| loluengo | the xm is usd 180 on digikey | 22:12 |
| loluengo | but not available yet | 22:12 |
| GrueMaster | It should be shipping sometime around EOM. | 22:12 |
| loluengo | yes... | 22:15 |
| loluengo | i think i'll wait for then | 22:15 |
| loluengo | and then start trying ubuntu on ARM :D | 22:15 |
| rsalveti | nice :-) | 22:15 |
| loluengo | does anyone know the minimum system requirements for running ubuntu on arm? | 22:58 |
| rsalveti | loluengo: lucid+ requires you an armv7 | 23:00 |
| rsalveti | and you should have at least 256 of ram, but 512 would be much better | 23:00 |
| rsalveti | if you want the desktop experience (like netbook) | 23:01 |
| loluengo | i just need a console | 23:04 |
| loluengo | 256 mb of ram shouls be enough? | 23:04 |
| loluengo | *should* | 23:04 |
| rsalveti | yep | 23:04 |
| rsalveti | I'm running ubuntu on my beagle with 128, but without graphic, just as a server | 23:05 |
| loluengo | ok | 23:11 |
| loluengo | and how much of flash memory do you use for the system image? | 23:12 |
| rsalveti | for minimal I guess it goes around 256, but 512 would be the recommended one for a usable system | 23:13 |
| rsalveti | but I'm running my beagle with external sd cards | 23:13 |
| loluengo | aaa ok @rsalveti | 23:28 |
| loluengo | you boot your system from the sd card? | 23:28 |
| loluengo | and the ram, is on chip? or on board? | 23:29 |
| rsalveti | loluengo: yep, the boot loader loads the kernel from the sd and put it as the root fs | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!