| danes | hello | 01:20 |
|---|---|---|
| danes | is it possible to install windows server on a pogoplug? | 01:20 |
| danes | is there any tutorial? | 01:20 |
| danes | I tried archlinux but I find it difficult as I am not familiar with the commands as I am with ubuntu | 01:21 |
| infinity | danes: Why are you asking about Windows Server here? :P | 01:24 |
| danes | sorry, I meant ubuntu server my bad | 01:24 |
| infinity | Anyhow, we (a) don't have kernels for them, and (b) a quick google search tells me they're v5 devices, we only support v7. | 01:25 |
| infinity | Debian's userspace would likely work for you. | 01:25 |
| danes | :( | 01:25 |
| scientes | danes, debian has an installer and kernel | 01:25 |
| infinity | (But again, no kernels, so you'd have to use the one provided by the manufacturer) | 01:25 |
| scientes | infinity, not true | 01:26 |
| infinity | scientes: Oh, Debian ships a kernel for them? I stand corrected. | 01:26 |
| scientes | http://www.cyrius.com/debian/kirkwood/sheevaplug/ | 01:26 |
| infinity | Pogo is just a rebraded sheeva? | 01:26 |
| scientes | AFAIK | 01:26 |
| infinity | rebranded, even. | 01:26 |
| scientes | at least the original was | 01:26 |
| infinity | Ahh, yeah. | 01:27 |
| scientes | except it doesn't neccicarily come with the JTAG board | 01:27 |
| scientes | for the serial port | 01:27 |
| infinity | No idea what the newer ones might be, but /proc/cpuinfo from a running system would be helpful. | 01:27 |
| infinity | danes: So, yeah. Debian/armel would be your best bet. | 01:27 |
| danes | thanks :) | 01:28 |
| === heathkid|2 is now known as heathkid | ||
| scientes | danes, see the bottom of this page: http://www.cyrius.com/debian/kirkwood/sheevaplug/plugs.html | 01:29 |
| scientes | it is the sheevaplug, but lacks the jtag board | 01:29 |
| scientes | so you can't safely change the kernel | 01:29 |
| scientes | even if you can get root | 01:29 |
| danes | scientes, infinity thanks guys (y) | 01:29 |
| danes | well, I have archlinux running on it | 01:29 |
| scientes | well the only reason its listed as "unsupported" is if you dont have access to the serial port/u-boot | 01:30 |
| benn | hi,all. Does anybody know to know the version of armcc ? | 05:35 |
| benn | how I can know the version of armcc ? | 05:35 |
| scientes | benn, you mean gcc for arm? | 05:36 |
| benn | scientes: I want to know the version of armcc in realview | 05:37 |
| benn | scientes: but I cannot find any option like '--version' or '-V' | 05:37 |
| scientes | i don't know what armcc is | 05:38 |
| benn | and somebody ask me that whit is armcc v2.0 | 05:38 |
| benn | the compiler provided by arm | 05:38 |
| scientes | just use the linaro toolchain in ubuntu | 05:39 |
| scientes | gcc or gcc-arm-linux-gnueabihf | 05:39 |
| benn | We are using linaro gnu toolchain. I asked this question just because somebody ask me that what is armcc v2.0 ? | 05:40 |
| scientes | i have no idea | 05:40 |
| benn | scientes: okay. thanks | 05:40 |
| scientes | clang is version 3.1, and gcc is version 4.6/4.7 | 05:42 |
| aum__ | Hello everyone, i have installed Pre-Installed OMAP/OMAP4 ubuntu 12.04 on begalboard its working fine. Now i have a sensor driver which compiles fine with normal gcc but when i insert it says - invalid kernel module. | 06:36 |
| aum__ | i know, i have to cross compile it, can anyone tell me how to cross compile it... | 06:37 |
| aum__ | please do suggest me how to install that driver. | 06:41 |
| aum__ | is there any other channel to discuss this kind of topic ? | 06:42 |
| scientes | aum_ goes so fast | 06:52 |
| LetoThe2nd | aum__: why crosscompile if you have ubuntu in place.. just compile on your beagle. | 07:03 |
| scientes | aum__, oh hes back.... you don't need to cross compile, and you have to use the same version of the kernel to compile against, otherwise the special string in the module wont match | 07:08 |
| aum__ | LetoThe2nd, in that pricompiled image the is no arm specific compiler. normal gcc compiler compiles it though kernel rejects it to insert. | 07:16 |
| LetoThe2nd | aum__: apt-get build-essential. done. | 07:17 |
| aum__ | scientes, can you please elaborate the process... should i compile it on begalboard itself or on another x86 desktop.? | 07:18 |
| aum__ | LetoThe2nd, i do have normal x86 gcc compiler which is not arm specific compiler | 07:18 |
| LetoThe2nd | aum__: i doubt that *on* your beagleboard. | 07:18 |
| LetoThe2nd | aum__: just log into the beagle, do apt-get install build-essential, compile like you would on your desktop. | 07:19 |
| aum__ | LetoThe2nd, thats what i did but the kernel rejects it to insert. | 07:20 |
| LetoThe2nd | then the module does not fit the kernel and you have to go hunting why it doesn't, instead of talking about crosscompile magic. | 07:20 |
| vaibhav_ | aum__ even i have same problem , i m trying to compile a kernel module for arm but compilation terminates with error "scripts/recordmcount: not fount" | 09:18 |
| vaibhav_ | i have tried to generate recordmcount using "make ARCH=arm CROSSCOMPILE=arm-linux-gnueabi- prepare " but it still not working | 09:21 |
| === doko_ is now known as doko | ||
| djszapi | ogra_: ping | 11:30 |
| djszapi | do you think there is an available hardware acceleration (3D, gfx) for embedded boards like the raspberry pi in case Linux? | 11:31 |
| === zyga is now known as zyga-food | ||
| === jkridner_ is now known as jkridner | ||
| === zyga-food is now known as zyga | ||
| ogra_ | djszapi, no idea, we dont support RPi, ask in an RPi channel | 13:06 |
| janimo | ogra_, are you having nightmares involving RPi already ? | 13:43 |
| ogra_ | lol | 13:43 |
| ogra_ | no, my current nightmares revolve more around flash-kernel currently | 13:43 |
| janimo | at one point you'll realize it's easier to bootstrap an RPi image than telling people it's unsupported :) | 13:43 |
| ogra_ | haha | 13:44 |
| janimo | what's flash-kernel doing that's nasty? | 13:44 |
| janimo | I finally went with modifying the precise version after talking to you last time. Works fine on the transformer | 13:44 |
| janimo | I may look at how the quantal version needs changing | 13:44 |
| janimo | ogra_, where do you think default bootcfg files for abootimg (and maybe similar ones for other bootloader tools) should be provided? Would flash-kernel itself not be a good container for them to have all board specifics in one package? | 13:45 |
| ogra_ | f-k 3.0 doesnt use any input config files anymore | 13:46 |
| ogra_ | you have to use abootimg directly on the boot partition to change anything | 13:46 |
| ogra_ | it doesnt currently support that for any bootloader btw | 13:47 |
| ogra_ | fo u-boot where we just switched to uEnv.txt and preEnv.txt i actually plan to store the cmdline in /etc/default/flash-kernel ... if you think we need something like that for abootimg too, we can indeed add it | 13:48 |
| janimo | ogra_, we need something like that for abootimg right? In case the user would like to change a kernel parameter (console, rootfs) they should be able to do it just like with grub | 13:55 |
| ogra_ | well, we could also just document how to do it with abootimg | 13:55 |
| janimo | ogra_, also something more generic than 'copy to this device' may be needed. On the transformer you actually copy the bootimg to a certain offset on the mmc | 13:55 |
| ogra_ | i think thats the debian approach | 13:56 |
| janimo | as the boot partition is hidden | 13:56 |
| ogra_ | but yeah, i would pretty much like to have a generic place | 13:56 |
| janimo | ogra_, so a kernel update would extract the bootimg and update the initrd and zimage in it and reuse the bootimg? | 13:56 |
| ogra_ | thats what it does on ac100 currently | 13:56 |
| janimo | the bootimg.conf I mean | 13:56 |
| ogra_ | the cmdline is set at install time and f-k doesnt touch it | 13:57 |
| janimo | I thought I saw it use /boot/bootimg.conf for the ac100 | 13:57 |
| janimo | on precise | 13:57 |
| ogra_ | with the pre-3.0 f-k | 13:57 |
| ogra_ | 3.0 completely changed | 13:57 |
| ogra_ | it doesnt generate boot.scr either anymore | 13:57 |
| ogra_ | only updates uImage uInitrd | 13:58 |
| janimo | any rationale for not supporting this,is it by design or just new codebase and noone hit this yet? | 13:58 |
| ogra_ | i think that was by design ... | 13:58 |
| ogra_ | which doenst mean we cant improve it ;) | 13:58 |
| ogra_ | as i said, for u-boot i plan to go with /etc/default/flash-kernel | 13:58 |
| janimo | well I wonder what the rationale was, it may be something I did not think of | 13:59 |
| ogra_ | working on this over here atm | 13:59 |
| ogra_ | janimo, ask lool | 13:59 |
| ogra_ | he designed it that way | 13:59 |
| janimo | if we can freely diverge from debian it may not be much benefit for them rearchitecting it carefully :) | 13:59 |
| ogra_ | with the new uEnv/preEnv.txt stup in u-boot its just a cat $cmdline >$preEnv.txt ... i would like to have a similar simplicity in abootimg | 14:00 |
| ogra_ | well, we already diverted 17 versions from debian | 14:00 |
| ogra_ | and beyond things like highbank/armada support, i dont expect them to take many of tehse changes | 14:01 |
| lool | ogra_, janimo: Essentially the idea was to live with static boot scripts as much as possible | 14:04 |
| lool | generally flash-kernel lacks a range of functions for setting the cmdline, multiple kernels, and allowing the end-user to change these at boot time | 14:05 |
| janimo | lool, to avoid bricking and support issues? | 14:05 |
| lool | janimo: generally keeping it simple stupid, yes | 14:05 |
| janimo | if defaults are simple that should work no? While allowing those who need it override the actual boot files | 14:05 |
| lool | janimo: It's to avoid multiple code pathes | 14:06 |
| lool | many combinations of options | 14:06 |
| lool | also, handling of the cmdline is quite complex to do in a generic way | 14:06 |
| lool | In Ubuntu, we only face U-Boot, but then some platforms might be using other bootloaders; then do you express the fact that some config items don't work on certain platforms? | 14:07 |
| janimo | I am not aware of the wider set of scenarios flash-kernel is used in. On the ac100/abootimg case I do not see multiple codepaths, just a way of telling what goes into the image - every image. With a sane default and the option of editing the file thus overriding it | 14:07 |
| lool | how do you deal with cmdline that might be set in U-Boot environment | 14:07 |
| ogra_ | well, our discussion revolves around abootimg :) | 14:07 |
| janimo | really like grub.cfg | 14:07 |
| lool | then there's also what do you offer in terms of cmdline: override, append, prepend, everything? | 14:07 |
| lool | some bootloaders hardcode root= in their environment | 14:07 |
| ogra_ | same thing as grub does | 14:08 |
| janimo | override would be the most commonly used I'd say | 14:08 |
| lool | janimo: Yup abootimg is fairly clean there | 14:08 |
| ogra_ | /etc/default/flash-kernel carries a single var that has the cmdline | 14:08 |
| janimo | it is much simpler to use than uboot | 14:08 |
| lool | there's also a default kernel cmdline in the kernel itself | 14:08 |
| robher | lool, ogra_: in case you weren't aware u-boot supports syslinux menus now | 14:08 |
| ogra_ | robher, nice ! | 14:09 |
| lool | robher: Awesome, I've followed the email thread where missing features were discussed as well | 14:09 |
| lool | robher: and the bug | 14:09 |
| ogra_ | but not a level of complexity i want to play with right now | 14:09 |
| lool | I lack a bit of time to discuss this here | 14:09 |
| lool | but I'd like to discuss a new project with you folks | 14:09 |
| lool | it's a bit early to discuss it though | 14:09 |
| janimo | lool, np. thanks for your input anyway | 14:09 |
| lool | Linaro is working on a GRUB port to U-Boot | 14:10 |
| janimo | looks like for abootimg we could do what ogra suggests without complicating the code | 14:10 |
| lool | This would not only change the game for the flash-kernel flexibility issues I mentioned earlier | 14:10 |
| lool | (basically flash-kernel would just be used to write a grub payload, then the usual grub configuration interface would apply) | 14:10 |
| lool | it would also change the game around the syslinux/pxelinux compatibility problems | 14:11 |
| robher | bugs and lacking features can be fixed... | 14:11 |
| lool | Instead of doing pxelinux "emulation", we'd be using grub's netboot support and making sure that e.g. cobbler generates grub config giles | 14:11 |
| lool | robher: Yes, but consider that we'll be using grub on top of uefi | 14:11 |
| lool | and that uefi's PXE support (or basically any plain PXE implementation) isn't enough for booting a kernel with an initrd and cmdline etc. | 14:12 |
| lool | Ok; now that I've launched this grenade, I'll go prepare a meeting :-) | 14:13 |
| lool | robher: I still think that it's great that we have this pxelinux "emulation" right now | 14:13 |
| lool | robher: it's definitely a great way of delivering the feature for U-Boot platforms | 14:13 |
| robher | so what's the pxelinux solution in an ARM UEFI world? | 14:14 |
| lool | robher: above, I'm proposing not to use pxelinux | 14:15 |
| lool | robher: but rather grub's script/menu config format, and implement support for that in e.g. cobbler or other places generating pxelinux ocnfigs | 14:16 |
| lool | your DHCP server would server a pre-built grub for u-boot or grub for uefi ARM binary that would optionally bundle a config (or the config can be read from the network), the config would show a menu allowing to chose between multiple kenrel + initrd images loaded from the network | 14:16 |
| lool | (I've also looked at the syslinux source code to check how much effort it would be to port the actual code to ARM and it would be crazy -- 12 kLOC of x86 assembly) | 14:17 |
| lool | (reimplementing the support for the format was definitely the right thing for a pragmatic U-Boot implementation) | 14:18 |
| robher | does grub do tftp/http loading? | 14:18 |
| lool | robher: not http | 14:18 |
| lool | Another option is to write another pxelinux/syslinux config parser as an UEFI application and/or as a GRUB command | 14:19 |
| lool | but since GRUB EFI is likely to be what distros use on installed systems anyway and since GRUB has a config / script / menu language already, I personally it is a bit more natural to just generate GRUB configs | 14:20 |
| lool | need to run, bbl | 14:20 |
| lilstevie | speaking of grub-efi is that working with uefi on arm yet? | 14:44 |
| janimo | ogra_, so regarding abootimg. If you add seek and bs args to the dd invocation it will be reusalbe on the tf101 too with non-zero seek offset :) | 14:59 |
| ogra_ | janimo, dd invocation ? | 15:03 |
| ogra_ | there is no dd anymore | 15:03 |
| ogra_ | just a single abootimg call | 15:03 |
| janimo | ogra_, hmm. Not good for the tf then. | 15:03 |
| janimo | Oh yes, I remember you directly pass the block to abootimg | 15:03 |
| janimo | instead of using a tmpfile as in precise | 15:03 |
| ogra_ | i dont :) | 15:03 |
| ogra_ | my code used dd and created an image first ;) | 15:04 |
| janimo | yes | 15:04 |
| lilstevie | janimo, actually there is still a way of using it | 15:04 |
| ogra_ | thats all debians reworking that dropped this | 15:04 |
| janimo | that woudl have worked for the tf | 15:04 |
| janimo | lilstevie, which one? | 15:04 |
| lilstevie | janimo, there is a hacked up driver which exposes boot/recovery | 15:04 |
| janimo | lilstevie, ah indeed you mentioned that, and I forgot | 15:04 |
| lilstevie | but with something like syslinux or grub on u-boot I could see that being irrelevant anyway | 15:05 |
| janimo | that would be good. Although maybe risky to expose those, especially recovery | 15:05 |
| lilstevie | just repartition with nvflash for initial install | 15:05 |
| janimo | lilstevie, syslinux or grub on uboot are way in the future I guess | 15:05 |
| lilstevie | janimo, we currently expose them in android on the tf201 in cm | 15:05 |
| janimo | certainly not on existing hardware | 15:05 |
| ogra_ | waaaay in the future | 15:05 |
| lilstevie | hm | 15:06 |
| lilstevie | didn't I just read that someone cobbled syslinux menu parsing into u-boot | 15:06 |
| ogra_ | but you would need syslinux first :) | 15:07 |
| lilstevie | ah | 15:07 |
| lilstevie | ok I missed that, I thought it handled that part | 15:07 |
| lilstevie | that could be nasty | 15:07 |
| lilstevie | how is grub looking with uefi on arm? same deal? | 15:08 |
| ogra_ | janimo, anyway, my current task is /etc/default, if you want changes to abootimg handling, i'll happily take patches (or you just upload them yourself :) ) | 15:08 |
| janimo | lilstevie, having the code that exposes those extra partitions would be nice. Although it may confuse existing tools that expect certain partition naming order | 15:08 |
| ogra_ | as long as you dont break ac100 handling, feel free to change it over | 15:08 |
| lilstevie | janimo, it tacks them to the end | 15:09 |
| lilstevie | so no, it wouldn't | 15:09 |
| janimo | ogra_, sure. I was saying this so you can take it into account now. If ac100 still used dd, we would not need an extra snippet for transformer, as it would be just different parameters to the same method | 15:09 |
| janimo | lilstevie, good | 15:09 |
| lilstevie | janimo, but more importantly tf101 gets nvflashed, which it is easy to just move the partitions to the end, rather than using hacked up drivers | 15:10 |
| janimo | maybe the kernel solution is better | 15:10 |
| ogra_ | janimo, right, i dont mind either way | 15:10 |
| ogra_ | something like tegrapart would surely be betterm yeah | 15:10 |
| janimo | lilstevie, not all tf can be nvflashed. Mine which is a tf101g cannot | 15:10 |
| lilstevie | janimo, well it can | 15:10 |
| lilstevie | just nobody has put the effort in | 15:10 |
| janimo | well, cannot at the moment, which is what I care about :) | 15:11 |
| * lilstevie is still waiting for someone to try and figure out how the nvflash stuff on the tf201 works and port it to other devices | 15:11 | |
| janimo | lilstevie, so that patch is like ac100's tegrapart? | 15:18 |
| lilstevie | janimo, not exactly | 15:23 |
| ogra_ | why | 15:23 |
| lilstevie | it hooks into the gpt driver | 15:23 |
| Limer_ | Hello, while trying to boot ubuntu-server on my pandaboard for the first time i get a blank screen. I can switch to tty2 and get a password prompt, but i don't know the password as it has not been set yet. I would really appreciate some pointers as to what might be wrong. | 18:49 |
| === Limer_ is now known as Limer | ||
| GrueMaster | Limer: The server images need to run through the install setup first, which defaults to the serial console. | 19:03 |
| GrueMaster | That will set your locale, network, system name, and user info. | 19:03 |
| Limer | Is there a way to reach the setup without the need of a serial cable? | 19:07 |
| infinity | Limer: If you remove the console= bits from the kernel command line, it'll stop trying to do it on serial. | 19:22 |
| === Quintasan_ is now known as Quintasan | ||
| Limer | But in order to remove those i need to make a new image? It is unfortunate that the normal image isn't installable without a serial cable. | 19:52 |
| Quintasan | infinity: Noob question, bought the damn serial cable, can't connect to the iMX though. First some message with "Broken stream" flashes and then I get "Could not find PTY". I used sudo screen /dev/ttyUSB0 115200 | 19:55 |
| infinity | Quintasan: And then screen exits? | 19:56 |
| Quintasan | Yes | 19:56 |
| infinity | Quintasan: If so, that's a problem with the cable/driver/host machine, not with the board. | 19:56 |
| infinity | Quintasan: (plugging in a USB/RS-232 dongle and firing up screen on the device will "work" regardless of if you attach it to something on the other end) | 19:56 |
| Quintasan | hurr | 19:57 |
| Quintasan | infinity: http://wklej.org/id/806837 | 19:57 |
| infinity | Or permissions. | 19:57 |
| Quintasan | I plugged it in and it got discovered | 19:57 |
| Quintasan | First it didn't want to eunumerate for some reason | 19:57 |
| infinity | Permissions will/can also be an issue. We don't add the default user to the "dialout" group, which is required to access that device. | 19:58 |
| infinity | "sudo adduser $me dialout" and log out/in, should that seem to be an issue for you. | 19:58 |
| Quintasan | Yeah | 19:59 |
| Quintasan | Not in dialout | 19:59 |
| Quintasan | uhh | 20:06 |
| Quintasan | infinity: http://wklej.org/id/806855 | 20:06 |
| Quintasan | Any idea why do I get that? | 20:07 |
| Quintasan | It happens everytime I copy big stuff to sdcards | 20:07 |
| Quintasan | like images | 20:07 |
| * Quintasan should probably ask in #ubuntu-kernel | 20:07 | |
| infinity | Your SD cards suck. Or your reader. Or it's a kernel bug. | 20:08 |
| infinity | Pick one or more of the above, season to taste. | 20:08 |
| Limer | Time to give up on this and buy a serial-cable tomorrow ;) | 20:09 |
| Quintasan | infinity: Oh, ok. It's class 4 SD card | 20:09 |
| scientes | i've had really bad luck with kingston brand sd | 20:10 |
| scientes | Quintasan, yeah you need class 10 | 20:10 |
| infinity | If you're going to rewritre frequently, I swear by Lexar (or, in fact, anything targetted at photography professionals). | 20:10 |
| infinity | If you're writing it once, pretty much any junk will do. | 20:10 |
| Quintasan | Will sudo screen /dev/ttyUSB0 115200 suffice to connect or I need to invoke some other black magic? | 20:11 |
| Quintasan | bah | 20:11 |
| infinity | Quintasan: That'll do. No need for the sudo if you're in dialout, mind you. | 20:11 |
| Quintasan | Stil the same error | 20:11 |
| Quintasan | So my cable is crap | 20:12 |
| Quintasan | Ha ha, | 20:12 |
| Quintasan | Now it won't eunumerate | 20:12 |
| Quintasan | infinity: THE WHOLE ARM BUSINESS IS IN CONSPIRACY AGAINST ME | 20:17 |
| * Quintasan panics | 20:17 | |
| Limer | I feel the same way right now ;) | 20:17 |
| Quintasan | Limer: What, another proud owner of iMX53? | 20:18 |
| Quintasan | Or something worse? | 20:18 |
| Limer | I am using a pandaboard, so things should work. However they don't. | 20:19 |
| Quintasan | Logic. | 20:19 |
| infinity | Limer: Your issue is just that the server image defaults to serial out, as we said. | 20:19 |
| Quintasan | ARM = Automatically Rebooting Machine. | 20:19 |
| infinity | Limer: You can change the boot.scr and fix that. | 20:19 |
| Limer | if i change anything in boot.scr it refuses to boot at all | 20:20 |
| infinity | Limer: Well, yes. boot.scr has a magic binary header on it. | 20:20 |
| Limer | What is this black magic? How can i make a boot.scr that works? | 20:21 |
| infinity | Limer: Strip off the binary header, edit the text to be what you need, save that as, say, boot.script, then: | 20:21 |
| infinity | mkimage -A arm -T script -C none -n "Boot Image" -d boot.script boot.scr | 20:21 |
| infinity | mkimage is in the u-boot-tools package. | 20:22 |
| Limer | wow, thanks a lot! | 20:31 |
| biker_rat | Why does there seem to be a limited number of video modes availible in the linux images for my MK802? | 21:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!