dts: Bring in Chrome OS keyboard device tree definition

Sync this up with Linux v3.18-rc5. Exclude features that are unlikely to supported in U-Boot soon (regulators, pinmux). Also the addresses are updated to 32-bit. Otherwise it is the same. Also bring in the dt-bindings for pinctrl.

Quoted 5 lines · Simon Glass

Sync this up with Linux v3.18-rc5. Exclude features that are unlikely to supported in U-Boot soon (regulators, pinmux). Also the addresses are updated to 32-bit. Otherwise it is the same. Also bring in the dt-bindings for pinctrl.

Assuming this content exactly matches the kernel,

Acked-by Stephen Warren <[email protected]>

Do all the existing nodes exactly match the kernel already?

Modern kernels require a device tree to boot.

Enable FIT support to permit
booting these images, rather than just legacy images.

This allows booting of Chrome OS kernels, among other things.

Quoted 2 lines · Simon Glass

Modern kernels require a device tree to boot.

True.

Quoted 3 lines

Enable FIT support to permit

booting these images, rather than just legacy images.

I don't understand this? Modern kernels boot perfectly well without FIT support. U-Boot supports the kernel's standard separate DTB and zImage file formats just fine.

To be honest, I'd strongly prefer not to enable support for non-universal (bootloader-specific) formats such as FIT.

Quoted 2 lines

This allows booting of Chrome OS kernels, among other things.

This might be a reasonable justification to support FIT. However, it'd be best to enable FIT support only on boards that are actually supported by ChromeOS, so as not to pollute other boards' configuration.

Hi Stephen,

Quoted 12 lines · Stephen Warren

Quoted 2 lines · Simon Glass

Modern kernels require a device tree to boot.

True.

Quoted 3 lines

Enable FIT support to permit

booting these images, rather than just legacy images.

Quoted 6 lines

I don't understand this? Modern kernels boot perfectly well without FIT support. U-Boot supports the kernel's standard separate DTB and zImage file formats just fine.

To be honest, I'd strongly prefer not to enable support for non-universal (bootloader-specific) formats such as FIT.

In U-Boot? FIT is U-Boot's standard format

and avoids all the mess that is zImage with a single attached DTB, etc.

Quoted 6 lines

Quoted 1 line

This allows booting of Chrome OS kernels, among other things.

This might be a reasonable justification to support FIT. However, it'd be best to enable FIT support only on boards that are actually supported by ChromeOS, so as not to pollute other boards' configuration.

I feel that FIT is a pretty core feature for U-Boot. Are you worried about the space?

Quoted 26 lines · Simon Glass

Hi Stephen,

Quoted 21 lines · Stephen Warren

Quoted 3 lines · Simon Glass

Modern kernels require a device tree to boot.

True.

Quoted 3 lines

Enable FIT support to permit

booting these images, rather than just legacy images.

I don't understand this? Modern kernels boot perfectly well without FIT support. U-Boot supports the kernel's standard separate DTB and zImage file
formats just fine.

Quoted 5 lines

Quoted 2 lines

To be honest, I'd strongly prefer not to enable support for non-universal (bootloader-specific) formats such as FIT.

In U-Boot? FIT is U-Boot's standard format

That's rather my point: FIT is *U-Boot's* standard format, not a global standard format.

I want to strongly guide anyone using Tegra towards globally standard formats, not intimate that they should be using bootloader-specific formats.

zImage (without appended DTB) is a standard Linux format that all booatloaders should support.

Raw DTB in a separate file (or perhaps provided by earlier firmware directly in RAM/ROM) is a standard Linux format that all bootloaders should support.

extlinux.conf is something that all bootloaders should support.

Linux distros that install binaries or config files in those standard formats should expect them to work with any bootloader, on any board. This way, distros won't have to write explicit support for any board; they'll just install standard files and everything will just work anywhere.

Quoted 1 line

