This is just enough to get the device booting and serial console
working. Sufficient for debugging further MSM7k/Dream Support.
This will support HTC Dream / T-Mobile G1 / Android ADP1 (which
are all the same hardware, known as "trout" to the ARM machine
database).
Signed-off-by: Brian Swetland <[email protected]>
Reviewed-by: GeunSik Lim <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
---
arch/arm/mach-msm/Kconfig | 6 +++
arch/arm/mach-msm/Makefile | 1 +
arch/arm/mach-msm/board-dream.c | 84 +++++++++++++++++++++++++++++++++++++++
arch/arm/mach-msm/board-dream.h | 5 ++
4 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-msm/board-dream.c
create mode 100644 arch/arm/mach-msm/board-dream.h
diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
index 35f2a90..f780086 100644
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@ -34,4 +34,10 @@ config MACH_HALIBUT
help
Support for the Qualcomm SURF7201A eval board.
+config MACH_TROUT
+ default y
+ bool "HTC Dream (aka trout)"
+ help
+ Support for the HTC Dream, T-Mobile G1, Android ADP1 devices.
+
endif
diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index 1aa4700..91e6f5c 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -6,3 +6,4 @@ obj-y += clock.o clock-7x01a.o
obj-$(CONFIG_MACH_HALIBUT) += board-halibut.o
+obj-$(CONFIG_MACH_TROUT) += board-dream.o
diff --git a/arch/arm/mach-msm/board-dream.c b/arch/arm/mach-msm/board-dream.c
new file mode 100644
index 0000000..6eae7e3
--- /dev/null
+++ b/arch/arm/mach-msm/board-dream.c
@@ -0,0 +1,84 @@
+/* linux/arch/arm/mach-msm/board-dream.c
+ *
+ * Copyright (C) 2009 Google, Inc.
+ * Author: Brian Swetland <[email protected]>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+
+#include <mach/board.h>
+#include <mach/hardware.h>
+#include <mach/msm_iomap.h>
+
+#include "devices.h"
+#include "board-dream.h"
+
+static struct platform_device *devices[] __initdata = {
+ &msm_device_uart3,
+ &msm_device_smd,
+ &msm_device_nand,
+ &msm_device_hsusb,
+ &msm_device_i2c,
+};
+
+extern struct sys_timer msm_timer;
+
+static void __init trout_init_irq(void)
+{
+ msm_init_irq();
+}
+
+static void __init trout_init(void)
+{
+ platform_add_devices(devices, ARRAY_SIZE(devices));
+}
+
+static struct map_desc trout_io_desc[] __initdata = {
+ {
+ .virtual = TROUT_CPLD_BASE,
+ .pfn = __phys_to_pfn(TROUT_CPLD_START),
+ .length = TROUT_CPLD_SIZE,
+ .type = MT_DEVICE_NONSHARED
+ }
+};
+
+static void __init trout_map_io(void)
+{
+ msm_map_common_io();
+ iotable_init(trout_io_desc, ARRAY_SIZE(trout_io_desc));
+
+#ifdef CONFIG_MSM_DEBUG_UART3
+ /* route UART3 to the "H2W" extended usb connector */
+ writeb(0x80, TROUT_CPLD_BASE + 0x00);
+#endif
+
+ msm_clock_init();
+}
+
+MACHINE_START(TROUT, "HTC Dream")
+#ifdef CONFIG_MSM_DEBUG_UART
+ .phys_io = MSM_DEBUG_UART_PHYS,
+ .io_pg_offst = ((MSM_DEBUG_UART_BASE) >> 18) & 0xfffc,
+#endif
+ .boot_params = 0x10000100,
+ .map_io = trout_map_io,
+ .init_irq = trout_init_irq,
+ .init_machine = trout_init,
+ .timer = &msm_timer,
+MACHINE_END
diff --git a/arch/arm/mach-msm/board-dream.h b/arch/arm/mach-msm/board-dream.h
new file mode 100644
index 0000000..4f345a5
--- /dev/null
+++ b/arch/arm/mach-msm/board-dream.h
@@ -0,0 +1,5 @@
+
+#define TROUT_CPLD_BASE 0xE8100000
+#define TROUT_CPLD_START 0x98000000
+#define TROUT_CPLD_SIZE SZ_4K
+
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, Nov 02, 2009 at 11:49:49AM +0100, Pavel Machek wrote:
> +MACHINE_START(TROUT, "HTC Dream")
> +#ifdef CONFIG_MSM_DEBUG_UART
> + .phys_io = MSM_DEBUG_UART_PHYS,
> + .io_pg_offst = ((MSM_DEBUG_UART_BASE) >> 18) & 0xfffc,
> +#endif
Why is this ifdef'd? Two reasons why not to do this:
1. MSM_DEBUG_UART is always defined, so the conditional is pointless
2. the low level page table building code does not expect these to be
unset (or even set to an invalid value). Leaving them unset and
having DEBUG_LL enabled is a recipe to prevent booting.
To put it another way, these two fields aren't optional.
On Mon, Nov 16, 2009 at 8:36 AM, Russell King - ARM Linux
<[email protected]> wrote:
> On Mon, Nov 02, 2009 at 11:49:49AM +0100, Pavel Machek wrote:
>> +MACHINE_START(TROUT, "HTC Dream")
>> +#ifdef CONFIG_MSM_DEBUG_UART
>> + .phys_io = MSM_DEBUG_UART_PHYS,
>> + .io_pg_offst = ((MSM_DEBUG_UART_BASE) >> 18) & 0xfffc,
>> +#endif
>
> Why is this ifdef'd? Two reasons why not to do this:
>
> 1. MSM_DEBUG_UART is always defined, so the conditional is pointless
For a default dream build, definitely, but not always on every msm7k
target (some devices may not have a serial port that can safely be
chattered at by the debug code). For this board file, no harm to
require it.
> 2. the low level page table building code does not expect these to be
> unset (or even set to an invalid value). Leaving them unset and
> having DEBUG_LL enabled is a recipe to prevent booting.
What's the best way to handle a situation where there is no valid
debug uart? Could the arch/platform require DEBUG_LL be unset via
Kconfig directives if it is configured in a way where there is no
valid debug uart?
> To put it another way, these two fields aren't optional.
>
Thanks,
Brian
On Mon, Nov 16, 2009 at 08:43:20AM -0800, Brian Swetland wrote:
> What's the best way to handle a situation where there is no valid
> debug uart? Could the arch/platform require DEBUG_LL be unset via
> Kconfig directives if it is configured in a way where there is no
> valid debug uart?
You're the first to have that issue. Everyone else has a UART they
can always direct stuff at.
However, I believe you're making the issue far larger than it really is.
1. If you define the DEBUG_LL macros to be empty, printascii() etc will
not touch any mapping.
2. If no mapping is going to be touched by printascii(), does it matter
whether a UART is mapped via this early mapping stuff?
The answer to (2) is no.
So, you can still arrange for these fields to be populated with a valid
value even if you don't intend to use the resulting mapping. And so
there's no need to force DEBUG_LL to be unset.
If you really have no values you can use, make sure you set io_pg_offst
to 0x3ffc - the last offset in the L1 page table. This will cause the
code to write a single dummy entry at the very top of the page table,
which will then be overwritten by the generic ARM arch code for its own
use.
On Mon, Nov 16, 2009 at 8:57 AM, Russell King - ARM Linux
<[email protected]> wrote:
> On Mon, Nov 16, 2009 at 08:43:20AM -0800, Brian Swetland wrote:
>> What's the best way to handle a situation where there is no valid
>> debug uart? Could the arch/platform require DEBUG_LL be unset via
>> Kconfig directives if it is configured in a way where there is no
>> valid debug uart?
>
> You're the first to have that issue. Everyone else has a UART they
> can always direct stuff at.
>
> However, I believe you're making the issue far larger than it really is.
I actually haven't run into it on the hardware I've worked on (often
the debug uart isn't exposed anywhere useful, but it's usually there),
but have seen designs where it would happen (all uarts assigned to
some non-debug function). Just curious about how to deal with such a
situation correctly.
> 1. If you define the DEBUG_LL macros to be empty, printascii() etc will
> not touch any mapping.
>
> 2. If no mapping is going to be touched by printascii(), does it matter
> whether a UART is mapped via this early mapping stuff?
>
> The answer to (2) is no.
>
> So, you can still arrange for these fields to be populated with a valid
> value even if you don't intend to use the resulting mapping. And so
> there's no need to force DEBUG_LL to be unset.
>
> If you really have no values you can use, make sure you set io_pg_offst
> to 0x3ffc - the last offset in the L1 page table. This will cause the
> code to write a single dummy entry at the very top of the page table,
> which will then be overwritten by the generic ARM arch code for its own
> use.
Pointing it at UART1 with the DEBUG_LL macros empty in the event of no
debug uart available works great.
Thanks,
Brian
Russell King - ARM Linux <[email protected]> writes:
> On Mon, Nov 16, 2009 at 08:43:20AM -0800, Brian Swetland wrote:
>> What's the best way to handle a situation where there is no valid
>> debug uart? Could the arch/platform require DEBUG_LL be unset via
>> Kconfig directives if it is configured in a way where there is no
>> valid debug uart?
>
> You're the first to have that issue. Everyone else has a UART they
> can always direct stuff at.
Just for the record, there are machine files without a debug UART, especially in
the smartphone area.
In the PXA subworld I know, the UARTs are often used for :
- a GSM chip (pxa ffuart)
- a Bluetooth chip (pxa btuart)
- a GPS chip (pxa stuart / hwuart)
- an IR chip (pxa stuart / hwuart)
I didn't check through the mach-pxa/*.c, but mioa701.c accounts for one, and I
think magician and hx4700 would be part of it too. That also means kernel
debugging is _really_ painfull for these platforms.
Cheers.
--
Robert