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