and avoids all the mess that is zImage with a single attached DTB, etc.

Yes, we should avoid appended DTB where possible. However, there's no need to use appended DTB even when not using FIT; just put the zImage and DTB in separate files. To load them, either use a simple extlinux.conf config file, or a set of U-Boot commands to load each file; see
https://github.com/NVIDIA/tegra-uboot-scripts for something that'll generates some examples.

Example /boot/extlinux.conf (for media-based booting) or pxelinux.cfg/default (for network booting via syslinux command):

TIMEOUT 100

MENU TITLE TFTP boot options

LABEL jetson-tk1-emmc
MENU LABEL ../zImage root on Jetson TK1 eMMC
LINUX ../zImage
FDTDIR ../
APPEND console=ttyS0,115200n8 console=tty1 loglevel=8 rootwait rw
earlyprintk root=/dev/mmcblk0p1

        #root=UUID=8eac677f-8ea8-4270-8479-d5ddbb797450

LABEL sdcard
MENU LABEL ../zImage, root on 2GB sdcard
LINUX ../zImage
FDTDIR ../
APPEND console=ttyS0,115200n8 console=tty1 loglevel=8 rootwait rw
earlyprintk root=PARTUUID=b2f82cda-2535-4779-b467-094a210fbae7

LABEL venice2-emmc
MENU LABEL ../zImage root on Venice2 eMMC
LINUX ../zImage
FDTDIR ../
APPEND console=ttyS0,115200n8 console=tty1 loglevel=8 rootwait rw
earlyprintk root=PARTUUID=5f71e06f-be08-48ed-b1ef-ee4800cc860f
...

Quoted 5 lines

Quoted 5 lines

Quoted 2 lines

This allows booting of Chrome OS kernels, among other things.

Quoted 7 lines

Quoted 3 lines

This might be a reasonable justification to support FIT. However, it'd be best to enable FIT support only on boards that are actually supported by ChromeOS, so as not to pollute other boards' configuration.

I feel that FIT is a pretty core feature for U-Boot. Are you worried about the space?

I'm worried about guiding people towards non-standard file formats and protocols that lock people into a particular boot-loader.

For use-cases where it makes sense, I think it's fine to enable FIT. As a general feature across all boards, I would strongly prefer not to. One use-case that makes sense might be to boot ChromeOS. Of course, that's only applicable to boards that ChromeOS (or ChromiumOS) supports, and hence FIT should only be enabled in those boards' config files, not globally.

Hi Stephen,

Quoted 38 lines · Stephen Warren

Quoted 16 lines · Simon Glass

Hi Stephen,

Quoted 11 lines · Stephen Warren

Quoted 3 lines · Simon Glass

Modern kernels require a device tree to boot.

True.

Quoted 2 lines

Enable FIT support to permit
booting these images, rather than just legacy images.

Quoted 8 lines

Quoted 6 lines

I don't understand this? Modern kernels boot perfectly well without FIT support. U-Boot supports the kernel's standard separate DTB and zImage file formats just fine.

To be honest, I'd strongly prefer not to enable support for non-universal (bootloader-specific) formats such as FIT.

In U-Boot? FIT is U-Boot's standard format

That's rather my point: FIT is *U-Boot's* standard format, not a global standard format.

I want to strongly guide anyone using Tegra towards globally standard formats, not intimate that they should be using bootloader-specific formats.

zImage (without appended DTB) is a standard Linux format that all booatloaders should support.

Raw DTB in a separate file (or perhaps provided by earlier firmware directly in RAM/ROM) is a standard Linux format that all bootloaders should support.

Quoted 6 lines

extlinux.conf is something that all bootloaders should support.

Linux distros that install binaries or config files in those standard formats should expect them to work with any bootloader, on any board. This way, distros won't have to write explicit support for any board; they'll just install standard files and everything will just work anywhere.

