[01:09] hah! google.com/+ interactive tour blew up my X session on ubuntu 11.04 pandaboard :) [01:09] google + will blow your mind (or your embedded systems mind) === asac_ is now known as asac [03:25] is anyone around that can tell me how the initial boot stuff works with the preinstalled image [03:26] with my device I found nvflash to have a 4GB filesize upload restriction [03:33] Maybe. What part don't you understand? [03:34] well, 1 is triggering it on another device [03:34] 2 is a bit more difficult to explain [03:34] Another device? Do you mean different partitions? [03:34] (or rather, different /dev/ nodes) [03:34] no I mean the transformer rather than panda [03:35] :p [03:35] I upload an ext4 image [03:35] which does not take up all the room it is allocated [03:37] Ah, so you want to resize the filesystem on first boot? [03:37] Doesn't the transformer have significant internal flash? [03:38] yeah 16 or 32 [03:38] but I am trying to retain enough for the android system to co-exist [03:38] Heh, OK. Ubuntu requires 4GB, and 8 or more is recommended. [03:39] well my current image is 4.2GB [03:39] Is the transformer capable of booting from alternate media (e.g. SD)? [03:39] which is nvflashes max upload [03:39] yeah it can, but emmc is soooooo much faster :) [03:39] its like an F1 next to a smart [03:39] That's fine. [03:39] Sure, but slow installation media isn't the end of the world. [03:40] ah installation media :p [03:40] In cases where it is possible to boot off removable media OR internal storage, you don't want to do what is done with the panda. [03:40] I see [03:40] Instead you want to cause booting off the SD to perform an install to the internal media [03:40] actually that would be better [03:40] (and you want to give the user choices to set up dual-boot or completely reformat and just run Ubuntu). [03:41] providing everyone has µSD [03:41] infinity, Were you ever pointed to the branch for that tarball installer ogra wrote? [03:41] yeah that does sound nicely [03:41] nicer* [03:41] persia: Nope, but we'll get it all public RSN. [03:41] Oh well. [03:41] persia: Especially since it'll find its way into an official image soon. :P [03:42] lilstevie, So, there exists an installer that does precisely what you want. Unfortunately, it's not being developed transparently, so you have to wait, or reinvent the wheel :( [03:42] eh :( [03:42] (Not that you have to wait long, mind you) [03:42] I am not reinventing something when it does not need to be [03:42] infinity: define not that long :) [03:42] There's no reason it's not public except a bit of laziness. We have the technology to fix that. [03:43] I'm not sure there is a technical solution to ogra being lazy, really. [03:43] heh [03:43] Like, you're not waiting for weeks/months on process or anything, just waiting hours/days on people being poked sufficiently violently. [03:43] heh [03:43] * persia has been waiting months [03:43] well it would make things easier [03:43] persia: I poke harder. [03:43] flash kernel, insert SDCard, make the choises [03:43] True. I've only tried cajoling, shaming, and bribing. [03:43] does this installer have the option for a virtual keyboard [03:43] Sharp sticks. [03:43] Bribery doesn't work [03:44] lilstevie: Virtual keyboard is mostly up to your FS image, not the installer. [03:44] lilstevie, From my experience with my dynabook, it's more 1) tell the bootloader to boot from SD, 2) insert SD card, 3) make the choices. [03:44] lilstevie: Well, "installer" here meaning "tiny initramfs shim". [03:44] Kernel should come from the archive. [03:44] StevenK, It's worked for me many a time. Corruption and graft are rife. [03:44] infinity: heh, cause that is somethign of a must for me, while the dock is there, it is not always going to be [03:44] some people don't own the keyboard dock [03:45] lilstevie: I'll keep that in mind as I generalise this. Since I suspect that virtual keyboards and early boot will NOT get along. [03:45] lilstevie: We might want to generalise something for phone-like hardware interrupt hooks. [03:45] lilstevie, Aren't there some function buttons on the tablet? [03:45] (things like "press the home button to select installation to media X", etc) [03:46] persia: power, vol-up vol-down [03:46] We can work with that. [03:46] hc devices have no other GPIO buttons [03:46] Yeah, if there's any hardware button at all, we can do clever things. [03:46] I have a bit more to work with on the SGT [03:46] vol-up/vol-down to select. Power to choose. Hold power for hard-reset. [03:46] I have that plus a touchstrip [03:46] For some value of "we" that won't be me, unless I have devices to muck with. But I could proof-of-concept the idea on my N900 or G1 or something. [03:47] Do you have a working kernel for that? I'd *really* like to upload it. [03:47] infinity, If you can get something working for the n900, the kubuntu-mobile folk would love you. [03:47] persia: for which ? [03:47] They've a wiki page with all sorts of annoying mucking about currently. [03:47] lilstevie, SGT. [03:48] We were talking about it a couple weeks ago, and you ran into a touchscreen issue, and I hadn't heard from you since. [03:48] persia: oh the issue is much bigger than we though [03:48] persia: My N900 is pretty much Just Another armel Buildd right now, so yeah, I'm happy to screw with it as a dev device again. [03:49] 2.6.32 is the only kernel with a working tsp at the moment, and one of the utouch team has found a bug [03:49] apachelogger, Notice the volunteer for the installer work above [03:49] but I have been a little preoccupied with the transformer for the time being [03:50] Oh, annoying. Can I have a kernel with broken touchscreen? [03:50] We can call that a bug, and fix it later, but we can't fix not having a package once the freezes start. [03:50] Real men ssh to their tablets and phones anyway [03:50] Touchscreens are for the weak. [03:51] (Is the above pretty much proof of all the Maemo work I did for Nokia?) [03:51] persia: heh, well bug on which [03:51] persia: cause both of them are kinda working [03:51] 2.6.35 has a weird issue where clicks are not being interpretted correctly [03:52] lilstevie, So, we upload linux-sgt 2.6.35+, and we file a bug "Touchscreen driver is broken". [03:52] and 2.6.32 is duplicating the touch frame [03:52] There was a 2 month period or so where neither the hardware OR on-screen keyboards worked on the N9 prototypes. :P [03:52] infinity: Which gave you what, ssh? [03:52] infinity, Isn't that why one has bluetooth? [03:52] persia: sure then I can upload one :) [03:52] StevenK: SSH and serial. [03:52] lilstevie, That would be lovely! Put it anywhere, and I'll dig through it for packaging stuff, and stick it in the archive. [03:53] persia: source or binary [03:53] and we need to mark 2 major bugs :) [03:53] Source. Preferably packaged source :) [03:53] That's fine. Once it's in the archive, we just report them to LP. [03:53] persia: How do you pair a bluetooth keyboard with a host you can't talk to? ;) [03:53] 1) TSP, 2) Temp broken command line [03:54] infinity, agressive udev rule. [03:54] persia: well I have te source up on github if that helps [03:54] persia: I imagine the GUI folks probably pulled such tricks. I don't touch UI anyway, so whatever. Serial/SSH are less hassle than poking phones anyway. [03:54] Well, kinda. Are you up for packaging it, or do you need someone else to help with that? [03:55] well I have only packed for butchered apt before [03:55] so I would need some help :) [03:55] infinity, You are my favourite flavour of luddite :) [03:55] * persia tries to find jcrigby's handy kernel packaging instructions [03:56] persia: Have you seen how I use computers? Heck, even my mobile phone is pretty much just a mobile terminal emulator. [03:56] do I need to strip the .gitignores? [03:56] persia: X exists to multiplex terminals. That's it. [03:56] infinity, I've seen you use GUI browsers :p [03:56] lilstevie, https://wiki.linaro.org/Resources/HowTo/PackageYourOwnKernel [03:57] It's not absolutely perfect, but it will get you 95% of the way there. [03:57] persia: I blame that on the fact that HTML5 and Flash and other fancy crap is pretty painful in lftp/w3m/lynx/etc. [03:57] If you want a comparison source, take a look at the linux-n900 package: I tweaked a few bits there. [03:57] infinity, You just haven't configured your MIME handlers properly then. [03:58] Heh. [03:58] lilstevie, Actually, please ignore the hints to add ccache in that HOWTO: I forgot to clear that, and my first upload FTBFS. [03:59] heh ok [03:59] If any of the free swf reader libraries were actually usable, I'd totally waste a weekend writing an aalib frontend. [03:59] Why aalib? [03:59] No reason you can't spawn a useful viewer [04:00] * persia fondly remembers web surfing with twm and no internal browser handlers [04:00] Ahh, but if I want to live my life entirely in terminals. [04:00] persia: thanks, will get on to that soon :) [04:00] There are any number of terminals that can show bitmaps... [04:00] lilstevie, If you get stuck or run out of time, let me know, and I'll see what I can do from your git tree. [04:01] Well, I guess with framebuffers being the norm these days. In my mind, I still live in a "terminal = text mode" world. [04:01] Even if that's almost never true anymore. [04:01] But I'd rather if you have time to learn it, as I'd be counting on you to maintain it :) [04:01] persia: :) no problems [04:02] Cool. Two more kernels queued :) [04:02] Now if only there were documentation on how to create an image with arbitrary kernels and extra driver bits from a published rootfs... [04:03] * infinity glares. [04:04] We'll get there. [04:05] We're not in a terrible hurry. The kernels need a preview cycle before any of the product managers are supposed to request an image anyway. [04:05] (sometimes people work around that, but it involves bribing the release managers, and it's just easier to wait a few extra months). [04:05] heh [04:05] I accept pie. [04:06] And peanut butter cookies. [04:06] I've been trying to get someone to send me homemade peanut butter cookies for months. [04:07] I'll accept a job [04:07] :p [04:07] I'll give you a job baking me cookies. That's some corporate synergy right there. [04:07] hah [04:08] * persia suggests http://www.simplesimonpies.com/ as preferred pie provisioners [04:08] persia: They don't have pumpkin. [04:08] * micahg wishes -pie and arm would get along [04:09] infinity, You failed to specify [04:09] micahg: We have Top Men working on that bug, apparently. [04:10] * persia has lost the site for delivery of peanut butter cookies, unfortunately :( [04:14] * micahg wonders if giving infinity pie will get me -pie on arm :) [04:14] persia : Delivery .. of .. wha? [04:14] persia : Sign me up. [04:15] * Martyn is busy putting in even _more_ patches to u-boot [04:15] to allow loading configs from disk, with menu [04:15] approaching syslinux capability now [04:15] syslinux levels of capability rather [04:15] Martyn, We've a temporary issue: simplesimonpies apparently doesn't carry pumpkin, which means we aren't actually arranging a delivery just now. [04:16] poo [04:16] Martyn, Did you see jcrigby's proposal for the configuration file? He had something that would allow one u-boot compilation per SoC, rather than per-board (at least in theory). [04:16] Not to mention pecan-coconut being an abomination. [04:16] I did .. [04:16] persia : It's a ways off though [04:17] infinity : coconut creme, equally so [04:19] Hrm? I thought it was RSN, for a unified OMAP u-boot. [04:20] persia: I didn't get the impression that it was THAT soon when we chatted about it in Dublin. [04:20] persia: Just a definite "working-toward" thing. [04:20] Which beats "it's on the TODO". [04:21] yep [04:21] it _might_ be ready, just after Oneric [04:21] GrueMaster: mahmoh: found the issue with pxe [04:21] is a bug at the device tree support at u-boot [04:21] rsalveti: Issue? [04:21] rsalveti: *perk* [04:21] rsalveti, Nice! [04:21] what happened? [04:22] rsalveti, you are my hero! [04:22] Martyn, I'm reminded: do you have network and usb gadget drivers for u-boot for your devices? [04:22] network, yes [04:22] USB, no (we don't do USB) [04:22] Heh, if there's no port, there's no need for the driver. [04:23] But if you don't do USB, how do you handle KVM? [04:23] Well, in-theory- I guess you could put a USB device on a PCIe bus .. but .. um .. yea [04:23] jcrigby: hey! [04:23] persia : We have our own built-in management CPU [04:23] the issue is kind of stupid [04:23] persia : Where we're going .. we don't need .. keyboards: ) [04:23] Martyn, So only VKVM via IPMI? [04:23] SOL, yep [04:23] all out of band [04:24] Ah, that works. [04:24] jcrigby: common/cmd_pxecfg.c, check function label_boot [04:24] rsalveti : Looking here too [04:24] jcrigby: in the end it tries to set the agv[3] [04:24] bootm_argv[3] = getenv("fdtaddr"); [04:24] and later call do_bootm(NULL, 0, 4, bootm_argv); [04:24] so argc is always 4 [04:24] Most of the implementations I've seen in the past end up wiring something that looks like PS/2 or USB to the HW, but if you don't need that, more power to you (or rather more power saved, really). [04:24] even when argv[3] is NULL [04:25] so later on u-boot things the ftd file is there, because argc > 3 [04:25] and tries to use it, and boom, seg fault [04:25] Aha! [04:25] so, transformer is wifi capable now, but this is far from optimal [04:25] rsalveti : Oops.. [04:25] needs a full network block in the wpa_supplicant [04:25] no scanning [04:25] Martyn: :-) [04:25] rsalveti : Make sure you tell jason.hobbs@calxeda.com [04:26] we'll fix it ... [04:26] Martyn: sure, cooking a patch now [04:26] plus it means we need to patch the upstream, again .. *sigh* [04:26] * Martyn is on the trail of getting rid of pre-baked configs in configuration.h now [04:27] since, if everything works according to plan, you'll be able to load the configuration and environment in u-boot from -- an AHCI device (FAT/EXT2,3,4), off the network, off some local flash ... [04:27] instead of having it all baked in [04:28] leaving the only thing needing to be baked in .. the order of where to search [04:28] Why? [04:29] Create a menu that lists the various (detected) options, and whilst it is scanning them, waits for the user to select the preferred one. [04:29] if the user completely fails to be paying attention, then fall back to a predetermined order once the scan is complete. [04:29] rsalveti: when you have a u-boot with a patched pxe please ping me [04:29] mahmoh: in a minute :-) [04:30] persia : Chicken and egg problem [04:30] Martyn, Why? [04:30] persia : Because even with a timeout, you need to have -some- indication of where to look first [04:30] since the u-boot environment is coming from there, and not from configuration.h [04:31] Martyn, So, as you're doing device discovery, you're prepared to accept an interrupt from console input. If an interrupt is received, you wait for the user to confirm the list before proceeding. If no interrupt is received, you go ahead with your prebaked order. [04:31] persia : Also, u-boot doesn't do detection [04:31] persia : At least, not _yet_ it doesn't [04:31] Fix the yet :p [04:31] it only detects what you tell it to :) [04:31] yes yes yes [04:31] But I'll attack this one (large) problem at a time [04:31] rsalveti: in a min.? I was hoping tmw ;) [04:31] if I try to patch too much at once, Wolfgang will have kittens [04:32] haha [04:32] lol [04:32] Martyn, So, short term: you tell it to detect foo, bar, baz, and quux in a predetermined order for your hardware. [04:32] Then you start constructing a menu whilst it's doing that. [04:33] And if the user does something, you let them reorder the sequence before starting the selected config. [04:33] If the user is too slow, you proceed with your initial intentions. [04:33] Yep, that's more or less what's in store [04:33] although the menu generation code is brand-spanking new [04:33] and it's really designed to handle PXE stuff [04:33] however, things are progressing nicely [04:34] Ah, good. Your initial announcement made me think it was just going to check foo, bar, baz, and quux in compile-time order, and boot the config found first. [04:34] persia : Well that's what _will_ happen in the first pass [04:34] (which config might include a menu, etc.) [04:34] Awwww..... [04:34] however, from whatever source it finds first, it will load the menu [04:35] and so it's not any worse than, say, syslinux booting from EXT2, or a CD, or whatever [04:35] And thanks to the AHCI support, it just may .. MAY .. be possible for me to boot a CD on ARM .. wouldn't that be something? [04:35] Just in time for the whole CD technology to go obsolete, of course .. but .. :) [04:35] I'm going to pretend you didn't say that. [04:35] I suppose. Can't we do that today with EHCI and USB CD drives? [04:36] If someone asks me for ARM ISOs, I intend to stuff my fingers in my ears and scream "la la la, I can't hear you". [04:36] mahmoh: http://people.canonical.com/~rsalveti/pxe/3/u-boot.bin [04:36] infinity : I -promise- you the format of an ARM CD will be something simple and sane [04:36] infinity, There is a reason why the provided images on cdimage.ubuntu.com are supposed to be less than 700MB compressed. [04:36] infinity, Something about tradeshows and pressing costs... [04:36] infinity : Such that you won't have to bend your tools [04:37] Martyn: Good, I don't like bending my tool. [04:37] Err. [04:37] infinity: But ARM is a good place to break clean away from CD's [04:37] Martyn, they have already been warped beyond recognition, in ways that may significantly improve the situation for other architectures. [04:37] infinity: There is absolutely NO reason that we shouldn't be booting from good, standard 1G memory sticks [04:37] Martyn: Yeah, I tend to boot from USB or SD on all my non-ARM hardware too. [04:37] I have put in an order for 500 ubuntu, oneric logo'ed usb keys for Orlando to give away [04:37] Martyn, trade shows...pressing costs... [04:38] (But in that case, it often involves pretending it's a CD, which is VILE) [04:38] infinity: It shouldn't ... at least not on ARM [04:38] infinity : AFAIK, the ARM installer is nothing more than the standard net installer really.. [04:38] infinity, Hrm? Even most of my powerpcs can boot from USB if I glower at them enough. [04:38] bunch of seeds and a repository .. which is a far easier layout than the usual CD layout [04:39] no ISO9660 to worry about [04:39] persia: I was pointing a finger at x86 in that case. PPC is much saner, as are all the arches that grew up in the UNIX world. [04:39] Martyn, So, there are *four* installers currently provided (well, three and the one expected later this week). [04:39] yeah, noticed that [04:39] infinity, I don't believe I have any remaining x86 devices that can't boot USB, but then I'm kinda rough on hardware. [04:40] * Martyn got his hands on a Nufront machine .. cute laptop, but FLIMSY [04:41] someone out there MUST be making a better laptop with the Cortex A9 [04:41] Martyn, All of them are based on debian-installer in one way or another. We have the base d-i environment (sometimes called "alternate" or "netboot"), the ubiquity wrapper for running it in a live environment, jasper which does just enough to launch oem-config, another d-i wrapper, and another initramfs shim (yet to be named), which again does just enough to run oem-config (at least, as last I heard it described). [04:41] Although I did see a Kal-El based prototype here in Austin that -was- seeeeexxxy ... looked like a thin thinkpad .. ran 2Ghz, had 3Gb of RAM [04:42] mahmoh: let me know if it works for you [04:42] jcrigby: just sent you the patch [04:42] had one hell of a pretty screen (1400x900) too [04:42] Martyn: also included jason [04:42] thanks! [04:42] he'll get to it tomorrow when he gets into work [04:42] * Martyn is doing OpenMPI work this weekend [04:43] making sure the whole OpenMPI set works .. [04:43] great, panda booted with PXE :-) [04:43] and working fine [04:43] then I need to convince all -you- folks to compile and put OpenMPI 1.5.3 into the repository [04:43] awesome [04:43] jcrigby: then we just need to fix the mac address problem with panda [04:43] rsalveti : Awesome... [04:43] rsalveti : Doesn [04:43] and it'll be done :-) [04:43] Doesn't the panda use a USB adapter? [04:44] so you have to get USB up first, then the network adapter, then get all the PXE stuff up? Ever fun. [04:44] Martyn: it uses smsc95xx, usb hub and usb eth [04:44] yeah.. thought so [04:44] the kernel is setting a unique mac address using the die id [04:44] rsalveti: small problem [04:44] we just need to use the same code at u-boot [04:44] I'll be -much- happier when more SoC vendors get off their asses and integrate a NIC right into the AMBA bus like we do [04:44] mahmoh: didn't work? [04:44] rsalveti: it works, now I have more work to do! I was hoping for a few days off ;) [04:45] rsalveti: want a bug for it? [04:45] mahmoh: ;-) [04:45] Buah-ha-ha-ha! [04:45] mahmoh: don't need, just sent the patch to jcrigby [04:45] rsalveti: ok but we should track the work ... [04:45] hm, maybe a bug to update the package before the 07 release... [04:45] mahmoh: yeah, please fill a bug :-) [04:45] Bah. Filing bugs is for when you *don't have the fix ready. [04:46] then we can patch the package [04:46] and properly track it [04:46] rsalveti: against lp:u-boot? [04:46] mahmoh: against package u-boot-linaro [04:47] you can also link at u-boot-linaro project [04:47] mahmoh: let me know the number and I'll take care of it [04:47] shortly [04:50] rsalveti: u-boot-linaro ? [04:50] mahmoh: yup [04:51] rsalveti: I'll file it there then you can add the other one? [04:51] mahmoh: sure [04:51] sweet, thx [04:56] rsalveti : Hey, mail me the patch as well -- martin@calxeda.com [04:56] Martyn: sure, 1 sec [04:56] (yeah, different style address to everyone else ... early hire hath it's privs ... and besides, who wants to type martin.bogomolni@ all day?) [04:57] Martyn: sent [04:57] danke [05:02] rsalveti: is this panda specific? I'm guessing not. [05:02] mahmoh: nops [05:02] but you'll only find this issue if you build with CONFIG_OF_LIBFDT [05:03] rsalveti: all yours, thx all! https://bugs.launchpad.net/ubuntu/+source/u-boot-linaro/+bug/808612 [05:03] Ubuntu bug 808612 in u-boot-linaro "pxe fails after loading kernel and initrd" [Undecided,New] [05:03] mahmoh: great, thanks [05:03] np [05:06] nighty, nite [05:06] and good work, I appreciate it (everyone) === Lopi is now known as Lopi|idle [09:05] hi all [09:05] can any one point me how to build a rootfs using rootstock for custom kernel [09:15] iam following steps mentioned at here to build rootfs [09:16] http://elinux.org/BeagleBoardUbuntu [09:16] i have a doubt in [09:16] stm__: For which board? [09:16] sudo ./rootstock --fqdn omap --login ubuntu --password temppwd --imagesize 2G \ --seed wget,nano,linux-firmware,wireless-tools,usbutils --dist natty --serial ttyO2 \ --components "main universe multiverse" \ --kernel-image http://rcn-ee.net/deb/natty/v2.6.39-x1/linux-image-2.6.39-x1_1.0natty_armel.deb [09:16] pandaboard [09:17] what changes i have to do in the above command [09:17] i have bulded uimage [09:17] I don't think you need to make any changes? [09:17] What's wrong with the image that's produced? [09:17] of xenomai patched kernel 2.6.37.6 [09:18] no , i have to build rootfs for the custom kernel [09:19] which patched with xenomai alreay [09:20] how should i use that kernl to build the rootfs [09:54] stm__: Sorry, I didn't know you replied [09:54] stm__: Please use my nick when replying [09:54] ok [09:54] stm__: The rootfs is not built for the kernel [09:54] stm__: Once you have a rootfs you can just install a new kernel into it and it'll just work [09:55] stm__: Is your kernel in *.deb or uImage form? [09:55] lag: mkdir /tmp/xeno cd /tmp/xeno wget http://www.codesourcery.com/sgpp/lite/arm/portal/package7851/public/arm-none-linux-gnueabi/arm-2010.09-50-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 tar -xvjf arm-2010.09-50-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 export PATH=/tmp/xeno/arm-2010.09/bin:$PATH git clone --depth 1 git://git.xenomai.org/xenomai-2.5.git git clone --depth 1 --branch for-ipipe-2.6.37-arm git://git.xeno [09:56] lag: this is the procedure i got the patched kernel and [09:56] builded u Image [09:57] lag: how should i build the rootfs using this uImage [09:58] stm__: You don't [09:58] stm__: I'm assuming you're using an SD card? [09:58] lag: yes [09:58] iam using sdcard [09:59] Mount the SD card [09:59] Llag: i placed uImage and mlo and uboot.bin in fat16 partion [10:00] sorry [10:00] That's it then [10:00] lag [10:00] Boot it [10:00] All you have to do is replace the uImage with your own kernel [10:00] placed modules on ext partion [10:00] Great [10:00] Done - boot it [10:01] lag: its not booting [10:01] Then there's a problem with the kernel [10:01] Or u-boot [10:01] Does u-boot boot? [10:02] if dide not use update initramfs then its givng me root partion is not mounted [10:02] u-boot [10:03] Paste me your output [10:03] lag: if i done update initramfs [10:03] @ paste.ubuntu.com [10:03] ok [10:16] lag:http://paste.ubuntu.com/641780/ [10:18] stm__: Can you paste your u-boot variables (printenv) [10:18] stm__: Did you back-up the old kernel? Does that still work? [10:18] lag: yes i backuped [10:19] In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 Panda # printenv bootcmd=if mmc init ${mmcdev} [10:19] sorry [10:20] bootcmd=if mmc init ${mmcdev}; then if run loadbootscript; then run bootscript;i bootdelay=3 [10:20] bootcmd=if mmc init ${mmcdev}; then if run loadbootscript; then run bootscript;i bootdelay=3 baudrate=115200 loadaddr=0x82000000 console=ttyS2,115200n8 usbtty=cdc_acm [10:21] mmcdev=1 mmcroot=/dev/mmcblk0p2 rw mmcrootfstype=ext3 rootwait [10:23] lag: here is the printenv [10:23] http://paste.ubuntu.com/641786/ [10:26]