On Mon, Jan 21, 2013 at 6:55 PM, Peter Robinson pbrobinson@gmail.com wrote:
On Mon, Jan 21, 2013 at 6:51 PM, Brendan Conoboy blc@redhat.com wrote:
On 01/21/2013 03:38 PM, Peter Robinson wrote:
On Sun, Jan 20, 2013 at 8:09 PM, Brendan Conoboy blc@redhat.com wrote:
Slight correction: plan is to add a kernel sub package in 3.7 that includes dtbs. This won't go in the rc since the rc will be 3.6 based.
Why a kernel sub package? Why don't we add the dtb files for the platforms that will work to the kernels that support it. We will support half a dozen omap devices (and maybe include a few others that might work) but there's no point shipping 100s of dtb files for devices that we don't even enable the SoC for.
I don't have a firm opinion on this except that we should make a sustainable decision. In my book all that really matters is that upgrading the kernel from 3.6 to 3.7 allows the systems we support to continue booting (and 3.7 to 3.8, etc). In my book that means the kernel provides the dtb (or requires a subpackage that contains the dtb). And the boot script knows to load the dtb if it's available. Wwe might as well do it the way we mean to keep on doing it, so picking good paths for these dtbs makes sense. There will presumably be quite a few of these files with kernel unification.
I think then it should be as part of the kernel. We can make a better decision and they are small so I don't see splitting it into another file makes sense. The directory should be default like the firmwares do but again we should be going with an upstream standard.
Not sure why the list got removed but re-adding.
Peter
On Mon, Jan 21, 2013 at 5:56 PM, Peter Robinson pbrobinson@gmail.comwrote:
On Mon, Jan 21, 2013 at 6:55 PM, Peter Robinson pbrobinson@gmail.com wrote:
On Mon, Jan 21, 2013 at 6:51 PM, Brendan Conoboy blc@redhat.com wrote:
On 01/21/2013 03:38 PM, Peter Robinson wrote:
On Sun, Jan 20, 2013 at 8:09 PM, Brendan Conoboy blc@redhat.com
wrote:
Slight correction: plan is to add a kernel sub package in 3.7 that includes dtbs. This won't go in the rc since the rc will be 3.6
based.
Why a kernel sub package? Why don't we add the dtb files for the platforms that will work to the kernels that support it. We will support half a dozen omap devices (and maybe include a few others that might work) but there's no point shipping 100s of dtb files for devices that we don't even enable the SoC for.
I don't have a firm opinion on this except that we should make a
sustainable
decision. In my book all that really matters is that upgrading the
kernel
from 3.6 to 3.7 allows the systems we support to continue booting (and
3.7
to 3.8, etc). In my book that means the kernel provides the dtb (or requires a subpackage that contains the dtb). And the boot script
knows to
load the dtb if it's available. Wwe might as well do it the way we
mean to
keep on doing it, so picking good paths for these dtbs makes sense.
There
will presumably be quite a few of these files with kernel unification.
I think then it should be as part of the kernel. We can make a better decision and they are small so I don't see splitting it into another file makes sense. The directory should be default like the firmwares do but again we should be going with an upstream standard.
Not sure why the list got removed but re-adding.
Peter
ok so if the kernel were to install many .dtb files that work with the soc, then it makes sense to have them organized into their own folder. Maybe /boot/dtb/*.dtb ??
What about grubby support? When the new kernel is installed we need the right thing to happen to the boot.cmd. I suppose grubby will need to be aware that it's operating on a specific board: panda versus beagle versus beagle bone, etc... Perhaps we should start considering what changes need to happen to grubby, and what load addr's need to be chosen for the .dtb files.
I'm keen on the idea (at least initially) of having both a .dtb file loaded from u-boot, and in parallel have an appended kernel present in /boot. That way if for whatever reason the loading of the .dtb fails the end-user may simply mount the sdcard and swap the boot.scr for the one that specifies the appended kernel. I realize in a perfect world we would never use an appended kernel, but it's wise to plan for the worst, and hope for the best. In my testing some boards only work with appending, so perhaps we might want to consider a way to have some boards always boot one way or another. For our initial support it might be best to use the appended mode for the sake of simplifying things, and later we can convert over to loading .dtb files.
-Jon Disnard irc: masta fas: parasense
From: Jon jdisnard@gmail.com To: arm@lists.fedoraproject.org Sent: Monday, January 21, 2013 11:02 PM Subject: Re: [fedora-arm] F18 ARM Final plan from this morning's hackfest discussion
On Mon, Jan 21, 2013 at 5:56 PM, Peter Robinson pbrobinson@gmail.com wrote:
On Mon, Jan 21, 2013 at 6:55 PM, Peter Robinson pbrobinson@gmail.com wrote:
On Mon, Jan 21, 2013 at 6:51 PM, Brendan Conoboy blc@redhat.com wrote:
On 01/21/2013 03:38 PM, Peter Robinson wrote:
On Sun, Jan 20, 2013 at 8:09 PM, Brendan Conoboy blc@redhat.com wrote:
Slight correction: plan is to add a kernel sub package in 3.7 that includes dtbs. This won't go in the rc since the rc will be 3.6 based.
Why a kernel sub package? Why don't we add the dtb files for the platforms that will work to the kernels that support it. We will support half a dozen omap devices (and maybe include a few others that might work) but there's no point shipping 100s of dtb files for devices that we don't even enable the SoC for.
I don't have a firm opinion on this except that we should make a sustainable decision. In my book all that really matters is that upgrading the kernel from 3.6 to 3.7 allows the systems we support to continue booting (and 3.7 to 3.8, etc). In my book that means the kernel provides the dtb (or requires a subpackage that contains the dtb). And the boot script knows to load the dtb if it's available. Wwe might as well do it the way we mean to keep on doing it, so picking good paths for these dtbs makes sense. There will presumably be quite a few of these files with kernel unification.
I think then it should be as part of the kernel. We can make a better decision and they are small so I don't see splitting it into another file makes sense. The directory should be default like the firmwares do but again we should be going with an upstream standard.
Not sure why the list got removed but re-adding.
Peter
ok so if the kernel were to install many .dtb files that work with the soc, then it makes sense to have them organized into their own folder. Maybe /boot/dtb/*.dtb ??
What about grubby support? When the new kernel is installed we need the right thing to happen to the boot.cmd. I suppose grubby will need to be aware that it's operating on a specific board: panda versus beagle versus beagle bone, etc... Perhaps we should start considering what changes need to happen to grubby, and what load addr's need to be chosen for the .dtb files.
I'm keen on the idea (at least initially) of having both a .dtb file loaded from u-boot, and in parallel have an appended kernel present in /boot. That way if for whatever reason the loading of the .dtb fails the end-user may simply mount the sdcard and swap the boot.scr for the one that specifies the appended kernel. I realize in a perfect world we would never use an appended kernel, but it's wise to plan for the worst, and hope for the best. In my testing some boards only work with appending, so perhaps we might want to consider a way to have some boards always boot one way or another. For our initial support it might be best to use the appended mode for the sake of simplifying things, and later we can convert over to loading .dtb files.
Why not just add the device tree to uboot? Then when the system gets to uboot, it already has a device tree, and you just have to map it to the os? Then you don't have to ship 1000 dtb files and probe the 32 different revs of the same named board. You leave it up to the user to get the right file. You merely just map the device tree in uboot to the OS. Or is that what you are saying? :)
We do not ship u-boot for any boards except maybe Pandaboard.
I believe the device tree blobs are generated from the kernel src, so it might make sense to have them as part of the kernel package or a sub-package.
-Jon Disnard
On Tue, Jan 22, 2013 at 9:36 AM, Jon jdisnard@gmail.com wrote:
We do not ship u-boot for any boards except maybe Pandaboard.
Currently we do for Panda*, Beagle, BBone, and will enable more as we get kernels for them such as some of the samsung devices and as the AllWinner support goes upstream. Basically for nearly half of our supported devices.
I believe the device tree blobs are generated from the kernel src, so it might make sense to have them as part of the kernel package or a sub-package.
That's if they're appended, in theory it could be placed into memory for retrieval by uboot as well which means we wouldn't need the kernel ones. The idea behind this is that the vendor ships a working and supported uboot (like the trimslice has a uboot in firmware) and a generic kernel just boots and retrieves the DT that is provided by the uboot. We should be able to test this if the panda/beagle ones we compile provide DT, we might need to tweak the way we build those uboots to ensure it does provide a DT or to enable the DT. The trimslice in theory should be providing this in their new firmware.
Peter
On Mon, 2013-01-21 at 22:00 -0800, Sean Omalley wrote:
Why not just add the device tree to uboot? Then when the system gets to uboot, it already has a device tree, and you just have to map it to the os? Then you don't have to ship 1000 dtb files and probe the 32 different revs of the same named board. You leave it up to the user to get the right file. You merely just map the device tree in uboot to the OS. Or is that what you are saying? :)
The DTBs are in a state of flux. This is temporary during the transition, but this transition is going to go on for a while, and we will need to carefully match DTB and kernel versions for the foreseeable future. I think this indicates that we should put them in a package required by the kernel, which will allow us to update the kernel and DTBs in lockstep for now but gives us the flexibility to stop updating the DTBs (or update less frequently) once they stop churning.
-Chris
-
Chris Tyler -
Jon -
Peter Robinson -
Sean Omalley