Just so I am clear, on ARM what is the list of bootloaders that you are concerned with? FIT is actually not a difficult thing to add to a boot loader. Presumably they all support libfdt, so it is just a case of plumbing in the FIT access stuff.

I'm really not keen on this lowest-common-denominator approach, it's just a sad situation. Also I don't see why extlinux.conf should preclude people using FIT if they want to.

Quoted 2 lines

Example /boot/extlinux.conf (for media-based booting) or pxelinux.cfg/default (for network booting via syslinux command):

How does U-Boot select which device tree to pass to the kernel with the scheme above? We shouldn't rely on the user, right? With FIT we use CONFIG_FIT_BEST_MATCH.

Quoted 64 lines · Simon Glass

Hi Stephen,

Quoted 57 lines · Stephen Warren

Quoted 25 lines · Simon Glass

Hi Stephen,

Quoted 19 lines · Stephen Warren

Quoted 4 lines · Simon Glass

Modern kernels require a device tree to boot.

True.

Quoted 2 lines

Enable FIT support to permit
booting these images, rather than just legacy images.

I don't understand this? Modern kernels boot perfectly well without FIT support. U-Boot supports the kernel's standard separate DTB and zImage file formats just fine.

Quoted 6 lines

Quoted 3 lines

To be honest, I'd strongly prefer not to enable support for non-universal
(bootloader-specific) formats such as FIT.

In U-Boot? FIT is U-Boot's standard format

That's rather my point: FIT is *U-Boot's* standard format, not a global standard format.

I want to strongly guide anyone using Tegra towards globally standard formats, not intimate that they should be using bootloader-specific formats.

zImage (without appended DTB) is a standard Linux format that all booatloaders should support.

Raw DTB in a separate file (or perhaps provided by earlier firmware directly
in RAM/ROM) is a standard Linux format that all bootloaders should support.

extlinux.conf is something that all bootloaders should support.

Linux distros that install binaries or config files in those standard formats should expect them to work with any bootloader, on any board. This
way, distros won't have to write explicit support for any board; they'll just install standard files and everything will just work anywhere.

Quoted 4 lines

Just so I am clear, on ARM what is the list of bootloaders that you are concerned with? FIT is actually not a difficult thing to add to a boot loader. Presumably they all support libfdt, so it is just a case of plumbing in the FIT access stuff.

I believe that Barebox supports extlinux.conf too.

Quoted 4 lines

I'm really not keen on this lowest-common-denominator approach, it's just a sad situation. Also I don't see why extlinux.conf should preclude people using FIT if they want to.

It doesn't. My point is that it's unlikely people will want FIT support except in certain specific cases (such as ChromeOS compatibility), and we shouldn't enable it except where there's a demonstrable use-case, so we don't confuse people with non-standard options and accidentally lead them down the wrong path.

...

Quoted 3 lines

Quoted 3 lines

Example /boot/extlinux.conf (for media-based booting) or pxelinux.cfg/default (for network booting via syslinux command):

...

Quoted 4 lines

How does U-Boot select which device tree to pass to the kernel with the scheme above? We shouldn't rely on the user, right? With FIT we use CONFIG_FIT_BEST_MATCH.

extlinux.conf can specify a particular DTB filename if it wants. Alternatively, it can specify a directory containing a set of DTBs, and the bootloader must select which DTB to load.

If $fdtfile is set in U-Boot's environment, that file is used.

Otherwise, the U-Boot syslinux code uses some other environment variables to calculate a default DTB filename; ${soc}-${board}.dtb.

From: Allen Martin <[email protected]>

Nyan is a Tegra124 clamshell board that is very similar to venice2, but it has a different panel, the sdcard cd and wp sense are flipped, and it has a different revision of the AS3722 PMIC.

This is the Acer Chromebook 13 CB5-311-T7NN (13.3-inch HD, NVIDIA Tegra K1, 2GB). The display is not currently supported, so it should boot on other nyan-based Chromebooks also, but only the device tree for nyan-big is provided here.

