Bug#731345: flash-kernel: add support for DT based kernels on Sheeva Plug
Package: flash-kernel Version: 3.11 Severity: normal Tags: patch Hello, I've two patches to support DT based kernel on Sheeva Plug. These patches are needed to boot 3.12 (which is currently in experimental). regards, Marc -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (700, 'testing'), (70, 'experimental'), (70, 'unstable') Architecture: armel (armv5tel) Kernel: Linux 3.12-trunk-kirkwood Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages flash-kernel depends on: ii devio1.2-1+b1 ii initramfs-tools 0.115 ii linux-base 3.5 flash-kernel recommends no packages. Versions of packages flash-kernel suggests: ii u-boot-tools 2013.01.01-4 -- no debconf information >From 4fb0373e4596a5efcbc086b7e127096efd36fd7c Mon Sep 17 00:00:00 2001 From: Marc Kleine-Budde Date: Wed, 4 Dec 2013 13:59:40 +0100 Subject: [PATCH 1/2] all.db: add dtb support for Sheeva Plug This patch adds support to upgrade from a non DT based kernel (linux-image-3.11-2-kirkwood) or older to a DT based one (i.e. linux-image-3.12-trunk-kirkwood which is currently in experimental). --- db/all.db | 3 +++ 1 file changed, 3 insertions(+) diff --git a/db/all.db b/db/all.db index 76e99fd..55db11a 100644 --- a/db/all.db +++ b/db/all.db @@ -250,10 +250,13 @@ Bootloader-Sets-Root: no Machine: Marvell SheevaPlug Reference Board Kernel-Flavors: kirkwood +DTB-Id: kirkwood-sheevaplug.dtb +DTB-Append: yes U-Boot-Kernel-Address: 0x8000 U-Boot-Initrd-Address: 0x0 Boot-Kernel-Path: /boot/uImage Boot-Initrd-Path: /boot/uInitrd +Boot-DTB-Path: dtb Required-Packages: u-boot-tools Bootloader-Sets-Root: no -- 1.8.5.rc0 >From 2595607efde8338d35863e00eb60d409db050ec2 Mon Sep 17 00:00:00 2001 From: Marc Kleine-Budde Date: Wed, 4 Dec 2013 14:03:55 +0100 Subject: [PATCH 2/2] all.db: add section for DT based Sheeva Plug This patch is needed to let flash-kernel recognize a DT based Sheeva Plug. --- db/all.db | 12 1 file changed, 12 insertions(+) diff --git a/db/all.db b/db/all.db index 55db11a..3e060e4 100644 --- a/db/all.db +++ b/db/all.db @@ -248,6 +248,18 @@ Boot-Initrd-Path: /boot/uInitrd Required-Packages: u-boot-tools Bootloader-Sets-Root: no +Machine: Globalscale Technologies SheevaPlug +Kernel-Flavors: kirkwood +DTB-Id: kirkwood-sheevaplug.dtb +DTB-Append: yes +U-Boot-Kernel-Address: 0x8000 +U-Boot-Initrd-Address: 0x0 +Boot-Kernel-Path: /boot/uImage +Boot-Initrd-Path: /boot/uInitrd +Boot-DTB-Path: dtb +Required-Packages: u-boot-tools +Bootloader-Sets-Root: no + Machine: Marvell SheevaPlug Reference Board Kernel-Flavors: kirkwood DTB-Id: kirkwood-sheevaplug.dtb -- 1.8.5.rc0
Bug#731345: flash-kernel: add support for DT based kernels on Sheeva Plug
On 12/05/2013 11:43 AM, Martin Michlmayr wrote: > * Marc Kleine-Budde [2013-12-04 14:23]: >> Hello, I've two patches to support DT based kernel on Sheeva >> Plug. These patches are needed to boot 3.12 (which is currently in >> experimental). > > When I spoke to Ian Campbell recently, I got the impression that the > plan was to keep devices that were not using DT in wheezy as non-DT > in future releases. So maybe the kernel config for 3.12 should be > changed? That's no option, as non DT Sheeva Plug support has been removed from the kernel in ffbc50663b69462adc9d97b93b6b92c4fe74b94c: ffbc506 ARM: kirkwood: remove support for legacy booting of Sheevaplug This patch was first released on mainline linux in v3.12-rc1. Marc signature.asc Description: OpenPGP digital signature
Bug#731345: flash-kernel: add support for DT based kernels on Sheeva Plug
On 12/05/2013 12:34 PM, Martin Michlmayr wrote: > * Marc Kleine-Budde [2013-12-05 11:49]: >> That's no option, as non DT Sheeva Plug support has been removed from >> the kernel in ffbc50663b69462adc9d97b93b6b92c4fe74b94c: >> >> ffbc506 ARM: kirkwood: remove support for legacy booting of Sheevaplug > > Interesting. I thought they promised not to remove non-DT support for > existing devices. I personally don't mind, if it's removed once the DT works properly. > Anyway, Marc, so thanks for your patch. I wonder if it makes sense to > add a check to flash-kernel whether DT is required or not. i.e. that > flash-kernel would append the DT blob on 3.12+ kernels on SheevaPlug > but not on previous kernels. Yes, sounds like the way to go. Otherwise you have to tie certain flash-kernel versions to the non-DT and DT kernels. This will probably not scale when more no-DT board are removed from the kernel. Where should this information go? What about adding another field to all.db which limits an entry to certain kernel versions? Something like this: Machine: Marvell SheevaPlug Reference Board Kernel-Flavors: kirkwood Kernel-Version: < 3.12 U-Boot-Kernel-Address: 0x8000 U-Boot-Initrd-Address: 0x0 Boot-Kernel-Path: /boot/uImage Boot-Initrd-Path: /boot/uInitrd Required-Packages: u-boot-tools Bootloader-Sets-Root: no Machine: Marvell SheevaPlug Reference Board Kernel-Flavors: kirkwood Kernel-Version: >= 3.12 DTB-Id: kirkwood-sheevaplug.dtb DTB-Append: yes U-Boot-Kernel-Address: 0x8000 U-Boot-Initrd-Address: 0x0 Boot-Kernel-Path: /boot/uImage Boot-Initrd-Path: /boot/uInitrd Boot-DTB-Path: dtb Required-Packages: u-boot-tools Bootloader-Sets-Root: no Marc signature.asc Description: OpenPGP digital signature
Bug#731345: flash-kernel: add support for DT based kernels on Sheeva Plug
On 12/05/2013 12:57 PM, Ian Campbell wrote: > On Thu, 2013-12-05 at 12:46 +0100, Marc Kleine-Budde wrote: >> On 12/05/2013 12:34 PM, Martin Michlmayr wrote: >>> * Marc Kleine-Budde [2013-12-05 11:49]: >>>> That's no option, as non DT Sheeva Plug support has been removed from >>>> the kernel in ffbc50663b69462adc9d97b93b6b92c4fe74b94c: >>>> >>>> ffbc506 ARM: kirkwood: remove support for legacy booting of Sheevaplug >>> >>> Interesting. I thought they promised not to remove non-DT support for >>> existing devices. >> >> I personally don't mind, if it's removed once the DT works properly. >> >>> Anyway, Marc, so thanks for your patch. I wonder if it makes sense to >>> add a check to flash-kernel whether DT is required or not. i.e. that >>> flash-kernel would append the DT blob on 3.12+ kernels on SheevaPlug >>> but not on previous kernels. >> >> Yes, sounds like the way to go. Otherwise you have to tie certain >> flash-kernel versions to the non-DT and DT kernels. This will probably >> not scale when more no-DT board are removed from the kernel. >> >> Where should this information go? What about adding another field to >> all.db which limits an entry to certain kernel versions? Something like >> this: > > I think it would be sufficient to have a field marking the DTB as > optional and have f-k only do the append if there is a dtb present in > the DTS directory (/usr/lib/linux-X.Y/whatever) for the version it is > handling. If the kernel needs a DTB but doesn't ship one, well ,that's a > bug in the kernel (until we get to the point of burning DTBs into > firmware, but lets not worry about that now!). ...or when the DT sources will be move into a separate repository. > I take it from your original patches that the machine ID differs with DT > vs non as well? Yes, this is why the second patch adds another entry. Marc signature.asc Description: OpenPGP digital signature
Bug#731345: flash-kernel: add support for DT based kernels on Sheeva Plug
On 12/05/2013 01:15 PM, Ian Campbell wrote: > On Thu, 2013-12-05 at 13:04 +0100, Marc Kleine-Budde wrote: >> On 12/05/2013 12:57 PM, Ian Campbell wrote: >>> On Thu, 2013-12-05 at 12:46 +0100, Marc Kleine-Budde wrote: >>>> On 12/05/2013 12:34 PM, Martin Michlmayr wrote: >>>>> * Marc Kleine-Budde [2013-12-05 11:49]: >>>>>> That's no option, as non DT Sheeva Plug support has been removed from >>>>>> the kernel in ffbc50663b69462adc9d97b93b6b92c4fe74b94c: >>>>>> >>>>>> ffbc506 ARM: kirkwood: remove support for legacy booting of Sheevaplug >>>>> >>>>> Interesting. I thought they promised not to remove non-DT support for >>>>> existing devices. >>>> >>>> I personally don't mind, if it's removed once the DT works properly. >>>> >>>>> Anyway, Marc, so thanks for your patch. I wonder if it makes sense to >>>>> add a check to flash-kernel whether DT is required or not. i.e. that >>>>> flash-kernel would append the DT blob on 3.12+ kernels on SheevaPlug >>>>> but not on previous kernels. >>>> >>>> Yes, sounds like the way to go. Otherwise you have to tie certain >>>> flash-kernel versions to the non-DT and DT kernels. This will probably >>>> not scale when more no-DT board are removed from the kernel. >>>> >>>> Where should this information go? What about adding another field to >>>> all.db which limits an entry to certain kernel versions? Something like >>>> this: >>> >>> I think it would be sufficient to have a field marking the DTB as >>> optional and have f-k only do the append if there is a dtb present in >>> the DTS directory (/usr/lib/linux-X.Y/whatever) for the version it is >>> handling. If the kernel needs a DTB but doesn't ship one, well ,that's a >>> bug in the kernel (until we get to the point of burning DTBs into >>> firmware, but lets not worry about that now!). >> >> ...or when the DT sources will be move into a separate repository. > > Indeed. > > Actually, now that I think about it -- a non-DT aware kernel just > shouldn't care if you append a DT to it, it won't ever go looking. It's > probably safe to just append it unconditionally. Yes, should be safe. > Which is what you did, so we've come full circle, sorry for the > distraction. It's good to talk about the implications. If we want to handle downgrading of kernels with an updated flash-kernel, I think, that cannot be done without an additional Kernel-Version field. This is because v3.11 ships with: /usr/lib/linux-image-3.11-2-kirkwood/kirkwood-sheevaplug.dtb But non-DT Sheeva support is still in the kernel, so non-DT Sheeva Plug is used with current flash-kernel and v3.11. Although v3.10 and v3.11 are not Wheezy's kernels. > I suppose it would be nice to just check that the Wheezy kernel doesn't > complain about or get confused by the appended DTB. Can you check that? I don't have physical access to that Sheeva Plug. Marc signature.asc Description: OpenPGP digital signature
Bug#731345: flash-kernel: add support for DT based kernels on Sheeva Plug
On 12/05/2013 06:01 PM, Ian Campbell wrote: > On Thu, 2013-12-05 at 13:39 +0100, Marc Kleine-Budde wrote: >> On 12/05/2013 01:15 PM, Ian Campbell wrote: >>> On Thu, 2013-12-05 at 13:04 +0100, Marc Kleine-Budde wrote: >>>> On 12/05/2013 12:57 PM, Ian Campbell wrote: >>>>> On Thu, 2013-12-05 at 12:46 +0100, Marc Kleine-Budde wrote: >>>>>> On 12/05/2013 12:34 PM, Martin Michlmayr wrote: >>>>>>> * Marc Kleine-Budde [2013-12-05 11:49]: >>>>>>>> That's no option, as non DT Sheeva Plug support has been removed from >>>>>>>> the kernel in ffbc50663b69462adc9d97b93b6b92c4fe74b94c: >>>>>>>> >>>>>>>> ffbc506 ARM: kirkwood: remove support for legacy booting of Sheevaplug >>>>>>> >>>>>>> Interesting. I thought they promised not to remove non-DT support for >>>>>>> existing devices. >>>>>> >>>>>> I personally don't mind, if it's removed once the DT works properly. >>>>>> >>>>>>> Anyway, Marc, so thanks for your patch. I wonder if it makes sense to >>>>>>> add a check to flash-kernel whether DT is required or not. i.e. that >>>>>>> flash-kernel would append the DT blob on 3.12+ kernels on SheevaPlug >>>>>>> but not on previous kernels. >>>>>> >>>>>> Yes, sounds like the way to go. Otherwise you have to tie certain >>>>>> flash-kernel versions to the non-DT and DT kernels. This will probably >>>>>> not scale when more no-DT board are removed from the kernel. >>>>>> >>>>>> Where should this information go? What about adding another field to >>>>>> all.db which limits an entry to certain kernel versions? Something like >>>>>> this: >>>>> >>>>> I think it would be sufficient to have a field marking the DTB as >>>>> optional and have f-k only do the append if there is a dtb present in >>>>> the DTS directory (/usr/lib/linux-X.Y/whatever) for the version it is >>>>> handling. If the kernel needs a DTB but doesn't ship one, well ,that's a >>>>> bug in the kernel (until we get to the point of burning DTBs into >>>>> firmware, but lets not worry about that now!). >>>> >>>> ...or when the DT sources will be move into a separate repository. >>> >>> Indeed. >>> >>> Actually, now that I think about it -- a non-DT aware kernel just >>> shouldn't care if you append a DT to it, it won't ever go looking. It's >>> probably safe to just append it unconditionally. >> >> Yes, should be safe. >> >>> Which is what you did, so we've come full circle, sorry for the >>> distraction. >> >> It's good to talk about the implications. If we want to handle >> downgrading of kernels with an updated flash-kernel, I think, that >> cannot be done without an additional Kernel-Version field. >> >> This is because v3.11 ships with: >> >> /usr/lib/linux-image-3.11-2-kirkwood/kirkwood-sheevaplug.dtb >> >> But non-DT Sheeva support is still in the kernel, so non-DT Sheeva Plug >> is used with current flash-kernel and v3.11. Although v3.10 and v3.11 >> are not Wheezy's kernels. > > Is 3.11+DTB actively broken though? v3.11+DT works on Sheeva Plug, just tested it. I was thinking of the following scenario: I have installed current flash-kernel (without DT support) and kernel v3.11. Then the new flash-kernel with append-DT-if-present-in-the-Kernel-package feature is released together with a new DT only kernel (=v3.12). I upgrade, because I want to have the shiny new kernel. For whatever reason I want to downgrade to v3.11, then I end up with v3.11 with DT, because the flash-kernel is still the new one. The system does not behave as I expected. I downgraded to the same kernel but now the DT Sheeva Plug is booted. Although the bootloader sets the ARCH number, a attached DT seems to be preferred. >>> I suppose it would be nice to just check that the Wheezy kernel doesn't >>> complain about or get confused by the appended DTB. Can you check that? >> >> I don't have physical access to that Sheeva Plug. > > Hrm, this would be something which would be good to try somewhere. On Wheezy there is no Sheevaplug DTB to attach... > Now I think of it the Wheezy kirkwood kernel did have DT and > APPENDED_DTB support enabled, in order to support dreamplugs. http://packages.debian.org/wheezy/armel/linux-image-3.2.0-4-kirkwood/filelist Wheezy has two dtb files: /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-dreamplug.dtb /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-iconnect.dtb > I have a feeling that would mean that it wouldn't boot if you appended a > dtb to it. Which would mean we do have to think about versioned checks > or something. Just stating the obvious: The Sheeva Plug probably wouldn't boot if I attach a dreamplug dtb to it. :) Marc signature.asc Description: OpenPGP digital signature
Bug#731345: flash-kernel: add support for DT based kernels on Sheeva Plug
On 12/06/2013 09:31 AM, Ian Campbell wrote: It's good to talk about the implications. If we want to handle downgrading of kernels with an updated flash-kernel, I think, that cannot be done without an additional Kernel-Version field. This is because v3.11 ships with: /usr/lib/linux-image-3.11-2-kirkwood/kirkwood-sheevaplug.dtb But non-DT Sheeva support is still in the kernel, so non-DT Sheeva Plug is used with current flash-kernel and v3.11. Although v3.10 and v3.11 are not Wheezy's kernels. >>> >>> Is 3.11+DTB actively broken though? >> >> v3.11+DT works on Sheeva Plug, just tested it. > > That's good. Do you know if v3.10 or earlier shipped a DT in the kernel > package? There is no DT for Sheeva Plug in Debian's v3.10, but 25 dtb in total. >> I was thinking of the following scenario: >> >> I have installed current flash-kernel (without DT support) and kernel >> v3.11. Then the new flash-kernel with >> append-DT-if-present-in-the-Kernel-package feature is released together >> with a new DT only kernel (=v3.12). I upgrade, because I want to have >> the shiny new kernel. >> >> For whatever reason I want to downgrade to v3.11, then I end up with >> v3.11 with DT, because the flash-kernel is still the new one. > > Right, this is the scenario I am worried about. > >> The system does not behave as I expected. I downgraded to the same >> kernel but now the DT Sheeva Plug is booted. > > Ideally v3.11+DT would work well enough that the user wouldn't care > about the difference. even if not I think so long as v3.11+DT works well > enough to be able to manually fix things (e.g. by downgrading f-k) then > this would be an acceptable trade-off to support such partial upgrades. Yes works for me. >> Although the bootloader sets the ARCH number, an attached DT seems to be >> preferred. > > That is what I would expect, yes. > > I suppose it would be nice to just check that the Wheezy kernel doesn't > complain about or get confused by the appended DTB. Can you check that? I don't have physical access to that Sheeva Plug. >>> >>> Hrm, this would be something which would be good to try somewhere. >> >> On Wheezy there is no Sheevaplug DTB to attach... > > Oh yes, of course. > >>> Now I think of it the Wheezy kirkwood kernel did have DT and >>> APPENDED_DTB support enabled, in order to support dreamplugs. >> >> http://packages.debian.org/wheezy/armel/linux-image-3.2.0-4-kirkwood/filelist >> >> Wheezy has two dtb files: >> >> /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-dreamplug.dtb >> /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-iconnect.dtb >> >>> I have a feeling that would mean that it wouldn't boot if you appended a >>> dtb to it. Which would mean we do have to think about versioned checks >>> or something. >> >> Just stating the obvious: The Sheeva Plug probably wouldn't boot if I >> attach a dreamplug dtb to it. :) > > Right, I was thinking/worrying that it won't boot if you attach any DTB > to it, including a newer one for the shivaplug. But of course f-k > wouldn't ever do that. > > So the only concern is intermediate kernel versions which have a DT file > but prefer non-DT operation. As I say I think so long as it boots well > enough to allow repair then this is ok. In Debian, v3.11 is the first kernel that ships with a Sheeva Plug DT and that works for me. > Do shivaplugs typically provide u-boot console access as standard or > does that require soldering and/or cracking the case open? No, just plug in a Mini USB Cable and you have a serial console (and a JTAG for debricking via openocd). Marc signature.asc Description: OpenPGP digital signature
Bug#731345: flash-kernel: add support for DT based kernels on Sheeva Plug
On 12/06/2013 09:31 AM, Ian Campbell wrote: [...] This is because v3.11 ships with: /usr/lib/linux-image-3.11-2-kirkwood/kirkwood-sheevaplug.dtb But non-DT Sheeva support is still in the kernel, so non-DT Sheeva Plug is used with current flash-kernel and v3.11. Although v3.10 and v3.11 are not Wheezy's kernels. >>> >>> Is 3.11+DTB actively broken though? >> >> v3.11+DT works on Sheeva Plug, just tested it. > > That's good. Do you know if v3.10 or earlier shipped a DT in the kernel > package? I just noticed that the Ethernet is missing with v3.11+DT. Ethernet support was added with v3.12-rc1~114^2~10^2~12. So probably don't want to use v3.11-DT on the Sheeva Plug. Marc signature.asc Description: OpenPGP digital signature
Bug#731345: Kirkwood Kernel 3.12-1
Martin Michlmayr wrote:
>Adding Marc, who proposed the initial patch.
>
>* Ian Campbell [2014-01-08 08:35]:
>> (adding the bug)
>>
>> On Wed, 2014-01-08 at 08:22 +0100, Martin Michlmayr wrote:
>> > Hi Markus,
>> >
>> > * Markus Krebs [2014-01-08 06:25]:
>> > > I just wanted to let you know that the last kernel update in
>testing
>> > > ("jessie") to 3.12-1 went really bad on my SheevaPlug. It
>wouldn't
>> > > boot anymore ("Error: unrecognized/unsupported machine ID (r1 =
>> > > 0x0831)"). Also the uImage.bak and the uInitrd.bak which had
>been
>> >
>> > flash-kernel needs the patch from #731345.
>> >
>> > Ian, 3.12 is in testing now. Is the patch from #731345 ready now
>and
>> > can you make an upload?
>>
>> When I was testing the ts41x DT patches from Andrew Lunn at the
>weekend
>> I found that the approach of just adding the DTB-Append option broke
>> with older kernels, complaining (rightly) that the DTB file wasn't
>> present.
>>
>> So, assuming I've not misdiagnosed it, the patch needs to be expanded
>> with some sort of conditional to cope with this, I haven't had time
>to
>> look into that. The bug thread came to the same conclusion, although
>the
>> rationale was different.
>>
>> An alternative would be for f-k to declare Breaks against older
>kernels.
>> I don't really want to do that though, since it would make upgrades
>> harder than they need to be.
>>
>> The best option is probably a "DTB-Optional-Before: version" field I
>> guess?
Not quite, as 3.11 comes with DT for the sheeva plug, but that DT lacks
ethernet support.
Marc
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/0759aae8-e754-40a8-9f9b-be3cbdf23...@email.android.com
Bug#731345: flash-kernel: add support for DT based kernels on Sheeva Plug
Andrew Lunn wrote: >> Not quite, as 3.11 comes with DT for the sheeva plug, but that DT >> lacks ethernet support. > >Hi Marc > >I've not tested it, but ethernet should work. Adding DT support to the >ethernet driver took time, so during the transition, we instantiated >ethernet using old style platform_driver. > >If it really does not work, it is a bug, which i will fix and get put >into stable. > >Feel free to ask me about such issues. Sheeva Plug without DT works on 3.11, but there isn't any Ethernet with 3.11 and appended DT. I'm in 3.12 with my proposed patches and everything is fine. Marc -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1beee380-916b-442d-8076-68fa82ec8...@email.android.com
Bug#857205: flash-kernel: Add support for TI OMAP4 PandaBoard-ES
Package: flash-kernel Version: 3.75 Severity: normal Tags: d-i patch Dear Maintainer, the attached patch adds support for TI OMAP4 PandaBoard-ES using debian's latest u-boot and kernel release. This change is needed, as the OMAP4 architecture uses Device Tree for some time. regards, Marc -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (700, 'testing'), (70, 'experimental'), (70, 'unstable') Architecture: armhf (armv7l) Kernel: Linux 4.9.0-2-armmp (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages flash-kernel depends on: ii debconf [debconf-2.0] 1.5.60 ii devio 1.2-1.2+b1 ii initramfs-tools0.127 ii linux-base 4.5 ii mtd-utils 1:2.0.0-1 ii ucf3.0036 Versions of packages flash-kernel recommends: ii u-boot-tools 2016.11+dfsg1-3 flash-kernel suggests no packages. -- debconf information: flash-kernel/linux_cmdline: quiet >From a956634eac5ef45395d7318f6d4a10f43ac909e8 Mon Sep 17 00:00:00 2001 From: Marc Kleine-Budde Date: Wed, 8 Mar 2017 21:31:25 +0100 Subject: [PATCH] Add machine db entry for TI OMAP4 PandaBoard-ES --- db/all.db | 7 +++ 1 file changed, 7 insertions(+) diff --git a/db/all.db b/db/all.db index dc43ce33f57f..6209db44ae1e 100644 --- a/db/all.db +++ b/db/all.db @@ -1088,6 +1088,13 @@ Boot-Initrd-Path: uInitrd Boot-Script-Path: boot.scr Required-Packages: u-boot-tools +Machine: TI OMAP4 PandaBoard-ES +Kernel-Flavors: armmp armmp-lpae +DTB-Id: omap4-panda-es.dtb +Boot-Script-Path: /boot/boot.scr +U-Boot-Script-Name: bootscr.uboot-generic +Required-Packages: u-boot-tools + Machine: Orange Pi Kernel-Flavors: armmp armmp-lpae Boot-Script-Path: /boot/boot.scr -- 2.11.0
Bug#857205: flash-kernel: Add support for TI OMAP4 PandaBoard-ES
On 03/09/2017 02:35 AM, Sebastian Reichel wrote: > On Wed, Mar 08, 2017 at 08:53:50PM +0000, Marc Kleine-Budde wrote: >> +Machine: TI OMAP4 PandaBoard-ES >> +Kernel-Flavors: armmp armmp-lpae > > OMAP4 is Cortex A9, so no LPAE support. Thanks, fixed in v2 - see attachment. Marc From d63da8c5ba444f9a670d6762a9dfb634cd3dfb47 Mon Sep 17 00:00:00 2001 From: Marc Kleine-Budde Date: Wed, 8 Mar 2017 21:31:25 +0100 Subject: [PATCH v2] Add machine db entry for TI OMAP4 PandaBoard-ES --- db/all.db | 7 +++ 1 file changed, 7 insertions(+) diff --git a/db/all.db b/db/all.db index dc43ce33f57f..b57061bde227 100644 --- a/db/all.db +++ b/db/all.db @@ -1088,6 +1088,13 @@ Boot-Initrd-Path: uInitrd Boot-Script-Path: boot.scr Required-Packages: u-boot-tools +Machine: TI OMAP4 PandaBoard-ES +Kernel-Flavors: armmp +DTB-Id: omap4-panda-es.dtb +Boot-Script-Path: /boot/boot.scr +U-Boot-Script-Name: bootscr.uboot-generic +Required-Packages: u-boot-tools + Machine: Orange Pi Kernel-Flavors: armmp armmp-lpae Boot-Script-Path: /boot/boot.scr -- 2.11.0 smime.p7s Description: S/MIME Cryptographic Signature
Bug#781371: flash-kernel: Update machine entry for OpenRD boards
Package: flash-kernel Version: 3.33 Severity: normal Dear Maintainer, since linux kernel version 3.16 the OpenRD boards have been converted to device tree. regrads, Marc -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (700, 'testing'), (70, 'experimental'), (70, 'unstable') Architecture: armel (armv5tel) Kernel: Linux 3.14-2-kirkwood Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages flash-kernel depends on: ii debconf [debconf-2.0] 1.5.56 ii devio 1.2-1+b1 ii initramfs-tools0.119 ii linux-base 3.5 ii ucf3.0030 flash-kernel recommends no packages. Versions of packages flash-kernel suggests: ii u-boot-tools 2014.10+dfsg1-4 -- debconf information: flash-kernel/linux_cmdline: quiet >From 70eac0cb01311f6274a03434415240e3645e5589 Mon Sep 17 00:00:00 2001 From: Marc Kleine-Budde Date: Thu, 8 Jan 2015 12:37:17 +0100 Subject: [PATCH] Update machine entry for OpenRD boards Since 3.16 a appended Device Tree is needed. --- db/all.db | 9 + 1 file changed, 9 insertions(+) diff --git a/db/all.db b/db/all.db index afdcbf5..a921357 100644 --- a/db/all.db +++ b/db/all.db @@ -384,7 +384,10 @@ Boot-DTB-Path: /boot/dtb Required-Packages: u-boot-tools Machine: Marvell OpenRD Base Board +Machine: OpenRD Base Kernel-Flavors: kirkwood +DTB-Id: kirkwood-openrd-client.dtb +DTB-Append-From: 3.16 U-Boot-Kernel-Address: 0x8000 U-Boot-Initrd-Address: 0x0 Boot-Kernel-Path: /boot/uImage @@ -392,7 +395,10 @@ Boot-Initrd-Path: /boot/uInitrd Required-Packages: u-boot-tools Machine: Marvell OpenRD Client Board +Machine: OpenRD Client Kernel-Flavors: kirkwood +DTB-Id: kirkwood-openrd-client.dtb +DTB-Append-From: 3.16 U-Boot-Kernel-Address: 0x8000 U-Boot-Initrd-Address: 0x0 Boot-Kernel-Path: /boot/uImage @@ -400,7 +406,10 @@ Boot-Initrd-Path: /boot/uInitrd Required-Packages: u-boot-tools Machine: Marvell OpenRD Ultimate Board +Machine: OpenRD Ultimate Kernel-Flavors: kirkwood +DTB-Id: kirkwood-openrd-ultimate.dtb +DTB-Append-From: 3.16 U-Boot-Kernel-Address: 0x8000 U-Boot-Initrd-Address: 0x0 Boot-Kernel-Path: /boot/uImage -- 2.1.4
Bug#781371: flash-kernel: Update machine entry for OpenRD boards
On 03/28/2015 11:07 AM, Ian Campbell wrote: > On Sat, 2015-03-28 at 08:33 +0000, Marc Kleine-Budde wrote: >> since linux kernel version 3.16 the OpenRD boards have been converted >> to device tree. Indeed it's v3.17-rc1 not v3.16. > Exclusively? My understanding was that while DT support became available > earlier the board file support was not removed for most kirkwood > platforms until 3.17-rc1 and so the version of flash-kernel in > experimental enables DT mode from 3.17-rc1 onwards. > > Unless there is some sort of problem with using board file with 3.16 on > a given platform I'd prefer to keep it that way for Jessie at this point > in the freeze, since board files are the known quantity which everyone > has(/should have) been testing until now. > > Of course if OpenRD systems are actively broken with v3.16 board file > support then we should switch, please confirm if this is the case. > > If you are running a newer kernel than what is in Jessie then I would > recommend the experimental version of f-k. Doh! When doing it right, suddenly everything works. sorry for the noise, Marc signature.asc Description: OpenPGP digital signature
