| suihkulokki | can someone here poke the right people to get the mutrace update to oneiric | 10:06 |
|---|---|---|
| ogra_ | whats that ? just a sync or is there anything to merge ? | 10:07 |
| suihkulokki | ogra_: it was uninstallable: https://bugs.launchpad.net/ubuntu/+source/mutrace/+bug/875928 | 10:09 |
| ubot2 | Launchpad bug 875928 in mutrace "mutrace: uninstallable as it strictly depends on a specific binutils version" [Medium,Fix released] | 10:09 |
| ogra_ | suihkulokki, err, the bug says it is already autosynced | 10:12 |
| ogra_ | oh, oneiric, hmm | 10:12 |
| hrw | http://www.androidpolice.com/2011/11/25/best-buy-dropping-asus-transformer-to-just-250-on-black-friday-dock-just-100/ | 11:18 |
| infinity | If only Black Friday was a global thing. | 11:20 |
| hrw | infinity: ;) | 11:20 |
| ogra_ | heh | 11:21 |
| ogra_ | and then you would havee to fight with the locked bootloader | 11:21 |
| hrw | o. asus locked bootloader? | 11:21 |
| hrw | assholes | 11:21 |
| ogra_ | well, thats what NCommander claims since UDS | 11:21 |
| hrw | heh... found another annoying thing in unity ;( | 11:22 |
| hrw | typing in window == raise window ;( | 11:23 |
| lilstevie | nop | 11:25 |
| lilstevie | they don't lock bootloaders | 11:25 |
| lilstevie | they block nvflash | 11:25 |
| lilstevie | :p | 11:25 |
| lilstevie | and even then it is just more, lack of the encryption key for communication | 11:25 |
| hrw | so user oriented only device | 11:26 |
| lilstevie | yeah | 11:26 |
| infinity | I'm a user, and I want to install another OS on it. :P | 11:27 |
| lilstevie | well, it won't be an issue forever | 11:27 |
| lilstevie | just for the moment | 11:27 |
| lilstevie | and sorry but I can't give an eta, cause I simply don't know | 11:27 |
| lilstevie | 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 | 11:30 |
| === Jack87|Away is now known as Jack87 | ||
| rsalveti | 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? | 14:20 |
| ogra_ | rsalveti, for 12.04 ? sure ! | 14:21 |
| rsalveti | we can probably do this next week | 14:21 |
| rsalveti | ogra_: great | 14:21 |
| ogra_ | i dotn think we care much for oneiric | 14:21 |
| ogra_ | next week is bad though, we're in A1 freeze | 14:21 |
| ogra_ | better the week after | 14:21 |
| lilstevie | A1 freeze? | 14:22 |
| ogra_ | on monday, yes | 14:22 |
| rsalveti | ogra_: fair enough | 14:22 |
| ogra_ | lilstevie, A1 release is on dec. 1st, we usually freeze from monday on for that | 14:23 |
| lilstevie | what is A1 freeze, thats a term I haven't seen or heard before | 14:23 |
| lilstevie | ah | 14:23 |
| ogra_ | alpha 1 milestone release | 14:23 |
| lilstevie | I get it now | 14:23 |
| ogra_ | i'm a lazy typer :) | 14:23 |
| lilstevie | heh | 14:23 |
| lilstevie | damn it, where is persia | 14:23 |
| * ogra_ sighs ... another question about "how do i recompile ubuntu from source for ARM" | 14:24 | |
| lilstevie | heh | 14:24 |
| lilstevie | whats new in precise | 14:29 |
| ogra_ | lots of software :P | 14:30 |
| lilstevie | heh | 14:30 |
| ogra_ | not much beyond that ... armhf should soon be there | 14:30 |
| lilstevie | fair enough | 14:31 |
| An-iSociaL | sup | 16:11 |
| micahg | suihkulokki: thanks for getting chromium building on arm, I'll have to see if I can tweak your fix to use the internal libvpx | 17:22 |
| An-iSociaL | mm | 17:24 |
| An-iSociaL | i need to check that out | 17:24 |
| An-iSociaL | you got a link? | 17:24 |
| An-iSociaL | hmm | 17:28 |
| An-iSociaL | nvm | 17:28 |
| janimo | rsalveti, we most definitely want new kernel for mx53 | 19:44 |
| janimo | is it in a ppa? | 19:44 |
| rsalveti | janimo: it is, but we can push the same way we did, with the proper sauce and such | 19:44 |
| rsalveti | currently I don't think the sauce is in sync with the latest set available | 19:45 |
| janimo | rsalveti, yes pushing it in the archive would be great | 19:48 |
| janimo | and our aim for this cycle is to use the same sauce on all arm subarchs, and the same as on x86/amd64 | 19:49 |
| janimo | modulo arch-specific config | 19:49 |
| rsalveti | janimo: got it, good to know | 19:49 |
| infinity | janimo: That would be lovely if we actually achieve said goal. | 19:54 |
| NCommander | ogra_: all of them are locked, some have been hacked (lag, but I didn't see the earlier ping in this channel) | 20:29 |
| micahg | will we have mx51 live images this cycle or is everything focused on mx53 now? | 20:38 |
| NCommander | micahg: I believe any mx51 support has to be driven from the community | 20:42 |
| * micahg was hoping for xubuntu on arm, but only has mx51 hardware | 20:44 | |
| NCommander | micahg: which mx51? Babbage? | 20:44 |
| micahg | NCommander: idk, I have a genesi smartbook | 20:45 |
| janimo | micahg, the linaro mx5 kernel supports both mx53 and mx51 | 20:45 |
| janimo | uboot packages are separate | 20:45 |
| NCommander | janimo: thought there was issues with it on the smartbook | 20:45 |
| micahg | janimo: cool, so images would be possible then | 20:45 |
| janimo | NCommander, I have no mx51 hw (nor do I want any) to know more about the issue | 20:46 |
| micahg | yeah, ISTR an issue with the kernel on the smartbook, it worked on the smarttop | 20:46 |
| NCommander | all I know is second-hand | 20:46 |
| micahg | ok, well, maybe I"ll come back in a month when I have more time to work on this | 20:46 |
| janimo | 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 | 20:47 |
| NCommander | micahg: if you are interested in driving it, there's a program in the process of helping getting new devices enabled in ubuntu | 20:47 |
| janimo | 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 | 20:47 |
| micahg | well, I have to see if I have enough time to drive such a thing, I'm already spread pretty thin this cycle | 20:47 |
| janimo | but than we could have a singel image instead of yet another slightly different from the rest | 20:48 |
| micahg | ooh, that's tempting :) | 20:48 |
| janimo | having mutliple almost identical images suck from almost every PoV | 20:48 |
| * micahg can try hacking on that during his "vacation" at the end of next month | 20:48 | |
| janimo | micahg, ping jcrigby he may give you some tips. Or equally usefully tell you it has been tried before or it is impossible,etc | 20:49 |
| janimo | I wish we did the same with omap3/omap4 too | 20:49 |
| micahg | ok, will keep in mind, thanks | 20:49 |
| janimo | but there the kernels are still not using a common source let alone binary | 20:50 |
| jcrigby | 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 | 20:52 |
| NCommander | 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 | 20:53 |
| micahg | jcrigby: thanks, any ideas what I can do then? | 20:55 |
| infinity | 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? | 20:55 |
| jcrigby | 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 | 20:56 |
| infinity | jcrigby: Cause I'd be inclined to get in on the bribery action if an mx51/mx53(/mx6?) unified uBoot would be possible. | 20:56 |
| NCommander | jcrigby: many PCs do share BIOS blobs and do runtime detection for DRAM addresses and such | 20:56 |
| jcrigby | NCommander, ok you got me there | 20:57 |
| NCommander | :-) | 20:57 |
| rsalveti | iirc the only thing kind of blocking us was the lack of a device id | 20:58 |
| NCommander | 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) | 20:58 |
| jcrigby | rsalveti, and if we are willing to write a board id to a file on sd then we can work around that | 20:58 |
| RoAkSoAx | win 8 | 20:58 |
| NCommander | 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? | 20:58 |
| infinity | jcrigby: Yeah, but if was can write to SD, then we can just as easily have multiple bootloaders. | 20:58 |
| rsalveti | NCommander: I believe that can be done | 20:58 |
| infinity | jcrigby: In the end, it still comes down to "no unified install image". | 20:59 |
| jcrigby | infinity, yes | 20:59 |
| rsalveti | could be harder than having an easy way to probe the device id, but can probably be a solution | 20:59 |
| NCommander | 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 | 20:59 |
| rsalveti | jcrigby: maybe something to invest time and check if it's possible | 20:59 |
| rsalveti | NCommander: in theory I believe it's possible, something to try | 21:00 |
| jcrigby | rsalveti, andy green talked about "finger printing" at cambridge | 21:00 |
| rsalveti | jcrigby: and as we'll have spl for omap3 soon, that could be an ideal solution | 21:00 |
| jcrigby | so you could peek at a list of places and go through a decision tree to figure out what the board was | 21:01 |
| rsalveti | jcrigby: yeah, kind of brutal force | 21:01 |
| NCommander | jcrigby: rsalveti: if you make it work, I'll buy you a keg of beer at the next UDS | 21:01 |
| jcrigby | it would be fragile | 21:01 |
| infinity | That sort of thing always is. | 21:01 |
| rsalveti | well, at least should be able to cover beagle and pandas | 21:01 |
| rsalveti | what would already be a nice thing | 21:02 |
| infinity | 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. | 21:02 |
| NCommander | jcrigby: how robust does it realistically have to be? Until OMAP4+ shows up, then it has a very simple thing to do | 21:02 |
| rsalveti | now that we have panda 4430 and 4460 out, that would probably be a valid solution for at least one year | 21:02 |
| jcrigby | yes, I guess we should do what is possible instead of dismissing it because of the corner cases that are not possible | 21:02 |
| rsalveti | until we have omap 5 in place | 21:02 |
| NCommander | 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? | 21:03 |
| rsalveti | jcrigby: is it something that you're interested to work on? | 21:03 |
| rsalveti | we can probably schedule something for 11.12, 12.01 :-) | 21:03 |
| jcrigby | NCommander, we can figure out SoC | 21:03 |
| jcrigby | board id is harder | 21:03 |
| NCommander | jcrigby: board id isn't really an issue is it? | 21:03 |
| NCommander | X-loader is intercompatible across all boards, just omap3/4 versions | 21:03 |
| infinity | (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) | 21:03 |
| rsalveti | well, we can try the soc and then check the gpios for board id | 21:04 |
| rsalveti | or similar | 21:04 |
| NCommander | if x-loader can determine whats its running on, thenit can load a u-boot.bin3/u-boot.bin4 | 21:04 |
| rsalveti | yup | 21:04 |
| NCommander | 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 | 21:04 |
| jcrigby | all mx flavours have user definable fuse locs that we could use for a board id if we wanted | 21:05 |
| jcrigby | ti has fuses but does not expose them to end user | 21:05 |
| rsalveti | yeah | 21:05 |
| jcrigby | arm should recommend to vendors to have fuses with soc ids and board ids | 21:05 |
| rsalveti | jcrigby: wasn't that part of the boot architecture discussions? | 21:06 |
| jcrigby | rsalveti, I hope so | 21:06 |
| rsalveti | maybe lool knows about it | 21:06 |
| jcrigby | actually the other solution is soldered on flash for the spl | 21:06 |
| jcrigby | like bios flash chips on pc's | 21:06 |
| infinity | Soldered on flash solves lots of issues, but it's terribly hard to go back in time and do that. ;) | 21:07 |
| rsalveti | true, I believe that was the requirement microsoft had | 21:07 |
| jcrigby | that we (distro/os vendors) don't touch | 21:07 |
| rsalveti | to enable arm boards with windows | 21:07 |
| rsalveti | bbl, dinner time | 21:08 |
| * NCommander would be greatly amused if we used Microsoft's boot crack to help solve some of our boot issues | 21:08 | |
| infinity | NCommander: The new world order will be much simpler to boot on, and Microsoft's logo requirements will certainly factor into that. | 21:10 |
| infinity | Of course, we have an urge to boot on non-new-world machines, which they don't care about. | 21:10 |
| NCommander | infinity: right up until we have to deal with secure boot on ARM | 21:10 |
| * NCommander keeps thinking newworld == powerpc :-P | 21:10 | |
| infinity | Heh. | 21:10 |
| infinity | 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. | 21:11 |
| infinity | One can hope, anyway. | 21:11 |
| infinity | Well, crack-avoidance. | 21:11 |
| NCommander | 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 | 21:12 |
| infinity | (The inverse there, of course, is that ARM device vendors love locking things down, so...) | 21:12 |
| * NCommander is honestly expecting the current Microsoft antitrust lawsuite to go as well as the first one | 21:12 | |
| lool | rsalveti: Not really; we rather discussed firmware, not specifying where it would live | 21:13 |
| jcrigby | 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. | 21:17 |
| lool | jcrigby: We would want some mechanism to update it etc. | 21:17 |
| jcrigby | lool, yes but that would be the exception not the normal path. Like when you update the bios on a pc | 21:18 |
| lool | Yes | 21:18 |
| lool | I guess it's the fact that we're building all the pieces that go on the SD card image for OMAP | 21:18 |
| lool | from scratch, using the latest versions | 21:18 |
| infinity | Yeah, but there's no real reason to do so. | 21:19 |
| infinity | (Well, except where we've been doing fun things like hacking PXE support) | 21:19 |
| infinity | Normally, though, treating uBoot like a BIOS is the sane and right thing to do. | 21:19 |
| infinity | And 99% of end users never touch their BIOS post-purchase. | 21:20 |
| lool | 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 | 21:20 |
| infinity | That's actually how I boot my quickstart. | 21:21 |
| infinity | But yes, not an ideal solution. :P | 21:21 |
| infinity | I just treat the micro slot on my QS as a BIOS PROM, basically. | 21:21 |
| NCommander | infinity: lool: we did that with babbage 1/2 :-/ | 21:23 |
| lool | There are so many things to say on this topic that I'm not sure it's wise starting it on IRC | 21:25 |
| lool | starting with the fact that we currently target many developer boards, not production hardware where we expect end-users to reinstall the OS | 21:25 |
| lool | perhaps the class of machines where this will need to happen first is servers, and these will come with on-flash firmware | 21:26 |
| lool | likely UEFI | 21:26 |
| === Ursinha is now known as Ursinha-afk | ||
| lool | 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 :-/ | 21:27 |
| jcrigby | lool, I agree. I did not mean to give the impression that we should get out of the bootloader business:) | 21:29 |
| lool | 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 | 21:31 |
| lool | a bit like ACPI tables on x86 too | 21:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!