Re: [U-Boot] [PATCH] video: backlight: fix pwm invertation
Am Freitag, 21. Juni 2019, 22:01:35 CEST schrieb Marc Dietrich:
> Fixes: 57e7775413 ("video: backlight: Parse PWM polarity cell")
>
> set_pwm will always fail if pwm_set_invert is not implemented, leaving the
> backlight dark. Fix this by calling pwm_set_invert only if pwm is inverted.
>
> Signed-off-by: Marc Dietrich
ping?
> ---
> drivers/video/pwm_backlight.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/pwm_backlight.c b/drivers/video/pwm_backlight.c
> index a587977c22..26bcbeb42b 100644
> --- a/drivers/video/pwm_backlight.c
> +++ b/drivers/video/pwm_backlight.c
> @@ -61,12 +61,13 @@ static int set_pwm(struct pwm_backlight_priv *priv)
>
> duty_cycle = priv->period_ns * (priv->cur_level - priv->min_level) /
> (priv->max_level - priv->min_level + 1);
> +
> ret = pwm_set_config(priv->pwm, priv->channel, priv->period_ns,
>duty_cycle);
> - if (ret)
> - return log_ret(ret);
>
> - ret = pwm_set_invert(priv->pwm, priv->channel, priv->polarity);
> + if (!ret && priv->polarity)
> + ret = pwm_set_invert(priv->pwm, priv->channel, priv->polarity);
> +
> return log_ret(ret);
> }
>
> --
> 2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] video: backlight: fix pwm invertation
Fixes: 57e7775413 ("video: backlight: Parse PWM polarity cell")
set_pwm will always fail if pwm_set_invert is not implemented, leaving the
backlight dark. Fix this by calling pwm_set_invert only if pwm is inverted.
Signed-off-by: Marc Dietrich
---
drivers/video/pwm_backlight.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/video/pwm_backlight.c b/drivers/video/pwm_backlight.c
index a587977c22..26bcbeb42b 100644
--- a/drivers/video/pwm_backlight.c
+++ b/drivers/video/pwm_backlight.c
@@ -61,12 +61,13 @@ static int set_pwm(struct pwm_backlight_priv *priv)
duty_cycle = priv->period_ns * (priv->cur_level - priv->min_level) /
(priv->max_level - priv->min_level + 1);
+
ret = pwm_set_config(priv->pwm, priv->channel, priv->period_ns,
duty_cycle);
- if (ret)
- return log_ret(ret);
- ret = pwm_set_invert(priv->pwm, priv->channel, priv->polarity);
+ if (!ret && priv->polarity)
+ ret = pwm_set_invert(priv->pwm, priv->channel, priv->polarity);
+
return log_ret(ret);
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [Ac100] [PATCH v2 5/6] ARM: tegra: paz00: add dtbindings for nvec
Hi,
Am Montag, 28. April 2014, 17:04:13 schrieb Stephen Warren:
On 04/26/2014 07:14 PM, Andrey Danin wrote:
This patch isn't adding DT bindings for NVEC, but rather add DT nodes.
The binding is the schema, not the content.
We need a DT binding document that's been reviewed by the DT binding
maintainers. Can you please first submit a patch to the Linux kernel
that modifies the existing I2C core and Tegra I2C controller binding
documentation to add slave mode support. Once that's fully reviewed and
ack'd, this patch series can implement support for it in U-Boot.
I'm sorry that I didn't came up with a proper kernel implementation, but while
we are discussion the binding I just want to give some coins.
diff --git a/arch/arm/dts/tegra20-paz00.dts
b/arch/arm/dts/tegra20-paz00.dts
i2c@7000c500 {
- status = disabled;
+ status = okay;
+ clock-frequency = 4;
+ slave-addr = 138;
+ nvec {
+ compatible = nvidia,tegra20-nvec;
+ request-gpios = gpio 170 0; /* gpio PV2 */
The reg property is missing here. Since the i2c node has
#address-cells/#size-cells, there must be a reg property in the children.
There's nothing here to indicate that this node is a slave device rather
than a master device, and doesn't seem to be any allowance for a single
I2C controller to support both master and slave nodes at the same time
(which I think Tegra's controller can IIRC).
IIRC, I had previously suggested something like encoding master/slave
into the reg property of the I2C child nodes. We could either do:
a) Set some top-bit to indicate a slave device.
b) If #address-cells=1, only master devices are present. If
#address-cells=2, either master or slave devices could be present.
Cell 0 could be 0==master, 1==slave, and cell 1 the actual I2C bus address.
I'm not sure if this is really needed. NVEC knows it has to configure the
tegra controller as slave. I don't see a reason to double this fact in the
device tree. I like the idea of how the downstream kernel does it. The driver
calls something like tegra_i2c_init_slave with the slave address as an
parameter. This means that the slave address is not a property of the i2c
(slave-) controller, but of the master because it has the address hard coded
in its firmware. So reg = 138; would be sufficient here and it also enables
multi-slave configs.
i2c-tegra must take care that only one transaction (slave or master) is
running at a time. The client (e.g. nvec) is free to drop the excluse usage by
calling tegra_i2c_stop_slave so master mode can be used again or another
client (master device) can be started where the slave controller gets a
different address.
Multi-master would require that only one master can hold the lock enabling
slave mode, but that's all software stuff and not related to the binding.
Also the kernel binding would require that nvec node itself has subdevices for
e.g. keyboard, mouse, power, ... which are connected to the internal ec bus.
We can use the nvec protocol identifiers to assign an address here.
Ok, lets take a look at the binding now:
i2c@7000c500 {
status = okay;
clock-frequency = 4;
nvec@138 {
compatible = nvidia,nvec, simple-bus;
#address-cells = 1
#size-cells = 0;
reg = 138;
request-gpios = gpio 170 0; /* gpio PV2 */
keyboard@5 {
compatible = nvidia,nvec-kbd;
reg = 5;
};
mouse@6 {
compatible = nvidia,nvec-aux;
reg = 6;
packet-size = 6;
};
};
};
Only thing I'm not sure is where to put the clock-frequency because it really
depends on the i2c clients and if we have multiple masters, we could use
multiple frequencies. Or maybe the lowest supported must be used instead, in
which case the clock-frequency is better placed in the controller node.
Marc
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Ac100] [PATCH v2 5/6] ARM: tegra: paz00: add dtbindingsfor nvec
On Wed, 30 Apr 2014 10:21:07 -0600
Stephen Warren swar...@wwwdotorg.org wrote:
On 04/30/2014 01:52 AM, Marc Dietrich wrote:
Am Montag, 28. April 2014, 17:04:13 schrieb Stephen Warren:
On 04/26/2014 07:14 PM, Andrey Danin wrote:
This patch isn't adding DT bindings for NVEC, but rather add DT nodes.
The binding is the schema, not the content.
We need a DT binding document that's been reviewed by the DT binding
maintainers. Can you please first submit a patch to the Linux kernel
that modifies the existing I2C core and Tegra I2C controller binding
documentation to add slave mode support. Once that's fully reviewed and
ack'd, this patch series can implement support for it in U-Boot.
I'm sorry that I didn't came up with a proper kernel implementation, but
while
we are discussion the binding I just want to give some coins.
I'm not looking for a kernel driver implementation, but we do need to
the DT binding fully reviewed and accepted.
well, a kernel implementation would have included the binding.
diff --git a/arch/arm/dts/tegra20-paz00.dts
b/arch/arm/dts/tegra20-paz00.dts
i2c@7000c500 {
- status = disabled;
+ status = okay;
+ clock-frequency = 4;
+ slave-addr = 138;
+ nvec {
+ compatible = nvidia,tegra20-nvec;
+ request-gpios = gpio 170 0; /* gpio PV2 */
The reg property is missing here. Since the i2c node has
#address-cells/#size-cells, there must be a reg property in the children.
There's nothing here to indicate that this node is a slave device rather
than a master device, and doesn't seem to be any allowance for a single
I2C controller to support both master and slave nodes at the same time
(which I think Tegra's controller can IIRC).
IIRC, I had previously suggested something like encoding master/slave
into the reg property of the I2C child nodes. We could either do:
a) Set some top-bit to indicate a slave device.
b) If #address-cells=1, only master devices are present. If
#address-cells=2, either master or slave devices could be present.
Cell 0 could be 0==master, 1==slave, and cell 1 the actual I2C bus address.
I'm not sure if this is really needed. NVEC knows it has to configure the
tegra controller as slave. I don't see a reason to double this fact in the
device tree. I like the idea of how the downstream kernel does it. The
driver
calls something like tegra_i2c_init_slave with the slave address as an
parameter. This means that the slave address is not a property of the i2c
(slave-) controller, but of the master because it has the address hard
coded
in its firmware. So reg = 138; would be sufficient here and it also
enables
multi-slave configs.
The binding in this patch is very special-cased. Instead, we need to
create a generic binding that will work identically across arbitrary I2C
controllers, some of which do support multiple slave addresses.
I don't see why multi-slave capable controllers won't work. You just
increase the number in the controller's address-cells and add the slave
addresses to the master's reg property. The point here is that the slave
addresses of an i2c controller may be configured at runtime, not at
device initialization via devicetree. This also gives a higher
flexibility for different slave/master combinations.
The issue that caused Linus to blow up about ARM was because everyone went
off and did their own HW-specific stuff without taking a look at the big
picture. That's exactly what the binding proposed in this patch does too.
I can only assume that your are slowly getting tired of this binding
discussion. Still there is no reason for harsh words or to delete my
proposal from the context. IMHO, I tried to be as generic as possible.
Anyway, we should move this discussion to the devicetree ml.
Marc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Ac100] [PATCH 3/3] ARM: tegra: paz00: enable nveckeyboardsupport
On Tuesday 23 July 2013 08:40:42 Stephen Warren wrote: On 07/22/2013 01:09 AM, Marc Dietrich wrote: [ snip the stuff we agreed upon ] The nvec still needs to tell the slave driver which protocol to use, but that can be hard coded. I'm not sure what that means. At the controller/HW level, aren't I2C and SMBUS the same; it's just the data within the transactions that may be more defined by one or the other? at this level yes, but we need to handle the underlying protocol in the ISR, which means that depending on the protocol (smbus or I2C), we need a different interrupt service routine. Currently we are doing most of the smbus protocol in the ISR because of timing reasons and I'm not sure if we can change this. We are already suffering from nvec timeouts and I fear that splitting the protocol out of the ISR would make things even worse. I'm going to submit a new DT binding during the weekend. Meanwhile, Andrey is trying to split the uboot driver in the hw and nvec parts and also adapting it for the new binding. Marc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Ac100] [PATCH 3/3] ARM: tegra: paz00: enable nveckeyboard support
On Friday 19 July 2013 13:14:13 Stephen Warren wrote:
On 07/19/2013 02:47 AM, Andrey Danin wrote:
Signed-off-by: Andrey Danin danind...@mail.ru
(Some patch descriptions would be useful)
diff --git a/board/compal/dts/tegra20-paz00.dts
b/board/compal/dts/tegra20-paz00.dts
+ nvec {
+ compatible = nvidia,tegra20-nvec;
+ reg = 0x7000c500 0x100;
+ clock-frequency = 8;
+ request-gpios = gpio 170 0; /* gpio PV2 */
+ slave-addr = 138;
+ };
I would rather not propagate this DT binding. We need to fix the binding
to clearly separate the concepts of:
so here we go again. I think I have to take this on my shoulders since I
didn't got it right yet in the kernel.
a) The I2C slave controller (which should be a standalone driver for the
Tegra I2C slave HW).
b) The protocol sent over the I2C slave channel (which would be specific
to NVEC, implement the GPIO hand-shaking, etc.).
c) The devices that communicate over the protocol (keyboard in this case).
I suspect we need separate DT nodes/sub-nodes for all of those, and a
method of hooking them all together.
Let's skip how this may actually look like in software. Given the discussions
we had in the past, I propose the following binding:
i2c-slave@7000c500 {
compatible = nvidia,tegra20-i2c-slave;
reg = 0x7000c500 0x100;
interrupts = 0 92 0x04;
#address-cells = 1;
#size-cells = 0;
clock-frequency = 8;
slave-addr = 138;
clocks = tegra_car 67, tegra_car 124;
clock-names = div-clk, fast-clk;
nvec {
compatible = nvidia,nvec, simple-bus;
protocol = smbus-request-gpio;
request-gpios = gpio 170 0; /* gpio PV2 */
keyboard {
compatible = nvidia,nvec-keyboard;
};
};
};
Does this looks better?
Marc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Ac100] [PATCH 3/3] ARM: tegra: paz00: enable nveckeyboardsupport
Am Samstag, 20. Juli 2013, 21:20:52 schrieb Stephen Warren:
On 07/20/2013 03:12 AM, Marc Dietrich wrote:
On Friday 19 July 2013 13:14:13 Stephen Warren wrote:
...
Let's skip how this may actually look like in software. Given the
discussions we had in the past, I propose the following binding:
i2c-slave@7000c500 {
compatible = nvidia,tegra20-i2c-slave;
reg = 0x7000c500 0x100;
interrupts = 0 92 0x04;
#address-cells = 1;
#size-cells = 0;
clock-frequency = 8;
slave-addr = 138;
Hex would be more common, but that's a minor issue.
ok.
clocks = tegra_car 67, tegra_car 124;
clock-names = div-clk, fast-clk;
nvec {
Above, it says #address-cells=1, which means this node needs a reg
property. Perhaps slave-addr should be part of the child nodes (and the
Tegra I2C controller binding would limit itself to supporting only a
single node), so that the same binding style could be applicable to I2C
slave devices that support multiple slave addresses.
you mean
nvec@87 {
reg = 0x87;
...
} ?
I think that's ok. Didn't know that Tegra can support multiple slave
addresses. To make the binding as general as possible, we could support multi-
slave for the binding, but only support single slave in the code for now.
I guess that also warrants a simple-bus compatibility in the i2c-slave node.
compatible = nvidia,nvec, simple-bus;
protocol = smbus-request-gpio;
What is that property for; doesn't compatible=nvidia,nvec already
imply this, or does the NVEC spec define multiple different protocols?
The GPIO is optional, but SMBUS is required. Maybe to support master initiated
communications only. To get rid of the ugly protocol property, we could just
check if a valid gpio is given. I think that's what the downstream kernel also
does. The nvec still needs to tell the slave driver which protocol to use, but
that can be hard coded.
request-gpios = gpio 170 0; /* gpio PV2 */
We should use the C pre-processor to provide named constants there,
although I guess U-Boot isn't set up for that yet. The kernel is once
this is ported there, and once the 2013.07 release is out, U-Boot should
be able to support this very soon too.
keyboard {
Simple-bus might require a reg property; I forget. Does the NVEC
protocol include any form of virtual device address that it would make
sense to put into a reg property?
compatible = nvidia,nvec-keyboard;
well, we could misuse the nvec function select byte for this (e.g. 5 for
keyboard, 6 for mouse, ...), but we may run into trouble with the system
command = 1 which is used by several drivers.
Does this looks better?
Yes, overall much better.
New DT bindings should be sent to devicet...@vger.kernel.org for review.
Note that's a branch new list (it moved from a different server), so it
might be best to wait a few days for people to subscribe before sending
mail to it.
Ok, I'll send out a new version and cc dtml. Maybe this some more people
respond ;-)
Thanks for review!
Marc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2Cframework
Hi, Am Montag, 6. Mai 2013, 13:08:31 schrieb Stephen Warren: On 05/04/2013 06:01 AM, Heiko Schocher wrote: From: Simon Glass s...@chromium.org This enables CONFIG_SYS_I2C on Tegra, updating existing boards and the Tegra i2c driver to support this. include/configs/beaver.h| 5 ++- include/configs/cardhu.h| 3 +- include/configs/dalmore.h | 3 +- include/configs/seaboard.h | 5 ++- include/configs/trimslice.h | 5 ++- include/configs/whistler.h | 5 ++- There are a lot more Tegra boards than just those. Shouldn't they all be updated? You also didn't Cc the Tegra maintainer - I have done on this mail. not all boards use I2C up to now, to the patch seems to change only the boards which do. So this is ok for now. The question is if CONFIG_SYS_I2C could be moved to tegra_common or so because the device-tree disables I2C be default. Marc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] disk: fix unaligned access in efi partitions
start_sect is not aligned to a 4 byte boundary thus causing exceptions
on ARM platforms. Access this field via the get_unaligned macro.
Signed-off-by: Marc Dietrich marvi...@gmx.de
---
disk/part_efi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index b3fd0e9..6678a4c 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -30,6 +30,7 @@
*
* This limits the maximum size of addressable storage to 2 Terra Bytes
*/
+#include asm/unaligned.h
#include common.h
#include command.h
#include ide.h
@@ -505,7 +506,7 @@ err:
static int pmbr_part_valid(struct partition *part)
{
if (part-sys_ind == EFI_PMBR_OSTYPE_EFI_GPT
- le32_to_cpu(part-start_sect) == 1UL) {
+ le32_to_cpu(get_unaligned(part-start_sect)) == 1UL) {
return 1;
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk: add -mno-unaligned-access to CFLAGS
Albert, On Friday 29 March 2013 08:00:54 Albert ARIBAUD wrote: On Thu, 28 Mar 2013 23:35 +0100, Marc Dietrich marvi...@gmx.de wrote: [ ... ] On Thursday 28 March 2013 21:42:13 Albert ARIBAUD wrote: Which fields, which structures, which files are affected by the unalignment issue? in my test case, it is the start sector of a partition (check include/part_efi.h). disk/part_efi.c reads the legacy mbr (to an aligned buffer) which has a partition structure on offset 440+4+2 (- not aligned to 4 byte boundary) and inside this a 32 bit field start_sect (aligned to 4 byte boundary). Reading this field (and also the next, nr_sects) will cause an exception. Same is for part_dos, but there we still use le32_to_int which reads byte by byte. I didn't checked others. Thanks for clarifying. Considering this is about a very small number of reads, I strongly prefer that these reads be done through the get_unaligned(field) macro defined in e.g. arch/arm/include/asm/unaligned.h, even at the slightly added cost of decomposing the reads into 8-bit accesses. ok, this is what I was actually looking for :-) I've sent a new patch. Marc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk: fix unaligned access in efi partitions
Albert,
On Friday 29 March 2013 13:32:26 Albert ARIBAUD wrote:
On Fri, 29 Mar 2013 12:28:58 +0100, Marc Dietrich marvi...@gmx.de wrote:
start_sect is not aligned to a 4 byte boundary thus causing exceptions
on ARM platforms. Access this field via the get_unaligned macro.
Signed-off-by: Marc Dietrich marvi...@gmx.de
---
disk/part_efi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index b3fd0e9..6678a4c 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -30,6 +30,7 @@
*
* This limits the maximum size of addressable storage to 2 Terra Bytes
*/
+#include asm/unaligned.h
#include common.h
#include command.h
#include ide.h
@@ -505,7 +506,7 @@ err:
static int pmbr_part_valid(struct partition *part)
{
if (part-sys_ind == EFI_PMBR_OSTYPE_EFI_GPT
- le32_to_cpu(part-start_sect) == 1UL) {
+ le32_to_cpu(get_unaligned(part-start_sect)) == 1UL) {
return 1;
}
Suits me :) but did you not say the same issue was also affecting
nr_sects?
I checked again and this field is never read - only written to but to an
aligned buffer. So there shouldn't be a problem.
Also, beside the asm/unaligned.h file I gave as an example, other header
files in include/linux/unaligned/ exist that provide alignment-related
macros, notably with _le and _be versions. Maybe you can find one that
combines the effects of both le32_to_cpu() and get_unaligned()?
I looks like get_unaligned does the job for us already, so we can leave the
le32_to_cpu out. But I cannot test it here because of missing big endian
machine with efi and my two brain halfs are already swapped until confusion
(start_sect is defined as _le32).
Albert, I like to get a fix for this into 2013.04 if possible. Maybe someone
with more endian experience can look at it quickly.
Marc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] disk: fix unaligned access in efi partitions
start_sect is not aligned to a 4 byte boundary thus causing exceptions
on ARM platforms. Access this field via the get_unaligned_le32 macro.
Signed-off-by: Marc Dietrich marvi...@gmx.de
---
V2: replace le32_to_cpu(get_unaligned()) with get_unaligned_le32
disk/part_efi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index b3fd0e9..e9987f0 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -30,6 +30,7 @@
*
* This limits the maximum size of addressable storage to 2 Terra Bytes
*/
+#include asm/unaligned.h
#include common.h
#include command.h
#include ide.h
@@ -505,7 +506,7 @@ err:
static int pmbr_part_valid(struct partition *part)
{
if (part-sys_ind == EFI_PMBR_OSTYPE_EFI_GPT
- le32_to_cpu(part-start_sect) == 1UL) {
+ get_unaligned_le32(part-start_sect) == 1UL) {
return 1;
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Tegra: Restore cp15 VBAR _start vector write forARMv7
Tom, On Thursday 28 March 2013 10:26:03 Tom Warren wrote: A start vector fix was added by AneeshV for OMAP4 (commit 0d479b53), and caused the old monilithic Tegra builds to hang due to an undefined instruction trap. Previously, the code needed to run on both the AVP (ARM7TDI) and A9, and the AVP doesn't have a CP15 register. I corrected this in commit 6d6c0bae w/#ifndef CONFIG_TEGRA, but now that we use SPL, and boot the AVP w/o any ARMv7 code, I can revert my change, and make Aneesh's change apply to Tegra. I applied your patch (and the one from Vincent [1]) but I still get no exception output (just hang) with the test case I posted earlier [2]. There must be still something wrong. Marc [1] http://u-boot.10912.n7.nabble.com/PATCH-armv7-do-not-relocate-start-twice- td149815.html [2] http://u-boot.10912.n7.nabble.com/unaligned-access-in-part-efi-c- td150763.html Signed-off-by: Tom Warren twar...@nvidia.com --- arch/arm/cpu/armv7/start.S | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index c0e1849..7700315 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -251,12 +251,10 @@ ENTRY(c_runtime_cpu_setup) /* * Move vector table */ -#if !defined(CONFIG_TEGRA) /* Set vector address in CP15 VBAR register */ ldr r0, =_start add r0, r0, r9 mcr p15, 0, r0, c12, c0, 0 @Set VBAR -#endif /* !Tegra */ bx lr ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] disk: add -mno-unaligned-access to CFLAGS
Many on-disk structures used in the directory are accessed in a non aligned manner. gcc = 4.7 (and gcc-4.6 from Linaro) switched to -munaligned-access on default causing exceptions on ARM. The easiest way to fix this is to force no-unaligned-access in this (non speed critical) directory. Signed-off-by: Marc Dietrich marvi...@gmx.de --- disk/Makefile |1 + 1 file changed, 1 insertion(+) diff --git a/disk/Makefile b/disk/Makefile index 5affe34..01134a3 100644 --- a/disk/Makefile +++ b/disk/Makefile @@ -24,6 +24,7 @@ include $(TOPDIR)/config.mk #CFLAGS += -DET_DEBUG -DDEBUG +CFLAGS += -mno-unaligned-access LIB= $(obj)libdisk.o -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk: add -mno-unaligned-access to CFLAGS
Hi Albert, On Thursday 28 March 2013 21:42:13 Albert ARIBAUD wrote: On Thu, 28 Mar 2013 19:57:31 +0100, Marc Dietrich marvi...@gmx.de wrote: Many on-disk structures used in the directory are accessed in a non aligned manner. gcc = 4.7 (and gcc-4.6 from Linaro) switched to -munaligned-access on default causing exceptions on ARM. The easiest way to fix this is to force no-unaligned-access in this (non speed critical) directory. Signed-off-by: Marc Dietrich marvi...@gmx.de --- disk/Makefile |1 + 1 file changed, 1 insertion(+) diff --git a/disk/Makefile b/disk/Makefile index 5affe34..01134a3 100644 --- a/disk/Makefile +++ b/disk/Makefile @@ -24,6 +24,7 @@ include $(TOPDIR)/config.mk #CFLAGS += -DET_DEBUG -DDEBUG +CFLAGS += -mno-unaligned-access LIB= $(obj)libdisk.o Which fields, which structures, which files are affected by the unalignment issue? in my test case, it is the start sector of a partition (check include/part_efi.h). disk/part_efi.c reads the legacy mbr (to an aligned buffer) which has a partition structure on offset 440+4+2 (- not aligned to 4 byte boundary) and inside this a 32 bit field start_sect (aligned to 4 byte boundary). Reading this field (and also the next, nr_sects) will cause an exception. Same is for part_dos, but there we still use le32_to_int which reads byte by byte. I didn't checked others. Marc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] unaligned access in part_efi.c
On Wednesday 27 March 2013 12:23:22 Stephen Warren wrote: On 03/26/2013 02:42 PM, Marc Dietrich wrote: Hi, access to part-start_sect in pmbr_part_valid() (form disk/part_efi.c) and propably other positions/fields causes an unaligned access on ARM (tegra in my case) and a uboot crash. This was introduced by commit fae2bf22 [1] which changed le32_to_int (which is a byte access) to le32_to_cpu (which is a 32bit access). I can't reproduce this with latest u-boot-arm/master, which includes that commit. Both mmc dev N; mmc rescan ; mmcinfo and part list mmc N work fine for me with both DOS PT and GPT. I did test this on a Tegra Seaboard which isn't identical to the AC100, but the only practical difference is 512M vs 1G RAM, which seems unlikely to cause this. It'd help if you pointed out exactly which access causes the issue; which piece of code is failing. The most likely issue is that some memory buffer is assumed to be aligned to 4-bytes, but actually isn't. To track that down, we'd need to know which code and which buffer. Also, a disassembly of the problematic function would be useful. As discussed on IRC, this only happens with gcc 4.7 or patched gcc 4.6 (e.g. from linaro) which has -maligned-access as default enabled. I added -mno- aligned-access to the disk/Makefile and now it boots, but I doubt that this is the best solution. Marc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] unaligned access in part_efi.c
Hi, access to part-start_sect in pmbr_part_valid() (form disk/part_efi.c) and propably other positions/fields causes an unaligned access on ARM (tegra in my case) and a uboot crash. This was introduced by commit fae2bf22 [1] which changed le32_to_int (which is a byte access) to le32_to_cpu (which is a 32bit access). I'm not sure how to fix this as I'm not very familar with this kind of problems. Any help? Thanks! Marc [1] gpt: The leXX_to_int() calls replaced with ones defined at compiler.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 3/4] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files
On Thursday 21 February 2013 09:45:44 Tom Warren wrote:
Linux dts files were used for those boards that didn't already
have sdhci info populated. Tamonten has their own dtsi file with
common sdhci nodes (sourced from Linux).
Signed-off-by: Tom Warren twar...@nvidia.com
Tested-by: Thierry Reding thierry.red...@avionic-design.de
looks (and boots) fine now. Thanks!
Tested-by: Marc Dietrich marvi...@gmx.de
---
v2:
- cleanup comments in dts files/match w/kernel files
- add sdhci aliases in all dts files
- use tegra20-tamonten.dtsi from the kernel for AD boards
v3:
- include tamonten.dtsi file directly in AD dts files
- fix Seaboard power-gpios flags
- add cd-gpios for Colibri T20 Iris
- add include paths to DTC command
v4:
- move dts Makefile change to separate patch
v5:
- change /include/ to #include, allows C preprocessor to find files
v6:
- change ARCH_CPU_DTS to tegra20.dtsi
- change cd-gpios flags to 1, active-low
arch/arm/dts/tegra20.dtsi| 16
board/avionic-design/dts/tegra20-medcom-wide.dts |1 +
board/avionic-design/dts/tegra20-plutux.dts |1 +
board/avionic-design/dts/tegra20-tec.dts |1 +
board/compal/dts/tegra20-paz00.dts | 21 ++---
board/compulab/dts/tegra20-trimslice.dts | 16 +++-
board/nvidia/dts/tegra114-dalmore.dts|2 +-
board/nvidia/dts/tegra20-harmony.dts | 20 +++-
board/nvidia/dts/tegra20-seaboard.dts| 14 +-
board/nvidia/dts/tegra20-ventana.dts | 17 -
board/nvidia/dts/tegra20-whistler.dts| 15 ++-
board/nvidia/dts/tegra30-cardhu.dts |2 +-
board/toradex/dts/tegra20-colibri_t20_iris.dts |9 -
13 files changed, 116 insertions(+), 19 deletions(-)
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index d163ff8..3805750 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -318,24 +318,32 @@
sdhci@c800 {
compatible = nvidia,tegra20-sdhci;
reg = 0xc800 0x200;
- interrupts = 46 ;
+ interrupts = 0 14 0x04;
+ clocks = tegra_car 14;
+ status = disabled;
};
sdhci@c8000200 {
compatible = nvidia,tegra20-sdhci;
reg = 0xc8000200 0x200;
- interrupts = 47 ;
+ interrupts = 0 15 0x04;
+ clocks = tegra_car 9;
+ status = disabled;
};
sdhci@c8000400 {
compatible = nvidia,tegra20-sdhci;
reg = 0xc8000400 0x200;
- interrupts = 51 ;
+ interrupts = 0 19 0x04;
+ clocks = tegra_car 69;
+ status = disabled;
};
sdhci@c8000600 {
compatible = nvidia,tegra20-sdhci;
reg = 0xc8000600 0x200;
- interrupts = 63 ;
+ interrupts = 0 31 0x04;
+ clocks = tegra_car 15;
+ status = disabled;
};
};
diff --git a/board/avionic-design/dts/tegra20-medcom-wide.dts
b/board/avionic-design/dts/tegra20-medcom-wide.dts
index 2acfbc1..a9a07f9 100644
--- a/board/avionic-design/dts/tegra20-medcom-wide.dts
+++ b/board/avionic-design/dts/tegra20-medcom-wide.dts
@@ -8,6 +8,7 @@
aliases {
usb0 = /usb@c5008000;
+ sdhci0 = /sdhci@c8000600;
};
memory {
diff --git a/board/avionic-design/dts/tegra20-plutux.dts
b/board/avionic-design/dts/tegra20-plutux.dts
index dba200d..20016f2 100644
--- a/board/avionic-design/dts/tegra20-plutux.dts
+++ b/board/avionic-design/dts/tegra20-plutux.dts
@@ -8,6 +8,7 @@
aliases {
usb0 = /usb@c5008000;
+ sdhci0 = /sdhci@c8000600;
};
memory {
diff --git a/board/avionic-design/dts/tegra20-tec.dts
b/board/avionic-design/dts/tegra20-tec.dts
index 04e6730..1d7cf89 100644
--- a/board/avionic-design/dts/tegra20-tec.dts
+++ b/board/avionic-design/dts/tegra20-tec.dts
@@ -8,6 +8,7 @@
aliases {
usb0 = /usb@c5008000;
+ sdhci0 = /sdhci@c8000600;
};
memory {
diff --git a/board/compal/dts/tegra20-paz00.dts
b/board/compal/dts/tegra20-paz00.dts
index b5580c9..780203c 100644
--- a/board/compal/dts/tegra20-paz00.dts
+++ b/board/compal/dts/tegra20-paz00.dts
@@ -1,13 +1,15 @@
/dts-v1/;
-#include ARCH_CPU_DTS
+#include tegra20.dtsi
/ {
-model = Toshiba AC100 / Dynabook AZ;
-compatible = compal,paz00, nvidia,tegra20;
+ model = Toshiba AC100 / Dynabook AZ;
+ compatible = compal,paz00, nvidia,tegra20;
aliases {
usb0 = /usb@c5008000;
+ sdhci0 = /sdhci@c8000600;
+ sdhci1 = /sdhci@c800
Re: [U-Boot] [PATCH v4 4/4] Tegra: MMC: Add DT support to MMCdriver for all T20 boards
Stephen,
On Thursday 14 February 2013 16:12:42 Stephen Warren wrote:
On 02/14/2013 02:04 PM, Tom Warren wrote:
tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc.
Tested on Seaboard, fully functional.
Tamonten boards (medcom-wide, plutux, and tec) use a different/new
dtsi file w/common settings.
diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
@@ -515,44 +483,47 @@ static int mmc_core_init(struct mmc *mmc)
int tegra_mmc_getcd(struct mmc *mmc)
{
struct mmc_host *host = (struct mmc_host *)mmc-priv;
+ debug(%s called, host-cd_gpio = 0x%08X\n, __func__,
+ (unsigned)host-cd_gpio);
That last line should be:
host-cd_gpio.gpio;
The case is because it's a struct address, not the GPIO you want to print.
+static int do_mmc_init(int dev_index)
- if (host-pwr_gpio = 0) {
+ if (fdt_gpio_isvalid(host-pwr_gpio)) {
sprintf(gpusage, SD/MMC%d PWR, dev_index);
- gpio_request(host-pwr_gpio, gpusage);
- gpio_direction_output(host-pwr_gpio, 1);
+ gpio_request(host-pwr_gpio.gpio, gpusage);
+ fdtdec_set_gpio(host-pwr_gpio, 1);
That change completely removes the call to gpio_direction_output;
fdtdec_set_gpio() doesn't do that. This is the cause of the problem on
PAZ00, and Harmony.
- if (host-cd_gpio = 0) {
+ if (fdt_gpio_isvalid(host-cd_gpio)) {
sprintf(gpusage, SD/MMC%d CD, dev_index);
- gpio_request(host-cd_gpio, gpusage);
- gpio_direction_input(host-cd_gpio);
+ gpio_request(host-cd_gpio.gpio, gpusage);
+ card_det = fdtdec_get_gpio(host-cd_gpio);
Similarly, this change removes the call to gpio_direction_input();
fdtdec_get_gpio() just reads the GPIO's value and is pointless here.
I'll go retest all the boards after fixing that...
yup - with these changes, everything is fine again on PAZ00.
Marc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/4] Tegra: MMC: Add DT support for MMC to T20 boards
Hi Tom, On Thursday 14 February 2013 14:03:57 Tom Warren wrote: This patchset adds device-tree support to the Tegra MMC driver. All device config is done via properties in the DT files instead of hard-coded config options/function arguments. I've tested this on my Seaboard and everything works fine, including card detect. For the other T20 boards, I've used the Linux kernel DTS files for the sdhci nodes where there wasn't one already, or expanded the info that was already there. Everything builds fine, but I haven't tested anything but Seaboard. unfortunately, this is still no go on PAZ00. U-Boot SPL 2013.01-00093-g206c157-dirty (Feb 14 2013 - 23:37:03) U-Boot 2013.01-00093-g206c157-dirty (Feb 14 2013 - 23:37:03) TEGRA20 Board: Compal Paz00 DRAM: 512 MiB MMC: tegra_mmc_init entry tegra_mmc_init: count of sdhci nodes is 2 process_nodes: count = 2 mmc_get_config: node = 5772 mmc_get_config: found controller at c8000600, width = 8, periph_id = 15 do_mmc_init: index 0, bus width 8 pwr_gpio -1 cd_gpio -1 do_mmc_init: bus width = 8 mmc_get_config: node = 5244 mmc_get_config: found controller at c800, width = 4, periph_id = 14 do_mmc_init: index 1, bus width 4 pwr_gpio 169 cd_gpio 173 Power GPIO name = power-gpios CD GPIO name = cd-gpios do_mmc_init: CD state = 0 do_mmc_init: bus width = 4 Tegra SD/MMC: 0, Tegra SD/MMC: 1 tegra_mmc_getcd called, host-cd_gpio = 0x1FBCC044 mmc_reset called ... so far so good # ext2ls mmc 1 tegra_mmc_getcd called, host-cd_gpio = 0x1FBCC084 mmc_reset called mmc_core_init: host version = 0 mmc_set_ios: bus_width: 1, clock: 375000 mmc_change_clock called mmc_change_clock: div = 8 mmc_change_clock: clkcon = 0405 mmc_set_ios: hostctl = mmc_set_ios: bus_width: 1, clock: 375000 mmc_change_clock called mmc_change_clock: div = 8 mmc_change_clock: clkcon = 0405 mmc_set_ios: hostctl = mmc_send_cmd: called mmc_send_cmd_bounced called mmc_send_cmd_bounced: cmd-arg: mmc_send_cmd_bounced: cmd: 0 mmc_send_cmd: called mmc_send_cmd_bounced called mmc_send_cmd_bounced: cmd-arg: 01aa mmc_send_cmd_bounced: cmd: 8 mmc_send_cmd_bounced: error: 010c8001 cmd 8 mmc_send_cmd: called mmc_send_cmd_bounced called mmc_send_cmd_bounced: cmd-arg: mmc_send_cmd_bounced: cmd: 55 mmc_send_cmd_bounced: error: 010c8001 cmd 55 mmc_send_cmd: called mmc_send_cmd_bounced called mmc_send_cmd_bounced: cmd-arg: mmc_send_cmd_bounced: cmd: 2 mmc_send_cmd_bounced: error: 00048001 cmd 2 ** Bad device mmc 1 ** any ideas? Marc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMC driver forall T20 boards
Hi Tom,
Am Montag, 4. Februar 2013, 16:48:55 schrieb Tom Warren:
tegra_mmc_init() now uses DT info for bus width, WP/CD GPIOs, etc.
Tested on Seaboard, fully functional.
Signed-off-by: Tom Warren twar...@nvidia.com
---
arch/arm/include/asm/arch-tegra/mmc.h |2 +-
arch/arm/include/asm/arch-tegra/tegra_mmc.h | 12 +-
board/avionic-design/common/tamonten.c|4 +-
board/compal/paz00/paz00.c| 14 +-
board/compulab/trimslice/trimslice.c | 10 +-
board/nvidia/harmony/harmony.c| 12 +-
board/nvidia/seaboard/seaboard.c | 14 +-
board/nvidia/whistler/whistler.c |4 +-
board/toradex/colibri_t20_iris/colibri_t20_iris.c |2 +-
drivers/mmc/tegra_mmc.c | 186
++--- include/fdtdec.h |
1 +
lib/fdtdec.c |1 +
12 files changed, 165 insertions(+), 97 deletions(-)
[...]
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 1447f47..5cee91a 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/compal/paz00/paz00.c
@@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
- debug(board_mmc_init called\n);
+ debug(%s called\n, __func__);
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
- debug(board_mmc_init: init eMMC\n);
- /* init dev 0, eMMC chip, with 8-bit bus */
- tegra_mmc_init(0, 8, -1, -1);
+ debug(%s: init eMMC\n, __func__);
+ /* init dev 0, eMMC chip */
+ tegra_mmc_init(0);
This looks wrong because the sd is on sdmmc0
- debug(board_mmc_init: init SD slot\n);
- /* init dev 3, SD slot, with 4-bit bus */
- tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
+ debug(%s: init SD slot\n, __func__);
+ /* init dev 3, SD slot */
+ tegra_mmc_init(3);
and the emmc on sdmmc3. The DTS is correct.
Not your fault as it seems to be wrong in the original code already.
I guess it didn't made large difference but may in the future. I wonder how to
test this though.
Marc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMC driverforall T20 boards
On Tuesday 05 February 2013 08:31:03 Tom Warren wrote:
Marc,
On Tue, Feb 5, 2013 at 2:28 AM, Marc Dietrich marvi...@gmx.de wrote:
[...]
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 1447f47..5cee91a 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/compal/paz00/paz00.c
@@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
- debug(board_mmc_init called\n);
+ debug(%s called\n, __func__);
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
- debug(board_mmc_init: init eMMC\n);
- /* init dev 0, eMMC chip, with 8-bit bus */
- tegra_mmc_init(0, 8, -1, -1);
+ debug(%s: init eMMC\n, __func__);
+ /* init dev 0, eMMC chip */
+ tegra_mmc_init(0);
This looks wrong because the sd is on sdmmc0
- debug(board_mmc_init: init SD slot\n);
- /* init dev 3, SD slot, with 4-bit bus */
- tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
+ debug(%s: init SD slot\n, __func__);
+ /* init dev 3, SD slot */
+ tegra_mmc_init(3);
and the emmc on sdmmc3. The DTS is correct.
Not your fault as it seems to be wrong in the original code already.
I guess it didn't made large difference but may in the future. I wonder
how to test this though.
Marc
OK, so just the comments are wrong in paz00.c - I can fix that if I
have to do a V2 patchset, or when I apply the patches to u-boot-tegra.
ah no, this is weird!
index 3 maps to sdmmc1
index 2 maps to sdmmc2
index 1 maps to sdmmc3
index 0 maps to sdmmc4
so all is fine, nearly ...
As to testing, just stop at the command prompt and select each device
(mmc dev 0, etc.) and run mmcinfo. You should be able to tell from the
data displayed whether you are on an SD-card or eMMC chip. You can
also eject the SD-card and you should get a warning about card
presence due to the CD GPIO.
the sd card is not detected because:
TEGRA20
Board: Compal Paz00
DRAM: 512 MiB
MMC: tegra_get_setup: dev_index = 0
tegra_get_setup: count of nodes is 2
tegra_get_setup: found controller at c8000600, width = 8, periph_id = 15
tegra_mmc_init: index 0, bus width 8 pwr_gpio -1 cd_gpio -1
tegra_mmc_init: bus width = 8
tegra_get_setup: dev_index = 3
tegra_get_setup: count of nodes is 2
tegra_get_setup: device index 3 exceeds node count (2)!
If I understand correctly, you are counting the aliases only, not the
controllers..., so index 3 (the sdcard) is not initialized at all. Arrr,
debugging stole all of my time, but I guess this needs fixing.
Marc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMCdriverforall T20 boards
Tom,
On Tuesday 05 February 2013 13:41:21 Tom Warren wrote:
Marc,
On Tue, Feb 5, 2013 at 1:06 PM, Marc Dietrich marvi...@gmx.de wrote:
On Tuesday 05 February 2013 08:31:03 Tom Warren wrote:
Marc,
On Tue, Feb 5, 2013 at 2:28 AM, Marc Dietrich marvi...@gmx.de wrote:
[...]
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 1447f47..5cee91a 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/compal/paz00/paz00.c
@@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
- debug(board_mmc_init called\n);
+ debug(%s called\n, __func__);
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
- debug(board_mmc_init: init eMMC\n);
- /* init dev 0, eMMC chip, with 8-bit bus */
- tegra_mmc_init(0, 8, -1, -1);
+ debug(%s: init eMMC\n, __func__);
+ /* init dev 0, eMMC chip */
+ tegra_mmc_init(0);
This looks wrong because the sd is on sdmmc0
- debug(board_mmc_init: init SD slot\n);
- /* init dev 3, SD slot, with 4-bit bus */
- tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
+ debug(%s: init SD slot\n, __func__);
+ /* init dev 3, SD slot */
+ tegra_mmc_init(3);
and the emmc on sdmmc3. The DTS is correct.
Not your fault as it seems to be wrong in the original code already.
I guess it didn't made large difference but may in the future. I wonder
how to test this though.
Marc
OK, so just the comments are wrong in paz00.c - I can fix that if I
have to do a V2 patchset, or when I apply the patches to u-boot-tegra.
ah no, this is weird!
index 3 maps to sdmmc1
index 2 maps to sdmmc2
index 1 maps to sdmmc3
index 0 maps to sdmmc4
so all is fine, nearly ...
As to testing, just stop at the command prompt and select each device
(mmc dev 0, etc.) and run mmcinfo. You should be able to tell from the
data displayed whether you are on an SD-card or eMMC chip. You can
also eject the SD-card and you should get a warning about card
presence due to the CD GPIO.
the sd card is not detected because:
TEGRA20
Board: Compal Paz00
DRAM: 512 MiB
MMC: tegra_get_setup: dev_index = 0
tegra_get_setup: count of nodes is 2
tegra_get_setup: found controller at c8000600, width = 8, periph_id = 15
tegra_mmc_init: index 0, bus width 8 pwr_gpio -1 cd_gpio -1
tegra_mmc_init: bus width = 8
tegra_get_setup: dev_index = 3
tegra_get_setup: count of nodes is 2
tegra_get_setup: device index 3 exceeds node count (2)!
If I understand correctly, you are counting the aliases only, not the
controllers..., so index 3 (the sdcard) is not initialized at all. Arrr,
debugging stole all of my time, but I guess this needs fixing.
Yep, I am checking the aliases to get a node count (just like the
Tegra SPI, SLINK, and I2C drivers, and the Exynos SPI and S3C I2C
drivers).
I left the Paz00 tegra_mmc_init(3) call the same as originally (w/o
the width and GPIO params, of course). The device numbering is kind of
arbitrary - if there are only 2 MMC devices present, I'd expect dev 0
to be eMMC and dev 1 to be SD (again, like my T20 reference board,
Seaboard). I don't see that Paz uses mmc anywhere in its config files
for a boot script - does it have to have mmc dev 3 be SD? or would dev
1 work? Note that the tegra20-common-post.h file that all T20 boards
inherit uses dev 0 and dev 1.
U-boot scans all devices during boot, so no need to specify a specific one. I
think what Stephen is suggesting is the right way. Forget all this dev ids and
let the device tree control everything. The aliases can be used for enumbering
if someone really needs it.
Let me look into it - wish I had a Paz00 board here to debug with.
I'll try to simulate this on my Seaboard, maybe with all 4 MMC device
addresses in the alias.
He, if you ever come to old Europe, there are still some shops selling
them ;-)
Marc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tegra: remove custom TEGRA_DEVICE_SETTINGS for board files
TEGRA_DEVICE_SETTINGS lives now in tegra-common-post.h. This removes custom TEGRA_DEVICE_SETTINGS for all tegra boards providing video output, except seaboard, which was fixed by Stephen already. Cc: Thierry Reding thierry.red...@avionic-design.de Signed-off-by: Marc Dietrich marvi...@gmx.de --- Tom, this needs to be applied ontop of Stephen's patch tegra: only define TEGRA_DEVICE_SETTINGS if not already defined include/configs/medcom-wide.h | 6 -- include/configs/paz00.h | 6 -- include/configs/tec.h | 6 -- 3 files changed, 18 deletions(-) diff --git a/include/configs/medcom-wide.h b/include/configs/medcom-wide.h index 452d587..bae4ba0 100644 --- a/include/configs/medcom-wide.h +++ b/include/configs/medcom-wide.h @@ -78,12 +78,6 @@ ext2load mmc 0 0x1700 /boot/uImage; \ bootm -#undef TEGRA_DEVICE_SETTINGS -#define TEGRA_DEVICE_SETTINGS \ - stdin=serial\0\ - stdout=serial,lcd\0 \ - stderr=serial,lcd\0 - /* LCD support */ #define CONFIG_LCD #define CONFIG_PWM_TEGRA diff --git a/include/configs/paz00.h b/include/configs/paz00.h index 4a74d00..2edb4aa 100644 --- a/include/configs/paz00.h +++ b/include/configs/paz00.h @@ -72,12 +72,6 @@ #define CONFIG_CMD_NET #define CONFIG_CMD_DHCP -#undef TEGRA_DEVICE_SETTINGS -#define TEGRA_DEVICE_SETTINGS \ - stdin=serial\0\ - stdout=serial,lcd\0 \ - stderr=serial,lcd\0 - /* LCD support */ #define CONFIG_LCD #define CONFIG_PWM_TEGRA diff --git a/include/configs/tec.h b/include/configs/tec.h index 815afa6..caeb9cd 100644 --- a/include/configs/tec.h +++ b/include/configs/tec.h @@ -85,12 +85,6 @@ ext2load mmc 0 0x1700 /boot/uImage; \ bootm -#undef TEGRA_DEVICE_SETTINGS -#define TEGRA_DEVICE_SETTINGS \ - stdin=serial\0\ - stdout=serial,lcd\0 \ - stderr=serial,lcd\0 - /* LCD support */ #define CONFIG_LCD #define CONFIG_PWM_TEGRA -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2 v2] tegra: display: add board pinmux
Boards may require a different pinmux setup for DISPLAY than the default one.
Add a way to call into board specific code to set this up.
Signed-off-by: Marc Dietrich marvi...@gmx.de
---
changes in V2:
- fix comment padding
arch/arm/include/asm/arch-tegra/board.h |1 +
board/nvidia/common/board.c |7 +++
2 files changed, 8 insertions(+)
diff --git a/arch/arm/include/asm/arch-tegra/board.h
b/arch/arm/include/asm/arch-tegra/board.h
index be6bf25..7453dcd 100644
--- a/arch/arm/include/asm/arch-tegra/board.h
+++ b/arch/arm/include/asm/arch-tegra/board.h
@@ -44,5 +44,6 @@ void gpio_early_init(void); /* overrideable GPIO config
*/
void pin_mux_usb(void); /* overrideable USB pinmux setup */
void pin_mux_spi(void); /* overrideable SPI pinmux setup */
void pin_mux_nand(void); /* overrideable NAND pinmux setup */
+void pin_mux_display(void); /* overrideable DISPLAY pinmux setup */
#endif
diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
index 76ec687..819c120 100644
--- a/board/nvidia/common/board.c
+++ b/board/nvidia/common/board.c
@@ -87,6 +87,12 @@ void __pin_mux_nand(void)
void pin_mux_nand(void) __attribute__((weak, alias(__pin_mux_nand)));
+void __pin_mux_display(void)
+{
+}
+
+void pin_mux_display(void) __attribute__((weak, alias(__pin_mux_display)));
+
/*
* Routine: power_det_init
* Description: turn off power detects
@@ -126,6 +132,7 @@ int board_init(void)
debug(%s: Failed to init pwm\n, __func__);
#endif
#ifdef CONFIG_LCD
+ pin_mux_display();
tegra_lcd_check_next_stage(gd-fdt_blob, 0);
#endif
/* boot param addr */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2 v2] tegra: enable LCD on PAZ00
This adds LCD panel descriptions to the device tree of PAZ00 and
enables LCD support in the configuration.
Signed-off-by: Marc Dietrich marvi...@gmx.de
---
I'll create a patch to add LCD support to common TEGRA_DEVICE_SETTINGS
once the tegra tree is rebased.
changes in V2:
- s/DISPALY/DISPLAY/
- removed W0 gpio which is not used
- set all panel-timings to 0
board/compal/dts/tegra20-paz00.dts | 31 +++
board/compal/paz00/paz00.c | 11 +++
include/configs/paz00.h| 15 +++
3 files changed, 57 insertions(+)
diff --git a/board/compal/dts/tegra20-paz00.dts
b/board/compal/dts/tegra20-paz00.dts
index 9e3e169..8c258ff 100644
--- a/board/compal/dts/tegra20-paz00.dts
+++ b/board/compal/dts/tegra20-paz00.dts
@@ -54,4 +54,35 @@
usb@c5004000 {
status = disabled;
};
+
+ host1x {
+ status = okay;
+ dc@5420 {
+ status = okay;
+ rgb {
+ status = okay;
+ nvidia,panel = lcd_panel;
+ };
+ };
+ };
+
+ lcd_panel: panel {
+ /* PAZ00 has 1024x600 */
+ clock = 5403;
+ xres = 1024;
+ yres = 600;
+ right-margin = 160;
+ left-margin = 24;
+ hsync-len = 136;
+ upper-margin = 3;
+ lower-margin = 61;
+ vsync-len = 6;
+ hsync-active-high;
+ nvidia,bits-per-pixel = 16;
+ nvidia,pwm = pwm 0 0;
+ nvidia,backlight-enable-gpios = gpio 164 0; /* PU4 */
+ nvidia,lvds-shutdown-gpios = gpio 102 0; /* PM6 */
+ nvidia,panel-vdd-gpios = gpio 4 0; /* PA4 */
+ nvidia,panel-timings = 0 0 0 0;
+ };
};
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 6492d41..1447f47 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/compal/paz00/paz00.c
@@ -71,3 +71,14 @@ int board_mmc_init(bd_t *bd)
return 0;
}
#endif
+
+#ifdef CONFIG_LCD
+/* this is a weak define that we are overriding */
+void pin_mux_display(void)
+{
+ debug(init display pinmux\n);
+
+ /* EN_VDD_PANEL GPIO A4 */
+ pinmux_tristate_disable(PINGRP_DAP2);
+}
+#endif
diff --git a/include/configs/paz00.h b/include/configs/paz00.h
index 38c79cf..4a74d00 100644
--- a/include/configs/paz00.h
+++ b/include/configs/paz00.h
@@ -36,6 +36,7 @@
#define CONFIG_MACH_TYPE MACH_TYPE_PAZ00
#define CONFIG_BOARD_EARLY_INIT_F
+#define CONFIG_BOARD_LATE_INIT
/* SD/MMC */
#define CONFIG_MMC
@@ -71,6 +72,20 @@
#define CONFIG_CMD_NET
#define CONFIG_CMD_DHCP
+#undef TEGRA_DEVICE_SETTINGS
+#define TEGRA_DEVICE_SETTINGS \
+ stdin=serial\0\
+ stdout=serial,lcd\0 \
+ stderr=serial,lcd\0
+
+/* LCD support */
+#define CONFIG_LCD
+#define CONFIG_PWM_TEGRA
+#define CONFIG_VIDEO_TEGRA
+#define LCD_BPPLCD_COLOR16
+#define CONFIG_SYS_WHITE_ON_BLACK
+#define CONFIG_CONSOLE_SCROLL_LINES10
+
#include tegra-common-post.h
#endif /* __CONFIG_H */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] tegra: display: add board pinmux
Hi Tom,
On Monday 26 November 2012 09:55:49 Tom Warren wrote:
Boards may require a different pinmux setup for DISPALY than the default
one.
s/b 'DISPLAY'
ups.
-void pin_mux_usb(void); /* overrideable USB pinmux setup */
-void pin_mux_spi(void); /* overrideable SPI pinmux setup */
-void pin_mux_nand(void); /* overrideable NAND pinmux setup */
+void pin_mux_usb(void); /* overrideable USB pinmux setup */
+void pin_mux_spi(void); /* overrideable SPI pinmux setup */
+void pin_mux_nand(void); /* overrideable NAND pinmux setup*/
+void pin_mux_display(void); /* overrideable DISPLAY pinmux setup */
Don't pad the end of the other comments just to match up with your new
DISPLAY proto comment. Had to look at this twice to see what you were
really doing here.
yeah, I had to decide whether to create an ugly patch or an ugly comment.
Will choose the other solution then.
Marc
Otherwise this patchset LGTM. I'll apply it to tegra/next once you've
fixed these nits.
Tom
On Sun, Nov 25, 2012 at 2:26 PM, Marc Dietrich marvi...@gmx.de wrote:
Boards may require a different pinmux setup for DISPALY than the default
one. Add a way to call into board specific code to set this up.
Signed-off-by: Marc Dietrich marvi...@gmx.de
---
arch/arm/include/asm/arch-tegra/board.h |7 ---
board/nvidia/common/board.c |7 +++
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-tegra/board.h
b/arch/arm/include/asm/arch-tegra/board.h index be6bf25..3db0d93 100644
--- a/arch/arm/include/asm/arch-tegra/board.h
+++ b/arch/arm/include/asm/arch-tegra/board.h
@@ -41,8 +41,9 @@ void gpio_early_init(void); /* overrideable GPIO config
*/
* an empty stub function will be called.
*/
-void pin_mux_usb(void); /* overrideable USB pinmux setup */
-void pin_mux_spi(void); /* overrideable SPI pinmux setup */
-void pin_mux_nand(void); /* overrideable NAND pinmux setup */
+void pin_mux_usb(void); /* overrideable USB pinmux setup */
+void pin_mux_spi(void); /* overrideable SPI pinmux setup */
+void pin_mux_nand(void); /* overrideable NAND pinmux setup*/
+void pin_mux_display(void); /* overrideable DISPLAY pinmux setup */
#endif
diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
index 76ec687..819c120 100644
--- a/board/nvidia/common/board.c
+++ b/board/nvidia/common/board.c
@@ -87,6 +87,12 @@ void __pin_mux_nand(void)
void pin_mux_nand(void) __attribute__((weak, alias(__pin_mux_nand)));
+void __pin_mux_display(void)
+{
+}
+
+void pin_mux_display(void) __attribute__((weak,
alias(__pin_mux_display))); +
/*
* Routine: power_det_init
* Description: turn off power detects
@@ -126,6 +132,7 @@ int board_init(void)
debug(%s: Failed to init pwm\n, __func__);
#endif
#ifdef CONFIG_LCD
+ pin_mux_display();
tegra_lcd_check_next_stage(gd-fdt_blob, 0);
#endif
/* boot param addr */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] tegra: enable LCD on PAZ00
On Monday 26 November 2012 12:00:51 Stephen Warren wrote: On 11/25/2012 02:26 PM, Marc Dietrich wrote: This adds LCD panel descriptions to the device tree of PAZ00 and enables LCD support in the configuration. diff --git a/include/configs/paz00.h b/include/configs/paz00.h +#define CONFIG_BOARD_LATE_INIT What's that for? I don't think any of the other Tegra boards have it. No, all board defining CONFIG_LCD have this (seaboard, avionics). You may ask Simon why it is required. Without it, backlight will not come up on PAZ00 at least. /* SD/MMC */ #define CONFIG_MMC @@ -71,6 +72,20 @@ #define CONFIG_CMD_NET #define CONFIG_CMD_DHCP +#undef TEGRA_DEVICE_SETTINGS +#define TEGRA_DEVICE_SETTINGS \ + stdin=serial\0\ + stdout=serial,lcd\0 \ + stderr=serial,lcd\0 Why not extend tegra-common-post.h's automatic calculation of TEGRA_DEVICE_SETTINGS to support the lcd case too? Allen Martin's recent change tegra: move TEGRA_DEVICE_SETTINGS to tegra-common-post.h should make it easy to do that. Yes, I have such a patch in my gitorious tree for some time now. Allen's patch is not in any u-boot-tegra branch yet. I can fix it up when it has landed. Marc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] tegra: display: add board pinmux
Boards may require a different pinmux setup for DISPALY than the default one.
Add a way to call into board specific code to set this up.
Signed-off-by: Marc Dietrich marvi...@gmx.de
---
arch/arm/include/asm/arch-tegra/board.h |7 ---
board/nvidia/common/board.c |7 +++
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-tegra/board.h
b/arch/arm/include/asm/arch-tegra/board.h
index be6bf25..3db0d93 100644
--- a/arch/arm/include/asm/arch-tegra/board.h
+++ b/arch/arm/include/asm/arch-tegra/board.h
@@ -41,8 +41,9 @@ void gpio_early_init(void); /* overrideable GPIO config
*/
* an empty stub function will be called.
*/
-void pin_mux_usb(void); /* overrideable USB pinmux setup */
-void pin_mux_spi(void); /* overrideable SPI pinmux setup */
-void pin_mux_nand(void); /* overrideable NAND pinmux setup */
+void pin_mux_usb(void); /* overrideable USB pinmux setup */
+void pin_mux_spi(void); /* overrideable SPI pinmux setup */
+void pin_mux_nand(void); /* overrideable NAND pinmux setup*/
+void pin_mux_display(void); /* overrideable DISPLAY pinmux setup */
#endif
diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
index 76ec687..819c120 100644
--- a/board/nvidia/common/board.c
+++ b/board/nvidia/common/board.c
@@ -87,6 +87,12 @@ void __pin_mux_nand(void)
void pin_mux_nand(void) __attribute__((weak, alias(__pin_mux_nand)));
+void __pin_mux_display(void)
+{
+}
+
+void pin_mux_display(void) __attribute__((weak, alias(__pin_mux_display)));
+
/*
* Routine: power_det_init
* Description: turn off power detects
@@ -126,6 +132,7 @@ int board_init(void)
debug(%s: Failed to init pwm\n, __func__);
#endif
#ifdef CONFIG_LCD
+ pin_mux_display();
tegra_lcd_check_next_stage(gd-fdt_blob, 0);
#endif
/* boot param addr */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] tegra: enable LCD on PAZ00
This adds LCD panel descriptions to the device tree of PAZ00 and
enables LCD support in the configuration.
Signed-off-by: Marc Dietrich marvi...@gmx.de
---
board/compal/dts/tegra20-paz00.dts | 32
board/compal/paz00/paz00.c | 11 +++
include/configs/paz00.h| 15 +++
3 files changed, 58 insertions(+)
diff --git a/board/compal/dts/tegra20-paz00.dts
b/board/compal/dts/tegra20-paz00.dts
index 9e3e169..afebbe5 100644
--- a/board/compal/dts/tegra20-paz00.dts
+++ b/board/compal/dts/tegra20-paz00.dts
@@ -54,4 +54,36 @@
usb@c5004000 {
status = disabled;
};
+
+ host1x {
+ status = okay;
+ dc@5420 {
+ status = okay;
+ rgb {
+ status = okay;
+ nvidia,panel = lcd_panel;
+ };
+ };
+ };
+
+ lcd_panel: panel {
+ /* PAZ00 has 1024x600 */
+ clock = 5403;
+ xres = 1024;
+ yres = 600;
+ right-margin = 160;
+ left-margin = 24;
+ hsync-len = 136;
+ upper-margin = 3;
+ lower-margin = 61;
+ vsync-len = 6;
+ hsync-active-high;
+ nvidia,bits-per-pixel = 16;
+ nvidia,pwm = pwm 0 0;
+ nvidia,backlight-enable-gpios = gpio 164 0; /* PU4 */
+ nvidia,lvds-shutdown-gpios = gpio 102 0; /* PM6 */
+ nvidia,backlight-vdd-gpios = gpio 176 0; /* PW0 */
+ nvidia,panel-vdd-gpios = gpio 4 0; /* PA4 */
+ nvidia,panel-timings = 400 4 203 17 15;
+ };
};
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 6492d41..1447f47 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/compal/paz00/paz00.c
@@ -71,3 +71,14 @@ int board_mmc_init(bd_t *bd)
return 0;
}
#endif
+
+#ifdef CONFIG_LCD
+/* this is a weak define that we are overriding */
+void pin_mux_display(void)
+{
+ debug(init display pinmux\n);
+
+ /* EN_VDD_PANEL GPIO A4 */
+ pinmux_tristate_disable(PINGRP_DAP2);
+}
+#endif
diff --git a/include/configs/paz00.h b/include/configs/paz00.h
index 38c79cf..4a74d00 100644
--- a/include/configs/paz00.h
+++ b/include/configs/paz00.h
@@ -36,6 +36,7 @@
#define CONFIG_MACH_TYPE MACH_TYPE_PAZ00
#define CONFIG_BOARD_EARLY_INIT_F
+#define CONFIG_BOARD_LATE_INIT
/* SD/MMC */
#define CONFIG_MMC
@@ -71,6 +72,20 @@
#define CONFIG_CMD_NET
#define CONFIG_CMD_DHCP
+#undef TEGRA_DEVICE_SETTINGS
+#define TEGRA_DEVICE_SETTINGS \
+ stdin=serial\0\
+ stdout=serial,lcd\0 \
+ stderr=serial,lcd\0
+
+/* LCD support */
+#define CONFIG_LCD
+#define CONFIG_PWM_TEGRA
+#define CONFIG_VIDEO_TEGRA
+#define LCD_BPPLCD_COLOR16
+#define CONFIG_SYS_WHITE_ON_BLACK
+#define CONFIG_CONSOLE_SCROLL_LINES10
+
#include tegra-common-post.h
#endif /* __CONFIG_H */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 07/16] tegra: Add LCD driver
Simon,
I tried to adapt this for paz00. I only get backlight and an all white screen.
On checking what's wrong I stumpled about something strange below...
Marc
On Thursday 27 September 2012 17:44:28 Simon Glass wrote:
This driver supports driving a single LCD and providing a U-Boot console
on it.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Update LCD driver to deal with new fdt bindings
Changes in v3:
- Move some fdt decode code from LCD driver to SOC display driver
- Rename fdt config structures
- Use new pwm binding from pre-linux-next
- Adjust LCD driver to use new SOC display driver structures
Changes in v4:
- Rebase on top of new tegra common directory structure
- Change LCD panel GPIOs to be entirely optional
- Only indicate that LCD init is complete when all stages complete
drivers/video/Makefile |1 +
drivers/video/tegra.c | 361
2 files changed, 362
insertions(+), 0 deletions(-)
create mode 100644 drivers/video/tegra.c
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index ebb6da8..78a7668 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -49,6 +49,7 @@ COBJS-$(CONFIG_VIDEO_OMAP3) += omap3_dss.o
COBJS-$(CONFIG_VIDEO_SED13806) += sed13806.o
COBJS-$(CONFIG_VIDEO_SM501) += sm501.o
COBJS-$(CONFIG_VIDEO_SMI_LYNXEM) += smiLynxEM.o videomodes.o
+COBJS-$(CONFIG_VIDEO_TEGRA) += tegra.o
COBJS-$(CONFIG_VIDEO_VCXK) += bus_vcxk.o
COBJS:= $(sort $(COBJS-y))
diff --git a/drivers/video/tegra.c b/drivers/video/tegra.c
new file mode 100644
index 000..9df2bd3
--- /dev/null
+++ b/drivers/video/tegra.c
@@ -0,0 +1,361 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include fdtdec.h
+#include lcd.h
+
+#include asm/system.h
+#include asm/gpio.h
+
+#include asm/arch/clock.h
+#include asm/arch/funcmux.h
+#include asm/arch/pinmux.h
+#include asm/arch/pwm.h
+#include asm/arch/display.h
+#include asm/arch-tegra/timer.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* These are the stages we go throuh in enabling the LCD */
+enum stage_t {
+ STAGE_START,
+ STAGE_LVDS,
+ STAGE_BACKLIGHT_VDD,
+ STAGE_PWM,
+ STAGE_BACKLIGHT_EN,
+ STAGE_DONE,
+};
+
+static enum stage_t stage; /* Current stage we are at */
+static unsigned long timer_next; /* Time we can move onto next stage */
+
+/* Our LCD config, set up in handle_stage() */
+static struct fdt_panel_config config;
+struct fdt_disp_config *disp_config; /* Display controller config */
+
+enum {
+ /* Maximum LCD size we support */
+ LCD_MAX_WIDTH = 1366,
+ LCD_MAX_HEIGHT = 768,
+ LCD_MAX_LOG2_BPP= 4,/* 2^4 = 16 bpp */
+};
+
+int lcd_line_length;
+int lcd_color_fg;
+int lcd_color_bg;
+
+void *lcd_base; /* Start of framebuffer memory */
+void *lcd_console_address; /* Start of console buffer */
+
+short console_col;
+short console_row;
+
+vidinfo_t panel_info = {
+ /* Insert a value here so that we don't end up in the BSS */
+ .vl_col = -1,
+};
+
+char lcd_cursor_enabled;
+
+ushort lcd_cursor_width;
+ushort lcd_cursor_height;
+
+#ifndef CONFIG_OF_CONTROL
+#error You must enable CONFIG_OF_CONTROL to get Tegra LCD support
+#endif
+
+void lcd_cursor_size(ushort width, ushort height)
+{
+ lcd_cursor_width = width;
+ lcd_cursor_height = height;
+}
+
+void lcd_toggle_cursor(void)
+{
+ ushort x, y;
+ uchar *dest;
+ ushort row;
+
+ x = console_col * lcd_cursor_width;
+ y = console_row * lcd_cursor_height;
+ dest = (uchar *)(lcd_base + y * lcd_line_length + x * (1 LCD_BPP) /
+ 8);
+
+ for (row = 0; row lcd_cursor_height; ++row, dest += lcd_line_length) {
+ ushort *d = (ushort *)dest;
+ ushort color;
+ int i;
+
+ for (i = 0; i lcd_cursor_width; ++i) {
+ color = *d;
+ color ^= lcd_color_fg;
+ *d = color;
+
[U-Boot] [PATCH] tegra: move common features to a common makefile
For Non-Nvidia boards to include newly added features (like emc clock scaling) it would be necessary to add each feature to their own board Makefile. This is because currently the top Makefile automaticly includes these features only for Nvidia boards. This patch adds a simple Makefile include so all new features become available for non-Nvidia board vendors. Cc: Stephen Warren swar...@wwwdotorg.org Cc: Tom Warren twar...@nvidia.com Cc: Thierry Reding thierry.red...@avionic-design.de Cc: Lucas Stach d...@lynxeye.de Signed-off-by: Marc Dietrich marvi...@gmx.de --- Passed: MAKEALL -s tegra20, booted on paz00 --- board/avionic-design/medcom-wide/Makefile |6 -- board/avionic-design/plutux/Makefile |6 -- board/avionic-design/tec/Makefile |6 -- board/compal/paz00/Makefile |6 -- board/compulab/trimslice/Makefile |6 -- board/nvidia/common/Makefile |4 +--- board/nvidia/common/common.mk |4 7 files changed, 25 insertions(+), 13 deletions(-) create mode 100644 board/nvidia/common/common.mk diff --git a/board/avionic-design/medcom-wide/Makefile b/board/avionic-design/medcom-wide/Makefile index 864bc0e..e8c1e8b 100644 --- a/board/avionic-design/medcom-wide/Makefile +++ b/board/avionic-design/medcom-wide/Makefile @@ -29,9 +29,11 @@ $(shell mkdir -p $(obj)../common $(obj)../../nvidia/common) LIB= $(obj)lib$(BOARD).o -COBJS := ../../nvidia/common/board.o -COBJS += ../common/tamonten.o +COBJS-y:= ../common/tamonten.o +include ../../nvidia/common/common.mk + +COBJS := $(COBJS-y) SRCS := $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS)) diff --git a/board/avionic-design/plutux/Makefile b/board/avionic-design/plutux/Makefile index 864bc0e..e8c1e8b 100644 --- a/board/avionic-design/plutux/Makefile +++ b/board/avionic-design/plutux/Makefile @@ -29,9 +29,11 @@ $(shell mkdir -p $(obj)../common $(obj)../../nvidia/common) LIB= $(obj)lib$(BOARD).o -COBJS := ../../nvidia/common/board.o -COBJS += ../common/tamonten.o +COBJS-y:= ../common/tamonten.o +include ../../nvidia/common/common.mk + +COBJS := $(COBJS-y) SRCS := $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS)) diff --git a/board/avionic-design/tec/Makefile b/board/avionic-design/tec/Makefile index 864bc0e..e8c1e8b 100644 --- a/board/avionic-design/tec/Makefile +++ b/board/avionic-design/tec/Makefile @@ -29,9 +29,11 @@ $(shell mkdir -p $(obj)../common $(obj)../../nvidia/common) LIB= $(obj)lib$(BOARD).o -COBJS := ../../nvidia/common/board.o -COBJS += ../common/tamonten.o +COBJS-y:= ../common/tamonten.o +include ../../nvidia/common/common.mk + +COBJS := $(COBJS-y) SRCS := $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS)) diff --git a/board/compal/paz00/Makefile b/board/compal/paz00/Makefile index 7f7287e..fa5c510 100644 --- a/board/compal/paz00/Makefile +++ b/board/compal/paz00/Makefile @@ -20,9 +20,11 @@ $(shell mkdir -p $(obj)../../nvidia/common) LIB= $(obj)lib$(BOARD).o -COBJS := $(BOARD).o -COBJS += ../../nvidia/common/board.o +COBJS-y:= $(BOARD).o +include ../../nvidia/common/common.mk + +COBJS := $(COBJS-y) SRCS := $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS)) diff --git a/board/compulab/trimslice/Makefile b/board/compulab/trimslice/Makefile index ff07879..cc844d2 100644 --- a/board/compulab/trimslice/Makefile +++ b/board/compulab/trimslice/Makefile @@ -28,9 +28,11 @@ $(shell mkdir -p $(obj)../../nvidia/common) LIB= $(obj)lib$(BOARD).o -COBJS := $(BOARD).o -COBJS += ../../nvidia/common/board.o +COBJS-y:= $(BOARD).o +include ../../nvidia/common/common.mk + +COBJS := $(COBJS-y) SRCS := $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS)) diff --git a/board/nvidia/common/Makefile b/board/nvidia/common/Makefile index a93d458..f6f419e 100644 --- a/board/nvidia/common/Makefile +++ b/board/nvidia/common/Makefile @@ -25,9 +25,7 @@ endif LIB= $(obj)lib$(VENDOR).o -COBJS-y += board.o -COBJS-$(CONFIG_SPI_UART_SWITCH) += uart-spi-switch.o -COBJS-$(CONFIG_TEGRA_CLOCK_SCALING) += emc.o +include common.mk COBJS := $(COBJS-y) SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) diff --git a/board/nvidia/common/common.mk b/board/nvidia/common/common.mk new file mode 100644 index 000..bd6202c --- /dev/null +++ b/board/nvidia/common/common.mk @@ -0,0 +1,4 @@ +# common options for all tegra boards +COBJS-y+= ../../nvidia/common/board.o +COBJS-$(CONFIG_SPI_UART_SWITCH) += ../../nvidia/common/uart-spi-switch.o +COBJS-$(CONFIG_TEGRA_CLOCK_SCALING) += ../../nvidia/common/emc.o -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] tegra: i2c: Enable I2C on PAZ00
This enables I2C on PAZ00. Signed-off-by: Marc Dietrich marvi...@gmx.de --- include/configs/paz00.h |8 1 file changed, 8 insertions(+) diff --git a/include/configs/paz00.h b/include/configs/paz00.h index 24cda48..7e21e66 100644 --- a/include/configs/paz00.h +++ b/include/configs/paz00.h @@ -38,6 +38,14 @@ #define CONFIG_BOARD_EARLY_INIT_F +/* I2C */ +#define CONFIG_TEGRA_I2C +#define CONFIG_SYS_I2C_INIT_BOARD +#define CONFIG_I2C_MULTI_BUS +#define CONFIG_SYS_MAX_I2C_BUS 4 +#define CONFIG_SYS_I2C_SPEED 10 +#define CONFIG_CMD_I2C + /* SD/MMC */ #define CONFIG_MMC #define CONFIG_GENERIC_MMC -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] tegra: enable lp0 on paz00
This enables LP0 to support suspend / resume on PAZ00. Signed-off-by: Marc Dietrich marvi...@gmx.de --- board/compal/paz00/Makefile |6 -- include/configs/paz00.h |8 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/board/compal/paz00/Makefile b/board/compal/paz00/Makefile index 7f7287e..fbe28b3 100644 --- a/board/compal/paz00/Makefile +++ b/board/compal/paz00/Makefile @@ -20,9 +20,11 @@ $(shell mkdir -p $(obj)../../nvidia/common) LIB= $(obj)lib$(BOARD).o -COBJS := $(BOARD).o -COBJS += ../../nvidia/common/board.o +COBJS-y:= $(BOARD).o +COBJS-y+= ../../nvidia/common/board.o +COBJS-$(CONFIG_TEGRA_CLOCK_SCALING) += ../../nvidia/common/emc.o +COBJS := $(COBJS-y) SRCS := $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS)) diff --git a/include/configs/paz00.h b/include/configs/paz00.h index 7e21e66..1c96f1c 100644 --- a/include/configs/paz00.h +++ b/include/configs/paz00.h @@ -18,6 +18,14 @@ #define __CONFIG_H #include asm/sizes.h + +/* LP0 suspend / resume */ +#define CONFIG_TEGRA20_LP0 +#define CONFIG_AES +#define CONFIG_TEGRA_PMU +#define CONFIG_TPS6586X_POWER +#define CONFIG_TEGRA_CLOCK_SCALING + #include tegra20-common.h /* Enable fdt support for Paz00. Flash the image in u-boot-dtb.bin */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] tegra: enable lp0 on paz00
On Monday 10 September 2012 13:07:43 Stephen Warren wrote: On 09/10/2012 12:51 PM, Marc Dietrich wrote: This enables LP0 to support suspend / resume on PAZ00. Ooh. Did you test this out with the AC100 kernel, and have it work? That'd be pretty cool... yeah, it would. Unfortunately, I failed to boot a nvidia 3.1 kernel with uboot (hangs somewhere in usb code), so I couldn't test it so far. But I'll retry soon. diff --git a/board/compal/paz00/Makefile b/board/compal/paz00/Makefile -COBJS := $(BOARD).o -COBJS += ../../nvidia/common/board.o +COBJS-y:= $(BOARD).o +COBJS-y+= ../../nvidia/common/board.o +COBJS-$(CONFIG_TEGRA_CLOCK_SCALING) += ../../nvidia/common/emc.o Hmmm. That's odd. I'd expect that to be part of the core Tegra code, rather than something boards have to pull in manually. Correct, will kill it in the next try. diff --git a/include/configs/paz00.h b/include/configs/paz00.h +/* LP0 suspend / resume */ +#define CONFIG_TEGRA20_LP0 That's been renamed CONFIG_TEGRA_LP0 in u-boot-tegra/next. Thanks for the hint. At least I have a better chance to test it now ;-) Marc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] tegra: i2c: Enable I2C on PAZ00
On Monday 10 September 2012 13:04:42 Stephen Warren wrote: On 09/10/2012 12:51 PM, Marc Dietrich wrote: This enables I2C on PAZ00. Really? You need to edit board/compal/dts/tegra20-paz00.dts to enable the I2C ports, don't you? yes, together with the regulator node. Should this be split in two patches? Marc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: paz00: add device tree support
Am Dienstag, 22. Mai 2012, 16:30:29 schrieb Stephen Warren: On 05/22/2012 03:15 PM, Marc Dietrich wrote: On Tuesday 22 May 2012 10:58:37 Stephen Warren wrote: On 05/22/2012 10:14 AM, Stephen Warren wrote: On 05/22/2012 02:04 AM, Marc Dietrich wrote: Hi Stephen, Am Montag, 21. Mai 2012, 14:04:37 schrieb Stephen Warren: From: Stephen Warren swar...@nvidia.com ... to enable USB host support, which enables Ethernet support. Signed-off-by: Stephen Warren swar...@nvidia.com while adding usb support is fine, I see no reason to add smsc95xx support because contrary to harmony, paz00 does not contain an ethernet port. Is the SMSC95xx only an internal part, or could it be present on a user-pluggable USB dongle? I wasn't sure, so I left it in. Looking at the driver (and the Linux kernel driver and SMSC's website), it supports both the standalone USB-Ethernet 9500 chip that's likely to be in USB Ethernet dongles, and various combo USB hub + Ethernet chips that are found on motherboards (e.g. Harmony). As such, I think it's reasonable to leave this config option enabled on Paz00 and other Tegra boards even when such a chip isn't on the board itself. Do you agree? Following this argument would mean to enable all current (and future) usb devices and we end up with an u-boot which is to heavy to swim. I only have a mcs7830 which is unfortunately not supported. Do you have a SMSC95xx based usb adapter or plan to get one? In this case I think it would be ok to enable it, otherwise I tend to disagree here. On the other hand, given that you kindly take care of the paz00 code, the decision is up to you. Mine is an Asix-based dongle. It seems a pity to artificially limit ourselves. I'd be happy seeing all the USB devices enabled as the drivers are written myself. But I suppose net-booting is a developer thing, and developers can easily turn on this option if they want, so I can remove it. Is your objection for the Paz00 board only? I turned it on for all the other boards too. Note that Harmony really does have this chip on the board, so would need this option enabled either way. My comment was only with regard to Paz00. Of course, if Harmony has it build in (I mean the hardware), it should also be included in u-boot. The question was more if we should also support all possible pluggable hw. I only found a smsc 9500 eval board (usb adapter) for 160 pounds, while my mcs only cost me 1/10th of that. As I said, I'll leave it up to you (and the vendors) to enable it in the build. Marc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: paz00: add device tree support
Hi Stephen,
Am Montag, 21. Mai 2012, 14:04:37 schrieb Stephen Warren:
From: Stephen Warren swar...@nvidia.com
... to enable USB host support, which enables Ethernet support.
Signed-off-by: Stephen Warren swar...@nvidia.com
while adding usb support is fine, I see no reason to add smsc95xx support
because contrary to harmony, paz00 does not contain an ethernet port.
Marc
---
board/compal/dts/tegra2-paz00.dts | 57
+ include/configs/paz00.h |
22 +-
2 files changed, 78 insertions(+), 1 deletions(-)
create mode 100644 board/compal/dts/tegra2-paz00.dts
diff --git a/board/compal/dts/tegra2-paz00.dts
b/board/compal/dts/tegra2-paz00.dts new file mode 100644
index 000..9e3e169
--- /dev/null
+++ b/board/compal/dts/tegra2-paz00.dts
@@ -0,0 +1,57 @@
+/dts-v1/;
+
+/include/ ARCH_CPU_DTS
+
+/ {
+model = Toshiba AC100 / Dynabook AZ;
+compatible = compal,paz00, nvidia,tegra20;
+
+ aliases {
+ usb0 = /usb@c5008000;
+ };
+
+ memory {
+ reg = 0x 0x2000;
+ };
+
+ clocks {
+ clk_32k: clk_32k {
+ clock-frequency = 32000;
+ };
+ osc {
+ clock-frequency = 1200;
+ };
+ };
+
+ clock@60006000 {
+ clocks = clk_32k osc;
+ };
+
+ serial@70006000 {
+ clock-frequency = 21600 ;
+ };
+
+ i2c@7000c000 {
+ status = disabled;
+ };
+
+ i2c@7000c400 {
+ status = disabled;
+ };
+
+ i2c@7000c500 {
+ status = disabled;
+ };
+
+ i2c@7000d000 {
+ status = disabled;
+ };
+
+ usb@c500 {
+ status = disabled;
+ };
+
+ usb@c5004000 {
+ status = disabled;
+ };
+};
diff --git a/include/configs/paz00.h b/include/configs/paz00.h
index ced185e..f8bd7dc 100644
--- a/include/configs/paz00.h
+++ b/include/configs/paz00.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2010,2011, NVIDIA CORPORATION. All rights reserved.
+ * Copyright (c) 2010-2012 NVIDIA CORPORATION. All rights reserved.
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -20,6 +20,11 @@
#include asm/sizes.h
#include tegra2-common.h
+/* Enable fdt support for Paz00. Flash the image in u-boot-dtb.bin */
+#define CONFIG_DEFAULT_DEVICE_TREE tegra2-paz00
+#define CONFIG_OF_CONTROL
+#define CONFIG_OF_SEPARATE
+
/* High-level configuration options */
#define V_PROMPT Tegra2 (Paz00) MOD #
#define CONFIG_TEGRA2_BOARD_STRING Compal Paz00
@@ -48,6 +53,21 @@
/* Environment not stored */
#define CONFIG_ENV_IS_NOWHERE
+/* USB Host support */
+#define CONFIG_USB_EHCI
+#define CONFIG_USB_EHCI_TEGRA
+#define CONFIG_USB_STORAGE
+#define CONFIG_CMD_USB
+
+/* USB networking support */
+#define CONFIG_USB_HOST_ETHER
+#define CONFIG_USB_ETHER_SMSC95XX
+#define CONFIG_USB_ETHER_ASIX
+
+/* General networking support */
+#define CONFIG_CMD_NET
+#define CONFIG_CMD_DHCP
+
#include tegra2-common-post.h
#endif /* __CONFIG_H */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: paz00: add device tree support
On Tuesday 22 May 2012 10:58:37 Stephen Warren wrote: On 05/22/2012 10:14 AM, Stephen Warren wrote: On 05/22/2012 02:04 AM, Marc Dietrich wrote: Hi Stephen, Am Montag, 21. Mai 2012, 14:04:37 schrieb Stephen Warren: From: Stephen Warren swar...@nvidia.com ... to enable USB host support, which enables Ethernet support. Signed-off-by: Stephen Warren swar...@nvidia.com while adding usb support is fine, I see no reason to add smsc95xx support because contrary to harmony, paz00 does not contain an ethernet port. Is the SMSC95xx only an internal part, or could it be present on a user-pluggable USB dongle? I wasn't sure, so I left it in. Looking at the driver (and the Linux kernel driver and SMSC's website), it supports both the standalone USB-Ethernet 9500 chip that's likely to be in USB Ethernet dongles, and various combo USB hub + Ethernet chips that are found on motherboards (e.g. Harmony). As such, I think it's reasonable to leave this config option enabled on Paz00 and other Tegra boards even when such a chip isn't on the board itself. Do you agree? Following this argument would mean to enable all current (and future) usb devices and we end up with an u-boot which is to heavy to swim. I only have a mcs7830 which is unfortunately not supported. Do you have a SMSC95xx based usb adapter or plan to get one? In this case I think it would be ok to enable it, otherwise I tend to disagree here. On the other hand, given that you kindly take care of the paz00 code, the decision is up to you. Just my two cents, Marc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 19/23] tegra: Add EMC settings for Seaboard
Am Montag, 9. April 2012, 21:51:32 schrieb Stephen Warren:
On 04/09/2012 05:07 PM, Simon Glass wrote:
Hi Stephen,
On Mon, Apr 9, 2012 at 3:03 PM, Olof Johansson o...@lixom.net wrote:
On Mon, Apr 9, 2012 at 2:59 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 04/09/2012 03:40 PM, Simon Glass wrote:
+Olof
Hi Stephen,
On Mon, Apr 9, 2012 at 2:27 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 04/05/2012 03:55 PM, Simon Glass wrote:
From: Jimmy Zhang jimmzh...@nvidia.com
Set Seaboard to optimal memory settings based on the SOC in use (T20
or T25).
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Move EMC tables to device tree
- Removed check for nominal voltage (not needed as it is done just
before)
Changes in v3:
- Add better error reporting when EMC setup fails
Changes in v4:
- Remove support for T20 memory timings
diff --git a/board/nvidia/common/emc.c b/board/nvidia/common/emc.c
+/* This rate is hard-coded for now, until fdt provides them */
+#define EMC_SDRAM_RATE_T25 (38 * 2 * 1000)
+
+int board_emc_init(void)
+{
+ unsigned rate;
+
+ switch (tegra_get_chip_type()) {
+ default:
+ case TEGRA_SOC_T20:
+ debug(%s: EMC timings not supported for T20
Seaboard\n,
+ __func__);
This isn't Seaboard-specific code, so the string shouldn't say
Seaboard there.
Why not support Tegra20? Many/all of the other Tegra boards U-Boot
supports are Tegra20 not Tegra25.
Presumably this code doesn't blow up if the EMC tables aren't in the
.dts file; the code should use the tables if they're present,
otherwise
be a no-op.
I don't mind, we can either go with v3 (with T20) or v4 (without).
Both sets of patches are on the list and the removable of T20 support
is the only change in v4. Please can you discuss this with Olof?
IIRC, Olof objected to the incorrect Seaboard .dts file (which contained
two unrelated sets of EMC tables for different board variants), not the
ability for the EMC driver itself to function on either Tegra20 or
Tegra25.
Correct. I objected to the one device tree describing 50% inaccurate
contents without a documented way to tell the accurate from inaccurate
(unlike the case with bootid straps).
What we do on the kernel side is that if the existing programming,
i.e. what's setup by BCT/u-boot is not matching the clocks in the
table, then we report it but continue with the existing settings. If
someone passes in bogus (matching) data in both BCT and the device
tree then all bets are off.
OK, that's different from what I understood (remove support for T20
Seaboard as was apparently done in the kernel). So I think this means
that this patch should revert back to the original version, right?
In the kernel, the Seaboard .dts file only supports Tegra25 since the
EMC tables we put into that .dts file are for Tegra25. There is no
Seaboard-with-Tegra20 .dts file.
I don't believe the EMC driver has any code that cares about
Tegra20-vs-Tegra25, so should work just fine for either.
In practice, we don't have any .dts files for boards with Tegra20 that
contain EMC tables though.
well, that may change in the future. In fact, I have a EMC table here for
paz00, but only for 333 MHz. I like to submit them once I got 166 MHz values.
Marc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/3] tegra2: Add paz00 support
On Sunday 20 November 2011 13:05:58 Thierry Reding wrote: * Stephen Warren wrote: This patch series adds support for the Toshiba AC100 Tegra netbook. I'm posting it as an RFC because: a) The AC100 is designed by Compal and marketed by Toshiba. Should we put the files into board/nvidia (since it uses an NVIDIA SoC), or create a board/toshiba or board/compal directory to contain this? I don't think it should go into board/nvidia. Directories below board are supposed to be vendor directories and NVIDIA isn't the vendor of the AC100. I have a slight tendency for preferring toshiba over compal mostly because I think that's what people will be looking for first. we had this discussion during addition of devicetree support to paz00 in the linux kernel already. The balance tended more into the direction of Compal, because 1) there exist two machines with different names with this board (Toshiba AC100 and Dynabook AZ) and 2) Toshibas/Dynabooks code name seems to be Procyon while paz00 is the code name at Compal. Having compal/paz00 in the kernel and Toshiba/procyon in u-boot would just add confusion and renaming everything is maybe not worth the effort (Toshiba/paz00 is totaly wrong). Marc b) It'll need rebasing on top of some of the many outstanding Tegra patches before it can be applied. Stephen Warren (3): MAINTAINERS: Fix my email address tegra2: Fix conflicting pinmux for UARTA tegra2: Add support for Paz00 (Toshiba AC100) MAINTAINERS |3 +- board/nvidia/common/board.c | 12 ++ board/nvidia/paz00/Makefile | 49 board/nvidia/paz00/paz00.c | 88 +++ boards.cfg |1 + include/configs/paz00.h | 59 + 6 files changed, 211 insertions(+), 1 deletions(-) create mode 100644 board/nvidia/paz00/Makefile create mode 100644 board/nvidia/paz00/paz00.c create mode 100644 include/configs/paz00.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/3] tegra2: Add support for Paz00 (Toshiba AC100)
Hi Stephen, first, thanks for looking at this! On Sunday 20 November 2011 13:10:08 Thierry Reding wrote: * Stephen Warren wrote: The Toshiba AC100 (code-name Paz00m a/k/a Dynabook AZ) is an netbook derived from the NVIDIA Tegra Harmony reference board. It ships with Ubuntu, but is often repurposed to run Linux. This patch adds just enough support to get a U-Boot serial console, and the ability access built-in eMMC and the external SD slot. FIXME: Since this board is not marketed by NVIDIA (Toshiba is the vendor, and Compal the ODM), this board should possibly be moved out of the board/nvidia directory. Signed-off-by: Stephen Warren swar...@nvidia.com --- MAINTAINERS |1 + board/nvidia/paz00/Makefile | 41 ++ board/nvidia/paz00/paz00.c | 81 +++ boards.cfg |1 + include/configs/paz00.h | 52 +++ 5 files changed, 176 insertions(+), 0 deletions(-) create mode 100644 board/nvidia/paz00/Makefile create mode 100644 board/nvidia/paz00/paz00.c create mode 100644 include/configs/paz00.h [...] diff --git a/include/configs/paz00.h b/include/configs/paz00.h new file mode 100644 index 000..fcec6fa --- /dev/null +++ b/include/configs/paz00.h @@ -0,0 +1,52 @@ +/* + * Copyright (c) 2010,2011, NVIDIA CORPORATION. All rights reserved. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + * + * This program is distributed in the hope it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + */ + +#ifndef __CONFIG_H +#define __CONFIG_H + +#include asm/sizes.h +#include tegra2-common.h + +/* High-level configuration options */ +#define TEGRA2_SYSMEM mem=384M@0M nvmem=128M@384M Can we get rid of this? I think I remember some discussion about the same topic going on the linux-tegra/devicetree mailing lists, where it was decided that /mem-reserve/ entries should be dropped until some driver in the mainline kernel was actually going to use this memory. Perhaps U-Boot should take the same approach. I also vote for this. Additionally, most users prefer mem=448M here. The device was original ships with 448 MB user memory, which was later reduced to 384 MB, maybe because of flash player requirements. I'm also not sure if nvmem is needed at all (maybe for android original kernel only) +#define V_PROMPT Tegra2 (Paz00) # +#define CONFIG_TEGRA2_BOARD_STRING NVIDIA Paz00 + +/* Board-specific serial config */ +#define CONFIG_SERIAL_MULTI +#define CONFIG_TEGRA2_ENABLE_UARTA +#define CONFIG_SYS_NS16550_COM1NV_PA_APB_UARTA_BASE + +#define CONFIG_MACH_TYPE MACH_TYPE_PAZ00 +/* + * The following should be 512MB, but I don't know how to set that value + * It doesn't matter, since this isn't really used any more + */ +#define CONFIG_SYS_BOARD_ODMDATA 0x200d8011 /* lp1, 1GB */ I don't know what is the effect of this paramter, but paz00 has 512 MB. The original valu was 0x8000c0085, AFAIK, which leaves most stuff on the default value. Marc + +#define CONFIG_BOARD_EARLY_INIT_F + +/* SD/MMC */ +#define CONFIG_MMC +#define CONFIG_GENERIC_MMC +#define CONFIG_TEGRA2_MMC +#define CONFIG_CMD_MMC + +#define CONFIG_DOS_PARTITION +#define CONFIG_EFI_PARTITION +#define CONFIG_CMD_EXT2 +#define CONFIG_CMD_FAT +#endif /* __CONFIG_H */ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
