| 00:04.22 | *** join/#edev flyback- (~flyback@c-98-219-134-156.hsd1.pa.comcast.net) |
| 00:24.46 | *** join/#edev roxfan (dunno@91.180.70.123) |
| 00:58.41 | *** join/#edev djerome (~djerome@ip68-2-20-108.ph.ph.cox.net) |
| 01:11.48 | *** join/#edev liuyq (~liuyq0307@221.123.128.226) |
| 01:22.11 | *** join/#edev bizhanMona (~bizhan@nat/cisco/x-lhjwjrzpdlcoyqzh) |
| 02:15.54 | *** join/#edev calculus (~calculus@adsl-76-254-63-181.dsl.pltn13.sbcglobal.net) |
| 02:15.55 | *** join/#edev calculus (~calculus@gentoo/user/calculus) |
| 03:05.31 | *** join/#edev blupp (~blupp@dslb-188-099-243-158.pools.arcor-ip.net) |
| 03:53.53 | *** join/#edev mpk (mp@aggr.com) |
| 04:30.00 | *** join/#edev mbuf (user@nat/redhat/x-yjjiflcavadvzsxw) |
| 04:40.43 | *** join/#edev av500 (~vladimir@b2b-46-252-131-98.unitymedia.biz) |
| 07:22.29 | *** join/#edev bizhanMona (~bizhan@nat/cisco/x-cqiaddvidnukrhow) |
| 07:57.16 | *** join/#edev liuyq (~liuyq0307@221.123.128.226) |
| 08:37.10 | slashbeast | stabs landley |
| 08:37.21 | *** join/#edev florian_kc (~fuchs@port-217-146-132-69.static.qsc.de) |
| 08:37.21 | *** join/#edev florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 08:37.23 | slashbeast | landley: yo, how the mdadm thing going? |
| 09:00.18 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 09:11.01 | *** join/#edev liuyq (~liuyq0307@221.123.128.226) |
| 09:52.55 | *** join/#edev g1powermac (~g1powerma@rrcs-173-197-150-24.west.biz.rr.com) |
| 09:52.56 | *** join/#edev g1powermac (~g1powerma@unaffiliated/g1powermac) |
| 09:59.07 | lautriv | slashbeast, you try to config some raid or waiting for a port ? |
| 10:02.24 | slashbeast | I dont understand your question |
| 10:02.31 | slashbeast | lautriv: ^ |
| 10:04.04 | lautriv | slashbeast, you asked "how is it going" and i wonder if you will use it or waiting for an port to your box. |
| 10:06.34 | slashbeast | I am waiting for a fix to aboriginal as the mdadm builit into it is unusable |
| 10:06.47 | slashbeast | or now I use mdadm binary bulid with buildroot |
| 10:07.39 | lautriv | ah,ok. |
| 11:06.04 | *** join/#edev [7] (~quassel@rockbox/developer/TheSeven) |
| 11:55.59 | [7] | hm, so what's the best/easiest way to set up a toolchain for armv7-m (both soft and hard float) on ubuntu precise amd64? |
| 11:56.27 | [7] | planning to use it with a cortex m4 core, and I'd like to integrate it into eclipse cdt |
| 11:57.25 | [7] | is there something that can compile for cortex M series in the ubuntu repositories? the arm-linux-gnueabi seems to only have a libgcc for cortex A series |
| 11:57.43 | lautriv | [7], purge that ugly morontu, install debian, apt-get it. |
| 11:58.05 | [7] | well, does debian have such a thing? and where would I find it? |
| 11:59.01 | lautriv | [7], a.) debian was the first (like often) and they have a complete dedicated part, look for "embdebian" |
| 11:59.55 | [7] | does embdebian support cortex M properly? they don't really say so |
| 12:00.07 | lautriv | [7], you could even install it on your target and compile there. |
| 12:00.37 | [7] | hahaha not with only 192K of RAM I suppose :) |
| 12:00.47 | lautriv | the actual armhf needs VFPV3D16, others will follow later. |
| 12:01.08 | lautriv | [7], i had a complete debian on a pda with 64M |
| 12:06.41 | lautriv | [7], btw. you asked about soft and hard float ....... never mix them ;) |
| 12:07.10 | [7] | sure, I just want to work on both an M3+softfloat and M4+hardfloat platform |
| 12:07.39 | [7] | and things seem to be working with the armel/armhf toolchains from the ubuntu repositories except for libgcc being compiled for cortex A |
| 12:08.17 | av500 | lautriv: as long as your code does not pass floats in function calls, you can mix them |
| 12:09.06 | lautriv | [7], it's always the biggest common amount used for a base-set |
| 12:09.44 | [7] | also these ubuntu toolchains seem to basically be the emdebian ones, built by the same people |
| 12:09.50 | lautriv | av500, but the difference goes very deep and you can't warrant that any dynamic library may do so. |
| 12:10.15 | av500 | yes, you have to be careful |
| 12:10.46 | [7] | well, for my purposes this doesn't really matter, as I'm planning to just compile a standalone binary blob without any fancy runtime linking |
| 12:11.05 | [7] | this platform isn't really capable of running linux memory-wise anyway |
| 12:11.20 | [7] | i just want to cherrypick a toolchain from somewhere :) |
| 12:11.43 | lautriv | [7], ubu does nothing else taking debian and fullfil it with a crapload of patches, delivered etirely untested and stamped "stable". so what do you belive ? |
| 12:12.42 | lautriv | <-- lunch, bbl |
| 12:12.43 | [7] | well, this leads me to concluding that it isn't likely to work any better on debian :) |
| 12:13.23 | lautriv | sure, debian is not patched to death and the maintainers are serious and bright :P |
| 12:16.39 | [7] | hm, so assuming that these tools work with m4, how would I go about setting up a matching libgcc? |
| 12:28.35 | lautriv | [7], just get details about the architecture-specific CCFLAGS ? |
| 12:33.57 | lautriv | actually i wonder if there is a bug or a feature in kernel 3 series..........if i select usb-gadget to be built-in, the menuconfig refuses to use cdc-ether and disable all others but i want g_serial included. is this really intended for any curious reason ? |
| 12:39.47 | *** join/#edev GPSFan (~kenm@64.92.145.112) |
| 12:39.47 | *** mode/#edev [+o GPSFan] by ChanServ |
| 12:48.50 | [7] | lautriv: is USB_CDC_COMPOSITE what you're looking for? |
| 12:51.28 | lautriv | [7], i'm looking for any possible driver which can give me a serial console built but right after selecting y for usb-gadget, there is only cdc-ether left and no option for any other gadget. |
| 12:52.04 | lautriv | this happens at least on 3.0.1 and 3.4 |
| 12:52.20 | [7] | "usb-gadget" being USB_GADGET in kconfig? ("USB Gadget Support") |
| 12:52.29 | lautriv | yes |
| 12:53.41 | [7] | hm, I think USB_ETH or USB_G_SERIAL or whatever are only supposed to show up at all if USB_GADGET is m/y? |
| 12:54.28 | lautriv | if it's M, they show all up. if it's Y all but cdc_ether vanish |
| 12:55.12 | lautriv | i see they may disturb each other but it should be possible to select G_SERRIAL=Y and CDC_ETHER=N |
| 12:55.16 | [7] | and don't come back even if cdc_ether is m/n? |
| 12:55.33 | lautriv | not here |
| 12:57.03 | [7] | hm, USB_ETH is set as default for that choice option |
| 12:57.29 | lautriv | [7], btw. there is another simple method to get a toolchain pseudo-native running. you could install arm on qemu |
| 12:57.56 | [7] | lautriv: yeah, but what I want is far more trivial |
| 12:58.10 | [7] | I just want to compile monolithic cortex m4 code for now |
| 12:58.37 | [7] | running into this: /usr/lib/gcc/arm-linux-gnueabi/4.6/../../../../arm-linux-gnueabi/bin/ld: error: /usr/lib/gcc/arm-linux-gnueabi/4.6/hf/libgcc_s.so.1: Conflicting architecture profiles A/M |
| 13:01.20 | lautriv | [7], looks like you try to use libgcc from armel for armhf or the other way |
| 13:01.48 | [7] | no, that would cause a different error mentioning VFP |
| 13:01.56 | [7] | hf is correct in this case |
| 13:02.15 | [7] | I get the same error for armel if i disable VFP |
| 13:03.56 | lautriv | hmm, any other caveeat like NEON extensions or the like ? |
| 13:04.30 | [7] | I think it means to say that this libgcc uses something that cortex M series doesn't support |
| 13:04.57 | [7] | so the main question is: where do I get a matching libgcc from and how do I tell it to use that one |
| 13:05.49 | lautriv | that'S what i mean but it must be somehow vendor-specific because the last generation is used to be somewhat backwards compatible. |
| 13:06.28 | [7] | well, M series is mostly a subset of A series as far as usermode stuff is concerned |
| 13:06.56 | [7] | things like interrupts just work differently though |
| 13:08.16 | lautriv | maybe you get a hint by gcc -v, where it states bult with --blah --foo --bar |
| 13:08.28 | [7] | but as libgcc is supposed to be efficient, I think it's quite reasonable that a libgcc that targets cortex A requires some instructions that aren't available on M |
| 13:10.01 | lautriv | that should be mentioned there, on the other hand, they tend to use the most common amount to not build 30 versions. |
| 13:10.35 | lautriv | argh, i would like to shoot the inventor of systemd in the knee. |
| 13:15.43 | [7] | oh, and btw, regarding your USB/kconfig problem: "A choice can only be of type bool or tristate, while a boolean choice only allows a single config entry to be selected, a tristate choice also allows any number of config entries to be set to 'm'. This can be used if multiple drivers for a single hardware exists and only a single driver can be compiled/loaded into the kernel, but all drivers can be compiled as modules." |
| 13:16.04 | [7] | the one you're looking at is a tristate choice with default set to USB_ETH |
| 13:16.14 | [7] | so it should *in theory* allow you to do what you want |
| 13:18.11 | lautriv | that'S what i think but looks like it was not planned. already choosed cdc_ether which is visible on hst's lsusb but freakin' systemd won't start it for actual unknown reason. |
| 13:18.17 | [7] | if you want to hack it up, you could try changing the default to USB_CDC_COMPOSITE |
| 13:19.19 | [7] | tbh this looks like a kconfig bug more than anything else |
| 13:19.32 | lautriv | [7], this whole kernel is a hack to support hx4700 again. would be fine to have any remote console because the thingie has no keyboard :( |
| 13:22.30 | *** join/#edev bizhanMona (~bizhan@nat/cisco/x-mhkfmhwykotgkvjj) |
| 13:34.42 | [7] | lautriv: solved my problem btw... it was simply a missing "-static" in a gcc command line |
| 13:35.39 | lautriv | [7], that was somewhat fast, i know certain simple problems/miswritings takes a long time to find ;) |
| 13:52.46 | [7] | hm, can anyone point me to the ubuntu/debian package name for the arm cross gdb? |
| 13:54.08 | lautriv | it's something like gcc-cross-linux-arm-gnueabi. the good old dselect would let you search. |
| 13:54.33 | [7] | hm, I have installed that, but it doesn't seem to contain gdb |
| 13:54.37 | [7] | asks apt-file |
| 13:55.48 | lautriv | can anyone tell me what to symlink/ create for systemd to get netowking up on boot ? |
| 14:00.34 | landley | slashbeast: hmmm? |
| 14:01.07 | landley | I spent last night finishing debugging the darn arm build break, which was actually 2 commits. |
| 14:01.49 | landley | That gets me up to speed on 3.4. The remaining release blockers are the mdadm thing (which I think is a kernel .config issue rather than a uClibc thing) and the Fedora build break (which isn't ccache). |
| 14:12.30 | slashbeast | if it is a kernel .config issue why the glibc one and buildroot one works? |
| 14:12.39 | slashbeast | or you mean the headers are somehow affected? |
| 14:26.05 | *** join/#edev prpplague (~danders@192.91.66.186) |
| 14:26.52 | slashbeast | landley: the somehow headers config or running kernel? |
| 14:43.42 | landley | slashbeast: the buildroot one is using uclibc, right? |
| 14:43.48 | landley | COuld be uclibc .config... |
| 14:48.58 | slashbeast | indeed uclibc |
| 15:31.40 | landley | If the buildroot one is using the same kernel version, and the same uClibc version, then it's either a .config issue or compiler version skew. |
| 15:31.50 | landley | And .config issue is ~10 times more likely. |
| 15:32.23 | landley | Do you have the kernel and uclibc .config files for the system that works? |
| 15:52.35 | *** join/#edev arun (~arun@unaffiliated/sindian) |
| 16:43.02 | *** join/#edev ozialien (~ernest@ip68-0-179-160.tc.ph.cox.net) |
| 16:59.10 | *** join/#edev florian (~fuchs@sign-4d0940a8.pool.mediaWays.net) |
| 16:59.10 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 17:25.25 | *** join/#edev Elledan (~jigoku_ai@s529c4932.adsl.wanadoo.nl) |
| 17:26.52 | *** join/#edev lautriv (~lautriv@f050083078.adsl.alicedsl.de) |
| 17:29.44 | *** join/#edev NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey) |
| 17:56.29 | *** join/#edev grummund (~user@unaffiliated/grummund) |
| 19:10.08 | *** join/#edev strnx (strnx@199.127.227.146) |
| 19:18.01 | *** join/#edev ozialien (~ernest@ip68-0-179-160.tc.ph.cox.net) |
| 19:22.38 | *** join/#edev bizhanMona (~bizhan@nat/cisco/x-oelmsqxoeijqztbt) |
| 19:37.18 | *** join/#edev devilsadvocate (~quassel@109.200.19.188) |
| 19:53.45 | *** join/#edev strnx (strnx@199.127.227.146) |
| 20:56.59 | sorphin | prpplague: around? |
| 20:57.40 | prpplague | more of a square |
| 20:58.57 | sorphin | lol |
| 20:59.02 | sorphin | the sensys device arrived |
| 20:59.11 | sorphin | Took internal pics if interested at all. |
| 20:59.28 | prpplague | sorphin: start up an elinux.org wiki page |
| 21:04.51 | sorphin | ok |
| 21:26.41 | *** join/#edev TheSeven (~quassel@rockbox/developer/TheSeven) |
| 21:38.15 | *** join/#edev ozialien (~ernest@ip68-0-179-160.tc.ph.cox.net) |
| 22:08.14 | sorphin | prpplague: The AP uses one of these: http://www.arcturusnetworks.com/products/uc5272/ |
| 22:08.56 | sorphin | So I wonder if Sensys is even on the hook? Since Arcturus is who makes the module and they provide the source on their side and tools |
| 22:13.26 | prpplague | sorphin: the person who distributes the product is responsible for compliance |
| 22:13.44 | prpplague | sorphin: if it is sold and distributed by Sensys, they are responsible for the licensing compliance |
| 22:14.10 | SpeedEvil | The personwho supplies them is only responsible for their requirements as it applies to the person they supply it to, not the general public. |
| 22:15.30 | SpeedEvil | In addition - if the SoC maker has given them a 'GPL' + NDA package - that they've then gone on to make a binary with, and ship - that does not mean that they can ship the source. |
| 22:16.05 | SpeedEvil | Because they don't have a valid licence to ship that source - they would have to go back to the SoC vendor, and get a valid licence. |
| 22:16.26 | sorphin | well, it appears that the only 'linux' using part is that link i pasted, the Arcturus DIMM |
| 22:17.10 | SpeedEvil | If you distribute the DIMM as part of a package, you'd still need to supply source for it. |
| 22:20.06 | sorphin | nod |