On a plane...quickly written notes below.
F18 - Eclipse. Needs builder gid change for mockuser. Apparently done but need known good NVR. - ghc-devel. Apparently just a dep issue. Needs followup. - js. Confusion exists as to whether fix works. Reconfirm what was tested and consider pkexec has broader issue, whether we are blocked. Probably needs technical probing. - PackageKit. Official update mechanism needs to work (see also pkexec). See also js. - v5 images. Should just need building once we have the above fixed. - dtb. Need to get dtb built into 3.6 based F18 RC images in order to be ready for 3.7. Especially OMAP and Tegra. Dennis prefers built in standard package, ok with doing so in 3.7 kernel (kernel-dtb) and pulling back into RC images as an exception this one time. Saves reissuing 3.6 kernel package. Some testing done. Need to verify all targets have right bits in place and check 3.7 kernel upgrade.
Open issues - 3.7 kernel update scratch built. To send Peter final patch. Known working on highbank and versatile but unclear if upgrade works on e.g. OMAP. Need to at least get dtb in known good state on 3.6 image so we can hope to get 3.7 update right without hacks. Then need to test 3.7 more on OMAP, Tegra. - believe jcm's createrepo fix was never issued in an official package. Needs fix for PHX builders, etc. - spot experienced an issue likely caused by redhat-rpm-config not being installed by default in devel group, or via rpmbuild. Decision (acked by spot) to push for r-r-c dep on rpmbuild (all RPMs built on Fedora are generally Fedora/Red Hat targeted, other targets can then be supported specially via path override - we know we need Panu and others to agree this time around as not first time for this issue). - generic test package needed to e.g. on all arches cause fail if RPM macros or other build environment changes detected. Can then catch unintentional breaks like above mthumb.
On Sun, Jan 20, 2013 at 8:34 PM, Jonathan Masters jcm@redhat.com wrote:
On a plane...quickly written notes below.
F18 [snip]
- js. Confusion exists as to whether fix works. Reconfirm what was
tested and consider pkexec has broader issue, whether we are blocked. Probably needs technical probing.
Installing the latest scratch build on chromebook using f18-armv7hl was not happy when testing 'pkexec yum update' from a wheel user. My hope is that on v5 image the illegal instruction has gone away, somebody plz test.
- PackageKit. Official update mechanism needs to work (see also
pkexec). See also js.
I'm only aware that yumex in a graphical desktop setup (panda, chromebook, highbank, vexpress) would have this issue. We could choose to bundle some other GUI package update tool, or say that the cmdline yum utility is acceptable. That would entirely avoid having to fix the problem with policykit (as a blocker), which may or may not be a js problem.
- v5 images. Should just need building once we have the above fixed.
V5 image for panda would be nice to have, makes life easier to have for troubleshooting v5 issues. Also makes it easier to setup an image creation host for live media creator, or even a builder.
- dtb. Need to get dtb built into 3.6 based F18 RC images in order to
be ready for 3.7. Especially OMAP and Tegra. Dennis prefers built in standard package, ok with doing so in 3.7 kernel (kernel-dtb) and pulling back into RC images as an exception this one time. Saves reissuing 3.6 kernel package. Some testing done. Need to verify all targets have right bits in place and check 3.7 kernel upgrade.
Today I tried to get the pandaboard to boot using the 3.6 DTB from ausil website, and was not successful loading the DTB from u-boot load addr. I suspect for panda we might have to append the DTB to the zimage and run mkimage on it. That would be a great task for grubby or whatever part of the kernel install that invokes mkimage. The problem here is I think the trimslice works when the DTB is loaded from u-boot, but not appended (needs confirmation). So we might get different boards working different ways in terms of device tree.
Open issues
- 3.7 kernel update scratch built. To send Peter final patch. Known
working on highbank and versatile but unclear if upgrade works on e.g. OMAP. Need to at least get dtb in known good state on 3.6 image so we can hope to get 3.7 update right without hacks. Then need to test 3.7 more on OMAP, Tegra.
I promised to open a BZ on the DTB's thing, and will do that shortly. Basically we need to go ahead and get DTB's working for 3.6 kernel *before* 3.7 kernel update lands after we release.
[snip]
-Jon Disnard irc: masta fas: parasense
On Sun, 20 Jan 2013, Jon wrote:
On Sun, Jan 20, 2013 at 8:34 PM, Jonathan Masters jcm@redhat.com wrote:
- dtb. Need to get dtb built into 3.6 based F18 RC images in order to
be ready for 3.7. Especially OMAP and Tegra. Dennis prefers built in standard package, ok with doing so in 3.7 kernel (kernel-dtb) and pulling back into RC images as an exception this one time. Saves reissuing 3.6 kernel package. Some testing done. Need to verify all targets have right bits in place and check 3.7 kernel upgrade.
Today I tried to get the pandaboard to boot using the 3.6 DTB from ausil website, and was not successful loading the DTB from u-boot load addr. I suspect for panda we might have to append the DTB to the zimage and run mkimage on it. That would be a great task for grubby or whatever part of the kernel install that invokes mkimage.
Please don't do that (the DTB append that is). This is a convenience for platform where it is impossible to update the bootloader in order to accommodate a DTB. A Pandaboard certainly does not fall into that category.
And this DTB append is not something I'd advise Fedora to ever support unless there is absolutely no other way. Most of the Fedora ARM targets should have other ways.
U-Boot has had native device tree on ARM for quite a while now. Please ensure that the U-Boot version on your Panda is sufficiently recent.
Nicolas
Hi Nico,
Thanks for your comments. We are aligned in our thinking because (per another mail I sent) we discussed shipping a known good dtb in the final 3.6 F18 images for those targets so that we know the upgrade to 3.7 will work, not using the append approach. Hope this brief explanation elaborates enough as I just got to DC and need to sleep (offline on Monday).
Thanks,
Jon.
On Sun, Jan 20, 2013 at 10:50 PM, Nicolas Pitre nico@fluxnic.net wrote:
On Sun, 20 Jan 2013, Jon wrote:
On Sun, Jan 20, 2013 at 8:34 PM, Jonathan Masters jcm@redhat.com wrote:
- dtb. Need to get dtb built into 3.6 based F18 RC images in order to
be ready for 3.7. Especially OMAP and Tegra. Dennis prefers built in standard package, ok with doing so in 3.7 kernel (kernel-dtb) and pulling back into RC images as an exception this one time. Saves reissuing 3.6 kernel package. Some testing done. Need to verify all targets have right bits in place and check 3.7 kernel upgrade.
Today I tried to get the pandaboard to boot using the 3.6 DTB from ausil website, and was not successful loading the DTB from u-boot load addr. I suspect for panda we might have to append the DTB to the zimage and run mkimage on it. That would be a great task for grubby or whatever part of the kernel install that invokes mkimage.
Please don't do that (the DTB append that is). This is a convenience for platform where it is impossible to update the bootloader in order to accommodate a DTB. A Pandaboard certainly does not fall into that category.
And this DTB append is not something I'd advise Fedora to ever support unless there is absolutely no other way. Most of the Fedora ARM targets should have other ways.
U-Boot has had native device tree on ARM for quite a while now. Please ensure that the U-Boot version on your Panda is sufficiently recent.
It's the latest 2012.10 upstream release, it that sufficiently recent? But I agree on panda/beagle where we use the upstream I believe from my reading the uboot should be supplying the DT blob so it should "just work" the question is why isn't it and how do we tell if uboot is supplying a DT blob?
I've done a lot of googling and reading but while there's a lot of good resources for kernel driver developers for DT there's not really a good resource that I've found for distro side and how to deal with DT, how to check the uboot (or OFW or what ever other boot loader) supplies a DT and whether it is good or not. Is there a way to see it via /proc or /sys or some other means? Commands to print it from uboot? Anything we need to specify in the kernel to ensure it attempts to retrieve it first from the boot loader and a way to fail back if it doesn't?
Peter
On Mon, 21 Jan 2013, Peter Robinson wrote:
On Sun, Jan 20, 2013 at 10:50 PM, Nicolas Pitre nico@fluxnic.net wrote:
On Sun, 20 Jan 2013, Jon wrote:
On Sun, Jan 20, 2013 at 8:34 PM, Jonathan Masters jcm@redhat.com wrote:
- dtb. Need to get dtb built into 3.6 based F18 RC images in order to
be ready for 3.7. Especially OMAP and Tegra. Dennis prefers built in standard package, ok with doing so in 3.7 kernel (kernel-dtb) and pulling back into RC images as an exception this one time. Saves reissuing 3.6 kernel package. Some testing done. Need to verify all targets have right bits in place and check 3.7 kernel upgrade.
Today I tried to get the pandaboard to boot using the 3.6 DTB from ausil website, and was not successful loading the DTB from u-boot load addr. I suspect for panda we might have to append the DTB to the zimage and run mkimage on it. That would be a great task for grubby or whatever part of the kernel install that invokes mkimage.
Please don't do that (the DTB append that is). This is a convenience for platform where it is impossible to update the bootloader in order to accommodate a DTB. A Pandaboard certainly does not fall into that category.
And this DTB append is not something I'd advise Fedora to ever support unless there is absolutely no other way. Most of the Fedora ARM targets should have other ways.
U-Boot has had native device tree on ARM for quite a while now. Please ensure that the U-Boot version on your Panda is sufficiently recent.
It's the latest 2012.10 upstream release, it that sufficiently recent?
Certainly.
But I agree on panda/beagle where we use the upstream I believe from my reading the uboot should be supplying the DT blob so it should "just work" the question is why isn't it and how do we tell if uboot is supplying a DT blob?
Well, you have to supply U-Boot with a DT blob. In an ideal world, the DT blob describes hardware and that doesn't change, so in theory you'd install the DT blob into the boot media alongside U-Boot and then you'd forget about both of them. A new kernel wouldn't need to care about either U-Boot or the DTB.
In practice, things aren't as pretty as we'd like them to be, so mistakes and omissions in the DTB have to be fixed over time. This is why U-Boot is not providing a DTB on its own. However you need to tell U-Boot where to get the DTB.
To do that, you load the DTB just as you would do with any regular image from whatever source, and then use the 'fdt addr' command to tell U-Boot where it is. From that point, U-Boot will be able to update the provided DTB with information such as the effective RAM topology, the ramdisk address and the kernel cmdline string before the kernel is booted.
I've done a lot of googling and reading but while there's a lot of good resources for kernel driver developers for DT there's not really a good resource that I've found for distro side and how to deal with DT, how to check the uboot (or OFW or what ever other boot loader) supplies a DT and whether it is good or not. Is there a way to see it via /proc or /sys or some other means?
With CONFIG_PROC_DEVICETREE=y in your kernel config, you'll be able to browse the DT content in /proc/device-tree/.
Commands to print it from uboot?
There are subcommands to the U-Boot fdt command to do that. Try 'fdt help' at the U-Boot prompt.
Anything we need to specify in the kernel to ensure it attempts to retrieve it first from the boot loader and a way to fail back if it doesn't?
The kernel doesn't retrieve anything. It expects the DTB to be available in memory, and its location passed to the kernel from the bootloader via register r2. With no DTB, the kernel is toast. That's why U-Boot needs to be told about the location of the DTB in order to pass that over to the kernel, possibly after some modifications of its own to the DTB.
Nicolas
On Sun, Jan 20, 2013 at 9:34 PM, Jonathan Masters jcm@redhat.com wrote:
On a plane...quickly written notes below.
F18
- Eclipse. Needs builder gid change for mockuser. Apparently done but need known good NVR.
I've got the following running once I fixed dep and repo issues. It's been running about 12 hours so 24 to go. http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1378395
- ghc-devel. Apparently just a dep issue. Needs followup.
Not quite so simple as "just a dep issue"
- js. Confusion exists as to whether fix works. Reconfirm what was tested and consider pkexec has broader issue, whether we are blocked. Probably needs technical probing.
The patch that was posted to BZ is wrong. Need to sort out the cflags properly. I've seen the change that has been pushed and I still don't believe it is a correct and proper fix.
- PackageKit. Official update mechanism needs to work (see also pkexec). See also js.
- v5 images. Should just need building once we have the above fixed.
- dtb. Need to get dtb built into 3.6 based F18 RC images in order to be ready for 3.7. Especially OMAP and Tegra. Dennis prefers built in standard package, ok with doing so in 3.7 kernel (kernel-dtb) and pulling back into RC images as an exception this one time. Saves reissuing 3.6 kernel package. Some testing done. Need to verify all targets have right bits in place and check 3.7 kernel upgrade.
Please flesh this out in a separate thread because that doesn't make sense for my understanding of this issue.
Open issues
- 3.7 kernel update scratch built. To send Peter final patch. Known working on highbank and versatile but unclear if upgrade works on e.g. OMAP. Need to at least get dtb in known good state on 3.6 image so we can hope to get 3.7 update right without hacks. Then need to test 3.7 more on OMAP, Tegra.
I think we need to forget about 3.6 and move onto and get it working on 3.7+. There's a lot of changes between 3.6 and 3.7 for dtb so I think 3.6 is a dead end. The omap kernel for 3.7 on rawhide was reported as working by a number of people and it's a straight pull over from there so I'm not sure what the issues are or whether there was problems with the testing from the rawhide kernel.
I've got a couple of queries about the highbank patch which I'll catch up with you at some point soon about.
- believe jcm's createrepo fix was never issued in an official package. Needs fix for PHX builders, etc.
No, it was reported by seth to be fixed upstream already in a different means so it was never pushed upstream because of that. We need to test upstream to ensure it does fix the problem we see and then review again.
- spot experienced an issue likely caused by redhat-rpm-config not being installed by default in devel group, or via rpmbuild. Decision (acked by spot) to push for r-r-c dep on rpmbuild (all RPMs built on Fedora are generally Fedora/Red Hat targeted, other targets can then be supported specially via path override - we know we need Panu and others to agree this time around as not first time for this issue).
That problem has come up before, I know at one point upstream was talking about merging r-r-c straight into rpm-devel and killing r-r-c but that was back in the F-12 days or there abouts and I don't know what happened to it.
- generic test package needed to e.g. on all arches cause fail if RPM macros or other build environment changes detected. Can then catch unintentional breaks like above mthumb.
Can you go into more details as to what you mean by this.
Peter
Peter Robinson píše v Po 21. 01. 2013 v 05:20 -0500:
On Sun, Jan 20, 2013 at 9:34 PM, Jonathan Masters jcm@redhat.com wrote:
On a plane...quickly written notes below.
F18
- Eclipse. Needs builder gid change for mockuser. Apparently done but need known good NVR.
I've got the following running once I fixed dep and repo issues. It's been running about 12 hours so 24 to go. http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1378395
FYI eclipse 4.2.2 takes cca 20% more time to build on s390 when compared to 4.2.1 build times
Dan
-
Dan Horák -
Jon -
Jon Masters -
Nicolas Pitre -
Peter Robinson