[00:01] so beagle boards run ubuntu ... how does one take a beagleboard and begin putting specific code on it? is it a USB connection? [00:01] and its run in the linux environment right? [00:02] delinquentme, yeah it has a RW sd card [00:02] delinquentme, but binaries have to be compiled for ARM, x86 binaries wont run [00:03] and this can be written in any language that can compile to ARM? [00:03] correct [00:03] or any interpreted language, that has interpreter support on ARM [00:04] and how about the operation ... that code simply polls over and over ? [00:04] and to be apecific armv7, which is what ubuntu targets [00:04] delinquentme, linux is "tickless" [00:04] its running *inside* the ubuntu operating system right? much like any language I run on my laptop ubuntu system [00:04] so it only wakes up to meet the next deadline, if it doesn't get an interrupt [00:05] yes it is the same ubuntu you run on your laptop, but recompiled for arm [00:05] debian GNU/Linux did most of the porting work/troubleshooting [00:05] and the code would be automatically read from the SD card? [00:06] but armv7 hardfloat transition has been helped by ubuntu [00:06] delinquentme, its just ext4 filesystem like you use on your hard drive [00:06] so it has files just the same, and with the same layout [00:06] delinquentme, you can actually run the beagleboard software on your laptop, using qemu-arm [00:06] or qemu-arm-static [00:07] so If i've got a desktop which connects to the beagleboard via ethernet ... and I want the beagle to issue machine commands to MCs that branch off of it [00:08] " machine commands to MCs that branch off of it" [00:08] i have no idea what you are saying here [00:08] the beagle runs whatever compiled arm and would then issue commands via that beagleboard software to those branch MCs [00:08] you can run all the same server software on e arm that you can run on x86 [00:08] postfix, dovecot, postgresql, etc [00:09] now, the beagleboard is not the fastest arm board [00:09] basically the beagle controlling a number of attached MCs [00:09] what is a MC? [00:09] microcontroller [00:09] specifically.....? [00:09] ( sorry ) but yeah I'm trying to use the beagle to run steppers and the like [00:10] been looking at this one : http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATA_BRIEF/DM00037955.pdf [00:10] ~ 13 of those [00:10] well that has yet another arm cpu inside of it [00:11] however it has too little ram and flash to run linux [00:11] oh yeah im not trying to run linux on those [00:11] those are what controls the steppers and the sensors etc [00:11] which then geed information back to the beagle [00:11] geed = feed* [00:12] is that black on the bottom audio? [00:12] and the top usb is just the power (5v)? [00:12] "one audio DAC" yeah, audio [00:13] i think theres also a 5v in [00:14] seems to me that you use the "SWD" to communicate to it [00:15] "digital accelerometer and digital [00:15] microphone, one audio DAC with integrated class [00:15] D speaker driver, LEDs and push buttons and an [00:15] USB OTG micro-AB connector. [00:15] " [00:15] so i guess that is what it does [00:15] how to check if it can run communications over the micro usb [00:15] well since it says that all that is needed, it probably can [00:15] what do you want to do with it? [00:16] make a liquid handling robot [00:16] it has a number of modular cores [00:16] that thing seems to be audio-oriented [00:16] microphone and mono audio out [00:17] yeah I'm not really sure how the MC industry works [00:17] "digital microsoft" (does that mean it has a ADC ?) [00:17] like it can send signals and thats all I really need [00:17] i could probably go much simpler TBH [00:17] gcc supports compiling firmware IIRC [00:17] its the arm-non-gnueabi target for armv5+ [00:17] *none [00:17] but I dont have the capability to design printed circuit boards ... so i need to buy something thats already assembled [00:19] and it only has one usable button [00:19] so yeah just write come C code .. compile it with GCC stick it on a MC like that and let it poll for commands from the beagle [00:19] yeah I don't really see myself using anything other than a reset button [00:19] well, event-based would sure be nicer [00:20] delinquentme, you can do that without any MC [00:20] you can do that with a seial port [00:20] or even a usb keyboard/mouse [00:21] well for programming it I can attach it however [00:21] but yeah that board is designed for audio uses, it doesn't seem applicable for you [00:23] how does one go about finding a good board for an application? [00:23] all the IC vendors have huge lists [00:23] ( i'm kind of expecting there to be a tool like new egg where there are drop downs and I select the chips and things I want on it [00:23] freescale, marvell, broadcom [00:23] newark [00:23] and these are all programmed effectively the same way? [00:24] well im still not sure what youwant/are trying to do [00:25] arduino is pretty hot these days [00:25] true but they're also super costly [00:26] so is the beagle board [00:26] ahh yeah that might help :D .. I've got 2 steppers, 1 linear string pot, 1 linear actuator and 2 physical switches [00:26] compared to, like, the rasberri pi [00:28] delinquentme, how about this: http://www.st.com/stonline/stappl/productcatalog/app?page=productSelectorPage [00:30] oooooo [00:30] http://www.freescale.com/webapp/sps/site/application.jsp?code=APLSTEMOT [00:34] DSC ? [00:34] Digital Signal Controller [00:36] actually I should totally be able to email customer support @ these places and just be like [00:36] "this is what I need" [00:36] does u have? [00:36] also! [00:36] these are all chips .. is there a name used for the units when they're already attached to a board? [00:38] yeah ive come across that prob too [00:38] i dont really have an answer for you [00:40] haha im glad im not nuts :D [00:40] scientes, what do you do with all this coolness [00:40] specifically ubuntu arm chips? [00:41] well i actually dont have a armv7 comp yet [00:41] i only have the sheevaplug [00:41] which is armv5, running debian [00:42] but i really want a armv7, or better yet armv8 + quad core [00:42] * scientes wants to experiment with big.LITTLE too [00:42] OOo the sheevaplug [00:42] thats like mischief no? [00:42] its kinda old now [00:43] is this like PHD research scientes ? [00:44] you can basically hook that sheevaplug up to something and just let it sniff away at wireless packets [00:46] the one i have doesn't have wifi [00:47] but considering its size and power consumption that sort of use would certainly be feasable [00:47] and a good fit for the device [00:47] it also has gigabit ethernet, so you could access it remotely at high speed [02:08] configure: error: "PAM libraries not found" [02:08] how to fix ? [02:11] configure: error: "PAM libraries not found" how to fix ? [02:13] pnphi, what piece of software? [02:14] i'm building the package gdm [02:15] This error is coming from ./configure ? [02:16] no , dpkg-buildpackage -aarmel [02:16] pnphi, could be systemd-logind's pam module [02:17] try turning off systemd [02:18] dpkg-buildpackage: error: debian/rules build gave error exit status 2 [02:18] and this problem [02:19] pnphi: pastebin the full transcript [02:19] detail ? [02:25] I assume you're missing libpam-dev. [02:26] infinity: I thought dpkg-buildpackage would, like debuild, bitch about missing dependencies before getting to that point [02:26] It does. [02:26] So he's doing something silly. [02:26] And the pastbin will tell us what [02:26] But he may well either (A) have built with -d, or (B) be building sources with bad build-deps. [02:27] Nod [02:28] (When you call debuild, it's dpkg-buildpackage that's bitching; debuild is only a very thin wrapper around it) [02:58] checking for pam_start in -lpam... no configure: error: "PAM libraries not found" make: *** [debian/stamp-autotools] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 [02:59] I don't know to fix this problem [02:59] !!! [03:00] pnphi, PASTE [03:02] checking for pam_start in -lpam... no [03:02] configure: error: "PAM libraries not found" [03:02] make: *** [debian/stamp-autotools] Error 1 [03:02] dpkg-buildpackage: error: debian/rules build gave error exit status 2 [03:02] E: Failed autobuilding of package [03:03] pnphi, did you install libpam-dev? [03:04] yes [03:04] pnphi, paste dpkg -L libpam-dev [03:04] libpam0g-dev is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. [03:04] pnphi, paste dpkg -L libpam0g-dev [03:04] infinity: I realize that; I just don't remember which bits are still debuild-specific [03:06] yes [03:10] so what else ? [03:10] dpkg -L libpam0g-dev [03:10] usr/share/doc/libpam0g-dev [03:10] usr usr/share usr/share/doc usr/share/doc/libpam0g-dev usr/share/doc/libpam0g-dev/examples usr/share/doc/libpam0g-dev/examples/vpass.c usr/share/doc/libpam0g-dev/examples/modules usr/share/doc/libpam0g-dev/examples/modules/pam_secret.c.gz usr/share/doc/libpam0g-dev/examples/modules/Makefile usr/share/doc/libpam0g-dev/examples/xsh.c.gz usr/share/doc/libpam0g-dev/examples/check_user.c usr/share/doc/libpam0g-dev/examples/agents usr/s [03:10] pnphi_: http://paste.debian.net [03:11] what is it ? [03:11] pnphi_: you put your text there, hit "submit" and copy the resulting link here, rather than pasting the original text here [03:11] This is called a "pastebin", it stops us going insane [03:13] ok [03:14] paste.debian.net/163365/ [03:17] http://paste.debian.net/163366/ [03:17] Log of build and result of "dpkg -L" [03:20] checking for pam_start in -lpam... no configure: error: "PAM libraries not found" make: *** [debian/stamp-autotools] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 [03:20] specifically -lpam [03:20] there is no pam.h....doesn't -lpam require pam.h? [03:21] i don/t understand === LetoTheII is now known as LetoThe2nd === doko_ is now known as doko [09:23] ogra_, hi, which packages needed to be touched to get unity-3d gles working? nux, compiz+unity? [09:24] I'd like to to do a GLES rebuild for x86 and touch the minimum numer of packages locally [09:27] nux, unity, compiz and compiz-plugins-main [09:27] just grab the packages in precise, they are ready [09:27] you will need to change the arch checks etc [09:28] ogra_, and all of them need an extra config option passed, none do runtime detection right? [09:28] right [09:28] ogra_, thanks! [09:28] talk to alf_ for a different patch set [09:29] ogra_, for now the ones in precise are fine if they actually work with gles [09:29] iirc the new one they have in linaro can run with GL and GLES enabled [09:29] not sure when you have to select or if its automatic at all though [09:29] ogra_, ah they already hae packages for that, I'll ask him then === yofel_ is now known as yofel [11:43] infinity: ping [11:45] LetoThe2nd: pong? [11:45] infinity: ogra told me ask you: [11:45] any ideas why http://paste.pocoo.org/show/582316/ goes bi***ing about some dependency issues concerning linux-libc-dev:i386 and linux-libc-dev in a clean 12.04 chroot, and if you just re-run it, everything is fine? dependency solver problem? [11:46] LetoThe2nd: Temporary annoyance with a transition. If you add precise-proposed to your sources.list, it'll be happy. [11:46] LetoThe2nd: Should be resolved in ~5 hours when gcc-4.6 is built everywhere, and I can promote gcc and eglibc to release. [11:46] infinity: ahkay. nothing urgent, so will probably be sorted out soon? [11:46] i see, thx then. [11:46] infinity, compiz-plugins-extra (universe) is FTBFS on all arms with the new GLES compiz, should we leave it that way, or upload a package that has the arm arches dropped for final release ? (i dont think anyone ever cared in a port to GLES for these plugins) [11:47] ogra_: Ugh, really? Is it not a simple fix? [11:47] rsalveti: Hey, wake up and come be helpful. [11:48] i dont think linaro ever touched that package (not needed for unity) and afaik all GL->GLES switches need heavy patching [11:48] ogra_: Dropping the arches isn't necessary, but fixing it would be nice. [11:48] (more than just a config option) [11:48] Needs heavy patching for plugins? That seems wrong. [11:49] well, even in our normal compiz build on arm we have to disable more than half of the plugins [11:49] because the functions arent patched yet, i doubt its fixable in time for release and i also doubt linaro will ever care for these plugins [11:49] Letting it be FTBFS is fine. As you note, it's universe. [11:50] We just need to remove the stale binaries. [11:50] right, and makes SRUing a possible fix easier [11:50] And wow, compiz-plugins-main-gles2.patch is extensive. [11:50] i still try to catch alf_ or rsalveti to find out if they ever plan to fix that [11:50] right [11:50] What an awful architecture compiz is... [11:50] well, compared to the compiz patch its still small :) [11:51] The GNOME people really got this right with cogl. [11:51] well, we should just switch to Qt [11:51] unity-2d ftw [11:51] but i promised kaleo to not rave about that for a year :) [11:51] Heh. [11:52] I prefer 2d anyway. [11:52] To each their own, though. [11:52] yeah, and it shouldnt be to hard to get all the functions in that 3D has [11:52] * ogra_ completely reinstalled his ac100 this weekend from ubuntu-core [11:53] using lxde now [11:53] so much more free ram ! [11:53] (needed a reinstall to switch to hf) [11:54] using -core as a base it a big pain in the butt though ... [11:54] Well, yes. [11:54] It has no installer. :P [11:55] yeah [11:55] well, and getting the bootloader setup working by hand isnt really fun [11:55] <3 debootstrap [11:55] I'd suggest feeding core to linaro-image-tools (which works really well), but I assume they have no ac100 target. [11:55] LetoThe2nd, -core is essentially debootstrap --minbase [11:55] iirc [11:55] yeah, ac100 is spethial [11:56] ogra_: ah yea. [11:56] I don't mind my ac100 with unity-2d, but the RAM starvation does hurt. [11:56] the prob with the ac100 is to get it to a point where you can use the wlan for further install ... thats a real PITA starting from core [11:56] I had some builds failing on it because of that. [11:56] right, with lxde my system now uses 75MB with the idling desktop [11:57] ogra_: Hahaha. Yeah, my first ac100 install was from core, and involved a whole lot of wgetting and dpkg -i, and head-scratching. [11:57] thats half of what unity-2d uses [11:57] I don't really know what posessed Toshiba to only put 512MB on the thing. [11:57] adnroid [11:57] If they wanted to be competitive with crappy Atom netbooks, they all have 1G. [11:58] Hi All [11:58] i dont think that was the plan with the ac100 [11:58] Yeah, I suppose it was Android-specific. [11:58] But even Android breathes more easily with 1G. [11:58] its more like a POC of using android on netbooks [11:58] well, it is using 2.1 in the original setup ... that doesnt need much ram ... and has not many apps :) [11:59] It's the one thing I'd change about my phone, if I could (and the only reason I might look for upgrades) [11:59] anyone have detailed documentation on the architecture and packages on Ubuntu core rootfs? [11:59] hrhrhrhr [11:59] theer should be a manifest file in the download dir [11:59] Is there? [11:59] that has the packagelist [11:59] infinity, if there isnt ... it *should* :) [11:59] Oh look, I do publish the manifest. [12:00] Go me. [12:00] (there is) [12:00] fhilly, http://cdimage.ubuntu.com/ubuntu-core/daily/current/ ... [12:01] and http://cdimage.ubuntu.com/ubuntu-core/releases/ for released images [12:01] thanks ogra, I assume there is detailed information in there? [12:01] fhilly, well, there are the manifests and you can see which arches it is built for [12:02] how about rootstock? is it still maintained? [12:02] no [12:02] thanks ogra [12:02] hmm, that remonds me i should probably file a removal bug for the package [12:02] ok, if I want to get involved in the building process of the Ubuntu core rootfs, is there any specific root advised? [12:03] we use live-build (config files for that are in livecd-rootfs) to roll it [12:03] just take a look at the source of these [12:03] ogra_: I'll happily remove rootstock right now, no need for a bug. [12:03] infinity, go for it ! [12:03] ogra_: But I think you should do something about the LP project too. [12:04] yeah, i'll kill it [12:04] ok thanks a lot [12:04] or at least mark it inactive or so [12:04] there are some good code snippets in rootstock i wouldnt like to lose [12:05] (the fifo to serial interaction with qemu for example to do stuff scripted inside a VM) [12:05] well, I have tried ubuntu-core rootfs on x86, however I believe there is "sudo" package missing, as the user will not be able to install anything including "sudo" unless unlock the files system as sudo or su user [12:05] fhilly, thats on purpose [12:06] ubuntu-core is to *build* images on top (or as an easy to use base for a chroot), not actually to use it as an install base ... [12:07] sudo would be kinda useless given that there's also no user. [12:07] rootstock | 0.1.99.4-0ubuntu1 | precise/universe | source, amd64, armel, armhf, i386, powerpc [12:07] rootstock-gtk | 0.1.99.4-0ubuntu1 | precise/universe | all [12:07] infinity: one could make an alias called "medo" that root himself can use. [12:07] ogra_: ^--- That rootstock? [12:07] the typical usecase is for something like embedded IVI systems (car entertainment) where you wont even have a user account thats accessible by the ednuser [12:07] \o/ [12:07] infinity, yeah [12:08] funny, i didnt know we built it for armel/armhf ... [12:08] forgive my ignorance but can you tell me why? as in the short explanation of it, it says after you finish you can use pat-get, how can we use apt-get if we don't have sudo? I am new to community stuff and I am trying to get involve so I know I am asking too much [12:08] ok I see [12:08] ogra_: haven't you noticed all the people in #pandaboard who asked about starting from -core because the sound of the name suggested a more minimal image to them? [12:09] And it is a minimal image. [12:09] It just also has no installer. [12:09] lets say I want to build Ubuntu distro for ARM (beagle board) can I do it based on Ubuntu -core rootfs, or there is a better way of doing things? [12:09] well, it is [12:09] but you need to do a ton of things manually depending on your usecase [12:09] ogra_: Removed, should be gone in the next publisher run. [12:10] fhilly, well, i would just use one of the official beagle images from ubuntu for that [12:10] * ogra_ hugs infinity [12:10] is there any detailed documentation about it? guys I see you know everything about it, instead of me asking you, I could just read and get back to you if I have any questions [12:10] if you want a minimal install on your beagle, use the server image [12:11] see https://wiki.ubuntu.com/ARM/OMAP for instructions etc [12:12] if you want even more flexibility, use the netinstall SD card image [12:12] orga_ I am trying to get as much information as I can, as I would liek to be part of the community at one point, and contribute. it is not about the BeagleBoard only [12:12] (falsely called netboot on that wikipage) ... but nore that you nedd a network connection wired up for thet indeed [12:13] well, just hang out in this channel ... thats already a good step to being involved in the community ;) [12:13] fhilly: and, hint: tabcompletion for nicks works in any sane IRC client :) [12:14] ok thanks LetoThe2nd [12:14] it works [12:15] as a starting point for me, where can I start contributing? in terms of anything I could do? [12:15] oO( purge errors out of omappedia/elinux *duckandrun* ) [12:15] http://qa.ubuntuwire.org/ftbfs/ ... you could for example have a look at all packages that only fail on armel/armhf [12:16] or weed through launchpad and look for bugs that the ubuntu-arm team is subscribed to [12:16] then try to fix it, and report back? [12:16] if you have HW you can help testing images right before milestone (or final) releases [12:16] right [12:16] ok [12:17] I have BeagleBoard XM rev: C4 and BeagleBone [12:17] any testing procedures? [12:18] infinity, !! I started using a caching proxy and it's great! apt-cacher-ng [12:18] which year are you welcoming me into? [12:19] * ogra_ uses approx [12:20] I just picked this one as at one point in one of the mailing lists it was mentioned it more or less works out of the box [12:21] and it indeed does, besides putting a line in apt.conf [12:21] approx as well and i find it easier to configure for special cases like ports.u.c [12:21] * infinity just has a local Ubuntu and Debian mirror. [12:22] ... running on an i.MX53 [12:22] http://www.grawert.net:9999/ubuntu-ports ... :) [12:22] thats my laptop [12:22] ... uphill [12:22] (as long as i dont take it with me indeed (which i really rarely do since i have the ac100)) [12:27] how can I test the images before release? where can I get them from? can I subscribe to get notifications? [12:34] fhilly_: they're all up on the servers [12:35] fhilly_: http://cdimage.ubuntu.com/daily-preinstalled/current/ for example [12:36] LetoThe2nd: you know with which tool the images are build? live-build? [12:37] morphis: no idea. [12:37] infinity: you know how they are build? [12:38] Which images? [12:38] But yes, we use live-build to create live/preinstalled filesystems. [12:39] infinity: the images you can download from here: http://cdimage.ubuntu.com/daily-preinstalled/current/ [12:39] fhilly_, for testing you can subscribe to teh images you want to be notified about on http://iso.qa.ubuntu.com/ [12:40] morphis: live-build to create the filesystem, and then some hackery on top of that to make it bootable. [12:40] infinity: means installing system dependent files (fstab,kernel-modules, ...) [12:41] kernel modules come from the kernel package ... fstab and HW sepcific bits usually come from the installer [12:41] And creating a FAT filesystem, and populating it with a bootloader and kernel, and... [12:41] ogra_, LetoThe2nd thanks [12:41] infinity: ok [12:46] what do I have to do? just install them? do something specific? run scripts? or just work as normal? === ahs3` is now known as ahs3 [15:32] Hey! Is it okay if the daemon part of my project is started automatically by an upstart job put into the /etc/init/ folder with the ubuntu desktop version ? Is there a better interface for that like we had /etc/init/apps on Harmattan ? [15:57] i don't know to fix this problem [15:57] checking for pam_start in -lpam... no configure: error: "PAM libraries not found" make: *** [debian/stamp-autotools] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 [15:58] pnphi, just add the right dependency to your packge (or if you dont build a package, make sure to have the right -dev package installed that gives you the pam headers [15:58] ) [15:59] detail ? [15:59] djszapi, i dont know /etc/init/apps, but upstrart is surely a proper way to start daemon processes [16:00] pnphi, well, its your project, you should know what deps you need to build whatever you build there [16:00] ogra_: start on runlevel [23] or [12345] ? [16:00] so...i install deps of package [16:00] !!! [16:00] well, usually runlevels are moot anyway :) all debian and ubuntu systems default to 2 [16:01] what runlevel ? [16:01] (so [2 3<9 should be good) [16:01] err [16:01] [2 3] [16:02] dpkg-buildpackage: error: debian/rules build gave error exit status 2 [16:03] what the err ? [16:03] read your build log it should say [16:04] ogra_: runlevel 5 means for instance "Start the system normally with appropriate display manager. ( with GUI )" [16:04] djszapi, it doesnt [16:05] ogra_: http://en.wikipedia.org/wiki/Runlevel#Typical_Linux_runlevels [16:05] (nmot sure where you got that line from, but on debian based systems runlevel 2-5 are identical) [16:05] 1 is singleuser, 6 is reboot [16:07] (and 0 is halt) [16:07] read the link. [16:07] configure.ac:3: warning: AC_INIT: not a literal: http://bugzilla.gnome.org/enter_bug.cgi?product=gdm if [ -e ./Makefile.am ]; then cd . && automake-1.11 ; fi configure.ac:3: warning: AC_INIT: not a literal: http://bugzilla.gnome.org/enter_bug.cgi?product=gdm data/greeter-autostart/Makefile.am:10: `%'-style pattern rules are a GNU make extension automake-1.11: cannot open < gnome-doc-utils.make: No such file or directory make: *** [16:07] oh my god [16:07] and I have the desktop version of ubuntu on my pandaboard. [16:07] how would reading thge link change anything ? [16:07] the linux runlevels are defined in there... [16:08] no, they arent ... someone wrote up how the runlevels on his fedora box look like i guess [16:09] first of all, runlevels are moot, upstart is event based and only retains the runlevel concept for backwards compatibility ... if you develop something from scratch i would rather tie to an even than to a runlevel .... [16:10] and second, i onlycan repeat (for the last time now) runlevels 2-5 are identical on debian based systems) [16:10] what would you recommend to me, if my goal is to run my binary during the bootup ? [16:11] rsalveti, poke ... seems compiz-plugins-extra FTBFS with the new compiz [16:11] that is the trigger event. [16:11] ogra_: oh well, let me check [16:11] rsalveti, well, i didnt expect anyone to have a patch or so, just wanted to make sure i'm right [16:11] its a universe package etc etc blah blah ... [16:12] plugins-main is the one needed, this extra might not be useful in the end [16:12] djszapi, well, what does your daemon do ? i.e. for a network based service i would tie to a network-up event for something related to HW i would tie to a udev event [16:12] start on runlevel [23] stop on runlevel [!23] [16:12] I had the impression I should do something like that for this goal. [16:13] janimo`: there's a runtime detection for unity for gles as well [16:13] rsalveti, yes, thats what i thought, just wanted to look if you guys possibly have a patch [16:13] ogra_: listening to the serial port, and act accordingly for the incoming data. [16:13] so prolly udev. [16:13] janimo`: /usr/lib/nux/unity_support_test -p [16:13] ogra_: I'll check [16:13] djszapi, well, either use the runlevel or take a look if there is a udev event when the serial device shows up [16:25] dpkg-buildpackage: error: debian/rules build gave error exit status 2 [16:25] @ @ [16:26] read the log, find the error, fix it :) [16:38] rsalveti, yes, ran that already and works fine, still unity still crashes on logon [16:39] ogra_: I am unsure if there is an udev event for that. [16:58] are there any updates on SGX for omap3? [17:10] Out of interest. [17:10] Does the l-cache actually destroy back to back compatibility with prior programs? [17:10] Because it forces ARM into a modified Harvard Architecture... [17:11] Take for example the case where you write over and instruction, but the l-cache keeps a prior version and then executes the prior version. [17:11] djszapi, so just take [23] [17:11] You have to force the cache to clear... [17:11] ogra_: might fail if udev is not up yet [17:12] since connecting to the serial port depends on the udev [17:12] udev comes up in initrd [17:12] so it is guaranteed my binary would be run later ? [17:12] and i think also before the runlevels start [17:13] ogra@horus:~$ grep "start on" /etc/init/udev.conf [17:13] start on virtual-filesystems [17:13] so ? [17:13] yup ... udev comes up with /proc, /sys and friends [17:13] way before anything cares for runlevels [17:16] fine :-) [17:16] does the kernel care about the proper respawning ? Say, I open the serial port while launching the daemon, and I would ideally close the serial port while stopping. [17:16] what if the daemon dies, and there is a respawning ? [17:17] there is a proper serial port close and then open again ? [17:19] no, not the kernel ... init does (well upstart in our case) [18:01] ogra_: is "stop on runlevel [!23]" fine for stopping ? [19:27] is there an arm equivalent to dmidecode ? [19:31] recur: That would imply there was such a thing as device tables on ARM. [19:31] Hi infinity [19:31] ah, so I'm completely out of luck then :) [19:31] Pretty much. [19:31] I wanted to programmatically get my hardware serial, but I've used dmidecode for that in the past. [19:31] thanks for the info! === Dr_Who is now known as tgall_foo === jkridner___ is now known as jkridner