20:00:25 <pwhalen> #startmeeting
20:00:25 <zodbot> Meeting started Wed Oct  3 20:00:25 2012 UTC.  The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:25 <pwhalen> #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore
20:00:25 <zodbot> Current chairs: bconoboy ctyler dgilmore jonmasters pbrobinson pwhalen
20:00:31 <pwhalen> good afternoon all
20:00:45 <dmarlin> .fas dmarlin
20:00:46 <zodbot> dmarlin: dmarlin 'David A. Marlin' <dmarlin@redhat.com>
20:00:54 <pwhalen> .fas pwhalen
20:00:54 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
20:01:08 <DarthJava> .fas darthjava
20:01:09 <zodbot> DarthJava: darthjava 'Dmitry Kozunov' <dmitry.kozunov@senecac.on.ca>
20:01:10 <revident> .fas revident
20:01:15 <zodbot> revident: srsullivan 'Scott Sullivan' <scott@ss.org>
20:01:17 <agreene> .fas agreene
20:01:18 <zodbot> agreene: agreene 'Andrew Greene' <agreene@learn.senecac.on.ca> - tag4fedora 'Tim Greene' <tagreene@flowserve.com>
20:01:22 <djdelorie> .fas djdelorie
20:01:23 <zodbot> djdelorie: djdelorie 'DJ Delorie' <dj@redhat.com>
20:01:29 <rsc> .fas robert
20:01:30 <zodbot> rsc: abc1b2b34e 'roberto ramirez carbonell' <stone22062@hotmail.com> - romal 'Robert M. Albrecht' <mail@romal.de> - rwlove 'Robert Love' <robert.w.love@intel.com> - pca0909 'roberto ramirez carbonell' <robertoramirez07@gmail.com> - ah7013 'Andrew Hill' <andrewroberthill@gmail.com> - bobfischer 'Robert' <bobfischer69@gmail.com> - optimus1970 'Robert Ross' <rossrobert24@yahoo.com> - joseroberto 'José Roberto Colombo (50 more messages)
20:01:34 <rsc> gna.
20:01:44 <ctyler> .fas chris@tylers.info
20:01:44 <zodbot> ctyler: ctyler 'Chris Tyler' <chris@tylers.info>
20:01:47 <bconoboy> .fas blc@
20:01:47 <zodbot> bconoboy: blc '' <blc@redhat.com>
20:01:49 <rsc> Robert Scheck <robert@fedoraproject.org>
20:02:52 <pwhalen> #topic 1) F18/19 Build status - problem packages?
20:03:58 <pwhalen> not sure if we currently have any problem packages holding anything back, anyone?
20:04:34 <bconoboy> kernel :-)
20:04:43 <pwhalen> ah, yes that one
20:04:54 <bconoboy> I suppose it is building though
20:05:42 <bconoboy> I'd like to know why F19 builds are still so far behind
20:05:57 <bconoboy> glibc is fixed
20:06:15 <pwhalen> F19 Missing:  1698
20:06:42 * jonmasters is in
20:07:18 <pwhalen> perhaps we can come back if Peter is around later
20:07:26 <bconoboy> y
20:07:28 <pwhalen> #topic 2) Fedora 18 kernel status
20:07:43 <jonmasters> I'm looking into the MMC issue on OMAP
20:07:58 <pwhalen> #link http://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Testing#kernel-3.6.0-1.fc18
20:08:27 <pwhalen> that was the latest kernel built with some config changes that included mmc being built in. Sadly it did not boot with SD cards
20:08:40 <bconoboy> built it on on platforms?
20:08:49 <bconoboy> er on all?
20:09:00 <pwhalen> bconoboy, iiuc
20:09:43 <pwhalen> oh, perhaps just omap
20:10:03 <bconoboy> dgilmore: has dracut been updated to load the modules?
20:10:10 <pwhalen> changelog - - Build in OMAP MMC and DMA drivers to fix borkage for now
20:11:05 <dmarlin> bconoboy: but 3.6.0-1.fc18 "built' for all platforms:  http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=95645
20:11:25 <jonmasters> bconoboy: the modules were built-in
20:11:35 <bconoboy> dmarlin: y, I'm using it on my trimslice (sda)
20:11:37 <jonmasters> bconoboy: they still fail, it's an issue with omap dma
20:11:43 <bconoboy> Just wondering if I should test with mmc.
20:12:09 <bconoboy> jonmasters: right. the question was if only omap is getting mmc built in or if all platforms are.
20:12:11 <dmarlin> bconoboy: pwhalen tested it, and it failed.  see: http://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Testing#kernel-3.6.0-1.fc18
20:12:13 <jonmasters> bconoboy: do test, but I suspect you'll see a bunch of errors from the dma code
20:12:25 <jonmasters> bconoboy: ah sorry man...I dunno. Let's see...
20:12:31 * jonmasters is checking
20:12:33 <bconoboy> jonmasters: dma code on trimslice?
20:12:49 <jonmasters> on TS it ought to work if builtin
20:12:57 <bconoboy> dmarlin: okay, I see the fpaste now
20:13:00 <pwhalen> bconoboy, if you plug in an sd card, it wont be recognized, nor will it boot from sd
20:13:46 <jonmasters> pwhalen: that's on panda, right? Did you test boot anything else?
20:14:01 <dmarlin> jonmasters: see: http://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Testing#kernel-3.6.0-1.fc18
20:14:25 <dmarlin> jonmasters: it shows everything he tested and the results
20:14:36 <bconoboy> What I'm driving at is: Is this an omap problem, plus a dracut on trimslice problem, an omap and an omap problem? A generic mmc problem?
20:14:38 <jonmasters> I'm looking, but I'm not sure how to decode whether trimslice booted
20:14:39 <pwhalen> jonmasters, tegra boots on sata, fails on sd
20:14:53 <jonmasters> ok
20:14:59 <bconoboy> er, omap and a tegra problem..
20:15:21 <jonmasters> bconoboy: I think there are two issues. There's the MMC driver problem with being builtin or not (checking current config) and there's the specific OMAP problem
20:15:30 <bconoboy> The answer would be pretty easy to get: If the tegra kernel has mmc built in, it's not dracut
20:15:38 <jonmasters> indeed, looking
20:16:02 <bconoboy> (what happened to /proc/kconfig.gz?)
20:16:19 <dmarlin> bconoboy: no longer exists
20:16:26 <bconoboy> can we turn it back on?
20:16:33 <bconoboy> It's *really* handy
20:16:34 <jonmasters> config-arm-tegra:CONFIG_MMC_SDHCI_TEGRA=y
20:16:36 <dmarlin> bconoboy: I've been told no
20:16:45 <jonmasters> bconoboy: Fedora doesn't turn it on
20:16:46 <dmarlin> bconoboy: just use /boot/config-*
20:16:54 <jonmasters> bconoboy: I disagree with that policy, but it's what is done
20:17:05 <dmarlin> jonmasters: agreed
20:17:33 <bconoboy> Okay, I'm looking at /boot/config-3.6.0-1.fc18.armv7hl.tegra
20:17:41 <jonmasters> so it looks like MMC is turned on. Hey, let's do this. Leave me the ball on F18 on TS/OMAP in terms of figuring out what's up with MMC. I'll provide an update in 2 hours on #fedora-arm
20:17:50 <bconoboy> And it is *not* built in.
20:18:23 <bconoboy> jonmasters: Are we sure config-arm-tegra is being used?
20:18:26 <jonmasters> bconoboy: ok, so it's in the config files which means something went wrong during merging configs. Please paste the line?
20:18:46 <bconoboy> CONFIG_MMC_SDHCI_TEGRA=m
20:19:00 <bconoboy> even CONFIG_MMC is =m
20:19:03 <jonmasters> bconoboy: quite often what happens is something is turned on in the config but during build when they are merged there's some /other/ dep that causes the config to break
20:19:21 <bconoboy> Anybody have the omap config under /boot handy?
20:19:22 <jonmasters> ok, so I'm only looking at git for F18
20:19:34 <bconoboy> If we can't trust config tegra maybe omap doesn't actually have it turned on either.
20:19:50 <jonmasters> commit 63d527976ab38e62c43876fa14a7e8d86636e29a
20:19:51 <jonmasters> Author: Peter Robinson <pbrobinson@gmail.com>
20:19:51 <jonmasters> Date:   Tue Oct 2 08:20:54 2012 +0100
20:19:51 <jonmasters> - Update ARM configs for 3.6 final
20:19:51 <jonmasters> - Add highbank SATA driver for stability
20:19:51 <jonmasters> - Build in OMAP MMC and DMA drivers to fix borkage for now
20:20:41 <bconoboy> I'm downloading the kernel now
20:20:48 <pwhalen> I'm booting a panda now
20:20:48 <bconoboy> but if somebody has it handy that'd be even better
20:21:35 <bconoboy> CONFIG_MMC_OMAP=m
20:21:37 <pwhalen> CONFIG_MMC=m
20:21:45 <pwhalen> your quick :)
20:21:58 <jonmasters> ok so Peter meant to turn it on but something went wrong with the config merging
20:22:01 <bconoboy> I unpackaged a partially downloaded file ;-)
20:22:12 <ctyler> oooh, evil
20:22:15 <jonmasters> this is easily fixed by prepping the kernel sources and seeing what is going wrong
20:22:21 <bconoboy> Right, so what we need to do is fix the kernel config and make a -2
20:22:25 <jonmasters> it's a Kconfig dep issue
20:22:39 <jonmasters> yea, let me look because I want to poke at OMAP DMA anyway
20:22:45 <bconoboy> #info Bug in kernel config: 3.6.0-1 still builds MMC drivers as modules, even on omap
20:23:00 <jonmasters> I'll update #fedora-arm in 2 hour
20:23:06 <pwhalen> awesome!
20:23:21 <bconoboy> #info jonmasters to update #fedora-arm within 2 hours
20:23:27 <jonmasters> that way you can hold me to it ;)
20:23:36 <bconoboy> pwhalen: Is this also a good time to talk about device tree and 3.7 or is that a later topic?
20:23:54 <pwhalen> not currently, so we could do that now
20:23:58 <jonmasters> context: both Peter and I are also talking with Arnd in a G+ thread about 3.7
20:24:11 <bconoboy> pwhalen: Let's just move on and cover it at the end
20:24:23 <pwhalen> sure
20:24:25 <pwhalen> #topic 3) F18 alpha test images
20:25:02 * bconoboy looks at dmarlin
20:25:23 <dmarlin> I think we can create F18 test images as soon as we have kernels that boot on all platforms
20:25:49 <dmarlin> we have created some images to test kernels, but they are different versions and use scratch built kernels
20:26:08 <bconoboy> link?
20:26:32 <bconoboy> as long as people udnerstand they're pre-alpha it'd be good to get people testing them otherwise
20:26:35 <dmarlin> no public links to images at this point.
20:27:21 <ctyler> dmarlin: there aren't or there shouldn't be?
20:27:23 <dmarlin> if we will have bootable kernels "soon" I'd like to regenerate them with the same versions of packages and kernels
20:27:26 <revident> dmarlin, your images only v7 currently, correct?
20:27:36 <dmarlin> if not, we can post what we have
20:27:50 <bconoboy> I guess that's the question: Will we have bootable kernels soon, or will we have a bootable omap kernel soon and everything else using mmc will still be broken?
20:27:56 <dmarlin> revident: yes, we have only built vexpress, panda, and trimsl;ice
20:28:18 <jonmasters> pwhalen: which F18 image would you like me to test with?
20:28:37 <dmarlin> if agreed, I'd like to see what jonmasters comes up with and decide from there
20:28:50 <pwhalen> jonmasters, still working that out. I may have used an older kernel to boot and install
20:29:24 <jonmasters> ok, I'll just use an F17->F18 upgrade to get this moving, don't really need userspace much here
20:29:24 <pwhalen> the scratch build dmarlin did in koji has been cleared
20:29:44 <dmarlin> jonmasters: we were testing so many images and kernels that I may have overwritten the booting panda image
20:29:54 <jonmasters> no problem
20:29:56 <dmarlin> (with a non-booting kernel)
20:30:23 <dmarlin> jonmasters: note: we did have problems booting on an f17-> f18 upgraded rootfs, IIRC... pwhalen ?
20:30:56 <pwhalen> I think that was load addresses on tegra, once fixed it was fine
20:31:08 <jonmasters> I'll do OMAP first :)
20:31:09 <dmarlin> pwhalen: ok, thanks.
20:32:28 <pwhalen> so, once this kernel is fixed, we can create test images and do a vfad. Depending on when we get the kernel built. I can keep close tabs and schedule a vfad..?
20:32:42 <dmarlin> +1
20:34:49 <pwhalen> #agreed once bootable kernel built, F18 alpha images will be created and vfad scheduled. Email to be sent to the list.
20:35:39 <pwhalen> #topic 4) 3.7 kernel - Device Tree - no longer a choice
20:35:53 <jonmasters> is that a movie title?
20:36:05 <pwhalen> :) a scary film
20:36:21 <dmarlin> Device Tree - An Inconvenient Truth   :)
20:36:26 <bconoboy> Background: We know 3.7 is doing to be chock full of device tree goodness
20:36:32 <bconoboy> but it's not going to land in time for F17 GA.
20:36:36 <bconoboy> er F18 GA
20:36:40 <bconoboy> (I suppose F17 GA is also true:-)
20:36:59 <bconoboy> So, what do we need to do now to make yum updates keep on working after release?
20:37:04 * bconoboy nudges dgilmore
20:37:36 <jonmasters> we need to make sure the moment 3.7-rc1 is out that we test
20:37:44 <bconoboy> eta?
20:37:47 <jonmasters> the merge window is open for 3.7, -rc1 will be very soon
20:37:55 <jonmasters> end of next week or so
20:38:06 <jonmasters> let's say next Friday
20:38:09 <bconoboy> what platforms?
20:38:20 <bconoboy> I mean, will everything we're supporting today be DT enabled?
20:38:57 <dgilmore> bconoboy:
20:39:23 <jonmasters> it should be, dgilmore is working on a kernel subpackage with dtb references
20:39:28 <dgilmore> so we know that 3.7 is going to require DT
20:39:35 <dgilmore> so we need to enable it in GA
20:39:48 <dgilmore> and make sure that all devices are using DT
20:39:58 <dgilmore> and that it is persistent across kernel upgrade
20:40:02 <jonmasters> dgilmore: right, but what bconoboy is asking is how we make sure the upgrade from 3.6 to 3.7 doesn't explode
20:40:02 <djdelorie> i686 requires a DT ?
20:40:17 <dgilmore> we dont want to be in a position where most uses do a yum update to 3.7 and just dont boot
20:40:32 <dgilmore> jonmasters: best way is to enable DT in 3.6
20:40:37 <jonmasters> djdelorie: if you do a sub-arch variant of i686 you get a choice between ACPI, SFI, or DTB
20:40:41 <dgilmore> djdelorie: no
20:41:00 * djdelorie just wonders if the "requires DT" is just ARM or all Fedora platforms...
20:41:05 <bconoboy> dgilmore: Sure.  But practically speaking what does that mean?  Do we need to turn things on in the 3.6 kernel? Do we need new uboot parameters? What all is entailed? Who is doing what?
20:41:06 <jonmasters> only ARM
20:41:16 <jonmasters> indeed, bconoboy +1
20:41:21 <dgilmore> bconoboy: we have been turning on DT for a long time now
20:41:31 <bconoboy> in the kernel?
20:41:43 <jonmasters> we won't know what we need for 3.7 until there's an RC1. I suggest given the timing that we just jump on the 3.7-rc1 next week and test that
20:41:44 <dgilmore> bconoboy: so what it means is that we need to make sure that the systems boot loading the dtb
20:41:48 <dgilmore> bconoboy: yes
20:42:04 <dgilmore> bconoboy: to date DT and non-DT have been supported side by side
20:42:12 <jonmasters> but bconoboy 's point is that just because we turn it on doesn't mean we're using it
20:42:23 <bconoboy> dgilmore: How do I confirm my kernel has it turned on?
20:42:28 <dgilmore> in preperation of unified kernel the old board support is being removed and everything is DT only
20:42:29 <bconoboy> (what's the flag?)
20:42:36 <dgilmore> bconoboy: it shows when you boot
20:42:43 <dgilmore> there is messages about fdt
20:43:05 <jonmasters> bconoboy: you should also see /proc/device-tree
20:43:30 <dgilmore> jonmasters: right
20:43:41 <bconoboy> My tegra system does not have that.
20:43:42 <dgilmore> its pretty obvious that your using DT
20:43:55 <bconoboy> There is no 'fdt' in dmesg, there is no /proc/device-tree
20:43:56 <dgilmore> bconoboy: then your not using DT
20:44:15 <bconoboy> dgilmore: Okay. How to use it?
20:44:44 <jonmasters> bconoboy is making a good point. I really think it's worth considering how many systems are actually using dtb
20:45:09 <bconoboy> I don't really care about system count, I just want to know what has to be done to turn it on.
20:45:10 <dgilmore> bconoboy: if uboot natively supports it you load it to ram and pass it as a 3rd option to the boot line
20:45:24 <bconoboy> Okay, so we're talking about updating boot.cmd or uEnv.txt
20:45:27 <jonmasters> bconoboy: additional point, the dt compiler from Jon L. supports reading from /proc/device-tree and regenerating the dtb from that if you want to take a running kernel and effectively check what it actually used
20:45:28 <dgilmore> bconoboy: if uboot doesnt support it you have to cat dtb>> vmlinuz
20:45:28 <bconoboy> what with?
20:46:10 <dgilmore> bconoboy: we need to update grubby, uEnv.txt boot.scr
20:47:20 <bconoboy> #info We need to update grubby, uEnv.txt for omap and boot.scr for everything else
20:47:35 <jonmasters> so the point is the boot* commands in U-Boot should handle passing in the dtb address but if they don't for a given platform there's a hack where you can build in a dtb
20:47:47 <bconoboy> dgilmore: If we append the dtb to vmlinuz does that automagically get used or is there some flag we pass the kernel to let it know?
20:47:52 <dgilmore> bconoboy: in the case of the trimslice i think we will have to require that the user update uboot
20:47:59 <jonmasters> dgilmore: do you know what the priority is if there's a dtb provided by the platform but also appended to the kernel? kernel wins, right?
20:48:15 <dgilmore> bconoboy: its automatically used but you need to run mkimage after appending it
20:48:35 <bconoboy> dgilmore: is that true of bootz images?
20:48:41 * jonmasters is considering whether there's a way to have the platform dtb win but for F18 also build in a dtb in case U-Boot isn't update
20:48:44 <dgilmore> jonmasters: i i believe thats configurable
20:48:48 <jonmasters> dgilmore: right, ^^^
20:49:06 <jonmasters> that way we'd always have a dtb, even if U-Boot wasn't right
20:49:12 <dgilmore> jonmasters: for omap there is 3 dtb files
20:49:27 <dgilmore> jonmasters: one for beagle one for panda and one for pandaES
20:49:29 <bconoboy> dgilmore: Also, can you paste the link here for all the dtbs you generated?
20:49:33 <dgilmore> well there is others also
20:49:44 <dgilmore> bconoboy: sure
20:49:49 <jonmasters> dtb does also support merging, etc. but we need to check the priority
20:49:49 <dgilmore> #link http://ausil.us/dtb/
20:49:57 <bconoboy> tnx
20:50:08 <dgilmore> #info dtb files generated from the 3.6.0 tree
20:50:10 <bconoboy> dgilmore: Do you have an example load and boot command set using one of those?
20:50:16 <dgilmore> that is all the dtb files
20:50:39 <dgilmore> bconoboy: you load it the same as kernel or initramfs but to its own address
20:50:47 <dgilmore> bconoboy: then add the extra address
20:51:15 <bconoboy> dgilmore: you have done this?  I'm really just looking for a simple thing to copy that's known to work.
20:51:15 <dgilmore> so bootm 80008000 88008000 89008000
20:51:25 <dgilmore> bconoboy: i have done this
20:51:33 * jonmasters has also done this :)
20:51:44 <bconoboy> Okay, I'll take an example from anybody who has done it ;-)
20:51:58 <dgilmore> bconoboy: loading the dtb is the same as loading a kernel
20:52:10 <bconoboy> Right now I do this:
20:52:12 <dgilmore> bconoboy: you give it a different adress and tell it the file name for your dtb
20:52:12 <bconoboy> ext2load usb 0:1 4080000 uImage-tegra
20:52:12 <bconoboy> ext2load usb 0:1 8400000 uInitrd-tegra
20:52:12 <bconoboy> bootm 4080000 8400000
20:52:18 <dgilmore> bconoboy: ok
20:52:22 <jonmasters> bconoboy: so add an ext2load command for the dtb
20:52:29 <jonmasters> bconoboy: then add the address to bootm
20:52:30 <bconoboy> So instead I would do:
20:52:34 <bconoboy> ext2load usb 0:1 4080000 uImage-tegra
20:52:34 <bconoboy> ext2load usb 0:1 8400000 uInitrd-tegra
20:52:35 <bconoboy> ext2load usb 0:1 8800000 dtb-tegra
20:52:35 <bconoboy> bootm 4080000 8400000 8800000
20:52:36 <bconoboy> right?
20:52:43 <dgilmore> bconoboy: yes
20:52:49 <jonmasters> all that does is load the dtb to the memory address given, then bootm passes that address in r2
20:52:53 <dgilmore> bconoboy: to do that uboot has to support fdt
20:53:08 <jonmasters> the kernel then checks the magic in r2 and decides if it's a legacy boot (atags) or dtb
20:53:11 <bconoboy> dgilmore: Okay, and if the uboot doesn't have support then appending to the kernel is the way to go
20:53:19 <dgilmore> bconoboy: yes
20:53:27 <jonmasters> +1
20:53:31 <bconoboy> why don't we always just append to the kernel?
20:53:39 <dgilmore> appending is really not a great or prefered way to do it
20:53:43 <dgilmore> but it is a crutch
20:53:50 <jonmasters> bconoboy: see my comment above! We should verify appending will not take priority
20:53:57 <bconoboy> we're transitioning, isn't a crutch what we want?
20:54:05 <jonmasters> we don't want to be Ubuntu :)
20:54:17 <fossjon> we can include amazon into our fedora os
20:54:22 <fossjon> ads for all
20:54:37 <revident> uboot ads?
20:54:38 <djdelorie> Fedorazon !
20:54:45 <fossjon> HEHE
20:54:46 <bconoboy> Okay, I'll try it out both ways on my tegra and report back.
20:54:53 <jonmasters> It's not a good idea to set the expectation that the OS is providing the dtb. I think a crutch is a good idea, but only if it's secondary to the platform dtb. If we provide the primary dtb, we're doing it wrong
20:54:57 <bconoboy> #action bconoboy to test dtb support on tegra
20:55:24 <jonmasters> (other Linux distros are in the business of providing data that should be provided by the platform, that should not be us)
20:55:48 <dgilmore> we will have to provide the dtb where we provide uboot
20:55:57 <dgilmore> but that should be it
20:55:58 <jonmasters> sure, but you know that's different :)
20:56:10 <dgilmore> jonmasters: right just making it clear to all
20:56:16 <bconoboy> once we have working kernels for mmc we should test the other platforms
20:56:28 <pwhalen> #topic 5) Your topic here
20:56:35 <jonmasters> there are some fanboys who don't just firmware at all and think the kernel should always ship with dtb that is used. Those are the same folks who think U-Boot is supportable as an enterprise bootloader :)
20:56:41 <pwhalen> bconoboy, I started to test on vexpress, will continue that
20:57:04 <dgilmore> jonmasters: indeed
20:57:22 <dgilmore> i believe the long term plan is to remove the dtb sources from the kernel
20:57:27 * jonmasters apologizes for being a little quiet recently here. I'll get helpful with fixing the kernel issues in F18
20:58:27 <dgilmore> jonmasters: on another note my availability is going to be limited and stretched for the rest of the year
20:58:44 <jonmasters> dgilmore: FYI AArch64 initial implementation has a 2MB limit on the dtb, but can use multiple dtbs - and I'm trying hard to get a plan for ACPI support before we have anyone using dtb there
20:59:36 <dgilmore> jonmasters: ACPI and UEFI should be the way
21:00:03 <jonmasters> dgilmore: it will be :)
21:02:38 <bconoboy> we done?
21:02:47 * dgilmore thinks so
21:02:57 <pwhalen> booted vexpress passing in the dtb, not sure if it actually worked
21:03:06 * jonmasters is poking at kernel
21:03:37 <pwhalen> sorry, was semi distracted
21:03:39 <dgilmore> pwhalen: dmesg should show you it is or look for /proc/device-tree
21:03:41 <bconoboy> pwhalen: evidently you should see fdt in dmesg and /proc/device-tree
21:04:10 <jonmasters> I guess it would be nice to have something in /proc/cpuinfo or something
21:04:45 <dgilmore> jonmasters: not sure thats necessary
21:04:52 <pwhalen> yes, looks like there is
21:05:22 <pwhalen> cool, so working in vexpress
21:05:40 <jonmasters> pwhalen: good
21:05:48 <pwhalen> anything else for today?
21:06:01 * jonmasters will update on OMAP first then look at Tegra
21:06:11 <pwhalen> #endmeeting