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