The device tree file is from Linux but with features removed which are unlikely to be supported in U-Boot soon (regulators, pinmux). Also the addresses are updated to 32-bit.

Signed-off-by Allen Martin <[email protected]>

Signed-off-by Simon Glass <[email protected]>

(rebase, change to 'nyan', fix pinmux that resets nyan)

---

Changes in v3:
- Rename to nyan from norrin
- Bring in device tree file from Linux v3.18-rc5
- Generate pinmux file from tegra-pinmux-scripts

Hi,

Quoted 18 lines · Simon Glass

From: Allen Martin <[email protected]>

Nyan is a Tegra124 clamshell board that is very similar to venice2, but it has a different panel, the sdcard cd and wp sense are flipped, and it has a different revision of the AS3722 PMIC.

This is the Acer Chromebook 13 CB5-311-T7NN (13.3-inch HD, NVIDIA Tegra K1, 2GB). The display is not currently supported, so it should boot on other nyan-based Chromebooks also, but only the device tree for nyan-big is provided here.

The device tree file is from Linux but with features removed which are unlikely to be supported in U-Boot soon (regulators, pinmux). Also the addresses are updated to 32-bit.

Signed-off-by Allen Martin <[email protected]>

Signed-off-by Simon Glass <[email protected]>

Quoted 8 lines

(rebase, change to 'nyan', fix pinmux that resets nyan)

---

Changes in v3:
- Rename to nyan from norrin
- Bring in device tree file from Linux v3.18-rc5
- Generate pinmux file from tegra-pinmux-scripts

I should say that I'm not thrilled with this approach, particularly as the files it generate have no mentioned that they are auto-generated. Here we have a case where Nyan and Norrin apparently different by one pixmux setting but there is no way to exploit this commonality.

I think this was discussed a while ago (the idea of static pinmux being set up at start of day). If I recall I expressed my objections at the time. If U-Boot headed this way in general it would be unfortunate. You get a whole load of pinmux settings with no idea what they are for, and no idea how to change them for your board. It almost feels similar to a 'binary blob'.

I recently saw a patch to (from what I can tell) remove all the pinmux information from the device tree in Linux, presumably on the assumption it can never be changed except very early in the boot. If this is a limitation of Tegra then it seems unfortunate to me.

Hi,

Quoted 22 lines · Simon Glass

From: Allen Martin <[email protected]>

Nyan is a Tegra124 clamshell board that is very similar to venice2, but it has a different panel, the sdcard cd and wp sense are flipped, and it has a different revision of the AS3722 PMIC.

This is the Acer Chromebook 13 CB5-311-T7NN (13.3-inch HD, NVIDIA Tegra K1, 2GB). The display is not currently supported, so it should boot on other nyan-based Chromebooks also, but only the device tree for nyan-big is provided here.

The device tree file is from Linux but with features removed which are unlikely to be supported in U-Boot soon (regulators, pinmux). Also the addresses are updated to 32-bit.

Signed-off-by Allen Martin <[email protected]>

Signed-off-by Simon Glass <[email protected]>

(rebase, change to 'nyan', fix pinmux that resets nyan)

---

Quoted 4 lines

Changes in v3:
- Rename to nyan from norrin
- Bring in device tree file from Linux v3.18-rc5
- Generate pinmux file from tegra-pinmux-scripts

I should say that I'm not thrilled with this approach, particularly as the files it generate have no mentioned that they are auto-generated.

From: Allen Martin <[email protected]>

Nyan is a Tegra124 clamshell board that is very similar to venice2, but it has a different panel, the sdcard cd and wp sense are flipped, and it has a different revision of the AS3722 PMIC.

This is the Acer Chromebook 13 CB5-311-T7NN (13.3-inch HD, NVIDIA Tegra K1, 2GB). The display is not currently supported, so it should boot on other nyan-based Chromebooks also, but only the device tree for nyan-big is provided here.

