ARM: tegra: enable console framebuffer rotation
Subsystems (2)
PATCH 1/1 ARM: tegra: enable console framebuffer rotation
Console rotation is needed for devices like Tegra Note 7 and NVIDIA SHIELD to get the boot console in the expected orientation.
--- arch/arm/configs/tegra_defconfig | 1 + 1 file changed, 1 insertion(+)
arch/arm/configs/tegra_defconfig +1 -0
@@ -183,6 +183,7 @@ CONFIG_BACKLIGHT_CLASS_DEVICE=y # CONFIG_BACKLIGHT_GENERIC is not set CONFIG_BACKLIGHT_PWM=y CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y CONFIG_LOGO=y CONFIG_SOUND=y CONFIG_SND=y
Signature · 1 line
1.9.2
Quoted 2 lines · Alexandre Courbot
Console rotation is needed for devices like Tegra Note 7 and NVIDIA SHIELD to get the boot console in the expected orientation.
I've squashed this into Tegra's for-3.16/defconfig branch.
Can you please also update multi_v7_defconfig, and send that change to arm-soc (arm at kernel.org) to be applied. Thanks.
Quoted 8 lines · Stephen Warren
Quoted 2 lines · Alexandre Courbot
Console rotation is needed for devices like Tegra Note 7 and NVIDIA SHIELD to get the boot console in the expected orientation.
I've squashed this into Tegra's for-3.16/defconfig branch.
Can you please also update
multi_v7_defconfig, and send that change to arm-soc ([email protected]) to be applied. Thanks.
I omitted doing this for now because the devices that require this option (TN7/SHIELD) need a custom build with appended DTB and/or command-line anyway. Therefore they cannot use a multi-mach kernel and might as well be built against Tegra's defconfig. Does your remark above still apply in spite of this?
Thanks,
Alex.
Quoted 7 lines · Alex Courbot
Quoted 6 lines · Stephen Warren
Quoted 2 lines · Alexandre Courbot
Console rotation is needed for devices like Tegra Note 7 and NVIDIA SHIELD to get the boot console in the expected orientation.
I've squashed this into Tegra's for-3.16/defconfig branch.
Quoted 8 lines
Quoted 2 lines
Can you please also update
multi_v7_defconfig, and send that change to arm-soc (arm at kernel.org) to be applied. Thanks.I omitted doing this for now because the devices that require this option (TN7/SHIELD) need a custom build with appended DTB and/or command-line anyway. Therefore they cannot use a multi-mach kernel and might as well be built against Tegra's defconfig. Does your remark above still apply in spite of this?
Ah right, I guess we don't need it there then.
Am 08.05.2014 01:40, schrieb Alex Courbot:
Quoted 5 lines · Stephen Warren
Quoted 4 lines · Alexandre Courbot
Quoted 2 lines
Console rotation is needed for devices like Tegra Note 7 and NVIDIA SHIELD to get the boot console in the expected orientation.
Quoted 8 lines
Quoted 4 lines
I've squashed this into Tegra's for-3.16/defconfig branch.
Can you please also update
multi_v7_defconfig, and send that change to arm-soc (arm at kernel.org) to be applied. Thanks.I omitted doing this for now because the devices that require this option (TN7/SHIELD) need a custom build with appended DTB and/or command-line anyway. Therefore they cannot use a multi-mach kernel
What does appending a .dtb have to do with whether or not to use a multi-mach kernel? We package zImage/uImage and .dtbs separately, so surely the multi_v7_defconfig should be kept working with Tegra devices. Appending a .dtb only comes into play for preparing installation images.
Regards,
Andreas
Signature · 2 lines
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
Quoted 11 lines · Andreas F?rber
Am 08.05.2014 01:40, schrieb Alex Courbot:
Quoted 10 lines · Stephen Warren
Quoted 8 lines · Alexandre Courbot
Quoted 2 lines
Console rotation is needed for devices like Tegra Note 7 and NVIDIA SHIELD to get the boot console in the expected orientation.
I've squashed this into Tegra's for-3.16/defconfig branch.
Can you please also update
multi_v7_defconfig, and send that change to arm-soc (arm at kernel.org) to be applied. Thanks.
Quoted 8 lines
Quoted 3 lines
I omitted doing this for now because the devices that require this option (TN7/SHIELD) need a custom build with appended DTB and/or command-line anyway. Therefore they cannot use a multi-mach kernel
What does appending a .dtb have to do with whether or not to use a multi-mach kernel? We package zImage/uImage and .dtbs separately, so surely the
multi_v7_defconfigshould be kept working with Tegra devices. Appending a .dtb only comes into play for preparing installation images.
When appending a dtb the kernel image must also be built with CONFIG_ARM_APPENDED_DTB, which I guess is not an option we want to add by default to Tegra and probably even less to multi_v7. So since the kernel config needs to be changed anyway, I thought we would always want to use tegra_defconfig as a basis for these devices.
Not that adding CONFIG_FRAMEBUFFER_CONSOLE_ROTATION to multi_v7 would inflate the resulting kernel much, though.
Quoted 11 lines · Andreas F?rber
Am 08.05.2014 01:40, schrieb Alex Courbot:
Quoted 10 lines · Stephen Warren
Quoted 8 lines · Alexandre Courbot
Quoted 2 lines
Console rotation is needed for devices like Tegra Note 7 and NVIDIA SHIELD to get the boot console in the expected orientation.
I've squashed this into Tegra's for-3.16/defconfig branch.
Can you please also update
multi_v7_defconfig, and send that change to arm-soc (arm at kernel.org) to be applied. Thanks.
Quoted 8 lines
Quoted 3 lines
I omitted doing this for now because the devices that require this option (TN7/SHIELD) need a custom build with appended DTB and/or command-line anyway. Therefore they cannot use a multi-mach kernel
What does appending a .dtb have to do with whether or not to use a multi-mach kernel? We package zImage/uImage and .dtbs separately, so surely the
multi_v7_defconfigshould be kept working with Tegra devices. Appending a .dtb only comes into play for preparing installation images.
That would be a reasonable argument if generic distro installers or kernel packages were likely to support the TN7 and SHIELD. However, given the bootloader situation there and the need for a custom kernel anyway for APPENDED_DTB, I assume that's not the case on this particular device?
If you do intend to support this device with SuSe installer and kernel packages, could you give an outline of how you do so?
Am 09.05.2014 17:24, schrieb Stephen Warren:
Quoted 21 lines · Andreas F?rber
Quoted 11 lines
Am 08.05.2014 01:40, schrieb Alex Courbot:
Quoted 10 lines · Stephen Warren
Quoted 8 lines · Alexandre Courbot
Quoted 2 lines
Console rotation is needed for devices like Tegra Note 7 and NVIDIA SHIELD to get the boot console in the expected orientation.
I've squashed this into Tegra's for-3.16/defconfig branch.
Can you please also update
multi_v7_defconfig, and send that change to arm-soc (arm at kernel.org) to be applied. Thanks.Quoted 8 lines
Quoted 3 lines
I omitted doing this for now because the devices that require this option (TN7/SHIELD) need a custom build with appended DTB and/or command-line anyway. Therefore they cannot use a multi-mach kernel
What does appending a .dtb have to do with whether or not to use a multi-mach kernel? We package zImage/uImage and .dtbs separately, so surely the
multi_v7_defconfigshould be kept working with Tegra devices. Appending a .dtb only comes into play for preparing installation images.
Quoted 5 lines
That would be a reasonable argument if generic distro installers or kernel packages were likely to support the TN7 and SHIELD. However, given the bootloader situation there and the need for a custom kernel anyway for
APPENDED_DTB, I assume that's not the case on this particular device?
The Shield we probably don't, the TN7 I don't know. I was more concerned about the shortened justification.
Quoted 2 lines
If you do intend to support this device with SuSe installer and kernel packages, could you give an outline of how you do so?
I gave a presentation at embedded world Conference 2014 on how standard distributions work on ARM/AArch64, but I fear the slides are not online.
As far as possible, we use a single kernel source and a "default" or "lpae" v7 multi-platform config with lots of modules enabled.
http://kernel.opensuse.org/cgit/kernel-source/tree/config/armv7hl [*]
I just double-checked, and we do have CONFIG_ARM_APPENDED_DTB=y enabled. It does not restrict supplying the .dtb the "normal" way AIUI.
Our Open Build Service instance then builds a kernel-default .rpm package containing zImage and modules. The .dts files are separately compiled and packaged as, e.g., dtb-tegra2 for /boot/dtb/tegra20-*.dtb.
For building initrd, U-Boot boot.scr (including kernel command line) and installation image, we use Kiwi.
Anyway, we don't rely on the defconfigs for our distro, so do as you see fit; just gently reminding that it's not feasible for everyone to build kernels per device, as the above comment seemed to suggest.
Best regards,
Andreas
[*] Yes, some Tegra options are clearly missing; working on syncing them based on my tegra_defconfig.
Signature · 2 lines
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
Quoted 49 lines · Andreas F?rber
Am 09.05.2014 17:24, schrieb Stephen Warren:
Quoted 21 lines · Andreas F?rber
Quoted 11 lines
Am 08.05.2014 01:40, schrieb Alex Courbot:
Quoted 10 lines · Stephen Warren
Quoted 8 lines · Alexandre Courbot
Quoted 2 lines
Console rotation is needed for devices like Tegra Note 7 and NVIDIA SHIELD to get the boot console in the expected orientation.
I've squashed this into Tegra's for-3.16/defconfig branch.
Can you please also update
multi_v7_defconfig, and send that change to arm-soc (arm at kernel.org) to be applied. Thanks.Quoted 8 lines
Quoted 3 lines
I omitted doing this for now because the devices that require this option (TN7/SHIELD) need a custom build with appended DTB and/or command-line anyway. Therefore they cannot use a multi-mach kernel
What does appending a .dtb have to do with whether or not to use a multi-mach kernel? We package zImage/uImage and .dtbs separately, so surely the
multi_v7_defconfigshould be kept working with Tegra devices. Appending a .dtb only comes into play for preparing installation images.Quoted 5 lines
That would be a reasonable argument if generic distro installers or kernel packages were likely to support the TN7 and SHIELD. However, given the bootloader situation there and the need for a custom kernel anyway for
APPENDED_DTB, I assume that's not the case on this particular device?The Shield we probably don't, the TN7 I don't know. I was more concerned about the shortened justification.
Quoted 2 lines
If you do intend to support this device with SuSe installer and kernel packages, could you give an outline of how you do so?
I gave a presentation at embedded world Conference 2014 on how standard distributions work on ARM/AArch64, but I fear the slides are not online.
As far as possible, we use a single kernel source and a "default" or "lpae" v7 multi-platform config with lots of modules enabled.
http://kernel.opensuse.org/cgit/kernel-source/tree/config/armv7hl [*]
I just double-checked, and we do have
CONFIG_ARM_APPENDED_DTB=yenabled. It does not restrict supplying the .dtb the "normal" way AIUI.Our Open Build Service instance then builds a kernel-default .rpm package containing zImage and modules. The .dts files are separately compiled and packaged as, e.g., dtb-tegra2 for
/boot/dtb/tegra20-*.dtb.
Quoted 6 lines
For building initrd, U-Boot boot.scr (including kernel command line) and installation image, we use Kiwi.
Anyway, we don't rely on the defconfigs for our distro, so do as you see fit; just gently reminding that it's not feasible for everyone to build kernels per device, as the above comment seemed to suggest.
To be completely clear, we didn't expect these devices to be of interest to distros, due to the limitation of their bootloaders.
Both SHIELD and TN7 come with a locked bootloader and cannot use U-boot. The bootloader can only boot a kernel from a dedicated, raw boot partition (Android style), can only pass a device tree from another raw "dtb" partition, and will fill it with plenty of dirty command-line options that make mainline unusable. That seems to be a lot for distros to handle, so at this stage we'd rather advise users to use a root FS image of their favorite distro along with a self-compiled kernel.
That being said I only have a short-range view of the issue, so if you know of a way a distro installer could handle this and think it is worth doing, I'll be happy to cooperate here.
Thanks,
Alex.
On 05/13/2014 08:00 PM, Alexandre Courbot wrote:
...
Quoted 7 lines
Both SHIELD and TN7 come with a locked bootloader and cannot use U-boot. The bootloader can only boot a kernel from a dedicated, raw boot partition (Android style), can only pass a device tree from another raw "dtb" partition, and will fill it with plenty of dirty command-line options that make mainline unusable. That seems to be a lot for distros to handle, so at this stage we'd rather advise users to use a root FS image of their favorite distro along with a self-compiled kernel.
I don't know how much effort it's worth putting into this, but it /might/ be possible to port U-Boot to the devices, and use that as the "kernel" image that the binary bootloader boots, and then have U-Boot boot a kernel from a filesystem in the "normal" way. That's kind what I did by porting U-Boot to the Raspberry Pi. It would certainly increase the possibility of a distro supporting these devices in a generic way, as well as avoiding the need for hard-coded command-lines, memory layout, etc. in the DT files. We'd have to make sure that any installer didn't change the GPT layout, since then it'd get out of sync with the tegrapt partitions, which could cause the bootloader to fail.