=== 64MAAJNBW is now known as sunnydrake === fairuz_ is now known as fairuz === Baybal is now known as Baybal_Ni [09:33] persia, did you find a working nvflash yet ? [09:36] No, but I'm not sure that's the issue. [09:36] nvflash claims it can't see the USB device. [09:37] Looking at syslog, it seems that when I attach, two USB devices show, and then both disconnect. [09:37] * persia reproduces to get a viewable snippet [09:38] hrm. Reproduction failed. I wonder what changed. [09:39] well, are you sure the device was actually in flash mode ? [09:39] the usb device will only show up if its in that mode [09:41] Right, but it was the immediate disconnect that was the issue. As long as it stays connected, it ought be OK. [09:41] yep [09:45] Ugh. I tried to backup partition 0, and it failed, and now I get protocol errors. I guess this will be a bit of fun trial and error. [09:46] there is no 0 partition ;) [09:46] it starts at 2 [09:46] hence needing to power cycle :) [09:47] nvfalsh has a get partition table command [09:47] There's no 1 either? [09:47] no 1 either [09:47] What's that command? [09:47] * persia doesn't have a manpage :( [09:47] dont ask me what they are smoking at toshiba :) [09:47] it should have a help command [09:47] nvflash help ? [09:48] --help i think [09:48] with all the LD_PRELOAD mess [09:48] Indeed it does. [09:50] --getpartitiontable [09:50] with a textfile as output [09:50] Yep. So, I don't really like this tool. [09:51] nobody does [09:51] 1) It's non-free. 2) It doesn't qualify for multiverse. 3) It's not packaged. 4) It has no manpage, and poorly formatted --help. 5) it has some of the worst subcommand grammar I've ever encountered. [09:52] heh, yeah [09:52] sadly we need it [09:52] i dont know of any alternative yet [09:52] i wonder how trimsclice does it [09:53] they have largely the same board in their device [09:53] and u-boot is missing input support yet [09:53] and even then you would have to flash u-boot first [09:54] Lovely. I seem to get to run nvflash once per powercycle. [09:54] you can use the --resume command [09:54] replace the --bl flastboot.bin with it [09:54] it can only upload the bootloader once [09:55] Aha! And --resume lets me run another command without getting "usb read error (71): Protocol error" ? [09:55] i think so [09:55] try it [09:56] Hmm. Less than ideal. This power cycle the bootloader failed to install :/ [09:57] well, luckily you only have to do it once [09:58] --resume seems to work. [09:59] No, I'm super-extra-paranoid: I have to do it ~15 times, plus any that are unsuccessful. [10:00] i mean once you flashed successfull you dot have to do it anymore [10:00] though i would recommend also flashing a fallback kernel to part 5 [10:00] in case you mess up anything you can still boot from it [10:01] Why? Is there some way to select the partition from which one boots? [10:01] yes [10:01] if you hold down the home key during power up you get into fastboots recovery menu [10:01] If one bricks the device, can one restore with nvflash? [10:01] if you press 1 there it boots from part 5 [10:01] yes [10:01] the device is unbrickable [10:02] as long as you can restore the partitioning you will always get it back to life [10:03] That's nice. [10:03] part 5 is sadly only 5M big [10:03] so there is no space for nifty initrds [10:03] On most of my devices there is some flash that, if overwritten, will make the device completely useless. [10:03] tegra seems to be similar to omap here ... the rom code will always work [10:04] I suspect that is true for this, except that there is no way to write that flash (who said updating device firmware was a good idea) [10:04] and it seems the flash mode lives there [10:04] Oh, nifty. So it's not like BIOS flash, or the boot NOR on mx5 devices (yes, you can work around the boot NOR with the DIP switches, but they aren't exposed in real devices) [10:05] right [10:05] Seems that --resume only works once, and after two operations, I really have to power cycle. Oh well. [10:06] do you do a full backup ? [10:06] That's my plan. My hardware is different from yours, and my software is very different. [10:06] yeah, makes sense [10:07] (unless you have the REGZA control suite by default, etc.) [10:07] lol, no [10:07] what do you do with that, remote control your TV ? [10:07] That's what I thought :) [10:07] Rather, participate in your entertainment network. [10:08] ah, REGZA is more than a TV brand in .jp ? [10:08] At one level you can consider this a remote control for your TV, but you can also do things like switch the audio track from your TV to your stereo to your laptop headphones, control video streaming from your PVR to your TV or your laptop, and switch seamlessly, etc. [10:09] ah [10:09] REGZA is Toshiba's home entertainment brand. They do TVs, PVRs, Speaker systems, Keitais, Tablets, etc. [10:09] ah, i didnt know that [10:09] i only know trhe term from my TV :) [10:10] I haven't seen a REGZA Stereo, but the protocol should work with Onkyo or Denon hardware. [10:10] Yeah. The nifty stuff takes a while to export: someone has to figure out how to explain it to foreigners. [10:10] heh [10:11] No, seriously. Here they just stick a couple stickers on it, and the guy in the shop says "It connects to your network", and nobody asks questions. [10:11] Other places people want to know why they should pay more for feature X. [10:12] * persia suspects this has something to do with not having a law against selling electronics more than three years old [10:13] hey persia [10:13] XorA, Hey. [10:14] Im amused as I just bought an item that is now 30 years old [10:16] now I just need to build a circuit to adapt its video output to actually work with something modern so I can see it working :-D [10:17] * persia laughs [10:21] Grr... Partition 8 consistently fails. [10:21] is that the biggest one ? [10:22] i think nvflash has a prob with partitions bigger than 4G ... usually thats only the user data partition anyway and empty ... [10:22] Not by a long way. Biggest is 6774016 sectors. 8 is only 153600 [10:24] weird [10:25] Yeah, well, it's the oddities that make me do a full backup before I even boot the device. [10:29] * ppisati tried the mmu patch for kexec but still fails.. [10:44] ogra_, The partitions I can't read are labeled APP, UDA, and UDB. Do you know what these codes mean? [10:44] APP is android apps i think, did you look whats indside ? [10:45] ah, no. you said you didnt boot yet [10:46] (though the part table is completely shifted anyway in userspace ... you will never see part 2-6 in android [10:46] ) [10:47] UDA and UDB would be User Data A and User Data B? [10:47] so you have to guess which ones are APP, UDA, UDb [10:47] might be [10:48] Ugh. 8 gives a consistent format error, maybe some sort of copy protection. 12 and 14 just time out attempting to copy. [10:48] 14 should be mmcblk0p7 in userspace [10:48] that falls under the "biggest partition" stuff i mentioned above [10:49] no need to back it up [10:49] should be empty [10:49] I suspect so: it's 13,230M [10:49] yeah [10:50] But the 300M APP partition seems like something I want backed up, and I got just over a GB from the 1235 UDA parittion on one try, although most tries have been lower. [10:52] oh, if your device should offer you to upgrade to android 2.2, dont do it if you want to keep the dual boot option [10:52] if you should boot it into android before installing [10:53] I don't intend to ever boot Android on it, unless I have to verify a hardware issue for the warranty. [10:56] Connecting to a full speed hub rather than a high speed hub seems to help, although it takes *MUCH* longer. [10:57] HUB ?!? [10:57] * ogra_ just connects directly [10:58] You connect directly to the controller? What sort of device exposes that? I've never seen one. [10:58] i connect a mini usb cable between my x86 laptop and the ac100 [10:58] without extra hubs attached [11:00] Right. How many USB ports does your laptop have? [11:00] 3 [11:00] and i usually connect to a full speed port [11:01] Then you probably have 2 hubs in your laptop. The first providing those three ports and uplink to the second, and the second conneting to internal devices. [11:01] right, i thought you referred to an external hub [11:01] I was on high speed, which is something like 30x as fast, but it kept crashing. Now I'm on full speed, which works better. [11:01] k [12:01] ogra_, Aha! I encountered the 4G issue. You don't happen to know if there is a 64-bit nvflash floating around somewhere, do you? [12:02] hmm... sheet.zoho.com is default viewer of xls files under ubuntu? [12:02] hrw, In some environments (like those where openoffice/libreoffice was considered too heavy/slow/broken) [12:03] arm for example [12:03] From what I understand, natty libreoffice works, but it's kinda slow. natty koffice is a bit faster, but predates the revival/rebranding. [12:04] my daughter just sent panda x11 session to logout... power of power key ;:D [12:04] heh [13:04] Hey all, Could someone suggest anything? I'm running ubuntu on my arm tablet, I've built and installed touchscreen drivers and the cursor now follows my touch. The only problem is, no click event is launched on touch release/tap. Is there any way I could configure this? Thanks [13:04] Which tablet? [13:05] Vega [13:05] Try `xinput list` to find the id of your touchscreen [13:06] Yup, I have that [13:06] `xinput list-props ` will tell you what it belives it can do. [13:06] `xinput watch-props ` will let you see what it is sending. [13:07] ok, thanks [13:08] Depending on how the driver is implemented, you may need to have it send tap events, you may need to trap and process tap events to turn them into button activations, you may need to fiddle with input-utils to make sure the kernel has the right bits for the event driver... [13:08] hmm ok [13:09] It seems that despite moving my pointer, watch-props isn't providing any feedback. (I've tried all of the pointer devices and the touchscreen identifier specified in xorg.conf isn't in the list) [13:12] Right. I presume you're well past the xev stage, so diving in: does your driver provide a kernel event interface? [13:17] Umm, not too sure. This is the first time I've had to compile and install drivers manually so I'm kinda feeling my way around still. Through inspection of the source it seems it provides the click event via a call to xf86EventButtonPressP (or something similar to that) [13:17] Then it's just an X driver, making xinput the best tool for analysis. [13:17] Check your X log to make sure it's being loaded. [13:22] It seems to attempt to load it, but fails to initialise a touchscreen device and unloads due to EV_SYN missing. I can only assume it loads in some description of state as prior to installation, the cursor would just jump to 0,0 on touch. Post installation it follows touch [13:24] Hrm. I'm not sure. You might ask the team in #ubuntu-x, although they may send you back here if there are architecture-specific confusions. [13:24] (or someone else might know, if you wait a while) [13:25] isnt there also #ubuntu-touch ? [13:25] Is there? I hadn't encountered it before, but yeah, if it exists, it's a better place :) [13:26] Indeed there is! [13:26] Great, I'll ask there - thanks for the help ^^ [13:26] they focus more on enabling multitouch in existing drivers though [13:26] Well going from 0 to N is multi, right? [13:26] so they might not know much about new ones [13:27] the prob smells a bit like evdev would just select a mouse driver for the device [13:28] Or any other class of incorrect autodetect. [13:28] yep [13:29] ogra_, My notes have a confusion: I'm writing boot-2.6.37-1-ac100-SD.img to partition 6, right? [13:29] yes [13:29] OK. The command was listed once with a 6 and once with a 5, so I just wanted to double check. [13:30] Oh my. Partition 14 reduced to 0.1% of raw size with gzip :) [13:31] heh [13:32] OK. partition flashed. Device OFF. USB disconnect. SD insert. Close eyes and cross fingers... [13:32] :) [13:32] * ogra_ crosses [13:33] Yeah. ALSA errors then bootsplash. Thanks a lot! [13:33] awesome ! [13:33] the rest should be trivial [13:34] Yep. [13:35] Heh. Jasper. [13:35] jasper ? [13:35] there shouldnt be any jasper in these images [13:36] This is casper? What's giving me initial configuration? [13:36] oem-config ? [13:36] there should be neither casper nor jasper [13:37] Oh. It's an OEM image. I suppose that makes sense. [13:37] right [13:37] its directly derived from the omap3 one [13:37] (although it's a bit annoying now knowing that I have to go through this config process twice) [13:37] thats why i said you should set a rootpw or edit /etc/shadow [13:38] for the SD boot [13:38] this will be automated by an init script for the actual image [13:38] so you only need to cp the tarball onto a formatted SD [13:38] Really, we should use the installer. [13:39] But as we discussed before, this requires tracking down why cp is slow. [13:39] no [13:39] i think the oem team has a udeb that can install tarballs [13:39] Yes. Really yes. I'm inflexible on this. Maintenance overhead. [13:39] that might be an option [13:39] but i'm really not going through setting d-i to work with universe kernels etc [13:39] It's all part of the same suite that includes live-helper. [13:40] No, but NCommander has a WI to do that for a different spec. [13:40] So you don't have to worry about it. [13:40] so it will stay live/oem [13:40] NCommander, has no WI to make d-i work with universe bits [13:41] there is only one d-i related workitem ... and thats just a partitioning reciepe for partman [13:42] It's on a foundations spec. [13:42] universe ? [13:42] Yes. [13:42] that would need a complete redesign [13:42] d-i needs the kernel in main [13:43] and all other bits it uses to create images [13:43] You were *at* the UDS discussion about it. Now isn't the time to complain. [13:44] well, *shrug* [13:44] So, anyway, assuming the component issue is resolved, and the speed issue is resolved, I'll insist on proper installer images. [13:44] i wont change the ac100 image, since i find wasting hours of user time for copying or formatting tasks completely pointless [13:44] But that's not soon: make them however you want until then. [13:45] and i wont change them in the future either ... [13:45] Please read what I wrote above again? Your objection is already included. [13:45] it adds massive complexity for maintenance as well as for the enduser [13:46] Really it doesn't. It *streamlines* maintenance and provides a consistent experience for end users. [13:46] we have oem-config exactly for this task ... i dont plan on moving away from it [13:46] Mind you, currently it's painfully slow, which needs sorting. [13:46] It's also impossible, which needs sorting. [13:46] there is more than slowness [13:46] you have to do a d-i rebuild for every kernel version change [13:47] that doesnt scale to universe kernels [13:47] (it is already annoying enough for the non mainline kernels we have in main ... which was one of the most pressing reasons for preinstalled oem images) [13:48] So, this will be sorted. [13:48] not by me, mind you [13:48] No, not by you. [13:48] and as mentioned above, you will need a lot to convince me to move away from oem images [13:48] But when everyone else has done their bit, these images will switch to using an installer. [13:48] not mine [13:48] I have a Lanya smart book X6-7A with an SSD and I was wondering if putting ubuntu on it would be any different. It doesn't have a normal load up like another computer would, it just pops up the SmartBook screen and does the 25 second loading process. Would I put a live load in a USB and go from there? [13:48] Whether you do this or not at that point can be discussed later. [13:49] D34X, What's the processor? [13:49] i find it a massive waste of manopower to even put time into that [13:49] persia - ARM 926 [13:49] its fine for server but i dont see even the slightest reason to push us back into stonegae with the desktop images [13:50] D34X, Ubuntu doesn't support that processor. You might try Debian. [13:50] Poo.... [13:51] ogra_, I feel the opposite. I have no interest in remaining in an age of hardware-dependent images. I want generic solutions, that work for arbitrary hardware. We are getting much closer with the tools to be able to do this, and when we can, I'll have no interest in supporting less generic solutions. [13:52] where would a generic image help on the ac100 ? [13:52] well, let's assume we are able to construct a generic tree that supports all Tegra2 devices. [13:52] and whom would a generic image help on a specific board that can only run this specific image ? [13:52] LOL [13:52] Then we should only maintain that image. [13:52] that will never happen [13:52] Why LOL? [13:52] It will. This is the *point*. [13:53] because nvidia doesnt care at all and the board specific implementations collide heavily [13:53] If this was not a goal (and a believeably achievable goal), we wouldn't do doing any of this. [13:53] well, you wont see such a kernel for a long long time [13:54] it might happen at some point indeed ... like it did for the beagle after what ... 4 years or was it five [13:54] I'll continue to expect it tomorrow, and be disappointed with anyone that feels otherwise, simply because if we don't believe it will happen, we won't help make it happen, and we'll be discouraging the folk that are trying. [13:54] the only organization working on that (linaro) has no support at all for tegra [13:55] and there is no movement from either side [13:55] That's true today. I'm not convinced it has always been true nor that it will always be true. [13:56] *if* you get such support (which is already unlikely because every odm seems to implement its own bootloader solution) it will happen long after your ac100 collects dust in your basement [13:56] All I ask of you is that if the valid bugs you raise can be sorted, and we can make generic solutions, you help with those, rather than refusing. If you're right, and it's a long time before we get there, the cost to you of agreeing is nothing. [13:56] oh, i surely wont block any progress either way [13:57] i just wont change my images :) [13:57] even in a generic setup i would go for oem images for desktop [13:57] For all architectures? [13:57] at least on devices wheer you have things like hardcoded partition tables etc [13:58] its just pointless to count on d-i for two features we dont use/need at all [13:58] I'd rather have a generic installer that could recognise those devices, and skip bothering the user about partitioning, but rather just do the right thing. [13:58] I think you aren't understanding what I'm saying. [13:58] thats what an initrd script can do as well [13:58] in an easier way for the user [13:58] I don't intend to show the user anything pointless: that's poor interaction. [13:58] and with zero maintenance for the developer [13:59] With two pieces of code to maintain, to have bugs, to have security issues, and two places to fix them all, and inconsistency to confuse the support and advocacy teams,etc. [13:59] i only care for one place really ... [14:00] So someone else has to care for another? No opportunity for collaboration? [14:01] i wont pull d-i into the installation [14:01] d-i has its areas where it makes sense ... in this particular install to totally doesnt and only gets in the way [14:01] You do know that live-helper is a d-i component, so you'll be doing that anyway for all the preinstall images that use livecd-rootfs today, right? [14:01] not during install time [14:01] only during build time [14:03] what i would prefer to see would be a generic oem images initramfs hook [14:04] so that you hand over filesystem and target device on the cmdline or some such and a tarball gets unpacked to the target after verifying teh taball md5 sum ... [14:04] without all the crap i need to do for d-i [14:04] Have you looked at live-helper? It does something very similar to that. [14:04] And it does it from within d-i [14:05] no, i havent yet, i will have to before A1 though [14:05] And it can do it without bothering the user with lots of d-i prompting. [14:05] You may want to: I believe it both represents that which you protest against and that which you wish existed, simultaneously. [14:05] it bothers me as maintainer with the complexity i add through d-i [14:06] i dont want to a) maintain d-i b) have d-i booted at all for these kind of images === ZebraDroid is now known as ZebDroid|Work [14:06] having to maintain a ton of d-i components vs a 10 line initramfs shell script is really not wnat i'm after [14:08] Who said anything about "a ton of d-i components"? [14:09] And d-i is just some initramfs scripts. [14:10] So, for instance, if someone wrote partman-ac100, it could simply return, never prompting the user, and adding hints to everything else about how/where to install everything. [14:10] So, for instance, if someone wrote partman-ac100, it could simply return, never prompting the user, and adding hints to everything else about how/where to install everything. [14:10] d-i is a huge complex pile of stuff [14:10] of which i dont need 99% [14:11] Then don't put those bits in your image. [14:11] It's *designed* to be flexible, modular, etc. [14:12] i know [14:13] you wont convince me [14:14] I'm not trying to convince you. I'm trying to inform you that as a result of the change to live-helper, *every* image will become a d-i image. [14:14] now that would be really bad [14:14] And I'm trying to tell you that you needn't fear this change, and that it's not that different from what you do now. [14:14] and i doubt thats true [14:14] That's what the shift to live-helper means. [14:14] you think we will drop casper ? [14:14] No. [14:14] see [14:15] I think we'll wrap casper in a filesystem that we deliver with d-i through the live-helper support infrastructure. [14:15] heh [14:15] after we ported l-h to upstart indeed :) [14:15] given that upstart will now run the whole initrd [14:16] oh, and indeed all of d-i too [14:16] sorry, but i dont see us changing the whole structure on one release [14:16] Writing a single compatibility upstart job is trivial, so there's no blocking porting effort. [14:17] we'll see [14:17] Slowly moving more of the early boot stuff to upstart can happen over time. [14:17] i expect that in function and form of casper or the live initrd there wont be many changes [14:17] Really, go read about live-helper. Learn how it works. [14:18] I think you'll be pleased as much as you're annoyed. [14:18] * persia decides thrudhr has a nice ring to it [14:18] i wont be pleased for sure :) [14:23] how to change boot.scr without regenerating it by hand? panda [14:25] .. use my awesome flash-kernel boot.script->boot.scr demangler :D [14:25] hrw: or like this [14:25] sudo mkimage -A arm -T script -C none -n "Ubuntu boot script" -d boot.script boot.scr [14:25] guys does anyone have knowledge of a quick way to disable these horrible new scrollbars? [14:26] Don't install overlay-scrollbar? [14:26] both kinds.. gedit seems to have a kind of floating on the side scrollbar and other apps just have a kind of little orange line [14:26] I want traditional ones back [14:26] Neko: for efikas it uses /boot/boot.script [14:27] Neko: as base of boot.scr [14:27] I don't think I have a choice not to install overlay-scrollbar [14:27] hrw, run flash-kernel again it should do it on all boards? [14:27] Why not? The rdepends list is short. [14:28] Neko: right.. [14:28] but you want to do it "not by hand", you can't... you have to invoke it somehow with manual labor [14:29] persia, I just removed the package and I still get orange-line scrollbars [14:31] Hrm. That's unexpected. That package is supposed to be where the orange widget lives. [14:32] If you want different defaults, use a different seed. [14:32] the whole point is I am trying to replace the metapackages so we can basically define a behavior for our not-quite-ubuntu natty build [14:32] except, if I take these out, the scrollbar thing still happens [14:33] ahhh here we are [14:33] you need to remove liboverlay-scrollbar-0.1-0 too [14:33] Then I'm wrong. I thought it was that. Maybe grep for "scrollbar" in the natty-changes mbox to see what else got patched. [14:33] Ah, you found it. Excellent. [14:33] it's just reaaaaally difficult to hit those little orange lines with a netbook trackpad [14:34] also since firefox and thunderbird are blacklisted we get different behavior per app which is just not desirable [14:34] I wonder how this affects unity though [14:34] Try it with one of the tiny little "optical pointers". It becomes essentially impossible. [14:35] weurghhh [14:35] saving a file in gedit defaults to a directory called "chrome" [14:37] maybe because I am root.. but that's strange [14:42] Is it not possible to remove X / completely from the ARM version ? Everything I try just prompts it to want to download another desktop setup ... [14:43] ZeZu, It certainly is possible. I don't have X installed on my beagle. [14:44] You will have to either 1) start from a minimal image (you might be interested in the natty headless developer images), or 2) spend a lot of time making sure you have every reverse dependency removed. [14:48] I figured it would be something along those lines ... dependency mess , do you have the sgx drivers installed on your beagle ? [14:50] I didn't have nearly as many issues w/ beagle as i do w/ panda ... the pvr kernel drivers refuse to cross compile w/ 2.6.39-rc7 [14:51] if your .39 kernel is properly packaged they wont ;) [14:52] ZeZu, I don't have the sgx drivers on my beagle (no monitor, no need) [14:54] oh, wait you said cross ... [14:54] indeed [14:54] i fear there even a properly packaged kernel wont help [14:54] i dont think dkms gets along well with cross building [14:54] sounds like a good future project for hrw *g* [14:55] yes well i found out the hard way ... actually you have to pass ARCH=arm or else it tries to build bits and pieces for host system ... [14:56] define properly packaged btw, might help ... i do recall having to package the headers differently when building for beagle, but i don't think it used dkms at that time [14:58] ogra_: D: === prpplague_afk is now known as prpplague^2 [17:14] hi , does any one have a u-boot for omap4 panda board, where we 'saveenv' works ? .. any help pls [17:15] j /#panda [17:15] avinashhm, Does it not work for the u-boot in the Ubuntu images? [17:16] persia, sorry .. wasn't aware of the ubuntu images .. can u point me to .. i ll try [17:18] Most recent images at http://cdimage.ubuntu.com/releases/11.04/release/ [17:18] You can choose between a full environment (optimised for netbooks, but suitable for desktops), or a headless image as a base for arbitrary development. [17:19] ogra_, Do you know why there aren't any .torrent files for the omap images? [17:20] persia, thanks man .. i ll pick up these net book image and check out ... [17:26] avinashhm: When you say "saveenv", are you trying to save the u-boot environment between reboots? The panda doesn't have any emmc or nand for storing u-boot settings. [17:27] GrueMaster, can't we store to MMC .. just asking , i am not sure ? [17:28] Not from uboot. But you can modify the /boot/boot.script in our images and reflash it to the boot partition with flash-kernel. [17:28] (or modify it manually and reapply the u-boot crc with mkimage). [17:28] heh. kernel segfault during debootstrap. Extra points! [17:30] janimo: poke re chromium> any luck? [17:44] GrueMaster, ok .. i ll try to modify boot.script then .. thanks man [18:03] rsalveti: have the PXE boot patches landed in the Linaro u-boot tree? [18:10] NCommander: not that I know, jcrigby should know better [18:10] NCommander, no not yet [18:11] jcrigby: any idea when it will land? [18:12] NCommander, I could push them to the linaro-next if that is useful to you [18:12] jcrigby: indeed it would be [18:12] or are we talking pushed to archive? [18:13] ok, I'll do that [18:13] jcrigby: when it hits the linaro u-boot, it will get piced by the archive next time we update it [18:13] jcrigby, For pushed-to-archive, if you can get a candidate package ready, it's easy to get someone else to help drop it in. [18:16] NCommander, persia ok I'll prepare a 2011.05 release based on current upstream rc and the PXE patches [18:17] jcrigby: thanks, that's a huge help [18:20] jcrigby: it'd be good to include the tftp patches, but probably need more work at the ones that enables ehci for omap4 [18:21] rsalveti, the patches don't break anything so we can include them for those that want to experiment? [18:21] I know we have ehci support for omap3 already, so I believe we can also make it work with beagle xM [18:22] rsalveti, yes that would be great [18:22] jcrigby: sure, it's not touching anything outside usb, ehci and smsc driver [18:22] guess we can also include them [18:26] Thanks! That helps us play. [18:50] micahg, none so far, but I did not spend time on it since the UDS [18:53]