[07:51] <twb> lilstevie: I bought a TF101 (yaaaay!)  Should I update to the latest android firmware before attempting to switch it to debian?
[08:19] <lilstevie> twb: probably not :p you will end up blowing away everything on the fs and need to redo that stuff anyway
[08:21] <twb> $coworker said he thought it might have important fixes for the keyboard part or something
[08:21] <twb> (He bought a 16G one from RUC a few months ago, and followed your stuff to put Ubuntu on it last week.)
[08:22] <lilstevie> well are you going pure linux, or dualboot
[08:22] <twb> I don't care about android
[08:22] <lilstevie> cause things like prime include dock firmware updates
[08:22] <twb> Yeah, I think he is running prime
[08:23] <lilstevie> to be honest dock firmware updates really are to benefit android
[08:23] <twb> I mean MAYBE it'd be useful to not blow away android on day one, but I kinda doubt I'll ever use it
[08:23] <twb> It's not like I ever used windows or vxworks on my netbooks and routers
[08:24]  * twb thinks -- I probably shouldn't be drinking either
[08:27] <lilstevie> heh, I don't have android on my device
[08:28] <twb> Good man
[08:41] <twb> Bleh, I forgot I have to get pppd working with this 3G dongle before I'm allowed to play with my transformer
[08:41] <lilstevie> lol
[08:43] <soren> I have a Pandaboard rev A3. http://www.omappedia.org/wiki/Prebuilt_ubuntu_binaries only mentions up to A2. What to do?
[08:49] <lilstevie> soren: it doesn't really matter
[08:50] <soren> Ok.
[08:50] <lilstevie> soren: https://wiki.ubuntu.com/ARM/OmapNetbook only has one image
[08:51] <lilstevie> and the only difference between the A2 and A3 is the CPU has been updated for ES2.2
[08:54] <soren> I'm installing the headless image on an SD card right now. I don't have a serial cable handy. I don't suppose that image comes with any sort of networked access (ssh or even telnet)?
[08:56] <lilstevie> that I don't know I don't have a panda, nor have I used the headless image before
[08:58] <soren> Ok.
[09:58] <twb> OK, got the 3g doodad working, back to transformer
[09:58]  * twb digs up pile of napkins from last week when we were talking about this
[10:07] <twb> OK, so step #1 of flashing it is to find a copy of the nvflash ELF binary that can be trusted, i.e. download it myself from nvidia.com rather than "some forum post"
[10:07] <twb> Is that achievable?  AIUI it's only available bundled in their dev board SDK, but I'm happy to download 200MB of zip file to get a trusted version of that one binary.
[10:15] <lilstevie> twb: it is in the L4T pack
[10:15] <lilstevie> which isn't that big
[10:15] <twb> Do you have the exact URL on you?
[10:15] <twb> Otherwise I'll wade through their search page
[10:18] <twb> FFS, all the ddg.gg hits are 404d
[10:18] <lilstevie> http://tegradeveloper.nvidia.com/content/linux-tegra-release-12-alpha-1-released
[10:18] <twb> ty
[10:18] <lilstevie> driver package has nvflash binary
[10:20] <twb> Man, 10MB, why do all these forum weenies keep reposting it
[10:21] <twb> It's like those bt users who put a bunch of .rar's in another rar
[10:21] <ogra_> there is a deb of that driver (not sure it will work on your kernel thrugh)
[10:22] <ogra_> https://launchpad.net/~ac100/+archive/ppa
[10:23] <twb> Well, eventually I'd like to run stock Debian armhf kernel with as few device-specific patches as possible, but for now I was just going to git clone lilstevie's tegralinux one and compile that
[10:23] <lilstevie> twb: well I begrudgingly package it, if I didn't I would have a bunch of people continually complaining that my pack doesn't work
[10:24] <lilstevie> twb: which one, my repo has 2 :)
[10:24] <lilstevie> one is L4T driver compatible but only works with u-boot
[10:24] <twb> Dunno, I was gonna ask you once I was confident I had nvflash working and metastrap was chugging away building a btrfs debian sid armhf rootfs :P
[10:24] <twb> Oh, I can replace the bootloader with uboot?
[10:24]  * twb like uboot
[10:25] <lilstevie> yes, but u-boot is in its infancy
[10:25] <twb> Meaning that it isn't production-ready for this device?
[10:26] <lilstevie> it is missing some stuff :p
[10:26] <twb> I mean, I'd like to minimize my use of non-free software, but at the same time I don't want to brick it or not be able to e.g. use the screen
[10:27] <lilstevie> APX is always there
[10:27] <twb> That's the stage 1 bootloader?
[10:27] <lilstevie> bootrom
[10:27] <lilstevie> stage0
[10:27] <twb> OK
[10:28] <twb> It would be nice if I could interactively pick which kernel to boot and whether to pass "single" to it, but I'm assuming that's... nontrivial at the moment.
[10:29] <lilstevie> well you could do that with the standard bootloader
[10:29] <twb> Oh, OK.  I thought that only had two options "normal boot" and "recovery boot"
[10:29] <lilstevie> by adding single to the recovery kernel :p
[10:29] <twb> Yeah, that's plan B
[10:30] <twb> two kernels plus single vs. no single means four cases not two :P
[10:30] <lilstevie> if we can get the GPIO driver to co-operate with u-boot it would be trivial
[10:30] <lilstevie> but at the moment it is non-functional
[10:30] <twb> OK
[10:30] <twb> That ac100 PPA has a main and restricted in pool/, but only a main in dists/.
[10:32] <lilstevie> ogra_: doing 'dhclient -r;dhclient wlan0' seems to add the route, RE: network manager not setting the default route for me in oneiric
[10:33] <ogra_> weird
[10:33] <ogra_> did you file an NM bug ?
[10:33] <lilstevie> not yet
[10:33] <lilstevie> was about to do that, only hit me today to try renew the lease
[10:34] <lilstevie> renewing*
[10:45] <ogra_> twb, go to the package details,. thats a launchpad bug (the package has "restricted" in the control file, LP doesnt really have a concept for restricted packages)
[10:46] <twb> OK
[10:46] <twb> was just mentioning it fyi
[10:47] <ogra_> yeah, its known :(
[10:47] <ogra_> for the P release we will hopefully have the driver in the actual archive :(
[10:47] <ogra_> err
[10:47] <ogra_> :)
[10:48] <twb> lilstevie: awesome, that version of nvflash is 1) statically linked; and 2) has --help.  Much nicer than "doesn't run at all" old version from <wherever> that I was looking at last time
[10:48] <twb> (static linking = works without a 32-bit userland)
[10:49] <lilstevie> twb: hmm, well the one in my package is from that dump
[10:50] <lilstevie> the other one floating around is the asus one
[11:00] <twb> OK, this is weird
[11:00] <twb> I connect the keyboard (dock) 40-pin connector to my laptop, and lsusb can see two devices on it -- both ASUS vendor USB ID, one is a broadcom bluetooth device
[11:02] <lilstevie> interesting
[11:03] <twb> Ah, nm
[11:03] <twb> the bluetooth is just the onboard bluetooth in my netbook
[11:04] <twb> Gods, that 40pin cable is flimsy
[11:11] <twb> OK, why isn't this working?
[11:11] <twb> http://paste.debian.net/128994/
[11:12] <twb> Running nvflash as root seems like the coward's way out; I'd rather just have udev make the tf world-writable or so.
[11:15] <ogra_> i think nvflash uses raw device access, you need root
[11:15] <twb> Surely if I have write access to /dev/foo, that is "raw device access"
[11:17] <twb> The only related superuser capability I can see is CAP_SYS_RAWIO
[11:17] <twb> And that looks to be for something else
[11:17] <ogra_> well, i havent seen anyone getting nvflash to work without root in the 1.5 years i work with nvflash :)
[11:17] <ogra_> if yuo find a way, tell me :)
[11:18] <twb> OK, I did this
[11:18] <twb> chgrp -Rh twb /dev/bus/usb/*
[11:18] <twb> Now I get a different error
[11:18] <twb> USB device not found255
[11:18] <ogra_> intresting
[11:18] <twb> Maybe I need to plug the 40pin into the table directly instead of the dock?
[11:18]  * ogra_ never had to modify anything to flash his ac100
[11:19] <twb> btw same error running it as root
[11:19] <ogra_> plugging and running nvflash just works
[11:19] <twb> ogra_: running as root I bet tho
[11:19] <ogra_> indeed
[11:19] <twb> I try to be a bit paranoid :P
[11:19] <ogra_> i only use nvflash for new ac100's anyway though
[11:19] <ogra_> after the first flashing i can flash from userspace
[11:20] <twb> yeah openwrt is like that too
[11:21] <twb> lilstevie: do I need to do something special to put the TF into guest most?
[11:21] <twb> *mode
[11:22] <twb> hmm, there is some little "asus sync" thing on the tf's screen
[11:23] <twb> ANd another "usb debugging connected"
[11:41] <twb> Grmph, I'm not having any joy getting nvflash to see it
[11:41] <twb> Maybe I should read the docs more than just --help
[11:44] <twb> Hmm, gentoo's tegra2 page says "To power on the board, you need to press *BOTH* the Force Recovery and the Power on buttons until the LEDs power up. Then execute the following command to flash the bootloader."
[11:46] <twb> OK, booting while holding the volume down gives "safe mode"
[11:46] <lilstevie> ok back
[11:46] <lilstevie> sorry disconnected for a sec
[11:47] <twb> lilstevie: short version: I'm trying to make "./nvflash --getbct" do something useful
[11:47] <lilstevie> you should get error 0x4 if you invoke nvflash like that :p
[11:47] <twb> Hum
[11:47] <lilstevie> yeah you cant
[11:47] <lilstevie> the tf is an SBK locked device
[11:47] <lilstevie> you need to use the --sbk option
[11:48] <lilstevie> and with that you also need to specify --bl --bct and --config
[11:48] <twb> lilstevie: first of all, do I need to do anything on the TF to put it into "upgrade mode" or anything?
[11:49] <lilstevie> vol up plus power on boot will put it in APX
[11:49] <twb> OK
[11:49] <twb> And I need to do that?
[11:50] <lilstevie> need to do which?
[11:50] <lilstevie> put the tablet in APX?
[11:50] <twb> Do I need to put it into APX mode to use nvflash
[11:50] <lilstevie> yes
[11:51] <twb> OK.
[11:51] <lilstevie> nvflash is for communicating with apx
[11:53] <twb> goddammit, now it isn't turning on at all
[11:54] <twb> ok here we go
[11:55] <twb> It seems like from off I can't just hold both vol+ and power and have it boot
[11:56] <twb> Do i get any visual feedback when it goes into APX?
[11:58] <twb> Aha
[11:58] <twb> Answer is no, the screen is off, but lsusb suddenly sees an nvidia device
[11:59] <twb> Progress
[11:59] <twb> ogra_: you can use nvflash as non-root user provided you have write access to the block device.
[12:00] <ogra_> which you usually dont :)
[12:00] <twb> ogra_: but what this means is that you wrie a udev rule to say something like GROUP=disk
[12:00] <ogra_> eeek
[12:00] <twb> Then instead of running it as root, you run it as a non-root user who is in the disk group
[12:00] <ogra_> thats more of a security hole than using root
[12:01] <twb> Yes, well, you know what I mean.
[12:01] <ogra_> the disk group should never be used for users
[12:01] <twb> If you want use polkit or something to hand it to the user on the local screen or whatever
[12:01]  * ogra_ -> off for a phone conf
[12:01] <twb> np
[12:01] <lilstevie> later ogra_
[12:02] <twb> lsusb can't see it anymore after doing that bct (which did finally fail with error 4)
[12:02] <lilstevie> yep that is cause of SBK
[12:02] <lilstevie> error 0x4 is when the command is invalid
[12:03] <twb> Does it quit APX on the first command, or the first bad command?
[12:03] <lilstevie> which in the case of these SBK locked devices that means the command is incorrectly encrypted
[12:04] <lilstevie> it shuts down USB communication, only on incorrect bootrom commands
[12:04] <twb> OK
[12:04] <lilstevie> but when you use an SBK locked device you need to upload the miniloader (built in to nvflash) and bootloader to get interactive
[12:05] <lilstevie> at which point commands are no longer encrypted anyway
[12:05] <twb> OK, the SBK in your forum post (ending in 98) works for me, yay.
[12:05] <lilstevie> awesome :D
[12:06] <twb> So now I have a working nvflash I need to learn how to use it.
[12:06] <twb> First goal is to make a complete dump of all the data on there to begin with, just in case I ever want to put it back
[12:06] <lilstevie> ok, well best thing is to pass it create, and just configure the flash config
[12:06] <lilstevie> ok ./nvflash -r --download <partition ID> <filename>
[12:07] <twb> Shouldn't I get the partition table first? :-)  I don't know /a priori/ what partition IDs there are
[12:08] <lilstevie> well you could do that :p
[12:08] <lilstevie> but why reinvent the wheel
[12:08] <lilstevie> http://androidroot.mobi/2011/06/13/nvflash-on-asus-transformer/
[12:09] <twb> Because I trust a dump I make myself more than "what some guy told me"
[12:09] <twb> Same reason I wanted to get nvflash direct from nvidia.com
[12:09] <twb> (No offense intended, I'm just a paranoid sysadmin.)
[12:09] <lilstevie> nono I mean for flash.cfg and bct
[12:10] <twb> So presumably you can't just say "nvflash, please fetch flash.cfg and bct from my device, and write it to a file" ?
[12:10] <lilstevie> no
[12:10] <lilstevie> what you get is a basic information
[12:10] <twb> OK, then I fall back to plan B, which is using the prepared version you linked to :-)
[12:10] <lilstevie> which you then need to work on
[12:11] <lilstevie> and bct is something that is not really easy to get :p
[12:11] <lilstevie> on device it is encrypted
[12:11] <twb> Yeah but symmetrically -- you have the shared secret :-P
[12:11] <lilstevie> yeah
[12:11] <lilstevie> :p
[12:11] <twb> Also this is the 32GB version -- does that matter?
[12:12] <lilstevie> no
[12:12] <twb> Phew
[12:12] <lilstevie> flash.cfg is universal
[12:12] <twb> Does it matter for bct?
[12:12] <lilstevie> the 0x808 partition ID fills to end of partition
[12:12] <twb> OK, awesome
[12:12] <lilstevie> and no bct is config data for the tegra2 cpu not the emmc controller
[12:13] <twb> Ooooh right
[12:13] <lilstevie> and er, partition attribute to end of flash*
[12:14] <twb> I am used to in uboot sheevaplug where IIRC your "partition table" is basically half a dozen disk offsets and to boot you say "jump to block XXX of the MTD and start executing whatever you find there"
[12:14] <twb> I thought bct was that stuff
[12:14] <lilstevie> ah
[12:14] <twb> afk getting caffeine
[12:14] <twb> thanks for all your help btw
[12:14] <lilstevie> on sheeva bct is in the SPI IIRC
[12:15] <lilstevie> cya
[12:18] <twb> back
[12:18] <lilstevie> heh that was quick :p
[12:19] <twb> got a coffee machine in the office
[12:20] <lilstevie> ah
[12:20] <twb> Ah, OK, I got bct mixed up with these .cfg files in your linux-flash-kit.tar.gz
[12:22] <lilstevie> yeah the cfg files are the partition
[12:22] <twb> Is flash/default.cfg the flash.cfg that matches a brand new tf?
[12:22] <lilstevie> yes
[12:23] <twb> You know, it just occurred to me that if nvflash wants to write to a file instead of stdout, I won't have space to write it on my netbook
[12:23] <twb> I was planning more like dd if=/dev/sda1 | gzip >sda1.orig.gz
[12:23] <lilstevie> nvflash normally writes out to stdout
[12:23] <twb> Cool
[12:23] <lilstevie> oh wait you mean for the backups?
[12:24] <twb> Yeah
[12:24] <twb> e.g. --getbct wants me to provide --bct-file or so
[12:24] <lilstevie> the partition with UDA is the emmc
[12:24] <twb> OK
[12:24] <lilstevie> well, the "emmc to android"
[12:25] <lilstevie> the rest of your backup isn't that big
[12:25] <twb> OK
[12:26] <lilstevie> don't need to back up PT, USP
[12:26] <lilstevie> PT is generated at nvflash --create
[12:26] <lilstevie> USP is the "staging" partition that blobs are written to from android
[12:27] <lilstevie> for OTA updates
[12:27] <twb> Is android using ext3 or 4?
[12:27] <lilstevie> ext4
[12:27] <twb> Because default.cfg says 3, but the licenses page in android on the device, says ext4
[12:27] <twb> OK
[12:28] <lilstevie> it is ext3 for nvflash
[12:28] <lilstevie> because nvflash doesn't know or understand the difference
[12:28] <twb> Yeah, I guess nvflash doesn't distinguish.
[12:28] <twb> Wish I knew what it actually did different for "ext3" vs "basic"
[12:28] <twb> What lives in MSC?
[12:29] <lilstevie> tags
[12:29] <lilstevie> as for ext3 vs basic
[12:29] <lilstevie> it writes it differently
[12:29] <lilstevie> basic just does a 1:1 raw write
[12:29] <lilstevie> but MSC I guess really does not need to be backed up either
[12:30] <twb> Whereas ext3 only writes active blocks?
[12:30] <lilstevie> something like that yeah :)
[12:30] <twb> Yeah, cool.
[12:30] <lilstevie> still takes a full image, but only writes the ones that have content
[12:30] <twb> Even if I completely hose the UDA partition, I can still drop into APX and upload a new one, right?
[12:30] <twb> Because I plan to use btrfs :-)
[12:30] <lilstevie> even easier
[12:30] <lilstevie> :p
[12:30] <lilstevie> UDA is "User DAra"
[12:31] <twb> haha
[12:31] <lilstevie> so like in android, drop to CWM and do a factory reset
[12:31] <lilstevie> :)
[12:31] <twb> "honolabaru data-san"
[12:32] <twb> CWM is the rescue partition?
[12:32] <twb> Like, the rescue mode uses a completelt separate root= filesystem?
[12:32] <lilstevie> CWM is Clockwork Recovery Mod
[12:32] <lilstevie> android recovery doesn't use a root= perse
[12:32] <lilstevie> per se*
[12:33] <lilstevie> the initrd is /
[12:33] <lilstevie> and things like /system get mounted atop it
[12:33] <lilstevie> android doesn't pivot_root
[12:33] <twb> Christ, that's... unnervin
[12:34] <twb> I mean I work with some elaborate initramfs's, but nothing like android or splashtop
[12:35] <lilstevie> well android has its base set of tools in the initrd as well as the init info
[12:35] <lilstevie> but the android system itself gets mounted into /system
[12:35] <lilstevie> I certainly don't consider it "normal"
[12:36] <twb> Silly embedded devs :P
[12:36] <lilstevie> heh
[12:37] <lilstevie> the bootimg is really just a zImage squished up with an initrd, + a custom header with some information for the bootloader
[12:38] <twb> Yeah, that's how devicevm does it for their splashtop images, too
[12:38] <lilstevie> not all android devices follow that though
[12:38] <lilstevie> samsung don't
[12:38] <twb> When you compile the kernel you can even say "my ramdisk is that dir over there, tack it onto the end of the zimage"
[12:39] <lilstevie> they use an initramfs compiled when you compile the kernel
[12:39] <lilstevie> using the proper zImage packing method
[12:39] <lilstevie> because they use a partition called params
[12:39] <lilstevie> samsung use a u-boot based bootloader though
[12:40] <twb> So: ASUS are doing it wrong, film at 11
[12:40] <lilstevie> param.lfs is an j4fs filesystem with a param.blk which acts as nvram
[12:40] <twb> At least it's not using a damn graphical EFI BIOS like these new x86-64 motherboards I got last week
[12:40] <lilstevie> heh
[12:40] <lilstevie> I'm used to EFI tbh
[12:41] <lilstevie> all my computers have EFI
[12:41] <lilstevie> well AppleEFI
[12:41] <twb> "Sorry, we only support huge yelling bouncing icons, not text.  This way is TEH FUTURE"
[12:41] <twb> I am referring to MSI ClickBIOS
[12:41] <lilstevie> ew
[12:41] <lilstevie> need something like rEFIt
[12:42] <twb> Last time I touched Apple it was still using OpenFirmware, which I still looooove
[12:42] <lilstevie> OF was win
[12:42] <lilstevie> I miss OF
[12:42] <twb> And POWER beats x86-64
[12:42] <lilstevie> hands down
[12:43] <lilstevie> thats why my file server is an xbox360 :p
[12:43] <twb> I'm not happy about ARM's royalty model either, but they've pretty much won the embedded space
[12:43] <lilstevie> using the JTAG hack ofc
[12:43] <lilstevie> ARM may have a shoddy royalty model, but their processors are win in the embedded space
[12:43] <twb> Yep
[12:44] <lilstevie> I couldn't imagine going back to MIPS or the likes
[12:44] <twb> Although I think they should probably ditch thumb and jazelle and stuff and just bake one ISA into any given core
[12:44] <lilstevie> thumb does have its benefits
[12:44] <twb> lilstevie: Forth is best for microcontrollers tho
[12:44] <twb> REPL FTW
[12:45] <twb> You said MSC is for tags -- what are tags?
[12:45] <lilstevie> well like bootloader args
[12:46] <lilstevie> kinda what I was trying to say, but a bit more complex
[12:46] <lilstevie> they also serve as tags for telling recovery to do certain actions
[12:47] <lilstevie> most common use though is a file called recovery tells the bootloader to boot straight into recovery
[12:49] <twb> Oh, OK
[12:50] <twb> So kinda like a combination of nvram, syslinux.cfg and /forcefsck
[12:50] <lilstevie> kinda'
[12:50] <lilstevie> just done very wrong
[12:50] <twb> Heh
[12:51] <lilstevie> I hate the bootloader
[12:51] <twb> One day
[12:51] <twb> One day we will have coreboot on the PROM
[12:51] <lilstevie> I'd love to see UEFI :p
[12:51] <twb> And it will not load seabios or refit, it will load the openfirmware implementation that sun dumped into coreboot just before oracle ate them.
[12:52] <lilstevie> heh
[12:52] <twb> EFI... saying "DOS 6 like UI!" as if that's a good thing
[12:52] <lilstevie> :p
[12:52] <twb> And it is, man, it even has commands like "dir"
[12:53] <twb> And you run "if" at the prompt and it says "error: only works in batch scripts"
[12:54] <lilstevie> heh
[12:54] <twb> Ruh roh
[12:54] <twb> ./nvflash --read UDA /dev/stdout  --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 | file - # <-- hung
[12:56] <lilstevie> ok have you already uploaded the bl and stuff?
[12:56] <twb> Nope
[12:56] <lilstevie> also by ID I mean the numerical ID
[12:56] <lilstevie> you need to put it into bootloader update mode
[12:57] <lilstevie> apx wont listen to many commands when an SBK is set
[12:57] <twb> Do I do that with ./nvflash --bl --sbk ...; and then it's in bootloader update mode until next reboot?
[12:58] <twb> Ah, I need a bootloader.bin?
[12:59] <lilstevie> yes
[12:59] <lilstevie> and you also need a bct
[12:59] <twb> I notice the bootloader.bin you supply doesn't match any of the ones in tegra-linux-12.alpha.1.0
[13:00] <lilstevie> no
[13:00] <lilstevie> it is an asus one
[13:00] <twb> Hum.  Can I d/l that from foo.asus.com? :-)
[13:01] <lilstevie> yes
[13:01] <lilstevie> in the dlupdate you need to extract a file called "blob"
[13:01] <twb> Got the URL handy?
[13:01] <lilstevie> no sorry
[13:06] <twb> Is it the stuff labelled "firmware", like 200MB dl file?
[13:07] <lilstevie> yep
[13:08] <twb> OK
[13:10] <twb> Damn page needs js, and isn't working even in my fallback js-capable browser :-/
[13:10] <lilstevie> :/
[13:17] <twb> OK, reverse-engineered their js
[13:18] <lilstevie> heh
[13:21] <twb> It's EeePAD/TF101/UpdateLauncher_US_epaduser8659.zip, just need the hostname...
[13:22] <twb> Which is in http://support.asus.com/js/Download.js
[13:23] <twb> Bam: http://dlcdnet.asus.com/pub/ASUS/EeePAD/TF101/UpdateLauncher_US_epaduser8659.zip
[13:24]  * twb closes Xorg again
[13:37] <twb> lilstevie: FYI, the md5sum of blob also doesn't match yours
[13:37] <lilstevie> ?
[13:38] <lilstevie> oh right you are doing an md5 of the entire blob
[13:38] <lilstevie> :p
[13:38]  * twb sighs
[13:38] <twb> Lemem guess another yak to shave
[13:38] <lilstevie> that blob is 4 or 5 partitions worth od data
[13:38] <lilstevie> of*
[13:38] <twb> Oh, stupid me, the blob is the whole thing
[13:38] <lilstevie> https://github.com/AndroidRoot/BlobTools
[13:38] <lilstevie> not the whole thing
[13:39] <twb> Gotcha
[13:39] <lilstevie> but it is the partitions EBT(bootloader) PT(tegraparts pt) SOS(recovery kernel) LNX(normal boot kernel) at minimum
[13:40] <lilstevie> also there are multiple versions of the bootloader
[13:40] <lilstevie> so md5 may not match
[13:40] <lilstevie> there are at least 7 versions
[13:41] <twb> I might as well use the latest one from that blob tho, right?
[13:41] <lilstevie> but only 3 are visually noticeable
[13:41] <lilstevie> yeah, well, doesn't really matter :p
[13:41] <lilstevie> only thing with the newest is that to boot from root=/dev/mmcblk1p* you need to add a rootwait
[13:42] <twb> Hum
[13:42] <lilstevie> that is the microsd
[13:42] <twb> Oh, no, I only care about booting from eMMC
[13:43] <lilstevie> yeah :p
[13:43] <twb> Except if I completely brick it, in which case SD isn't gonna work either
[13:45] <lilstevie> you can't completely brick :)
[13:45] <lilstevie> APX is always there
[13:45] <twb> k
[13:46] <twb> Apparently OMAP on the ROM has enough smarts to boot off a FAT16 SD card, no matter what
[13:46] <twb> Which is pretty nice, even if you have to carefully align the CHS and shite
[13:46] <twb> *Apparently on OMAP boards the ROM
[13:47] <lilstevie> tegra2 does too
[13:47] <lilstevie> well,
[13:49] <lilstevie> tegra2 can change boot devices
[13:50] <lilstevie> but in our case the reason it drops back to APX is because the tegra2 only has the eMMC configured as a boot device
[13:51] <twb> OK, so which blobunpack result is bootloader.bin ?
[13:52] <lilstevie> blob.EBT
[13:52] <twb> Ha, so it's not an AmigaOS bitmap font :P
[13:52] <lilstevie> they are named for the partition code
[13:53] <lilstevie> so EBT refers to EBT in the flash.cfg
[13:53] <twb> Nod
[13:57] <twb> OK, so now I have a bootloader.bin that I can trace back to asus.com, and a bct from "some guy", and I need to load these in using -bl
[14:07] <lilstevie> twb: not really "some guy" :p the guy who gave the tf root, and who got the sbk for nvflash in the first place :p
[14:07] <lilstevie> doubting the bct is as good as doubting the sbk :p
[14:07] <lilstevie> look at the command line given in the scripts from the androidroot pack
[14:07] <lilstevie> remove --create and --go
[14:07] <lilstevie> and add --sync
[14:08] <lilstevie> that will get you into interactive mode
[14:08] <lilstevie> -r is required for each command
[14:08] <lilstevie> after the sync that is
[14:08] <lilstevie> as it is resume
[14:08] <twb> I know what you mean, but I see a difference between a hash and a blob
[14:08] <lilstevie> and --download reads the partition
[14:09] <lilstevie> twb: unfortunantly you hit a chicken and egg situation
[14:09] <lilstevie> you can't extract the bct without first uploading one
[14:09] <twb> Yeah, I realize that
[14:09] <twb> Er, no I didn't realize *that*, but oK
[14:09] <lilstevie> it is based off the asus service center one
[14:09] <lilstevie> but regenerated
[14:09] <lilstevie> using cros bct tools
[14:10] <twb> Is -r the same as --read ?
[14:10] <lilstevie> no
[14:10] <twb> Oh resume
[14:10] <lilstevie> -r is resume
[14:10] <twb> My brain hurts
[14:10] <lilstevie> nvflash is a bitch
[14:11] <twb> Hang on surely for backing up the original partitions I want --read not --download
[14:11] <lilstevie> and sorry made a mistake up there :p
[14:11] <lilstevie> yes
[14:11] <lilstevie> that is the mistake :p
[14:11] <lilstevie> I'm so used to uploading I automagically went for it :p
[14:11] <twb> So ./nvflash --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --bl bootloader.bin --bct transformer.bct --sync -r --read 6 orig.vmlinuz
[14:11] <twb> That will backup the original LNX partition?
[14:12] <twb> (I figure I should test with the small partition first, not UDA)
[14:12] <lilstevie> you need --setbct in there
[14:12] <lilstevie> and not the -r --read 6 orig.vmlinuz
[14:13] <lilstevie> the -r --read comes after the first command
[14:13] <twb> So the order of the arguments matters?
[14:13] <lilstevie> well it is more that they are seperate commands
[14:14] <lilstevie> sync throws it into "phone update mode" from the bootloader
[14:14] <twb> OK hang on, separate commands within a single invocation of nvflash, or separate invocations of nvflash?
[14:14] <lilstevie> then once it is in that mode, ./nvflash -r --read 6 boot.img
[14:14] <lilstevie> seperate invocations of nvflash
[14:14] <twb> OK
[14:14] <twb> ./nvflash --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --bl bootloader.bin --bct transformer.bct --sync --setbct
[14:14] <twb> ^^ that's just sitting there
[14:15] <lilstevie> hmm
[14:15] <lilstevie> order probably matters
[14:15] <twb> And dmesg just whinged because nvflash has been in D state for 2 min :P
[14:16] <twb> I can fix that by just replugging the USB, tho
[14:16] <lilstevie> and rebooting the tablet
[14:16] <twb> That's plan B
[14:16]  * twb does that now
[14:16] <lilstevie> you will need to reboot the tablet anyway
[14:17] <lilstevie> ./nvflash --bct transformer.bct --setbct --configfile flash.cfg --bl bootloader.bin --odmdata 0x300d8011 --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --sync
[14:17] <lilstevie> that should be the command
[14:17] <lilstevie> nvflash is really badly coded
[14:17] <twb> Thanks
[14:17] <twb> What's the odmdata for
[14:18] <lilstevie> odmdata is mode device specific configs
[14:18] <lilstevie> sets how much ram, and video output et al
[14:18] <lilstevie> it is a standard odmdata though
[14:18] <twb> As in settings baked into the nvflash binary?
[14:18] <twb> oh ok
[14:18] <lilstevie> flags for the processor
[14:20] <twb> Woo
[14:20] <twb> I got something on the screen
[14:21] <lilstevie> :)
[14:24] <twb> "!!!!!!device update sucesss!!!!!!!"
[14:24] <twb> Obviously the ASUS engineers are pretty excitable
[14:24] <lilstevie> nvidia engineers*
[14:24] <twb> k
[14:24] <lilstevie> :p
[14:25] <twb> So once I have done that BCT/BL upload, I just say "./nvflash -r 6 orig.vmlinuz" ?  I don't need any of the SBK and stuff until the next reboot?
[14:28] <lilstevie> -r --read and yeah
[14:28] <lilstevie> also it isnt really a vmlinuz :p
[14:29] <twb> orig.zImage then?
[14:29] <lilstevie> boot.img
[14:29] <lilstevie> :p
[14:30] <twb> Righto
[14:30] <twb> Is that the combined header/kernel/ramdisk thing that abootimg generates?
[14:32] <twb> Someone should teach libmagic to recognize it.
[14:34] <phh> what about you N
[14:34] <phh> ?*
[14:34] <twb> phh: sorry, are you talking to me?
[14:37] <twb> OK, I pissed it off
[14:37] <twb> Just to see what would happen I tried a named --read, and now it doesn't want to -r
[14:37]  * twb reboots TF
[14:41] <twb> lilstevie: how come you said to backup UDA, when the one in default.cfg with a filename is APP ?
[14:41] <twb> Presumably APP is the OS, and UDA is initially an empty ext4
[14:42] <lilstevie> I said you shouldn't need to back up UDA :p
[14:42] <twb> Oh I misread then
[14:43] <lilstevie> but make sure you back up BAK
[14:43]  * twb thinks: if there's already an immutable OS (APP) and a mutable user data (UDA) partition, instead of a single unified btrfs filesystem, I could/should use debian live to make a squashfs APP, and use aufs to merge that with a mutable btrfs UDA
[14:43] <twb> Same as I would for a live USB key
[14:44] <twb> And then when upgrading, I upload the new test squashfs to SOS, and if it works, I use that until the next upgrade, when I upload to APP again, and go on flip-flopping between the two
[14:45] <twb> I rolled out that approach (except with ext instead of btrfs) for a kiosk in a retirement village, it was pretty robust
[14:45] <twb> Oh, and "restore factory defaults" is just to use a tmpfs instead of btrfs in the union :-)
[14:48] <twb> lilstevie: what kernel version is your git tree at?  .39?
[14:49] <twb> about .38 (IIRC) or better will mean I can use XZ compression for the squashfs, which is like 40% better than gzip
[14:49] <lilstevie> .38 for u-boot
[14:49] <lilstevie> .36 for standard bootloader
[14:50] <twb> Hrm
[14:50]  * twb checks when SQUASHFS_COMP_XZ hit
[14:50] <lilstevie> also no aufs
[14:51] <twb> Oh yeah, damn.  I remember now aufs all the union filesystems are out-of-tree
[14:51] <twb> Can I tell nvflash not to flood my I/O bus printing "\ 228249600/536870912 bytes received" as fast as it can?
[14:52] <lilstevie> no
[14:52] <twb> Balls
[14:52] <twb> Maybe I can at least 2>/dev/null
[14:52] <lilstevie> under a "normal" shell it updates over the top of itself :p
[14:52] <lilstevie> yeah probably
[14:53] <twb> Yes but it's doing so so fast, and screen can't keep up
[14:53] <twb> It would probably be fine running directly in fbcon but not in screen
[14:53] <lilstevie> heh
[14:53] <twb> yeah 2>/dev/null is fine
[14:55] <twb> I wish val aurora had time to get "proper" union mounts into mainline
[14:56] <twb> 2>/dev/null isn't working, either ^C'ing the previous run pissed it off, or it can't handle 2>/dev/null
[14:56] <twb> I'll try running outside of screen
[14:58] <twb> Yeah that's much faster, it's done 100MB in a few seconds
[14:59] <twb> Aaaand now it's stopped because the netbook's SSD's buffer is full :P
[15:00] <lilstevie> lol
[15:01] <twb> netbook is running btrfs w/ block-level gzip compression, on an ssd
[15:01] <twb> I/O is not its forté
[15:01] <twb> (-tbtrfs -ocompress=lzo wasn't available when I set it up)
[15:02] <twb> WOW, nice, e2fsck on the APP partition says 0.0% fragmented
[15:03] <twb> Which is why resize2fs -M finished in O(1) time
[15:03] <lilstevie> well it is only marked ro
[15:04] <twb> Yeah but it means they did a good job setting up the original filesystem.
[15:04] <twb> If you just make an ext3 and loopback mount it and copy the chroot in, then do some finishing touches, it's not that well packed
[15:05] <twb> Ah, so SOS is just a small rescue boot.img, not a complete second rootfs
[15:08] <lilstevie> twb: mine is 0.2% fragmented by doing that
[15:09] <lilstevie> yeah :p if you read that before you would have seen that :p
[15:15] <twb> This probably won't interest you, but http://paste.debian.net/129033/
[15:18] <lilstevie> heh, nice little comparison
[15:18] <twb> lilstevie: are you in .nz?
[15:19] <twb> Must be late; it's 1AM here in melbourne, and I'm going home.
[15:19] <twb> Hopefully tomorrow I'll find time to actually roll a kernel and rootfs :-P
[15:19] <lilstevie> I'm in melbourne :p
[15:19] <twb> Ah, okies
[15:20] <twb> Then I definitely will need to buy you some beers after all this
[15:20] <lilstevie> just grew up in nz :)
[15:20] <twb> I'm at cyber.com.au, in Burnley (basically Richmond)
[15:20] <lilstevie> ah nice
[15:20] <lilstevie> I'm a student at VU :p
[15:20] <twb> Are you likely to be around tomorrow?
[15:20] <twb> in irc I mean
[15:21] <lilstevie> probably
[15:21] <twb> awesome
[15:21] <twb> g'night
[15:22] <lilstevie> later
[16:27] <RoAkSoAx> hi Guys, I was wondering if any of you have PXE booted a pandaboard lately
[16:27] <RoAkSoAx> as I now keep getting an error when trying to partition
[16:27] <GrueMaster> RoAkSoAx: I do it daily.  What is the issue you are seeing?
[16:29] <RoAkSoAx> GrueMaster: http://me.roaksoax.com/arm.png
[16:29] <GrueMaster> Sounds like a preseed issue, not a pxe issue.
[16:30] <RoAkSoAx> GrueMaster: right, though I've been using the same exact preseed I was using before and I didn't have the error
[16:30] <RoAkSoAx> GrueMaster: http://paste.ubuntu.com/686003/
[16:31] <RoAkSoAx> GrueMaster: http://paste.ubuntu.com/686004/
[16:31] <GrueMaster> Are you trying to netinstall to SD?
[16:32] <RoAkSoAx> GrueMaster: yes
[16:32] <GrueMaster> I don't think that works.  There are still issues with SD partitioning in partman for d-i.
[16:33] <GrueMaster> (although the bug I filed keeps getting marked as invalid w/o explanation.)
[16:34] <RoAkSoAx> GrueMaster: might be that, but again, I'm using the same preseed file I used before and that worked
[16:34] <GrueMaster> For performance reasons, I suggest doing netinstall to USB drive (leaving SD for boot).
[16:34] <RoAkSoAx> GrueMaster: the SD card has two partitions, the boot and rootfs
[16:34] <RoAkSoAx> GrueMaster: yeah, I guess I'll end up doing that. Thanks
[16:34] <GrueMaster> Hmm.  Not sure then.  Maybe you need to remove the root= line from your boot cmdline until after netinstall.
[16:34] <RoAkSoAx> GrueMaster: did that already
[16:37] <GrueMaster> I can try it later today (maybe).  All 6 of my pandas are currently tied up with CEPH cluster testing atm (which I am still trying to figure out).
[16:39] <RoAkSoAx> GrueMaster: cool, If you get the chance just let me know. Thanks
[16:39] <GrueMaster> Will do.
[18:43] <CocoaGeek> hi
[18:45] <CocoaGeek> I installed arm-linux-gnueabi-g++-4.4 on an Ubuntu 11.04 x64, but when I compile some code I get this error: invalid 'asm': invalid operand for code 'w'
[18:46] <CocoaGeek> I'm guessing that maybe I'm missing some include files specific to ARM …
[18:46] <CocoaGeek> any suggestions?
[18:47] <CocoaGeek> the error is on a line that contains a call to htons()
[18:50] <jhobbs> post some info about how to reproduce it on paste.ubuntu.com
[18:51] <jkridner_> we are looking at doing another BeagleBoard revision (geared toward the lower end with more hardware expansion) and are debating ferociously amongst ourselves if distro vendors would care if you needed a different (incompatible) bootloader for SD card images made for this new version board.  how big of a deal would that be?
[18:51] <steev_> ood5Chew
[18:53] <GrueMaster> jkridner_: It would be a very big deal.  This would mean that we would have to build yet another omap image, and it would be very confusing to users.
[18:53] <GrueMaster> CocoaGeek: This is a question best asked on #linaro I think.
[18:54] <CocoaGeek> thanks GrueMaster
[18:54] <jkridner_> GrueMaster: if the solution was to add an extra MLO-like file to the SD card image, would that be sufficient?
[18:55] <GrueMaster> jkridner_: Linaro is currently building MLO from u-boot.  This would likely require a new u-boot package, plus a new image to support for our preinstalled images.
[18:55] <infinity> jkridner_: Is it completely infeasible to have an MLO that works for both? :/
[18:56] <jkridner_> I'm not sure as the device on the new board seems to have a different internal memory address.  I'm trying to find a work-around.
[18:57] <GrueMaster> Device lookup table in MLO?  It would be cleaner.
[18:57] <jkridner_> One of my challenges has been to articulate the need for having a single MLO file for both.  Most of the people I interact with to help me do board bring-up don't seem to feel it is necessary/useful.
[18:57] <prpplague> jkridner_: hehe
[18:57] <prpplague> jkridner_: the joys of developing in a vaccum
[18:57] <infinity> Those people need to work with random community people who don't want to have to know their exact board revision to make it work.
[18:57] <CocoaGeek> jhobbs: sorry, were you talking to me?
[18:58] <jhobbs> yes
[18:58] <jkridner_> One challenge is that the load address and start address are encoded in the MLO file.  I'm looking at possibly using an on-board I2C EEPROM to load enough code to get around this issue.
[18:58] <infinity> jkridner_: We all realise that the ARM SoC world has been very used to having a new bootloader for every single SoC, board, revision, and moon phase, but I'm not sure anyone thinks that perpetuating this madness is a good idea.
[18:59] <jkridner_> I'm trying to figure out if BeagleBoard can go about it differently.  It is a challenge.  I'm the one being told that I'm mad.
[19:00] <jkridner_> is there a log of this conversation?  I want to share it with the bring-up team.
[19:00] <prpplague> jkridner_: there are plenty of things that can be done, the problem is getting a solid acceptable solution that fits with the legacy existing beagle designs
[19:00] <prpplague> jkridner_: http://irclogs.ubuntu.com/
[19:01] <prpplague> jkridner_: i already did this battle for the pandaboard and some of the other omap4430 based dev platforms
[19:01] <jkridner_> prpplague: what I care about is providing a reference that is backwards compatible with BeagleBoard and BeagleBoard-xM.  I can't do anything about legacy code running on newer platforms, but I can ask people to upgrade.
[19:01] <jkridner_> prpplague: I'm a persistent nag who is used to getting my way. :)
[19:02] <infinity> jkridner_: The bottom line for Ubuntu here is that if you hand us a new board-specific MLO, we'll happily ship it in the archive, but we won't build Yet Another OMAP image.
[19:02] <prpplague> jkridner_: if you think we call you nag, maybe it is best you not know what we call you in reality.........
[19:02]  * prpplague jokes with jkridner_ 
[19:02] <infinity> jkridner_: So, we'll have installers for Beagle and XM, but not for this NG thing.
[19:03] <infinity> jkridner_: Which, from my experience, can reall cut down on the community actually using the board.  Oddly enough, some people don't like having to sort out how to boot a system just to use it.
[19:03] <GrueMaster> jkridner_: It is my understanding that MLO needs to fit in 64k.  It is currently 34k.  I think this can be accomplished with lookup tables within the same binary.
[19:03] <jkridner_> infinity: but, if the new MLO worked with this NG thing *and* Beagle and XM, would you replace the MLO such that your image booted with all 3?
[19:03] <infinity> jkridner_: You bet.
[19:03] <infinity> jkridner_: That would be the ideal outcome.
[19:04] <prpplague> jkridner_: basically you;d want to have u-boot generate a SPL image that would be usable
[19:04] <prpplague> jkridner_: on all three
[19:04] <prpplague> jkridner_: it is doable, but takes some planning and testing
[19:04] <GrueMaster> jkridner_: You should work with jcrigby from linaro.  He has been doing some interesting work with u-boot, like getting x-loader/MLO back into the u-boot tree.
[19:05] <infinity> ^
[19:05] <GrueMaster> Give me hardware and I can add it to my testing.  :)
[19:05] <infinity> If you get any more hardware, your desk will collapse.
[19:06] <jkridner_> prpplague: It is worth money to me if you can make it work. ;-)
[19:06] <prpplague> jkridner_: same as GrueMaster ..... i'd need hardware
[19:06] <jkridner_> GrueMaster: will do!  send me shipping info to jkridner at beagleboard (.org).
[19:07] <jkridner_> ditto prpplgague, but I know where to find you.
[19:07] <GrueMaster> infinity: I have a 1/3 empty industrial rack cabinet in the basement.  Space isn't an issue.
[19:08] <CocoaGeek> bummer, I had -I/usr/include in the makefile …. ooopsy. Thanks to mkedwards on #linaro
[19:08] <infinity> Wait, wait.  People are giving away toys?
[19:10] <jkridner_> toys for promises of work.  output will be remembered. :)
[19:17] <prpplague> hehe
[19:18] <infinity> jkridner_: Well, screw that! ;)
[19:18] <jkridner_> :)
[19:18] <infinity> jkridner_: (But please do send one to GrueMaster, his testing is pretty invaluable)
[19:18] <jkridner_> I will indeed.
[19:18] <infinity> jkridner_: And if you're not already, do talk to jcrigby about this.
[19:18]  * GrueMaster blushes.
[19:19] <infinity> jkridner_: His work on the omap4 u-boot/mlo madness might be quite helpful in providing a way forward.
[19:19] <jkridner_> if he'll chime in, it'd be good, but I'll check back at other times for him.
[19:19] <prpplague> infinity: we must be talking about a different GrueMaster , the one i know is nothing but trouble
[19:20]  * prpplague points to GrueMaster 
[19:20] <prpplague> jkridner_: basically what we are talking about is a "bios" for omap series
[19:20] <GrueMaster> What?  Me cause trouble?  I just find the bugs that annoy engineers to no end.  :P
[19:20] <prpplague> hehe
[19:22] <GrueMaster> Yes!  I have 6 pandas running in a cluster filesystem configuration.  How cool is that?
[19:22] <jhobbs> oo
[19:22] <jhobbs> what filesystem are you using?
[19:23] <GrueMaster> ceph for this test.  Next will be GVFS.
[19:23] <GrueMaster> It's a tad slow.  USB<>SATA and only 100mb ethernet, but still....
[19:26]  * GrueMaster idly thinks about cell phone clusters.
[19:26] <prpplague> GrueMaster: probably going to spin a second version of the bamboo with internal mounts for a 2.5 sata drive
[19:27] <GrueMaster> Nice.  Is the sata more native or usb?
[19:27] <GrueMaster> Also, I have had problems with the panda providing enough power for my usb drives.
[19:27] <GrueMaster> (could be the drive cases).
[19:28] <prpplague> GrueMaster: no it would be usb based, but we would have a secondary power rail for the usb hard drive so no worries on power
[19:28] <GrueMaster> cool.
[19:28] <prpplague> GrueMaster: rob clark is pushing for the new case
[19:29] <GrueMaster> How soon unitl it is released?  I don't think I have seen an order option for it yet (but I haven't looked in over a month).
[19:31] <prpplague> GrueMaster: probably not until jan, we have to see how the bamboo sells first
[19:31] <prpplague> GrueMaster: bamboo should be available 1st week in november
[19:31] <GrueMaster> Cool.  Look forward to seeing it in the wild.
[19:32] <prpplague> GrueMaster: we keep debating on the color
[19:32] <prpplague> GrueMaster: i think we've decided on matte black
[19:32] <GrueMaster> Heh.
[19:32] <prpplague> GrueMaster: but i think green would have been cool
[19:33] <GrueMaster> Add a color "kit" option and ship a can of model paint.
[19:33] <prpplague> hehe
[19:33] <prpplague> circuitco is going to offer the pandaboard with the bamboo case and pcb pre-assembled
[19:42] <GrueMaster> prpplague: I doubt it will fit my mini-cluster.  http://members.dsl-only.net/~tdavis/Panda-rack.jpg
[19:42] <prpplague> GrueMaster: bamboo cases are stackable
[19:43] <GrueMaster> Nice!
[19:44] <prpplague> GrueMaster: bamboo also adds an additional sd/mmc slot
[20:13] <jcrigby> jkridner_, I sent you an email, we can go from there
[20:14] <jcrigby> jkridner_, btw infinity was too kind on the MLO from u-boot.  Aneesh V at TI did all that work, I just sorta watched.
[20:18] <jkridner_> hi jcrigby.
[20:18] <jkridner_> I'll take a look at the e-mail and come back.
[20:27] <infinity> jcrigby: I didn't say you did all the work, just that you (appear to) know what's going on. ;)
[20:28] <jcrigby> infinity, ok
[20:28] <jcrigby> thats fair
[20:36] <jkridner_> in my response e-mail, should I copy anyone besides jcrigby and prpplague and those already on the e-mail chain?
[20:36] <prpplague> jkridner_: don't forget aneesh
[20:36] <jkridner_> k
[20:58] <prpplague> GrueMaster: hope you don't mind, i didn't think about asking until i had clicked the upload, i posted your pandaboard minicluster pic on my google+ account
[20:59] <jkridner_> what is the rest of aneesh's name?
[21:00] <jkridner_> or, some part of it so I can look up an e-mail addres.
[21:00] <jkridner_> aneesh v?
[21:01] <prpplague> aneesh@ti.com
[21:01] <prpplague> jkridner_: yea
[21:01] <jkridner_> prpplague: don't you worry about loggers sending spam when you post e-mail addresses?
[21:02] <prpplague> jkridner_: i've not had any major issues with it
[21:07] <SysTom> Anyone running arm on something like a pandaboard?
[21:10] <prpplague> SysTom: running arm?
[21:10] <SysTom> Yeah, OMAP4
[21:11] <prpplague> SysTom: there are several ubuntu builds specifically for arm based devices such as the pandaboard and beagleboard, assuming that is what you are asking
[21:11] <SysTom> Yeah, I'm just having a dig around now :)
[21:11] <SysTom> Thinking about putting Ubuntu-server on this pandaboard...
[21:11] <SysTom> Desktop seems rather I/O limited with the SD card
[21:18] <SysTom> Hmmm, which versions *don't* require a serial cable, as I don't have one spare currently
[21:19] <prpplague> SysTom: if you plan on doing any serious development on the pandaboard, the purchase of a cable would be wise
[21:20] <SysTom> Seems that way, I just wanted to get something up and running tonight to play with
[21:29] <GrueMaster> prpplague: Cool with me.  I posted it on my facebook.
[21:45] <prpplague> cooloney: hey hey
[21:52] <GrueMaster> SysTom: The server image is just as slow as the desktop on SD when it comes to I/O.
[21:54] <GrueMaster> And the desktop image is better suited for non-serial console work.
[21:54] <SysTom> Okay, good to know- I'll give that a go first
[21:54] <SysTom> Just trying to set this SD card up properly
[21:54] <SysTom> ... shouldn't be difficult right *rolleyes*
[21:56] <prpplague> SysTom: if embedded linux was easy, they'd pay day-laborers to do the work
[21:56] <GrueMaster> There is an issue where flash-kernel doesn't properly sync during the preinstall boot through oem-config, but it usually passes on the second time through.
[21:56] <SysTom> prpplague: heh
[21:56] <GrueMaster> prpplague: People get paid to work on this?  :P
[21:57] <SysTom> I just wanted to get something vaguely up and running tonight
[21:57] <SysTom> Stuck on preparing the SD, ... might just head to bed :D
[21:57] <prpplague> GrueMaster: that;s what i hear
[21:57] <GrueMaster> SysTom: If you have a usb keyboard and a HDMI or DVI monitor, desktop is your best bet.
[21:57] <SysTom> I do
[21:57] <GrueMaster> The SD needs to be 4G or greater.
[21:58] <SysTom> I've got an 8GB SD card (with something already on it)
[21:58] <GrueMaster> 8G seems to be the sweet spot.
[21:58] <SysTom> In an ubuntu live environment now trying to get it sorted
[21:58] <SysTom> ubuntu-11.04-preinstalled-netbook-armel+omap4.img.gz
[21:58] <SysTom> ...and I'm downloading that as we speak
[21:58] <GrueMaster> Make sure you back up your existing stuff on the 8G.  You will be blasting it away with this image.
[21:59] <SysTom> That's fine, I don't need it (it was a spare SD card)
[21:59] <infinity> "Blasting" makes writing to SD sound so much speedier and cool than it really is.
[21:59] <infinity> "Trickling" might be more appropriate.
[21:59] <SysTom> I *will* be making noises when it's flashing
[21:59] <SysTom> Think Star Wars.
[21:59] <infinity> Heh.