lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 06 Jan 2015 10:09:04 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	linux-tegra@...r.kernel.org
CC:	Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Russell King <linux@....linux.org.uk>,
	Thierry Reding <thierry.reding@...il.com>,
	Alexandre Courbot <gnurou@...il.com>,
	devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] ARM: tegra: rely on bootloader pinmux programming
 on nyan-big

On 01/06/2015 03:37 AM, Tomeu Vizoso wrote:
> Following 6dbaff2b, the kernel expects that the bootloader has correctly
> programmed the Tegra pinmux.
>
> DTs for the Jetson and the Venice2 had been updated already but this one
> was left behind.

So this setup is true for NVIDIA-controlled development/reference boards 
where we've ensured that the bootloader sets up 100% of the pinmux.

However, I know that Coreboot on this board doesn't set up everything in 
the pinmux, and since it's in r/o flash never will. As such, I'm not 
sure this change is safe for this board. That is, unless you want to 
force upstream kernels to be booted via a chain-loaded path: Coreboot 
(r/o) -> U-Boot (r/w with full pinmux setup) -> kernel.

> Have tested this with the stock vendor firmware (coreboot) and have found no
> issues.

There are presumably a bunch of features which aren't yet supported 
upstream, and hence you couldn't test though? That means we might find 
that parts of the pinmux aren't yet programmed but need to be to enable 
those features.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