**** BEGIN LOGGING AT Sun Aug 28 02:59:57 2011
Aug 28 03:00:00 <dtzWill> did you guys know you can catch signals in bash?!
Aug 28 03:00:00 <dtzWill> lol
Aug 28 03:01:07 <ka6sox> dtzWill, yup...I love Bash....
Aug 28 03:01:11 <ka6sox> however...
Aug 28 03:01:19 <ka6sox> during boot I don't have it :(
Aug 28 03:01:36 <ka6sox> just busybox.
Aug 28 03:01:40 <dtzWill> oh, i'm in the world of X, not booting goodness :)
Aug 28 03:02:52 <cryptk> <id bus="0x19" vendor="0x1" product="0x1" version="0x100">gpio-keys</id>
Aug 28 03:02:54 <cryptk> found that so far
Aug 28 03:02:57 <cryptk> still looking...
Aug 28 03:03:41 <ka6sox> hmmm....
Aug 28 03:03:48 <ka6sox> I don't have grep or cat
Aug 28 03:09:14 <ka6sox> actually I do..
Aug 28 03:17:04 <dtzWill> bah gotta rebuild armv6
Aug 28 03:17:04 <dtzWill> >.<
Aug 28 03:17:13 <dtzWill> ...stupid pixi
Aug 28 03:17:14 <dtzWill> :P
Aug 28 03:17:24 <cryptk> ka6sox, I am pouring through sysfs to try and find something that changes when I hit vol down
Aug 28 03:17:26 <cryptk> no luck so far
Aug 28 03:19:54 <bpadalino> on tp ?
Aug 28 03:20:05 <cryptk> yeah
Aug 28 03:20:22 <cryptk> we need something in sysfs that ka6sox can check for during his initramfs startup
Aug 28 03:20:27 <cryptk> to get dual boot working
Aug 28 03:20:44 <bpadalino> ah
Aug 28 03:21:47 <destinal> wow people are apparently still using and updating my DOOM example with touchpad
Aug 28 03:23:51 <dtzWill> gahhh anyone have a working wIDK for armv6? :/
Aug 28 03:25:08 <dtzWill> dies on glib, TYPICAL
Aug 28 03:29:44 <bpadalino> line 324099 of the kernel for tp has the volume down GPIO assignment ..
Aug 28 03:29:57 <cryptk> what is it?
Aug 28 03:30:15 <bpadalino> 104 .. 103 is vol up ..
Aug 28 03:30:23 <bpadalino> let me try to see where it maps in sysfs or if it shows up there
Aug 28 03:30:37 <cryptk> that doesn't match up with the data I pulled yesterday
Aug 28 03:30:46 <cryptk> what I pulled yesterday said 114 for vol down
Aug 28 03:32:10 <bpadalino> uhoh
Aug 28 03:32:25 <cryptk> uhoh what?
Aug 28 03:33:03 <bpadalino> the differences!
Aug 28 03:33:20 <cryptk> http://www.webos-internals.org/wiki/HP_TP_Key_mapping
Aug 28 03:33:25 <cryptk> that's everything I pulled yesterday
Aug 28 03:33:39 <cryptk> or at least most of it
Aug 28 03:35:38 <dtzWill> YAY I think i fixed the glib stupidity in the WIDK, or at least hacked around it, confirming again with armv7...
Aug 28 03:36:03 <dtzWill> (solution was disable optimizations, and in particular don't emit vfp/neon instructions)
Aug 28 03:36:12 <dtzWill> and since we'll never use the glib itself that seems okay
Aug 28 03:36:27 <dtzWill> in a bit i'll see if optimizations work without the vfp/neon, but diasbling /both/ seems to do the trick
Aug 28 03:36:33 <dtzWill> thank god, that was annoying.
Aug 28 03:39:18 <ka6sox> cryptk, I saw 232 and 249 only
Aug 28 03:42:17 <cryptk> hrm
Aug 28 03:42:44 <cryptk> 232 is the home button
Aug 28 03:42:48 <cryptk> are you able to find that one?
Aug 28 03:42:59 <cryptk> if so, we can jsut have it mapped to the home button to boot to angstrom for now
Aug 28 03:43:02 <ka6sox> its sitting in a file
Aug 28 03:43:05 <cryptk> until we can find something else
Aug 28 03:43:13 <ka6sox> it doesnt' change
Aug 28 03:43:19 <ka6sox> thats no good if it doesnt' change
Aug 28 03:46:12 <ka6sox> root@webos-device:/sys/devices/platform/gpio-keys/input/input0# cat gpio_wake_ke
Aug 28 03:46:12 <ka6sox> ys
Aug 28 03:46:26 <ka6sox> 232 249
Aug 28 03:46:29 <cryptk> yeah
Aug 28 03:46:40 <cryptk> I I even tried changing that file to see if I could change the wake keys... no go
Aug 28 03:46:42 <ka6sox> I havent' found anything that *actually* changes.
Aug 28 03:47:51 <cryptk> pressing vol up and down does spit some data into dmesg though
Aug 28 03:47:56 <cryptk> and home
Aug 28 03:48:07 <cryptk> [43827.771493] gpio-keys: core navi button pressed
Aug 28 03:48:07 <cryptk> [43827.961501] gpio-keys: core navi button released
Aug 28 03:48:07 <cryptk> [43828.851499] gpio-keys: volume down button pressed
Aug 28 03:48:07 <cryptk> [43829.021518] gpio-keys: volume down button released
Aug 28 03:48:07 <cryptk> [43829.881494] gpio-keys: volume up button pressed
Aug 28 03:48:08 <cryptk> [43830.051496] gpio-keys: volume up button released
Aug 28 03:48:13 <cryptk> core navi button = home
Aug 28 03:50:34 <ka6sox> so thats dmesg | grep gpio
Aug 28 03:51:03 <cryptk> well, I just did dmesg after hitting them
Aug 28 03:52:21 <cryptk> but it means that they are processed on the kernel level... so they /should/ be in sysfs somewhere you would think
Aug 28 03:53:56 <ka6sox> those are printk's
Aug 28 03:55:51 <ka6sox> I could look in the source...
Aug 28 03:55:53 <ka6sox> and find it.
Aug 28 03:58:07 <ka6sox> cryptk, I'd jsut grep thru the entire sysfs tree till you found 114
Aug 28 04:00:04 <cryptk> tried... didn't find it
Aug 28 04:01:48 <ka6sox> okay let me look @ the source
Aug 28 04:02:55 <Jack87> are you guys making sure to document your findings in here
Aug 28 04:03:09 <Jack87> it doesnt look like we are logged
Aug 28 04:03:16 <Jack87> oh wait ya we are :)
Aug 28 04:03:17 <ka6sox> Jack87, ya, but yesterday is different than todya
Aug 28 04:03:33 <Jack87> ka6sox, yesterday was still today :)
Aug 28 04:03:44 <Jack87> just really early today
Aug 28 04:03:47 <ka6sox> Jack87, ya I know
Aug 28 04:03:53 <Jack87> hehe
Aug 28 04:04:15 <cryptk> today we are working to implement what we found yesterday
Aug 28 04:04:20 <cryptk> so far... nothing to document
Aug 28 04:04:52 <Jack87> yay for logs http://logs.nslu2-linux.org/livelogs/wosi-dev/
Aug 28 04:06:04 <cryptk> what's the correct patch invocation to apply the palm kernel patch again?
Aug 28 04:06:07 <cryptk> patch -p1?
Aug 28 04:06:37 <ka6sox> yes
Aug 28 04:06:56 <cryptk> if we find that printk, then it may help us to find what is triggering the printk
Aug 28 04:08:25 <ka6sox> you will need to find the headers for the tenderloin board (aka boardfile)
Aug 28 04:09:27 <ka6sox> look for tenderloin
Aug 28 04:10:09 <ka6sox> that should have the defs for the key and its hex code
Aug 28 04:20:08 <cryptk> not able to find it so far
Aug 28 04:26:17 <cryptk> I am gonna try and just brute it....
Aug 28 04:26:23 <cryptk> copy all of sys to somewhere
Aug 28 04:26:35 <cryptk> then hold down vol down while copying it somewhere else
Aug 28 04:26:37 <cryptk> then diff them
Aug 28 04:26:49 <ka6sox> it may come out as hex
Aug 28 04:28:57 <dtzWill> so i'm lacking a good way to test this myself.... think i'll just push to testing feed >_>
Aug 28 04:29:21 <dtzWill> (aka i'm announcing i might break things)
Aug 28 04:29:33 <dtzWill> but doing it that way is just sooo much easier than my own private little testing version
Aug 28 04:29:38 <dtzWill> grumble that's what the testing feed is for grumble
Aug 28 04:29:39 <dtzWill> O:)
Aug 28 04:30:07 <scoutcamper> dtzWill, you better /part #webos-internals first
Aug 28 04:30:37 <dtzWill> scoutcamper: nah, i'll just detach screen and go enjoy my evening with my  girl ;)
Aug 28 04:30:42 <scoutcamper> lol
Aug 28 04:30:54 <dtzWill> PS i want you to pay attention to how i said that
Aug 28 04:31:07 <dtzWill> as if i enjoying evening with girl still required me to detach
Aug 28 04:31:21 <scoutcamper> dtzWill, leave the rest of us to pick up the pices? bah
Aug 28 04:31:24 * ka6sox is glad he is NOT in -internals now.
Aug 28 04:31:25 <dtzWill> ...anyway i'm just amused at how that might be humorously interpreted
Aug 28 04:31:42 <dtzWill> scoutcamper: nah, if i actually break things just email me and i'll fix it--if they're broken it's stupid easy shit
Aug 28 04:31:48 <dtzWill> like a missing file from a commit, etc
Aug 28 04:31:58 <scoutcamper> lol
Aug 28 04:32:02 <scoutcamper> ok
Aug 28 04:32:23 <dtzWill> go go gadget builder
Aug 28 04:32:37 <scoutcamper> cryptk, can make that happen
Aug 28 04:32:44 <cryptk> only thing I have found in the sources so far is +#define VOL_UP_GPIO                    103
Aug 28 04:32:44 <cryptk> +#define VOL_DN_GPIO                    104
Aug 28 04:34:54 <cryptk> and it looks like the gpio chip is PM8058
Aug 28 04:36:07 <ka6sox> i2c to GPIO chip
Aug 28 04:38:24 <ka6sox> look in tenderloin.c for VOL_DN_GPIO
Aug 28 04:41:55 <cryptk> let me actually apply the kernel patch
Aug 28 04:42:01 <cryptk> that will be easier than grepping through the diff
Aug 28 04:43:33 <ka6sox> it will be in arch/asm/asm-msm that you will want to look.
Aug 28 04:44:57 <cryptk> yeah
Aug 28 04:45:01 <cryptk> looking through it
Aug 28 04:45:08 <cryptk> so far haven't ound any info that we don'e already know
Aug 28 04:46:21 <ka6sox> the printk is probably in that boardfile
Aug 28 04:55:49 <cryptk> not able to find it
Aug 28 04:57:50 <ka6sox> okay
Aug 28 04:58:34 <cryptk> ka6sox, can you just spin me one that pivots to the ext2fs for now?
Aug 28 04:58:41 <cryptk> we can deal with the keys later
Aug 28 05:06:16 <ka6sox> okay let me finish this script for creating it.
Aug 28 05:06:28 <ka6sox> I need to finish some excludes
Aug 28 05:12:09 <dtzWill> hopefully v0.8.1 fixes that broken push >_>
Aug 28 05:48:58 <ka6sox> mkimage -A arm -T multi -C none -n 'test-multi-image' -d arch/arm/boot/uImage:/tmp/uRamdisk /tmp/uMulti
Aug 28 05:49:19 <ka6sox> adjust your names as  appropriate
Aug 28 05:52:09 <ka6sox> jas...lets see if I can make this right
Aug 28 05:52:21 <ka6sox> cryptk, a question?
Aug 28 05:52:28 <ka6sox> do you have an ubuntu machine there?
Aug 28 05:52:54 <ka6sox> either that or add one to your TP.
Aug 28 05:59:16 <cryptk> yes I do
Aug 28 05:59:33 <cryptk> I am on an ubuntu machine now actually
Aug 28 06:00:36 <ka6sox> 3 step process
Aug 28 06:00:41 <ka6sox> step 1)
Aug 28 06:01:17 <ka6sox> copy uImage from /boot into /tmp on ubuntu machine
Aug 28 06:01:36 <ka6sox> create a tarball of /boot from the TP
Aug 28 06:01:50 <ka6sox> put that in /tmp on the ubuntu machine
Aug 28 06:02:55 <cryptk> done and done
Aug 28 06:03:44 <ka6sox> install (if not already done) uboot-mkuimage
Aug 28 06:03:52 <cryptk> I just did tar czvf boot.tgz -C /boot . to make the tarball
Aug 28 06:04:03 <ka6sox> fine
Aug 28 06:04:17 <ka6sox> get that on the ubuntu machine
Aug 28 06:04:29 <cryptk> they are
Aug 28 06:04:34 <cryptk> and uboot-mkimage is installed
Aug 28 06:04:40 <cryptk> so far I am keeping up
Aug 28 06:04:55 <ka6sox> untar the /boot into /tmp
Aug 28 06:05:09 <ka6sox> /tmp/ramfs...
Aug 28 06:05:10 <ka6sox> sorry
Aug 28 06:05:15 <ka6sox> othwise its a mess.
Aug 28 06:05:18 <cryptk> am I leaving the boot.tgz compressed?
Aug 28 06:05:25 <ka6sox> no
Aug 28 06:05:40 <cryptk> yeah, I was typing that while you were saying toe xtract it
Aug 28 06:05:48 <ka6sox> okay
Aug 28 06:05:53 <ka6sox> once you get that there...
Aug 28 06:05:57 <cryptk> ./dev/
Aug 28 06:05:58 <cryptk> ./dev/console
Aug 28 06:05:58 <cryptk> tar: ./dev/console: Cannot mknod: Operation not permitted
Aug 28 06:06:01 <cryptk> is that normal?
Aug 28 06:06:09 <ka6sox> yup
Aug 28 06:06:11 <cryptk> ok
Aug 28 06:06:16 <cryptk> so far still keeping up
Aug 28 06:06:27 <ka6sox> an initramfs is a CPIO file
Aug 28 06:06:37 <ka6sox> it *can* be compressed
Aug 28 06:07:06 <cryptk> ok, so I have the uImage, and I have the ramfs dir with same contents as /boot from the TP
Aug 28 06:07:13 <cryptk> next step?
Aug 28 06:11:22 <cryptk> ka6sox, ?
Aug 28 06:12:35 <ka6sox> jas...local issue here (kidlet out of bed)
Aug 28 06:12:39 <cryptk> ahh
Aug 28 06:12:48 <cryptk> I find that ratchet straps are good for that
Aug 28 06:24:03 <ka6sox> bakc
Aug 28 06:24:11 <ka6sox> straps installed :D
Aug 28 06:24:13 <ka6sox> j/k
Aug 28 06:24:32 <cryptk> heh
Aug 28 06:24:33 <ka6sox> in ramfs remove all references to *uImage*
Aug 28 06:24:56 <cryptk> done
Aug 28 06:25:14 <ka6sox> du -sh ramfs
Aug 28 06:25:25 <cryptk> 6.3M
Aug 28 06:26:00 <ka6sox> cd ramfs/sbin
Aug 28 06:26:34 <cryptk> done
Aug 28 06:26:49 <cryptk> change the mount line?
Aug 28 06:26:50 <ka6sox> vi init
Aug 28 06:26:53 <ka6sox> yup
Aug 28 06:27:04 <cryptk> done
Aug 28 06:27:31 <ka6sox> check the pivot_root file and make sure that points to where you want.
Aug 28 06:27:32 <cryptk> do I need to change this line also?
Aug 28 06:27:33 <cryptk> lvm.static lvchange -ay --ignorelockingfailure /dev/mapper/store-root
Aug 28 06:28:09 <cryptk> pivot_root is a symlink to ../bin/busybox
Aug 28 06:28:14 <ka6sox> you aren't going to use that one
Aug 28 06:28:31 <ka6sox> needs to be /dev/mapper/store-ext2fs
Aug 28 06:28:55 <cryptk> ok, both references to store-root have been changed to store-ext2fs
Aug 28 06:29:20 <ka6sox> verify that symlink to /bin/busybox
Aug 28 06:29:32 <cryptk> pivot_root -> ../bin/busybox
Aug 28 06:30:00 <ka6sox> this is what I"m not sure of
Aug 28 06:30:23 <ka6sox> it should call init in the realroot
Aug 28 06:30:40 <ka6sox> (which for that rootfs calls init.sysvinit
Aug 28 06:31:24 <rwhitby> ka6sox: BTW, we have an influx of people developing for webOS in the main channel now
Aug 28 06:32:19 <ka6sox> what are they working on?
Aug 28 06:33:11 <cryptk> I think it is correct the way it is
Aug 28 06:33:21 <cryptk> it will just be using the webOS busybox to do the pivot_root
Aug 28 06:33:27 <cryptk> then the boot sequence calls the init
Aug 28 06:33:34 <ka6sox> right
Aug 28 06:33:50 <ka6sox> the pivot_root should call init in the new root
Aug 28 06:33:53 <cryptk> yep
Aug 28 06:34:01 <cryptk> so, how to I wrap this thing up?
Aug 28 06:34:16 <ka6sox> you need to create a CPIO file for it.
Aug 28 06:34:30 <ka6sox> then run it thru mkuimage to create uRamdisk.
Aug 28 06:34:47 <cryptk> best way to do that?
Aug 28 06:35:41 <rwhitby> ka6sox: new kernel dev, gentoo guy, and cmake expert
Aug 28 06:36:35 <ka6sox> rwhitby, nice
Aug 28 06:36:50 <ka6sox> cryptk, you played with CPIO or is that too old skool?
Aug 28 06:36:55 <cryptk> find . | cpio -H newc -o > ../initramfs.cpio
Aug 28 06:37:00 <cryptk> that's the way I think I used to do it
Aug 28 06:37:00 <ka6sox> yup
Aug 28 06:37:10 <cryptk> then gzip it to a .igz file
Aug 28 06:37:21 <ka6sox> lets not do the zip
Aug 28 06:37:25 <cryptk> kk
Aug 28 06:37:39 <ka6sox> the reason is that I am not sure whether the kernel supports that or not.
Aug 28 06:38:11 <cryptk> kk
Aug 28 06:38:15 <cryptk> well, I have it both ways
Aug 28 06:38:26 <cryptk> I have an initramfs.cpio and an initramfs.igz
Aug 28 06:40:57 <cryptk> mkimage -A arm -T multi -C none -n test-multi-image -d uImage-2.6.35-palm-tenderloin:initramfs.cpio uImage-F15-angstrom
Aug 28 06:41:03 <cryptk> something like that would work right?
Aug 28 06:42:32 <ka6sox> you have to mkimage the cpio into a uRamdisk first
Aug 28 06:42:35 <ka6sox> as a single
Aug 28 06:42:47 <ka6sox> then create the multi after that.
Aug 28 06:42:54 <cryptk> how do I do that?
Aug 28 06:43:02 <ka6sox> I am searching history
Aug 28 06:43:04 <ka6sox> jasl
Aug 28 06:44:53 <cryptk> mkimage -A arm -T single -C none -d initramfs.cpio uRamdisk ???
Aug 28 06:44:56 <cryptk> something like that?
Aug 28 06:45:39 <cryptk> -T ramdisk
Aug 28 06:47:02 <ka6sox> pass that in a -h
Aug 28 06:47:08 <ka6sox> -T h
Aug 28 06:47:15 <ka6sox> sorry
Aug 28 06:47:19 <ka6sox> -T -h
Aug 28 06:47:25 <ka6sox> that gives you the options.
Aug 28 06:47:34 <cryptk> filesystem, firmware, kernel, multi, ramdisk, script, standalone, flat_dt
Aug 28 06:47:37 <ka6sox> ya
Aug 28 06:47:39 <ka6sox> thats the one
Aug 28 06:47:40 <cryptk> that's where I got the ramdisk from
Aug 28 06:47:43 <ka6sox> its a ramdisk
Aug 28 06:48:02 <ka6sox> right...tooo many interruptions today...so my history file is a mess.
Aug 28 06:48:24 <ka6sox> the outputfile is uRamdisk.
Aug 28 06:48:40 <ka6sox> and the input is the cpio file
Aug 28 06:48:44 <cryptk> yep
Aug 28 06:48:45 <cryptk> done
Aug 28 06:48:57 <cryptk> then I spun the multi image using the uImage kernel and the uRamdisk file
Aug 28 06:49:05 <ka6sox> yup
Aug 28 06:49:20 <cryptk> No filesystem could mount root, tried:  ext3 ext2 vfat fuseblk
Aug 28 06:49:20 <cryptk> <0>Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
Aug 28 06:50:01 <ka6sox> where are you seeinghat?
Aug 28 06:50:13 <cryptk> klog
Aug 28 06:50:43 <ka6sox> jas...
Aug 28 06:50:51 <ka6sox> we may have the names wrong.
Aug 28 06:50:59 <ka6sox> and that is very important.
Aug 28 06:51:58 <ka6sox> that means we didn't get the multi correct
Aug 28 06:52:13 <ka6sox> there are 3 parts
Aug 28 06:52:27 <ka6sox> uImage, uRamdisk, uMulti
Aug 28 06:52:38 <ka6sox> and that last one was the hardest for me to create.
Aug 28 06:53:20 <cryptk> #!/bin/bash
Aug 28 06:53:20 <cryptk> cd ramfs
Aug 28 06:53:20 <cryptk> find . | cpio -H newc -o > ../initramfs.cpio
Aug 28 06:53:20 <cryptk> cd ..
Aug 28 06:53:20 <cryptk> mkimage -A arm -T ramdisk -C none -d initramfs.cpio uRamdisk
Aug 28 06:53:21 <cryptk> mkimage -A arm -T multi -C none -n test-multi-image -d uImage-2.6.35-palm-tenderloin:uRamdisk uMulti
Aug 28 06:53:28 <cryptk> that's what I worked up to create them
Aug 28 06:53:42 <ka6sox> how big is that CPIO file?
Aug 28 06:53:54 <cryptk> 6M
Aug 28 06:54:07 <cryptk> ramfs is 6.3M the cpio is 6M
Aug 28 06:55:41 <ka6sox> can you email me that klog please?
Aug 28 06:55:56 <cryptk> let me re-point it at webOS and try that first
Aug 28 06:56:02 <cryptk> see if I can at least get this thing booting webOS
Aug 28 06:57:05 <cryptk> ok, mine won't even boot webOS
Aug 28 06:57:07 <cryptk> same problem
Aug 28 06:59:15 <ka6sox> wtheck
Aug 28 06:59:47 <ka6sox> let me copy out my history file and clean it up
Aug 28 07:00:04 <ka6sox> so I can get the thing simpler
Aug 28 07:01:21 <cryptk> there has got to be a step I am missing somewhere...
Aug 28 07:01:52 <ka6sox> http://manpages.ubuntu.com/manpages/natty/man1/mkimage.1.html
Aug 28 07:02:00 <ka6sox> thats what I used as my manpage for this
Aug 28 07:02:30 <ka6sox> it has to be in the CPIO
Aug 28 07:03:14 <ka6sox> you ran the CPIO from inside /tmp/ramfs it looks like
Aug 28 07:03:29 <cryptk> yeah, but I had it creating the file outside of it
Aug 28 07:03:40 <ka6sox> yes ../blah
Aug 28 07:03:59 <ka6sox> I must be missing something on teh CPIO
Aug 28 07:06:25 <Xuzz> rwhitby: preware patch to fix row cutoffs (i just spent way too much reading the Mojo source for such a simple fix…) http://pastie.org/private/d7wlse32h0achqokso9jwq
Aug 28 07:08:09 <cryptk> how did you do the cpio?
Aug 28 07:09:20 <rwhitby> Xuzz: "courtesy of Xuzz" for the changelog?
Aug 28 07:09:25 <Xuzz> chpwn
Aug 28 07:10:36 <ka6sox> same way but called it ramdisk
Aug 28 07:11:10 <ka6sox> I don't remember what header I put on it though.
Aug 28 10:07:21 <cryptk> ka6sox, I still can't get this damn thing to boot
Aug 28 10:41:28 <cryptk> ok, rwhitby you have embedded systems experience... mind taking a look?
Aug 28 10:41:47 <cryptk> the mount as part of the /sbin/init is failing
Aug 28 10:42:04 <cryptk> even when trying to have it mount the normal store-root
Aug 28 11:01:08 <rwhitby> cryptk: is /proc mounted?
Aug 28 11:02:47 <cryptk> I think I may know what is causing it
Aug 28 11:03:28 <cryptk> CONFIG_BLK_DEV_INITRD=y and CONFIG_INITRAMFS_SOURCE=""
Aug 28 11:03:31 <cryptk> in the kernel config
Aug 28 11:03:41 <cryptk> that means I need to be doing this as an INITRD not an initramfs I think
Aug 28 11:06:48 <cryptk> brb
Aug 28 11:26:49 <cryptk> rwhitby, I think I just got it to work...
Aug 28 11:27:24 <cryptk> I just built a uImage with the recovery kernel and an initrd...
Aug 28 11:27:36 <cryptk> which means we can now memboot even if the person trashes their /boot
Aug 28 11:28:58 <cryptk> and I /think/ I just did a pivot_root to angstrom...
Aug 28 11:29:04 <cryptk> rebooting and checkign log files to confirm
Aug 28 11:30:59 <rwhitby> cryptk: installer kernel+initrd doesn't need /boot
Aug 28 11:31:23 <rwhitby> but yeah, doing it with a real kernel and rootfs is good
Aug 28 11:32:21 <cryptk> damnit... angstrom has /var/log mapped to a volatile location
Aug 28 11:32:26 <cryptk> got rid of that... trying it again
Aug 28 11:32:33 <cryptk> lets see if we get some log files in the angstrom partition
Aug 28 11:33:19 <cryptk> I don't expect it to be a successful boot... but I expect it to be doing SOMETHING at least
Aug 28 11:33:25 <cryptk> errors lead to resolutions
Aug 28 11:34:00 <cryptk> the TP is at least not trying to load luna... which is good...
Aug 28 11:36:00 <cryptk> YES!!!!
Aug 28 11:36:06 <cryptk> rwhitby, there are Xorg log files present!
Aug 28 11:56:15 <cryptk> ok, lets see how far along I can get on this at work...
Aug 28 11:57:54 <cryptk> AFAICT... behing that pretty static HP logo... Angstrom is indeed running...
Aug 28 12:02:43 <cryptk> rwhitby, confirmed.... angstrom is definitely running... there isn't much in the logs... but I was able to install cron in the chroot and have it touch files and such... just enough to show that there is life behind that HP logo
Aug 28 12:02:47 <cryptk> now the fun begins
Aug 28 16:12:29 <dtzWill> cryptk|offline, ka6sox: YAY it booted ^.^
Aug 28 16:12:37 <dtzWill> and prelim support for X? \o/
Aug 28 17:19:07 <dtzWill> cryptk|offline, ka6sox: does your angstrom work presentl live somewhere? your WIP initrd, etc?
Aug 28 17:59:23 <dtzWill> anyone wanna test my experimental-ish framebuffer-blitting x server? O:)
Aug 28 17:59:34 <dtzWill> should do everything the current one does, except much much faster
Aug 28 17:59:59 <dtzWill> oh and only supports landscape on boot, althouhg you can change the rotation with xrandr (but the rotation will be done in software..so...don't do that :P)
Aug 28 18:00:32 <dtzWill> but i'm curious if y'all find it fast enough/etc to justify chasing down (or maybe sacrificing) misc other bugs...
Aug 28 18:00:38 <dtzWill> and/or fun to play with ^.^
Aug 28 18:00:44 <dtzWill> well if you get bored, check it out here: http://ompldr.org/vYTNmMQ
Aug 28 18:03:26 <dtzWill> one idea (I think rwhitby suggestd this) is some kind of hybrid that uses the goodness of the above-linked xsdl as a fast-path optimization when it's applicible
Aug 28 18:03:31 <dtzWill> and otherwise uses GL
Aug 28 18:04:11 <dtzWill> and from our discussions/him pushing on me not arbitrarily limiting things for speed ;), i believe we hashed out something that'd work.
Aug 29 02:30:12 <cryptk> dtzWill, pong
**** ENDING LOGGING AT Mon Aug 29 02:59:57 2011