**** BEGIN LOGGING AT Fri Nov 25 02:59:57 2011 Nov 25 10:09:20 can someone here poke the right people to get the mutrace update to oneiric Nov 25 10:10:11 whats that ? just a sync or is there anything to merge ? Nov 25 10:11:38 ogra_: it was uninstallable: https://bugs.launchpad.net/ubuntu/+source/mutrace/+bug/875928 Nov 25 10:11:39 Launchpad bug 875928 in mutrace "mutrace: uninstallable as it strictly depends on a specific binutils version" [Medium,Fix released] Nov 25 10:15:01 suihkulokki, err, the bug says it is already autosynced Nov 25 10:15:16 oh, oneiric, hmm Nov 25 11:20:48 http://www.androidpolice.com/2011/11/25/best-buy-dropping-asus-transformer-to-just-250-on-black-friday-dock-just-100/ Nov 25 11:23:07 If only Black Friday was a global thing. Nov 25 11:23:17 infinity: ;) Nov 25 11:23:36 heh Nov 25 11:23:48 and then you would havee to fight with the locked bootloader Nov 25 11:24:02 o. asus locked bootloader? Nov 25 11:24:05 assholes Nov 25 11:24:20 well, thats what NCommander claims since UDS Nov 25 11:25:24 heh... found another annoying thing in unity ;( Nov 25 11:25:46 typing in window == raise window ;( Nov 25 11:28:01 nop Nov 25 11:28:05 they don't lock bootloaders Nov 25 11:28:09 they block nvflash Nov 25 11:28:10 :p Nov 25 11:28:31 and even then it is just more, lack of the encryption key for communication Nov 25 11:29:11 so user oriented only device Nov 25 11:29:19 yeah Nov 25 11:29:34 I'm a user, and I want to install another OS on it. :P Nov 25 11:29:38 well, it won't be an issue forever Nov 25 11:29:46 just for the moment Nov 25 11:30:10 and sorry but I can't give an eta, cause I simply don't know Nov 25 11:33:10 when I say I don't know, I mean I don't know how long it will take for us to have something to release Nov 25 14:23:35 ogra_: janimo: we got a newer kernel for imx53 that's based on 3.1, do you want us to update the kernel at ubuntu side? Nov 25 14:23:51 rsalveti, for 12.04 ? sure ! Nov 25 14:23:53 we can probably do this next week Nov 25 14:23:59 ogra_: great Nov 25 14:24:08 i dotn think we care much for oneiric Nov 25 14:24:19 next week is bad though, we're in A1 freeze Nov 25 14:24:23 better the week after Nov 25 14:25:10 A1 freeze? Nov 25 14:25:24 on monday, yes Nov 25 14:25:30 ogra_: fair enough Nov 25 14:25:55 lilstevie, A1 release is on dec. 1st, we usually freeze from monday on for that Nov 25 14:26:00 what is A1 freeze, thats a term I haven't seen or heard before Nov 25 14:26:07 ah Nov 25 14:26:09 alpha 1 milestone release Nov 25 14:26:11 I get it now Nov 25 14:26:18 i'm a lazy typer :) Nov 25 14:26:21 heh Nov 25 14:26:34 damn it, where is persia Nov 25 14:26:56 * ogra_ sighs ... another question about "how do i recompile ubuntu from source for ARM" Nov 25 14:27:06 heh Nov 25 14:32:33 whats new in precise Nov 25 14:32:42 lots of software :P Nov 25 14:32:45 heh Nov 25 14:33:10 not much beyond that ... armhf should soon be there Nov 25 14:33:46 fair enough Nov 25 16:13:37 sup Nov 25 17:25:02 suihkulokki: thanks for getting chromium building on arm, I'll have to see if I can tweak your fix to use the internal libvpx Nov 25 17:26:46 mm Nov 25 17:26:52 i need to check that out Nov 25 17:26:57 you got a link? Nov 25 17:31:23 hmm Nov 25 17:31:26 nvm Nov 25 19:46:39 rsalveti, we most definitely want new kernel for mx53 Nov 25 19:46:42 is it in a ppa? Nov 25 19:47:20 janimo: it is, but we can push the same way we did, with the proper sauce and such Nov 25 19:47:41 currently I don't think the sauce is in sync with the latest set available Nov 25 19:51:23 rsalveti, yes pushing it in the archive would be great Nov 25 19:51:42 and our aim for this cycle is to use the same sauce on all arm subarchs, and the same as on x86/amd64 Nov 25 19:51:52 modulo arch-specific config Nov 25 19:52:01 janimo: got it, good to know Nov 25 19:56:50 janimo: That would be lovely if we actually achieve said goal. Nov 25 20:32:31 ogra_: all of them are locked, some have been hacked (lag, but I didn't see the earlier ping in this channel) Nov 25 20:41:36 will we have mx51 live images this cycle or is everything focused on mx53 now? Nov 25 20:45:24 micahg: I believe any mx51 support has to be driven from the community Nov 25 20:47:14 * micahg was hoping for xubuntu on arm, but only has mx51 hardware Nov 25 20:47:34 micahg: which mx51? Babbage? Nov 25 20:48:00 NCommander: idk, I have a genesi smartbook Nov 25 20:48:13 micahg, the linaro mx5 kernel supports both mx53 and mx51 Nov 25 20:48:19 uboot packages are separate Nov 25 20:48:24 janimo: thought there was issues with it on the smartbook Nov 25 20:48:31 janimo: cool, so images would be possible then Nov 25 20:48:47 NCommander, I have no mx51 hw (nor do I want any) to know more about the issue Nov 25 20:49:09 yeah, ISTR an issue with the kernel on the smartbook, it worked on the smarttop Nov 25 20:49:11 all I know is second-hand Nov 25 20:49:34 ok, well, maybe I"ll come back in a month when I have more time to work on this Nov 25 20:49:39 micahg, images could be possible sure. But with our current image build processes it may not be too appropriate to start tending for another one Nov 25 20:49:40 micahg: if you are interested in driving it, there's a program in the process of helping getting new devices enabled in ubuntu Nov 25 20:50:18 micahg, I wonder if it is not better to try making the uboot binary run on both mx51 and mx53. Not sure how much work is that though Nov 25 20:50:29 well, I have to see if I have enough time to drive such a thing, I'm already spread pretty thin this cycle Nov 25 20:50:45 but than we could have a singel image instead of yet another slightly different from the rest Nov 25 20:50:56 ooh, that's tempting :) Nov 25 20:51:22 having mutliple almost identical images suck from almost every PoV Nov 25 20:51:24 * micahg can try hacking on that during his "vacation" at the end of next month Nov 25 20:52:01 micahg, ping jcrigby he may give you some tips. Or equally usefully tell you it has been tried before or it is impossible,etc Nov 25 20:52:17 I wish we did the same with omap3/omap4 too Nov 25 20:52:17 ok, will keep in mind, thanks Nov 25 20:52:56 but there the kernels are still not using a common source let alone binary Nov 25 20:54:50 janimo, micahg mx51 and mx53 have have physical dram at different addresses (0x8xxxxxxx and 0x9xxxxxxx) so that would be more difficult that omap which is theoretically possible Nov 25 20:55:57 jcrigby: I've always been curious on why we can't have an unified x-loader on omap3/4; if we could unify x-loader (not even u-boot) it should be possible to have a unified image would make life easier Nov 25 20:57:44 jcrigby: thanks, any ideas what I can do then? Nov 25 20:58:32 jcrigby: I take it there's no sane way to determine which SoC you're on before we need to jump to (potentially nonexistant) addresses? Nov 25 20:58:59 NCommander, after thinking about his for sometime I have decided that asking for this is like asking two pc's to boot from the same bios binary Nov 25 20:59:11 jcrigby: Cause I'd be inclined to get in on the bribery action if an mx51/mx53(/mx6?) unified uBoot would be possible. Nov 25 20:59:32 jcrigby: many PCs do share BIOS blobs and do runtime detection for DRAM addresses and such Nov 25 20:59:49 NCommander, ok you got me there Nov 25 21:00:03 :-) Nov 25 21:00:41 iirc the only thing kind of blocking us was the lack of a device id Nov 25 21:00:47 jcrigby: most of what x-loader does is DRAM/initial hardware power on. If its possible to determine what CPU we're on (something similar to cpuid on x86) Nov 25 21:01:06 rsalveti, and if we are willing to write a board id to a file on sd then we can work around that Nov 25 21:01:10 win 8 Nov 25 21:01:14 rsalveti: bah, I know the ARM spec has ways to get information about the proc via mrc (and some deep voodoo). Not an option on panda/beagle? Nov 25 21:01:29 jcrigby: Yeah, but if was can write to SD, then we can just as easily have multiple bootloaders. Nov 25 21:01:35 NCommander: I believe that can be done Nov 25 21:01:38 jcrigby: In the end, it still comes down to "no unified install image". Nov 25 21:01:44 infinity, yes Nov 25 21:01:52 could be harder than having an easy way to probe the device id, but can probably be a solution Nov 25 21:02:17 rsalveti: so if we can do that early device detection, can't we then dynamically initialize DRAM/friends on the fly? My understanding is the BootROM takes up to 64 kib, and at last check, x-loader is considerably smaller than that Nov 25 21:02:21 jcrigby: maybe something to invest time and check if it's possible Nov 25 21:02:54 NCommander: in theory I believe it's possible, something to try Nov 25 21:03:08 rsalveti, andy green talked about "finger printing" at cambridge Nov 25 21:03:23 jcrigby: and as we'll have spl for omap3 soon, that could be an ideal solution Nov 25 21:03:40 so you could peek at a list of places and go through a decision tree to figure out what the board was Nov 25 21:03:53 jcrigby: yeah, kind of brutal force Nov 25 21:03:56 jcrigby: rsalveti: if you make it work, I'll buy you a keg of beer at the next UDS Nov 25 21:04:06 it would be fragile Nov 25 21:04:22 That sort of thing always is. Nov 25 21:04:28 well, at least should be able to cover beagle and pandas Nov 25 21:04:38 what would already be a nice thing Nov 25 21:04:44 But fragility in initial boot for installers is a known quantity (we always deal with it), and once the system's installed, it "obviously" works. Nov 25 21:04:49 jcrigby: how robust does it realistically have to be? Until OMAP4+ shows up, then it has a very simple thing to do Nov 25 21:05:19 yes, I guess we should do what is possible instead of dismissing it because of the corner cases that are not possible Nov 25 21:05:19 now that we have panda 4430 and 4460 out, that would probably be a valid solution for at least one year Nov 25 21:05:24 until we have omap 5 in place Nov 25 21:05:41 jcrigby: I've never dug into the startup.S code in x-loader that much. Is there a hook in BootROM we can simply read out the SoC? Nov 25 21:05:45 jcrigby: is it something that you're interested to work on? Nov 25 21:05:58 we can probably schedule something for 11.12, 12.01 :-) Nov 25 21:06:03 NCommander, we can figure out SoC Nov 25 21:06:15 board id is harder Nov 25 21:06:24 jcrigby: board id isn't really an issue is it? Nov 25 21:06:34 X-loader is intercompatible across all boards, just omap3/4 versions Nov 25 21:06:37 (Still, as interesting as it is for omap, I'm curious if this same sort of crazy can be applied to mx5, since we seem to have so many of the things in the hands of developers) Nov 25 21:06:45 well, we can try the soc and then check the gpios for board id Nov 25 21:06:51 or similar Nov 25 21:06:58 if x-loader can determine whats its running on, thenit can load a u-boot.bin3/u-boot.bin4 Nov 25 21:07:04 yup Nov 25 21:07:26 infinity: agreed. Kernel support was the holdup, my last stab at this on the smarttop I couldn't successfully boot a kernel which killed my image enablement work Nov 25 21:07:42 all mx flavours have user definable fuse locs that we could use for a board id if we wanted Nov 25 21:08:06 ti has fuses but does not expose them to end user Nov 25 21:08:12 yeah Nov 25 21:08:37 arm should recommend to vendors to have fuses with soc ids and board ids Nov 25 21:08:51 jcrigby: wasn't that part of the boot architecture discussions? Nov 25 21:08:58 rsalveti, I hope so Nov 25 21:09:07 maybe lool knows about it Nov 25 21:09:21 actually the other solution is soldered on flash for the spl Nov 25 21:09:35 like bios flash chips on pc's Nov 25 21:09:50 Soldered on flash solves lots of issues, but it's terribly hard to go back in time and do that. ;) Nov 25 21:09:52 true, I believe that was the requirement microsoft had Nov 25 21:09:55 that we (distro/os vendors) don't touch Nov 25 21:09:58 to enable arm boards with windows Nov 25 21:10:50 bbl, dinner time Nov 25 21:11:31 * NCommander would be greatly amused if we used Microsoft's boot crack to help solve some of our boot issues Nov 25 21:12:55 NCommander: The new world order will be much simpler to boot on, and Microsoft's logo requirements will certainly factor into that. Nov 25 21:13:09 Of course, we have an urge to boot on non-new-world machines, which they don't care about. Nov 25 21:13:11 infinity: right up until we have to deal with secure boot on ARM Nov 25 21:13:21 * NCommander keeps thinking newworld == powerpc :-P Nov 25 21:13:28 Heh. Nov 25 21:14:09 Secure boot's a different kettle of fish. And our very strong presence in the ARM market may actually help with leverage in crack-removal in the x86 market. Nov 25 21:14:13 One can hope, anyway. Nov 25 21:14:19 Well, crack-avoidance. Nov 25 21:14:42 infinity: meh, the EU shown its got balls to stand up to Microsoft. If things become an issue, at least I can hope they will get involved Nov 25 21:14:47 (The inverse there, of course, is that ARM device vendors love locking things down, so...) Nov 25 21:14:58 * NCommander is honestly expecting the current Microsoft antitrust lawsuite to go as well as the first one Nov 25 21:15:51 rsalveti: Not really; we rather discussed firmware, not specifying where it would live Nov 25 21:19:41 lool, I would like to see the vendors make their low-cost boards a little less lowcost and put some nand/spiflash/emmc whatever on the board for a boot loader that we never touch. Nov 25 21:20:15 jcrigby: We would want some mechanism to update it etc. Nov 25 21:20:56 lool, yes but that would be the exception not the normal path. Like when you update the bios on a pc Nov 25 21:21:12 Yes Nov 25 21:21:29 I guess it's the fact that we're building all the pieces that go on the SD card image for OMAP Nov 25 21:21:36 from scratch, using the latest versions Nov 25 21:21:51 Yeah, but there's no real reason to do so. Nov 25 21:22:19 (Well, except where we've been doing fun things like hacking PXE support) Nov 25 21:22:36 Normally, though, treating uBoot like a BIOS is the sane and right thing to do. Nov 25 21:22:48 And 99% of end users never touch their BIOS post-purchase. Nov 25 21:23:08 well we could ask people to keep a "firmware" SD card and use an USB key for the Ubuntu or Linaro rootfs but it would be inconvenient Nov 25 21:23:42 That's actually how I boot my quickstart. Nov 25 21:23:49 But yes, not an ideal solution. :P Nov 25 21:24:09 I just treat the micro slot on my QS as a BIOS PROM, basically. Nov 25 21:26:25 infinity: lool: we did that with babbage 1/2 :-/ Nov 25 21:27:57 There are so many things to say on this topic that I'm not sure it's wise starting it on IRC Nov 25 21:28:24 starting with the fact that we currently target many developer boards, not production hardware where we expect end-users to reinstall the OS Nov 25 21:28:44 perhaps the class of machines where this will need to happen first is servers, and these will come with on-flash firmware Nov 25 21:28:49 likely UEFI Nov 25 21:30:18 jcrigby: Linaro also develops pieces of the early boot itself; u-boot for certain boards, a spl for others, tianocore for others, so handling the bootloader as part of the firmware seems useful for now :-/ Nov 25 21:32:03 lool, I agree. I did not mean to give the impression that we should get out of the bootloader business:) Nov 25 21:34:06 jcrigby: Back to the idea of a board id somewhere, I think the consensus in the boot architecture discussion was rather to describe how the hardware look like rather than passing only a single id and keeping tables of what that means; there might still be an id somewhere "just in case", but instead of "if board_id == beaglexm, then GPIO_X is foo" you'd get the data about what each GPIO does from e.g. the DT or in general from the firmware Nov 25 21:34:24 a bit like ACPI tables on x86 too **** ENDING LOGGING AT Sat Nov 26 02:59:57 2011