=== zz_chihchun is now known as chihchun [06:30] hi [10:53] hi === chihchun is now known as zz_chihchun === breton_ is now known as breton [13:59] I'm trying to get sbuild working on my Nexus 7 running the touch developer preview (because it's the most convenient reasonably modern ARM device I have root on - I'm doing non-touch-related stuff). However, I can't debootstrap because the relevant filesystems are mounted nodev. Remounting them dev, even from adb shell, doesn't seem to change anything. Does anyone know how to work around this? [14:00] ugh [14:00] adb should definitely override [14:01] does mount still show it with nodev after a remount ? [14:01] no [14:01] cjwatson, did you mount /procc inside the container ? [14:02] its not there by default due to PID namespace issues afaik [14:02] I'm sshed in [14:02] I thought that was enough [14:02] seems to be there from ssh [14:03] dont trust mtab :) [14:03] cat /proc/net/dev ... see if the third level exists [14:03] it does [14:03] if not, it isnt mounted [14:03] hmm [14:03] I suspect maybe that the remount is ineffective because /data was already bind-mounted in some twisty way [14:04] oh, yeah [14:04] is it possible to get the android layer not to mount it nodev in the first place, and then I can reboot? [14:04] well, yes, if you reboot the android layer [14:04] err [14:04] rebuild [14:04] cjwatson: you can edit the ramdisk, I think there is normal fstab file [14:04] ah, /init.rc maybe [14:04] the mounting is done from /init.rc [14:05] and init.rc is put in place from the initramfs [14:05] you cant just edit it [14:05] I can do it for you if you send me the boot.img, It is like 5min of work for me since I do it quite often [14:05] Gotcha. Can I unpack/modify/repack the initramfs in-place? [14:05] (fstab as well, they are both copied from initrd) [14:05] Tassadar: I'd rather know how to do it myself :) [14:05] okay [14:05] (though thanks) [14:05] you should be able to dd /dev/mmcblk0p2 to a file [14:06] then you should be able to disassemble it with abootimg [14:06] into initrd/kernel/config [14:06] and indeed re-assmble it the same way [14:06] no /dev/mmc* [14:06] oh, android [14:06] /dev/block/mmc* [14:08] ok, let's see [14:27] hmm, so I dded that out, unpacked, edited ramdisk/init.rc, repacked, updated boot.img with the repacked initrd.img, dded that back to /dev/block/mmcblk0p2, rebooted - no change [14:27] after rebooting, /init.rc still has the original unchanged line in place [14:28] weird, it should update from the initrd [14:28] well, I conclude that I didn't successfully update the initrd, but I don't know why [14:28] I'm pretty sure there is fstab file in the ramdisk [14:28] did you edit fstab too ? [14:28] that's not really relevant since the basic problem is that my init.rc change didn't take effect at all [14:28] init.rc just calls something like "mount /data" [14:28] init.grouper.rc actually does "mount_all thenameofthefstabwhichIforgot" [14:28] not so [14:29] fstab defines the options [14:29] mount yaffs2 mtd@userdata /data nodev [14:29] hmm [14:29] that's not it [14:29] there is an fstab but it doesn't go near /data [14:29] no, we definitely dont use yaffs ... [14:29] there should be an ext4 mount [14:29] look if tehre is an fstab.grouper or so [14:30] * Tassadar goes to grab boot.img to see what is actually inside [14:30] and init.grouper.rc [14:30] that overrides [14:30] well, there is an fstab.grouper, so I'll edit that. That still doesn't explain why my init.rc change was ignored though [14:30] yeah [14:30] tell us what you did to rebuild the boot.img [14:31] * ogra_ guesses just using abootimg [14:31] since thats what i suggested [14:31] yeah, ubuntu touch has fstab.grouper, just like normal android [14:31] abootimg -x boot.img; sudo abootimg-unpack-initrd; vi ramdisk/init.rc; sudo abootimg-pack-initrd -f; abootimg -u boot.img -r initrd.img [14:31] abootimg -u boot.img -r initrd.foo [14:32] yeah [14:32] * cjwatson tries again [14:32] oh, where do abootimg-(un)pack-initrd come from [14:32] * ogra_ didnt know these [14:32] the abootimg package [14:33] must be new :) [14:33] i still use zcat/cpio usually [14:33] but i guess they just do the same [14:33] yeah, I figured I might as well use them to get cpio options right [14:38] Aha, that did it! Thanks [14:38] I guess I must just have failed to write back the modified boot.img before, somehow [14:38] Sorry for the noise === yofel_ is now known as yofel === mhall119_ is now known as mhall [19:49] anyone here got an arndaleboard? [19:51] ok :( [20:10] ptl: yes [20:48] Cortex A15 question [20:49] Which platform is recommended for testing A15 + Ubuntu? [20:49] Which dev boards are known to work? [20:50] chromebooks are used by community people pretty widely [20:52] ogra : the XE303? [20:52] the arm one [20:52] i dont think there is more than one [20:52] Yeah, dual core Samsung Exynos chip [20:53] right [20:53] Okay.. Hmm.. [20:53] the dev board equivalent is arndala i think [20:53] *arndale [20:53] *nod* [20:53] I just got a new devboard, and I wanted another platform to compare it to [20:54] nice [20:54] Yeah, the Xen guys have been doing all their work on Arndales and Chromebooks. [20:54] since getting Ubuntu up and running on this platform will take me a couple weeks [20:54] I'm not really aware of any other widely-available A15s. [20:54] infinity : There are none, that I am aware of. [20:54] nexus4 [20:54] infinity : I'd like to change that, but getting production-run quantities of A15 chips is hard [20:55] nexus 10 has the exynos 5 as well [20:55] right [20:55] but that's not a platform I'll be comfortable poking at [20:56] I'm talking to nVidia now [20:56] since there's exactly 0 chance of getting TI chips [20:57] why not ? [20:57] omap5 is on sale [20:57] in the new evm board [20:57] Because I can't get a volume production quantity from TI [20:57] and the IP they chose to put on the OMAP doesn't map well to an ATX form factor PC [20:59] Also, PowerVR drivers… always an issue [20:59] Nvidia at least handles OpenGL 4.x [20:59] https://www.svtronics.com/index.php?route=product/product&product_id=33 [20:59] the pandaboard that wasnt called panda ... [20:59] Yeah [20:59] Saw it [21:01] The nvidia tegra4 T42 will probably end up being the chip though [21:02] quad + 1, 2.0GHz has been verified and validated [21:02] The @#$@#$ thing is the lack of PCIe on all platforms [21:02] No PCIe on the Tegra4? [21:02] Even the Tegra2 had PCIe. [21:02] That's what the Trimslice's SATA hangs off of. [21:02] really ? [21:03] just like on the EnergyCore, it's got lockup issues [21:03] i thought i saw PCIe mentioned [21:03] It's the stupid AMBA bus to PCIe bridge that fails, when it gets out-of-order transactions [21:03] locks up the AMBA bus, and that's that [21:03] Brilliant. [21:04] If you look at the latest IO block diagram for the Nvidia, you'll see that I/O no longer lists PCIe [21:04] Kernel bug, or fundamental design flaw? [21:04] fundamental design flaw, on die, in chip [21:04] \o/ [21:04] workarounds require changes to the chip [21:04] thats what you call progress :) [21:04] (adding a method to reset the bus) [21:04] It's why Calxeda doesn't really acknowledge that there is a PCIe block on the die [21:04] I've said it a few times this year already, but I can't wait to see what sort of ARM silicon AMD spits out. They can't possibly get so many things wrong. [21:04] probably a fallout of not having a device partner at all [21:04] same with Tegra [21:05] same with NEC [21:05] ogra : Has to do with using the Syn…ys IP [21:05] Hey, at least the 10GigE works :) [21:06] (Though, AMD has no plans for armv7 AFAIK, only armv8... Maybe they'll surprise me and do both) [21:06] What's the other thing I need to have working .. one or two GigE interfaces are kind of "a requirement" when building ATX machines [21:06] Martyn: If I had an ARM board with two GigE devices that could actually saturate both links, full duplex, I'd be a very happy man. [21:07] infinity : Calxeda has that [21:07] Get an EnergyCore card [21:07] get ... heh [21:07] Erm, does anyone make single EnergyCore anything? [21:07] I don't need blades, I want a router. :P [21:07] No, but you can ask Calxeda for one of the little dev boards [21:07] it can take as little as one board [21:08] It was originally called a "slingshot" when the first prototype boards were brought in [21:08] If I knew how to get such a dev board, I'd already have one. [21:08] infinity : just ask. [21:08] Talk to Karl [21:08] well, there is that "get" thing :) [21:08] Care to introduce us? :P [21:08] asking is cheap [21:08] Unless things have changed so much .. I know that Calxeda joined the whole Linaro thing, so I know the platforms are out there [21:08] Also, you can go play with it on the OpenStack instances they have available for public playtime [21:09] thats a great idea ! [21:09] Bonus points if those boards boot and look vaguely like a card in a full chassis. Would make my life so much easier, trying to do various crackful things. [21:09] start up two instances, and talk to each other. They are likely going to be on two wholly different boards on the cluster [21:09] infinity, run your router in an openstack instance ! [21:10] ogra : Should work, right? [21:10] Martyn: Openstack sort of defeats the purpose for me, since I'm interested in being next to the metal, not abstracted away. [21:10] EnergyCore's are physicalized, not virtualized .. so he'll be playing with real hardware, at the metal [21:10] ^^ [21:11] infinity : That's the whole POINT of running ARM on OpenStack .. you're physicalized, not virtualized [21:11] You're in a jail, and if things are still like when I was at Calxeda, it's using LXC [21:11] Maybe I misunderstood, I thought current openstack-on-arm was lxc trickery and the like. [21:11] * ogra_ kind of wasnt serious about running a router in a foreign cloud instance [21:11] so you're going to be on the metal [21:11] lxc is not "next to the metal". [21:11] infinity : Close enough. Certainly closer than if you were on KVM [21:12] I'm interested in booting and installing bare systems, not playing in containers. [21:12] you're basically just in a fancy jail [21:12] I have tons of ARM hardware to screw around in userspace with. [21:12] meh, fair enough [21:12] but if you want to play with a platform that lets you pump >1Gigabit on ARM, Calxeda is the only platform I can think of capable [21:12] and LXC won't abstract you or slice you away from that [21:12] Yeah, two disparate goals there. :) [21:13] you'll still have full access to the interfaces, and fabric [21:13] One goal is better/shinier enablement, which needs me to sit next to the metal. And I think I might honestly just take a flight to Boston and play with some of our crap in the datacenter there. [21:13] The other goal is a personal home router. [21:13] So, again, need real hardware for that, cause running my home router in an LXC container in another city might not work so well. ;) [21:14] Ah, hold on .. looks like the SnapDragon also supports PCIe [21:14] 3.0 [21:14] And, to be fair, I don't need full saturation for the home router, my internetses are only 250 Mbit. [21:15] But that still demands more than I can get out of any ARM boards in my house. [21:15] IP is by Global ... [21:16] Hmm .. is there even PCIe support in the Linux SnapDragon kernel? [21:16] Is SnapDragon multiplatform enabled yet? [21:17] Not that that's relevant to the question, per se, but it probably makes PCIe enablement slightly more likely. Unless it's wildly different from other SoCs in how it works. Which it might be. [21:30] Mrrf. [21:30] Well, found a snapdragon dev board [21:30] ex-pen-sive doens't even begin to describe it [21:30] This is as expensive as the ARM development platforms for A15 when it first came out .. the one with the big Xylinx Spartan 7 on it