Quoted 11 lines · Simon Glass

From: Allen Martin <[email protected]>

Nyan is a Tegra124 clamshell board that is very similar to venice2, but it has a different panel, the sdcard cd and wp sense are flipped, and it has a different revision of the AS3722 PMIC.

This is the Acer Chromebook 13 CB5-311-T7NN (13.3-inch HD, NVIDIA Tegra K1, 2GB). The display is not currently supported, so it should boot on other nyan-based Chromebooks also, but only the device tree for nyan-big is provided here.

As Olof explained it to me, Nyan is a family of boards, of which "Nyan Big" is a particular member. In other words, "Nyan Big" is the CB5. As such, I believe the U-Boot board should be named "Nyan Big" not "Nyan", unless we expect the U-Boot support for work for the various other Nyan family boards; I believe the HP Tegra Chromebooks are also in the Nyan family. Either way though (i.e. even if nyan.c gets shared between the Acer and HP Tegra Chromebooks), I still think we want separate top-level U-Boot board names for the two, so that it's easy for people to build the right DT into their U-Boot binary for example.

Hi Stephen,

Quoted 14 lines · Stephen Warren

Quoted 11 lines · Simon Glass

From: Allen Martin <[email protected]>

Nyan is a Tegra124 clamshell board that is very similar to venice2, but it has a different panel, the sdcard cd and wp sense are flipped, and it has a different revision of the AS3722 PMIC.

This is the Acer Chromebook 13 CB5-311-T7NN (13.3-inch HD, NVIDIA Tegra K1, 2GB). The display is not currently supported, so it should boot on other nyan-based Chromebooks also, but only the device tree for nyan-big is provided here.

Quoted 9 lines

As Olof explained it to me, Nyan is a family of boards, of which "Nyan Big" is a particular member. In other words, "Nyan Big" is the CB5. As such, I believe the U-Boot board should be named "Nyan Big" not "Nyan", unless we expect the U-Boot support for work for the various other Nyan family boards; I believe the HP Tegra Chromebooks are also in the Nyan family. Either way though (i.e. even if nyan.c gets shared between the Acer and HP Tegra Chromebooks), I still think we want separate top-level U-Boot board names for the two, so that it's easy for people to build the right DT into their U-Boot binary for example.

What change are you requesting for this patch?

Quoted 39 lines · Simon Glass

Hi Stephen,

Quoted 32 lines · Stephen Warren

Quoted 10 lines · Simon Glass

From: Allen Martin <[email protected]>

Nyan is a Tegra124 clamshell board that is very similar to venice2, but it
has a different panel, the sdcard cd and wp sense are flipped, and it has
a different revision of the AS3722 PMIC.

Quoted 4 lines

This is the Acer Chromebook 13 CB5-311-T7NN (13.3-inch HD, NVIDIA Tegra K1, 2GB). The display is not currently supported, so it should boot on other nyan-based Chromebooks also, but only the device tree for nyan-big is provided here.

As Olof explained it to me, Nyan is a family of boards, of which "Nyan Big"
is a particular member. In other words, "Nyan Big" is the CB5. As such, I believe the U-Boot board should be named "Nyan Big" not "Nyan", unless we expect the U-Boot support for work for the various other Nyan family boards;
I believe the HP Tegra Chromebooks are also in the Nyan family. Either way
though (i.e. even if nyan.c gets shared between the Acer and HP Tegra Chromebooks), I still think we want separate top-level U-Boot board names for the two, so that it's easy for people to build the right DT into their
U-Boot binary for example.

Quoted 1 line

What change are you requesting for this patch?

Given Andrew's description of the board naming, I think this patch (patch subject/description, filenames, file content) and anything else for this board should call it nyan-big not nyan. The Acer Chrombook is apparently nyan-big, whereas plain nyan means Norrin.