* [U-Boot] [PATCH v3 2/8] tegra2: Simplify tegra_start() boot path
From: Simon Glass @ 2011-10-31 22:03 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320098592-21425-1-git-send-email-sjg@chromium.org>
The Tegra2 boot path is more complicated than it needs to be. Since we want
to move to building most of U-Boot with ARMv7 and only a small part with
ARMv4T (for AVP) it should be as simple as possible.
This makes tegra2_start() into a simple function which either does AVP
init or A9 init depending on which core is running it. Both cores now
following the same init path, beginning at _start, and the special Tegra2
boot path code is no longer required.
Only two files need to be built for ARMv4T, and this is handled in the
Tegra2 CPU Makefile.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
arch/arm/cpu/armv7/tegra2/Makefile | 5 +++
arch/arm/cpu/armv7/tegra2/ap20.c | 54 +++++++++++++++++++----------------
arch/arm/cpu/armv7/tegra2/ap20.h | 3 ++
3 files changed, 37 insertions(+), 25 deletions(-)
diff --git a/arch/arm/cpu/armv7/tegra2/Makefile b/arch/arm/cpu/armv7/tegra2/Makefile
index f0dc2ff..955c3b6 100644
--- a/arch/arm/cpu/armv7/tegra2/Makefile
+++ b/arch/arm/cpu/armv7/tegra2/Makefile
@@ -23,6 +23,11 @@
# MA 02111-1307 USA
#
+# The AVP is ARMv4T architecture so we must use special compiler
+# flags for any startup files it might use.
+CFLAGS_arch/arm/cpu/armv7/tegra2/ap20.o += -march=armv4t
+CFLAGS_arch/arm/cpu/armv7/tegra2/clock.o += -march=armv4t
+
include $(TOPDIR)/config.mk
LIB = $(obj)lib$(SOC).o
diff --git a/arch/arm/cpu/armv7/tegra2/ap20.c b/arch/arm/cpu/armv7/tegra2/ap20.c
index 5cb4b1b..4c44bb3 100644
--- a/arch/arm/cpu/armv7/tegra2/ap20.c
+++ b/arch/arm/cpu/armv7/tegra2/ap20.c
@@ -31,7 +31,12 @@
#include <asm/arch/scu.h>
#include <common.h>
-u32 s_first_boot = 1;
+/* Returns 1 if the current CPU executing is a Cortex-A9, else 0 */
+static int ap20_cpu_is_cortexa9(void)
+{
+ u32 id = readb(NV_PA_PG_UP_BASE + PG_UP_TAG_0);
+ return id == (PG_UP_TAG_0_PID_CPU & 0xff);
+}
void init_pllx(void)
{
@@ -283,38 +288,37 @@ void init_pmc_scratch(void)
writel(CONFIG_SYS_BOARD_ODMDATA, &pmc->pmc_scratch20);
}
-void cpu_start(void)
+void tegra2_start(void)
{
struct pmux_tri_ctlr *pmt = (struct pmux_tri_ctlr *)NV_PA_APB_MISC_BASE;
- /* enable JTAG */
- writel(0xC0, &pmt->pmt_cfg_ctl);
+ /* If we are the AVP, start up the first Cortex-A9 */
+ if (!ap20_cpu_is_cortexa9()) {
+ /* enable JTAG */
+ writel(0xC0, &pmt->pmt_cfg_ctl);
- if (s_first_boot) {
/*
- * Need to set this before cold-booting,
- * otherwise we'll end up in an infinite loop.
- */
- s_first_boot = 0;
- cold_boot();
+ * If we are ARM7 - give it a different stack. We are about to
+ * start up the A9 which will want to use this one.
+ */
+ asm volatile("ldr sp, =%c0\n"
+ : : "i"(AVP_EARLY_BOOT_STACK_LIMIT));
+
+ start_cpu((u32)_start);
+ halt_avp();
+ /* not reached */
}
-}
-void tegra2_start()
-{
- if (s_first_boot) {
- /* Init Debug UART Port (115200 8n1) */
- uart_init();
+ /* Init PMC scratch memory */
+ init_pmc_scratch();
- /* Init PMC scratch memory */
- init_pmc_scratch();
- }
+ enable_scu();
-#ifdef CONFIG_ENABLE_CORTEXA9
- /* take the mpcore out of reset */
- cpu_start();
+ /* enable SMP mode and FW for CPU0, by writing to Auxiliary Ctl reg */
+ asm volatile(
+ "mrc p15, 0, r0, c1, c0, 1\n"
+ "orr r0, r0, #0x41\n"
+ "mcr p15, 0, r0, c1, c0, 1\n");
- /* configure cache */
- cache_configure();
-#endif
+ /* FIXME: should have ap20's L2 disabled too? */
}
diff --git a/arch/arm/cpu/armv7/tegra2/ap20.h b/arch/arm/cpu/armv7/tegra2/ap20.h
index 49fe340..1bb48d6 100644
--- a/arch/arm/cpu/armv7/tegra2/ap20.h
+++ b/arch/arm/cpu/armv7/tegra2/ap20.h
@@ -102,3 +102,6 @@ void uart_init(void);
void udelay(unsigned long);
void cold_boot(void);
void cache_configure(void);
+
+/* This is the main entry into U-Boot, used by the Cortex-A9 */
+extern void _start(void);
--
1.7.3.1
^ permalink raw reply related
* [U-Boot] [PATCH v3 1/8] tegra2: Add arch_cpu_init() to fire up Cortex-A9
From: Simon Glass @ 2011-10-31 22:03 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320098592-21425-1-git-send-email-sjg@chromium.org>
We want to move away from a special Tegra2 start-up, and just use
arch_cpu_init() instead. However, if we run board_init_f() from boot
we need to build it for ARMv4T, since the Tegra's AVP start-up CPU
does not support ARMv7.
The effect of this is to do the AVP init earlier, and in
arch_cpu_init(), rather that board_early_init_f().
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Move Makefile armv4t flags from arch/arm/lib to Tegra's config.mk
arch/arm/cpu/armv7/tegra2/board.c | 15 +++++++++++++++
arch/arm/cpu/armv7/tegra2/config.mk | 6 ++++++
board/nvidia/common/board.c | 3 ---
board/nvidia/common/board.h | 1 -
include/configs/tegra2-common.h | 1 +
5 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv7/tegra2/board.c b/arch/arm/cpu/armv7/tegra2/board.c
index 751102d..4530194 100644
--- a/arch/arm/cpu/armv7/tegra2/board.c
+++ b/arch/arm/cpu/armv7/tegra2/board.c
@@ -23,6 +23,7 @@
#include <common.h>
#include <asm/io.h>
+#include "ap20.h"
#include <asm/arch/sys_proto.h>
#include <asm/arch/tegra2.h>
#include <asm/arch/pmc.h>
@@ -86,3 +87,17 @@ int checkboard(void)
return 0;
}
#endif /* CONFIG_DISPLAY_BOARDINFO */
+
+#ifdef CONFIG_ARCH_CPU_INIT
+/*
+ * Note this function is executed by the ARM7TDMI AVP. It does not return
+ * in this case. It is also called once the A9 starts up, but does nothing in
+ * that case.
+ */
+int arch_cpu_init(void)
+{
+ /* Fire up the Cortex A9 */
+ tegra2_start();
+ return 0;
+}
+#endif
diff --git a/arch/arm/cpu/armv7/tegra2/config.mk b/arch/arm/cpu/armv7/tegra2/config.mk
index 96c0795..f84fdc8 100644
--- a/arch/arm/cpu/armv7/tegra2/config.mk
+++ b/arch/arm/cpu/armv7/tegra2/config.mk
@@ -26,3 +26,9 @@
# Use ARMv4 for Tegra2 - initial code runs on the AVP, which is an ARM7TDI.
PLATFORM_CPPFLAGS += -march=armv4
+
+# Tegra has an ARMv4T CPU which runs board_init_f(), so we must build this
+# file with compatible flags
+ifdef CONFIG_TEGRA2
+CFLAGS_arch/arm/lib/board.o += -march=armv4t
+endif
diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
index 0f12de2..56850cc 100644
--- a/board/nvidia/common/board.c
+++ b/board/nvidia/common/board.c
@@ -125,9 +125,6 @@ int board_early_init_f(void)
/* Initialize periph GPIOs */
gpio_config_uart();
-
- /* Init UART, scratch regs, and start CPU */
- tegra2_start();
return 0;
}
#endif /* EARLY_INIT */
diff --git a/board/nvidia/common/board.h b/board/nvidia/common/board.h
index 35acbca..1f57086 100644
--- a/board/nvidia/common/board.h
+++ b/board/nvidia/common/board.h
@@ -24,7 +24,6 @@
#ifndef _BOARD_H_
#define _BOARD_H_
-void tegra2_start(void);
void gpio_config_uart(void);
int tegra2_mmc_init(int dev_index, int bus_width, int pwr_gpio, int cd_gpio);
diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h
index a9c665c..bdf7eab 100644
--- a/include/configs/tegra2-common.h
+++ b/include/configs/tegra2-common.h
@@ -35,6 +35,7 @@
#define CONFIG_SYS_CACHELINE_SIZE 32
+#define CONFIG_ARCH_CPU_INIT /* Fire up the A9 core */
#define CONFIG_ENABLE_CORTEXA9 /* enable CPU (A9 complex) */
#include <asm/arch/tegra2.h> /* get chip and board defs */
--
1.7.3.1
^ permalink raw reply related
* [U-Boot] [PATCH v3 0/8] tegra2: Tidy up boot path
From: Simon Glass @ 2011-10-31 22:03 UTC (permalink / raw)
To: u-boot
On Tegra2 the AVP runs the normal U-Boot code to a point, then halts and
the A9 takes over. The current Tegra2 boot path is fairly complex, since it
has a separate path and code for the Cortex-A9 and the AVP. In fact, they
can largely execute the same code path.
This series cleans up this logic and removes some parallel and un-needed
code.
Changes in v2:
- Move Makefile armv4t flags from arch/arm/lib to Tegra's config.mk
- Keep Tegra's config.mk file around so we can set the armv4t flags
Changes in v3:
- Update comment and also make it match style
- Fix cpu_init_cp15() name
- Remove exporting of cpu_init_cp15() from start.S
- Add test for ARMv7 CPU and skip CP15 init if not found
- Add lowlevel_init function back in (though it does nothing)
- Remove later CP15 init in board.c since this is not needed now
- Rebase against master (due to CONFIG_SYS_CACHELINE_SIZE series)
Simon Glass (8):
tegra2: Add arch_cpu_init() to fire up Cortex-A9
tegra2: Simplify tegra_start() boot path
arm: Only do CP15 init on ARMv7
tegra2: Remove unneeded boot code
tegra2: Remove unneeded config option
tegra2: Remove unused low-level Tegra2 UART code
tegra2: Remove unneeded 'dynamic ram size' message
tegra2: Don't use board pointer before it is set up
arch/arm/cpu/armv7/start.S | 57 ++++++--------
arch/arm/cpu/armv7/tegra2/Makefile | 5 +
arch/arm/cpu/armv7/tegra2/ap20.c | 54 +++++++------
arch/arm/cpu/armv7/tegra2/ap20.h | 10 +--
arch/arm/cpu/armv7/tegra2/board.c | 35 ++++-----
arch/arm/cpu/armv7/tegra2/config.mk | 7 +-
arch/arm/cpu/armv7/tegra2/lowlevel_init.S | 115 +----------------------------
board/nvidia/common/board.c | 3 -
board/nvidia/common/board.h | 1 -
drivers/serial/Makefile | 1 -
drivers/serial/serial_tegra2.c | 77 -------------------
drivers/serial/serial_tegra2.h | 29 -------
include/configs/tegra2-common.h | 5 +-
13 files changed, 86 insertions(+), 313 deletions(-)
delete mode 100644 drivers/serial/serial_tegra2.c
delete mode 100644 drivers/serial/serial_tegra2.h
--
1.7.3.1
^ permalink raw reply
* [U-Boot] [PATCH] cmd_bdinfo: simplify local static funcs a bit
From: Simon Glass @ 2011-10-31 21:49 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAOZdJXWjSMK0ZWxbfoww_8ZcWghicgt=tPnPtDYM7hsV2KZZ8Q@mail.gmail.com>
On Mon, Oct 31, 2011 at 2:15 PM, Tabi Timur-B04825 <B04825@freescale.com> wrote:
> On Sun, Oct 30, 2011 at 7:54 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>>
>>
>> -static void print_num(const char *, ulong);
>> +__maybe_unused
>> +static void print_num(const char *name, ulong value)
>> +{
>> + ? ? ? printf("%-12s= 0x%08lX\n", name, value);
>> +}
>>
>
> Will the linker remove the functions from the binary if they are unusued?
If built with -ffunction-sections and --gc-sections,, then the linker
can do this sort of thing. Otherwise it can't, but the compiler can. I
just tested Mike's code on my ARM compiler to make sure and it happily
removed print_eth() when it was not used.
Regards,
Simon
>
> --
> Timur Tabi
> Linux kernel developer at Freescale
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
^ permalink raw reply
* [U-Boot] [PATCH 3/9] arm: Move CP15 init out of cpu_init_crit()
From: Simon Glass @ 2011-10-31 21:44 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EAD23E9.3090605@aribaud.net>
Hi Albert,
On Sun, Oct 30, 2011 at 3:16 AM, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:
> Hi Simon,
>
> Le 29/10/2011 02:36, Simon Glass a ?crit :
>>
>> Hi Albert,
>>
>> On Thu, Oct 27, 2011 at 10:09 PM, Albert ARIBAUD
>> <albert.u.boot@aribaud.net> ?wrote:
>>>
>>> Le 28/10/2011 03:43, Simon Glass a ?crit :
>>>
>>>> The test was
>>>>
>>>> ? ? ? ?mrc ? ? p15, 0, r0, c0, c0, 0 ? @ get ID register
>>>> ? ? ? ?and ? ? r0, r0, #0xf0000 ? ? ? ?@ get architecture
>>>> ? ? ? ?cmp ? ? r0, #0xf0000 ? ? ? ? ? ?@ check for> ? ?ARMv6
>>>> ? ? ? ?movne ? pc, lr ? ? ? ? ? ? ? ? ?@ else skip cache init
>>>>
>>>> Unfortunately I think it is a plain ARM7TDMI with no CP15.
>>>
>>> What about other fields in r0 right after mrc?
>>
>> I don't really understand that sentence, sorry.
>>
>> The ARM7TDMI does not have a CP15 and aborts if I try to access it.
>> Just in case there is something odd going on I checked with DSTREAM /
>> RVdebug and it definitely doesn't have a CP15. [as Ford Prefect would
>> say, I counted them twice]
>
> Ok, so debug tools do not show cp15. But tools can be tailored to what tool
> makes think is needed -- I could tell about some debugging tools that will
> not let me see all I want a core because the debug designers had finite
> resources and what I wanted was not a priority to them.
Ye of little faith...
>
> OTOH, according to ARM, ARM7DTMI is an ARMv4T architecture, and indeed cp15
> is mandatory only for ARMv6 and up, but ARM also states cp15 support was a
> de facto standard already for ARMv4.
Yes it is de facto when you have a core with that support - typically
an MMU and caches. But in that case it would have three digits, as in
ARM720T, rather than ARM7TDMI. It is definitely an ARM7TDMI (actually
-S) core in the datasheet, and there is no external CP15 block shown,
etc. (Although I can see a cache!)
>
> So I am left with the question: would the Tegra2 AVP be the only ARM
> implementation supported by U-Boot that does not have a cp15? That is
> possible, but I want direct testimony from Nividia.
No there are lots and lots of ARM7TDMIs out there, just not that many
that run U-Boot - and Linux is hard without an MMU. But even in the
U-Boot tree we have the s3c44b0 cpu which seems to be a plain
ARM7TDMI.
In terms of direct testimony, two engineers are on this thread and may
wish to chime in. The datasheet is pretty clear to me...
>
> This is why I asked about the Tegra2 TRM, or whatever Nvidia calls it, in
> case it would explicitely state if AVP has cp15 support or not. Failing
See above, it clearly states ARM7TDMI-S.
> that, I'd be ok with experimenting but through the AVP, not through
> debugging tools -- encoding a cp15 MIDR read in the U-Boot startup code,
> step through it with the debugger and see if it causes an UND or not, and if
> not, what is the hex value of r0 -- maybe that is exactly what you did, but
> I am not 100% sure it is, hence my insistence.
OK I have done this, and yes the AVP definitely takes the undef
exception when you execute:
mrc p15, 0, r0, c0, c0, 0
>
> I am especially surprised that a recent core be synthesized without a means
> for run-time core identification, especially in a design with two ARM cores.
The -S means synthesized. It does have its own method of
identification as I mentioned. There is a Tegra-specific register that
I can read.
>
>> The simplest thing I have been able to think of that does not involve
>> exceptions, differing instruction behaviour, doing the init later or
>> putting in some Tegra-specific code is to check for the existence of
>> the Q bit in the CPSR (actually APSR on ARMv7). This does seem to work
>> and I have verified both in my old 1996 ARM ARM DDI 0100B and the
>> ARMv7-A one (DDI 0406B) that from an architecture point of view this
>> should work. The Q bit is RAZ on ARMv4T.
>
> This could hep if we really cannot access the Main ID Register on the AVP.
OK, well I will send a patch set up with this change.
>
>> I believe this will cope with the Cortex-A7 / A-15 combinations and
>> possibly even Cortex-R4 / A-15 although I have not tested this. I
>> suppose we can deal with this when it becomes an issue.
>>
>> So I have redone this one patch with that in mind, and adjusted the
>> series slightly to fit with this. I will resend it when it completes
>> MAKEALL.
>>
>> I hope that this resolves the matter, but if not(!), I would very much
>> appreciate it if you could send through some actual pseudo code
>> showing what you are looking for, to avoid any confusion.
>
> Well, I just want to see if the MIDR is accessible and what its value is, so
> I want the AVP to execute
>
> ? ? ? ?mrc ? ? p15, 0, r0, c0, c0, 0
>
> The ending 0 is what selects MIDR rather than other cp15 registers -- other
> values can cause UND (and I would gladly understand that AVP goes UND for
> reading cp15 CTR for instance).
>
> The simplest test would be to insert the exact instruction above in the
> reset sequence in start.S right after SVC32 switch, debug the reset
> execution path, see if the mrc above goes UND or else check r0's contents
> after mrc is done.
OK see above, I have done this. What I meant was for you to provide a
code sequence that you want in start.S. Hopefully my patch will fit
the bill.
I am very happy for this to be rewritten/changed down the track. But
for now, and assuming you don't want to call a function to find out
whether or not CP15 exists, I have created something which seems to
solve the problem. There are many other problems to solve. I feel that
this one has had its fair share of attention!
Regards,
Simon
>
>> Thanks,
>> Simon
>
> Amicalement,
> --
> Albert.
>
^ permalink raw reply
* [U-Boot] [PATCH v2] arm: Correct build error introduced by getenv_ulong() patch
From: Mike Frysinger @ 2011-10-31 21:40 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ04KHxvyYebLHiFYta6bpqrpiGU=TJV9X6D94QnZQnFVw@mail.gmail.com>
On Monday 31 October 2011 17:06:46 Simon Glass wrote:
> On Sun, Oct 30, 2011 at 5:44 PM, Mike Frysinger wrote:
> > On Sunday 23 October 2011 23:44:35 Simon Glass wrote:
> >> --- a/arch/arm/lib/board.c
> >> +++ b/arch/arm/lib/board.c
> >>
> >> flash_size = flash_init();
> >> if (flash_size > 0) {
> >> # ifdef CONFIG_SYS_FLASH_CHECKSUM
> >> + char *s = getenv("flashchecksum");
> >> +
> >> print_size(flash_size, "");
> >> /*
> >> * Compute and print flash CRC if flashchecksum is set to
> >> 'y' *
> >> * NOTE: Maybe we should add some WATCHDOG_RESET()? XXX
> >> */
> >> - s = getenv("flashchecksum");
> >> if (s && (*s == 'y')) {
> >> printf(" CRC: %08X", crc32(0,
> >> (const unsigned char *)
> >> CONFIG_SYS_FLASH_BASE, @@ -566,9 +567,12 @@ void board_init_r(gd_t *id,
> >> ulong dest_addr) /* Initialize from environment */
> >> load_addr = getenv_ulong("loadaddr", 16, load_addr);
> >> #if defined(CONFIG_CMD_NET)
> >> - s = getenv("bootfile");
> >> - if (s != NULL)
> >> - copy_filename(BootFile, s, sizeof(BootFile));
> >> + {
> >> + char *s = getenv("bootfile");
> >> +
> >> + if (s != NULL)
> >> + copy_filename(BootFile, s, sizeof(BootFile));
> >> + }
> >> #endif
> >
> > seems like a better solution would be to use at the top:
> > __maybe_unused char *s;
> >
> > also, shouldn't these be "const char *s" ?
>
> We can certainly do this and I agree it is easier than #ifdefs. Does
> it introduce the possibility that one day the code will stop using the
> variable but it will still be declared? Is the fact that we need the
> #ifdefs an indication that the function should be too long and should
> be refactored? it in fact better to have these explicit so we can see
> them for the ugliness they are?
yes, you're right that it does leave the door open to the variable being
declared, never used, and gcc not emitting a warning about it.
both setups suck, but i'd lean towards the less-ifdef state ... wonder if
Wolfgang has a preference.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111031/948e5d8d/attachment.pgp
^ permalink raw reply
* [U-Boot] [PATCH] cmd_bdinfo: simplify local static funcs a bit
From: Mike Frysinger @ 2011-10-31 21:38 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ0Scvb2WyxcydL1PFC=x5Xggj44OCFpDPutd-XRgUWO-g@mail.gmail.com>
On Monday 31 October 2011 16:47:08 Simon Glass wrote:
> On Mon, Oct 31, 2011 at 1:44 PM, Mike Frysinger wrote:
> > On Monday 31 October 2011 15:11:35 Simon Glass wrote:
> >> On Sun, Oct 30, 2011 at 5:54 PM, Mike Frysinger wrote:
> >> > If we move the local funcs to the top of the file, and use the
> >> > __maybe_unused define, we can drop a lot of ugly ifdef logic and
> >> > duplicated prototypes.
> >> >
> >> > Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> >>
> >> This is much cleaner - is the correct style to put attribute tags on
> >> the previous line?
> >
> > when responding to add your own, there isn't any real protocol. just
> > normal e-mail etiquette (no top posting/etc...). patchwork/humans will
> > do the right thing when manually updating the changelog.
>
> Actually I meant the __maybe_unused tag before the function name.
ah. i'm not sure there is a hard rule here. i did that because one line
would make the func def too long to fit.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111031/0b6ba257/attachment.pgp
^ permalink raw reply
* [U-Boot] [PATCH 1/2] nand_spl_simple: Add omap3 DMA usage to SPL
From: Scott Wood @ 2011-10-31 21:22 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EAE62D6.5030109@gmail.com>
On 10/31/2011 03:56 AM, Simon Schwarz wrote:
> Dear Scott,
>
> On 10/25/2011 08:24 PM, Scott Wood wrote:
>> On 10/16/2011 05:10 AM, Simon Schwarz wrote:
>>> This adds DMA copy for the nand spl implementation. If CONFIG_SPL_DMA_SUPPORT
>>> is defined the DMA is used.
>>>
>>> Based on DMA driver patch:
>>> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/109744/focus=109747
>>
>> As Wolfgang pointed out, this doesn't belong here. Create your own
>> alternate SPL driver if your hardware doesn't work with the simple one
>> (similar to the not-yet-migrated nand_spl/nand_boot_fsl_elbc.c,
>> nand_spl/nand_boot_fsl_ifc.c, etc).
>>
>
> Hm. The naming of the functions was a fault. Will rename the calls in
> nand_spl_simple to remove omap parts. So
> omap3_dma_wait_for_transfer
> will become
> dma_wait_for_transfer
> etc.
>
> So a board which intents to use DMA in SPL can implement these
> functions. Would this be ok?
What would the semantics of a generic dma_wait_for_transfer() be?
I just don't see how this is generic at all, whatever the name.
> A whole new driver is IMHO not the right thing as there is too much
> duplicated code then.
So factor the common bits out into a separate file.
>>> @@ -46,11 +59,11 @@ static int nand_command(int block, int page, uint32_t offs,
>>> this->cmd_ctrl(&mtd, offs, NAND_CTRL_ALE | NAND_CTRL_CHANGE);
>>> this->cmd_ctrl(&mtd, page_addr& 0xff, NAND_CTRL_ALE); /* A[16:9] */
>>> this->cmd_ctrl(&mtd, (page_addr>> 8)& 0xff,
>>> - NAND_CTRL_ALE); /* A[24:17] */
>>> + NAND_CTRL_ALE); /* A[24:17] */
>>> #ifdef CONFIG_SYS_NAND_4_ADDR_CYCLE
>>> /* One more address cycle for devices> 32MiB */
>>> this->cmd_ctrl(&mtd, (page_addr>> 16)& 0x0f,
>>> - NAND_CTRL_ALE); /* A[28:25] */
>>> + NAND_CTRL_ALE); /* A[28:25] */
>>> #endif
>>
>> Please refrain from making random unrelated whitespace changes in a
>> patch that also makes functional changes, particularly when they are
>> extensive enough to make it hard to spot the functional changes.
>>
>> In this particular case, I think the whitespace was fine the way it was;
>> the continuation lines were nicely aligned.
>
>
> If I remember right I changed these because of checkpatch errors.
I believe checkpatch only complains when you have 8 or more spaces in a
row, which isn't the case here. I don't think there's any prohibition
on lining things up with single-column granularity.
Further, checkpatch should not be complaining about lines that you don't
touch.
Where reformatting is warranted, it should be a separate patch.
-Scott
^ permalink raw reply
* [U-Boot] (no subject)
From: Tahani Kalender @ 2011-10-31 21:21 UTC (permalink / raw)
To: u-boot
Congratulation Your Email Address Have Won ?1,000,000.00 From The ICC CRICKET WORLD CUP-2011 for prize claims Contact Dr Dennis Smith on Email: iccwcluk2 at hotmail.co.uk
Tel:+447010050861
^ permalink raw reply
* [U-Boot] [PATCH] image: Allow images to indicate they're loadable at any address
From: Simon Glass @ 2011-10-31 21:20 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319464779-23571-1-git-send-email-swarren@nvidia.com>
On Mon, Oct 24, 2011 at 6:59 AM, Stephen Warren <swarren@nvidia.com> wrote:
> The legacy uImage format includes an absolute load and entry-
> point address. When presented with a uImage in memory that
> isn't loaded at the address in the image's load address,
> U-Boot will relocate the image to its address in the header.
>
> Some payloads can actually be loaded and used at any arbitrary
> address. An example is an ARM Linux kernel zImage file. This
> is useful when sharing a single zImage across multiple boards
> with different memory layouts, or U-Boot builds with different
> ${load_addr} since sharing a single absolute load address may
> not be possible.
>
> With this config option enabled, an image header may contain a
> load address of -1/0xffffffff. This indicates the image can
> operate at any load address, and U-Boot will avoid automtically
> copying it anywhere. In this case, the entry-point field is
> specified relative to the start of the image payload.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Simon Glass <sjg@chromium.org>
> ---
> Wolfgang,
>
> This is an much simpler and less invasive alternative to my previous
> IH_TYPE_KERNEL_REL patch. If it's OK, you can ignore that patch.
>
> u-boot.bin sizes for Tegra Seaboard without/with this config option on:
>
> ? text ? ?data ? ? bss ? ? dec ? ? hex filename
> ?165858 ? ?3565 ?217016 ?386439 ? 5e587 ./u-boot
>
> with:
>
> ? text ? ?data ? ? bss ? ? dec ? ? hex filename
> ?165950 ? ?3565 ?217012 ?386527 ? 5e5df ./u-boot
>
> ?README ? ? ? ? ? ? | ? 23 +++++++++++++++++++++++
> ?common/cmd_bootm.c | ? ?4 ++++
> ?common/image.c ? ? | ? 27 +++++++++++++++++++++++++++
> ?include/image.h ? ?| ? ?4 ++++
> ?4 files changed, 58 insertions(+), 0 deletions(-)
>
^ permalink raw reply
* [U-Boot] [PATCH] cmd_bdinfo: simplify local static funcs a bit
From: Tabi Timur-B04825 @ 2011-10-31 21:15 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320022463-26410-1-git-send-email-vapier@gentoo.org>
On Sun, Oct 30, 2011 at 7:54 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>
>
> -static void print_num(const char *, ulong);
> +__maybe_unused
> +static void print_num(const char *name, ulong value)
> +{
> + ? ? ? printf("%-12s= 0x%08lX\n", name, value);
> +}
>
Will the linker remove the functions from the binary if they are unusued?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [U-Boot] Hello
From: sonia emmedy Nnu @ 2011-10-31 21:11 UTC (permalink / raw)
To: u-boot
Hello My Dear,
I am interested in you, My name is Miss Sonia, i am 24 years old young
girl,I will want us to be friends for something important which I would like
to share with you, and we will get to know each other better, I hope you
don't mind being my friend. l want you to send an email to me to my email
address so that l can give you my picture for you to know whom l am.
please i am waiting for your responds to my email address, Remember that
distance or colour does not matter but love matters a lot in life,
Your New Friend,
Miss Sonia.
.
^ permalink raw reply
* [U-Boot] [PATCH v2] arm: Correct build error introduced by getenv_ulong() patch
From: Simon Glass @ 2011-10-31 21:06 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110302044.09233.vapier@gentoo.org>
Hi Mike,
On Sun, Oct 30, 2011 at 5:44 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Sunday 23 October 2011 23:44:35 Simon Glass wrote:
>> --- a/arch/arm/lib/board.c
>> +++ b/arch/arm/lib/board.c
>>
>> ? ? ? flash_size = flash_init();
>> ? ? ? if (flash_size > 0) {
>> ?# ifdef CONFIG_SYS_FLASH_CHECKSUM
>> + ? ? ? ? ? ? char *s = getenv("flashchecksum");
>> +
>> ? ? ? ? ? ? ? print_size(flash_size, "");
>> ? ? ? ? ? ? ? /*
>> ? ? ? ? ? ? ? ?* Compute and print flash CRC if flashchecksum is set to 'y'
>> ? ? ? ? ? ? ? ?*
>> ? ? ? ? ? ? ? ?* NOTE: Maybe we should add some WATCHDOG_RESET()? XXX
>> ? ? ? ? ? ? ? ?*/
>> - ? ? ? ? ? ? s = getenv("flashchecksum");
>> ? ? ? ? ? ? ? if (s && (*s == 'y')) {
>> ? ? ? ? ? ? ? ? ? ? ? printf(" ?CRC: %08X", crc32(0,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (const unsigned char *) CONFIG_SYS_FLASH_BASE,
>> @@ -566,9 +567,12 @@ void board_init_r(gd_t *id, ulong dest_addr)
>> ? ? ? /* Initialize from environment */
>> ? ? ? load_addr = getenv_ulong("loadaddr", 16, load_addr);
>> ?#if defined(CONFIG_CMD_NET)
>> - ? ? s = getenv("bootfile");
>> - ? ? if (s != NULL)
>> - ? ? ? ? ? ? copy_filename(BootFile, s, sizeof(BootFile));
>> + ? ? {
>> + ? ? ? ? ? ? char *s = getenv("bootfile");
>> +
>> + ? ? ? ? ? ? if (s != NULL)
>> + ? ? ? ? ? ? ? ? ? ? copy_filename(BootFile, s, sizeof(BootFile));
>> + ? ? }
>> ?#endif
>
> seems like a better solution would be to use at the top:
> ? ? ? ?__maybe_unused char *s;
>
> also, shouldn't these be "const char *s" ?
> -mike
>
We can certainly do this and I agree it is easier than #ifdefs. Does
it introduce the possibility that one day the code will stop using the
variable but it will still be declared? Is the fact that we need the
#ifdefs an indication that the function should be too long and should
be refactored? it in fact better to have these explicit so we can see
them for the ugliness they are?
I'm not sure, but thought I should ask.
Regards,
Simon
^ permalink raw reply
* [U-Boot] [PATCH] cmd_bdinfo: simplify local static funcs a bit
From: Simon Glass @ 2011-10-31 20:47 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110311644.02847.vapier@gentoo.org>
Hi Mike,
On Mon, Oct 31, 2011 at 1:44 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 31 October 2011 15:11:35 Simon Glass wrote:
>> On Sun, Oct 30, 2011 at 5:54 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>> > If we move the local funcs to the top of the file, and use the
>> > __maybe_unused define, we can drop a lot of ugly ifdef logic and
>> > duplicated prototypes.
>> >
>> > Signed-off-by: Mike Frysinger <vapier@gentoo.org>
>>
>> This is much cleaner - is the correct style to put attribute tags on
>> the previous line?
>
> when responding to add your own, there isn't any real protocol. ?just normal
> e-mail etiquette (no top posting/etc...). ?patchwork/humans will do the right
> thing when manually updating the changelog.
> -mike
>
Actually I meant the __maybe_unused tag before the function name.
Regards,
Simon
^ permalink raw reply
* [U-Boot] [PATCH 3/4] EHCI: adjust for mx5
From: Jana Rapava @ 2011-10-31 20:46 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EAE5830.8050700@compulab.co.il>
2011/10/31 Igor Grinberg <grinberg@compulab.co.il>
> > +struct mxc_ulpi_regs {
> > + u8 vendor_id_low; /* 0x00 - Vendor ID lower byte */
> > + u8 vendor_id_high; /* 0x01 - Vendor ID upper byte */
> > + u8 product_id_low; /* 0x02 - Product ID lower byte */
> > + u8 product_id_high; /* 0x03 - Product ID higher byte */
> > + /* Function Control; 0x04 - 0x06 Read, 0x04 Write */
> > + u8 function_ctrl_write;
> > + u8 function_ctrl_set; /* 0x05 Set */
> > + u8 function_ctrl_clear; /* 0x06 Clear */
> > + /* Interface Control; 0x07 - 0x09 Read, 0x07 Write */
> > + u8 iface_ctrl_write;
> > + u8 iface_ctrl_set; /* 0x08 Set */
> > + u8 iface_ctrl_clear; /* 0x09 Clear */
> > + /* OTG Control; 0x0A - 0x0C Read, 0x0A Write */
> > + u8 otg_ctrl_write;
> > + u8 otg_ctrl_set; /* 0x0B Set */
> > + u8 otg_ctrl_clear; /* 0x0C Clear */
> > + /* USB Interrupt Enable Rising; 0x0D - 0x0F Read, 0x0D Write */
> > + u8 usb_ie_rising_write;
> > + u8 usb_ie_rising_set; /* 0x0E Set */
> > + u8 usb_ie_rising_clear; /* 0x0F Clear */
> > + /* USB Interrupt Enable Falling; 0x10 - 0x12 Read, 0x10 Write */
> > + u8 usb_ie_falling_write;
> > + u8 usb_ie_falling_set; /* 0x11 Set */
> > + u8 usb_ie_falling_clear; /* 0x12 Clear */
> > + u8 usb_int_status; /* 0x13 - USB Interrupt Status */
> > + u8 usb_int_latch; /* 0x14 - USB Interrupt Latch */
> > + u8 debug; /* 0x15 - Debug */
> > + /* Scratch Register; 0x16 - 0x18 Read, 0x16 Write */
> > + u8 scratch_write;
> > + u8 scratch_set; /* 0x17 Set */
> > + u8 scratch_clear; /* 0x18 Clear*/
> > +};
>
>
> These are the generic ULPI specification registers
> and not mxc specific.
> I'd expect to have them in a more generic location.
>
This would be fixed in general ULPI support patch I'm working on. It should
be ready for posting in a few days.
> --
>
Regards,
> Igor.
>
^ permalink raw reply
* [U-Boot] [PATCH] cmd_bdinfo: simplify local static funcs a bit
From: Mike Frysinger @ 2011-10-31 20:44 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ1+waUNEtw=xh5UGJApxnL2ovVgVOAt0fTGaypUKVJ+WQ@mail.gmail.com>
On Monday 31 October 2011 15:11:35 Simon Glass wrote:
> On Sun, Oct 30, 2011 at 5:54 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> > If we move the local funcs to the top of the file, and use the
> > __maybe_unused define, we can drop a lot of ugly ifdef logic and
> > duplicated prototypes.
> >
> > Signed-off-by: Mike Frysinger <vapier@gentoo.org>
>
> This is much cleaner - is the correct style to put attribute tags on
> the previous line?
when responding to add your own, there isn't any real protocol. just normal
e-mail etiquette (no top posting/etc...). patchwork/humans will do the right
thing when manually updating the changelog.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111031/5fb80343/attachment.pgp
^ permalink raw reply
* [U-Boot] [PATCH v2 5/8] nand: Merge new implementation of 1-bit ECC from Linux nand driver
From: Scott Wood @ 2011-10-31 20:15 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EAE9311.8040907@aizo.com>
On 10/31/2011 07:22 AM, Christian Hitz wrote:
> Am 29.10.2011 00:30, schrieb Scott Wood:
>> On 10/12/2011 02:32 AM, Christian Hitz wrote:
>>> [backport from linux commit 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe]
>>>
>>> This patch synchronizes the nand driver with the Linux 3.0 state.
>>>
>>> Signed-off-by: Christian Hitz <christian.hitz@aizo.com>
>>> Cc: Scott Wood <scottwood@freescale.com>
>>> ---
>>>
>>> Adds 1416 bytes to the image size.
>>
>> What does this version of the code do that warrants the code size
>> increase? This could break some SPLs.
>>
>> If it's just a speed issue, we probably want to stick with the current code.
>
> It's the rewrite for performance and support for 512 byte pages, but this is
> on the basis of the rewritten code.
Several SPLs make use of nand_ecc.c, so NACK replacing it with a larger
implementation.
We could have the new ECC implementation available as a build-time
alternative, though.
-Scott
^ permalink raw reply
* [U-Boot] Pull request for u-boot-marvell.git
From: Albert ARIBAUD @ 2011-10-31 19:35 UTC (permalink / raw)
To: u-boot
In-Reply-To: <F766E4F80769BD478052FB6533FA745D1A14DD88BA@SC-VEXCH4.marvell.com>
Hi Prafulla,
Le 31/10/2011 12:58, Prafulla Wadaskar a ?crit :
> Hi Albert
> Please pull
>
> The following changes since commit b3fee4e17f9f2c136b8fcfc1b7e575b6b3ccd66a:
> Anatolij Gustschin (1):
> ARM: dreamplug: fix compilation
>
> are available in the git repository at:
>
> u-boot-marvell.git ..BRANCH.NOT.VERIFIED..
Seems like you did the 'git request-pull' before updating
u-boot-marvell/master. :)
> Ajay Bhargav (1):
> gplugD: Fix for error:MACH_TYPE_SHEEVAD undeclared
>
> Holger Brunck (2):
> arm/km: add variable waitforne to mgcoge3un
> arm/km/mgcoge3un: enhance "waitforne" feature
>
> Michael Walle (1):
> kirkwood: define CONFIG_SYS_CACHELINE_SIZE
>
> Mike Frysinger (1):
> kirkwood: drop empty asm-offsets.s file
>
> arch/arm/include/asm/arch-kirkwood/config.h | 3 ++-
> board/keymile/km_arm/km_arm.c | 11 ++++++++++-
> include/configs/gplugd.h | 12 +++++++++++-
> include/configs/mgcoge3un.h | 2 ++
> 4 files changed, 25 insertions(+), 3 deletions(-)
> delete mode 100644 arch/arm/cpu/arm926ejs/kirkwood/asm-offsets.s
Applied to u-boot-arm/master, thanks!
> Regards...
> Prafulla . . .
Amicalement,
--
Albert.
^ permalink raw reply
* [U-Boot] [PATCH] Powerpc/DIU: Fixed the 800x600 and 1024x768 resolution bug
From: Anatolij Gustschin @ 2011-10-31 19:32 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320041994-28675-1-git-send-email-Chang-Ming.Huang@freescale.com>
On Mon, 31 Oct 2011 14:19:54 +0800
<Chang-Ming.Huang@freescale.com> wrote:
> From: Jerry Huang <Chang-Ming.Huang@freescale.com>
>
> When the resolution is set to 800x600 and 1024x768,
> but, the driver will use 1280x1024 resolution to set the DIU register
>
> Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
> ---
> drivers/video/fsl_diu_fb.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
Applied to u-boot-video/master, thanks!
Anatolij
^ permalink raw reply
* [U-Boot] [PATCH] cmd_bdinfo: simplify local static funcs a bit
From: Simon Glass @ 2011-10-31 19:11 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320022463-26410-1-git-send-email-vapier@gentoo.org>
On Sun, Oct 30, 2011 at 5:54 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> If we move the local funcs to the top of the file, and use the
> __maybe_unused define, we can drop a lot of ugly ifdef logic and
> duplicated prototypes.
>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This is much cleaner - is the correct style to put attribute tags on
the previous line?
Acked-by: Simon Glass <sjg@chromium.org>
> ---
> ?common/cmd_bdinfo.c | ? 89 ++++++++++++++++++--------------------------------
> ?1 files changed, 32 insertions(+), 57 deletions(-)
>
^ permalink raw reply
* [U-Boot] [PATCH] ARM: define CONFIG_MACH_TYPE for all ronetix boards
From: Asen Chavdarov Dimov @ 2011-10-31 18:54 UTC (permalink / raw)
To: u-boot
Signed-off-by: Asen Chavdarov Dimov <dimov@ronetix.at>
---
board/ronetix/pm9261/pm9261.c | 3 ---
board/ronetix/pm9263/pm9263.c | 3 ---
board/ronetix/pm9g45/pm9g45.c | 2 --
include/configs/pm9261.h | 3 +++
include/configs/pm9263.h | 3 +++
include/configs/pm9g45.h | 3 +++
6 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/board/ronetix/pm9261/pm9261.c b/board/ronetix/pm9261/pm9261.c
index 871b94a..b26e33a 100644
--- a/board/ronetix/pm9261/pm9261.c
+++ b/board/ronetix/pm9261/pm9261.c
@@ -248,9 +248,6 @@ int board_init(void)
1 << ATMEL_ID_PIOC,
&pmc->pcer);
- /* arch number of PM9261-Board */
- gd->bd->bi_arch_number = MACH_TYPE_PM9261;
-
/* adress of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
diff --git a/board/ronetix/pm9263/pm9263.c b/board/ronetix/pm9263/pm9263.c
index cfc9847..b0f7ea6 100644
--- a/board/ronetix/pm9263/pm9263.c
+++ b/board/ronetix/pm9263/pm9263.c
@@ -349,9 +349,6 @@ int board_init(void)
(1 << ATMEL_ID_PIOB),
&pmc->pcer);
- /* arch number of AT91SAM9263EK-Board */
- gd->bd->bi_arch_number = MACH_TYPE_PM9263;
-
/* adress of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
diff --git a/board/ronetix/pm9g45/pm9g45.c b/board/ronetix/pm9g45/pm9g45.c
index f3374a4..961d193 100644
--- a/board/ronetix/pm9g45/pm9g45.c
+++ b/board/ronetix/pm9g45/pm9g45.c
@@ -139,8 +139,6 @@ int board_init(void)
(1 << ATMEL_ID_PIOC) |
(1 << ATMEL_ID_PIODE), &pmc->pcer);
- /* arch number of AT91SAM9M10G45EK-Board */
- gd->bd->bi_arch_number = MACH_TYPE_PM9G45;
/* adress of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
diff --git a/include/configs/pm9261.h b/include/configs/pm9261.h
index 89e17b8..55455e7 100644
--- a/include/configs/pm9261.h
+++ b/include/configs/pm9261.h
@@ -52,6 +52,9 @@
#undef CONFIG_USE_IRQ /* we don't need IRQ/FIQ stuff */
#define CONFIG_SYS_TEXT_BASE 0
+#define MACH_TYPE_PM9261 1187
+#define CONFIG_MACH_TYPE MACH_TYPE_PM9261
+
/* clocks */
/* CKGR_MOR - enable main osc. */
#define CONFIG_SYS_MOR_VAL \
diff --git a/include/configs/pm9263.h b/include/configs/pm9263.h
index 1f7543c..43104a3 100644
--- a/include/configs/pm9263.h
+++ b/include/configs/pm9263.h
@@ -52,6 +52,9 @@
#undef CONFIG_USE_IRQ /* we don't need IRQ/FIQ stuff */
#define CONFIG_SYS_TEXT_BASE 0
+#define MACH_TYPE_PM9263 1475
+#define CONFIG_MACH_TYPE MACH_TYPE_PM9263
+
/* clocks */
#define CONFIG_SYS_MOR_VAL \
(AT91_PMC_MOR_MOSCEN | \
diff --git a/include/configs/pm9g45.h b/include/configs/pm9g45.h
index acc1204..d3beaf3 100644
--- a/include/configs/pm9g45.h
+++ b/include/configs/pm9g45.h
@@ -41,6 +41,9 @@
#define CONFIG_PM9G45 1 /* It's an Ronetix PM9G45 */
#define CONFIG_SYS_AT91_CPU_NAME "AT91SAM9G45"
+#define MACH_TYPE_PM9G45 2672
+#define CONFIG_MACH_TYPE MACH_TYPE_PM9G45
+
/* ARM asynchronous clock */
#define CONFIG_SYS_AT91_MAIN_CLOCK 12000000 /* from 12 MHz crystal */
#define CONFIG_SYS_AT91_SLOW_CLOCK 32768 /* slow clock xtal */
--
1.7.4.4
^ permalink raw reply related
* [U-Boot] [PATCH V3] Arm: re-introduce the MACH_TYPE_XXXXXX for EB_CPUX9K2 board
From: Jens Scharsig @ 2011-10-31 18:52 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320045966-25187-1-git-send-email-js_at_ng@scharsoft.de>
* re-introduce the MACH_TYPE_XXXXXX for EB_CPUX9K2 board
Signed-off-by: Jens Scharsig <js_at_ng@scharsoft.de>
---
include/configs/eb_cpux9k2.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/configs/eb_cpux9k2.h b/include/configs/eb_cpux9k2.h
index 4324172..b08de4a 100644
--- a/include/configs/eb_cpux9k2.h
+++ b/include/configs/eb_cpux9k2.h
@@ -41,6 +41,8 @@
#define CONFIG_MISC_INIT_R
#define CONFIG_BOARD_EARLY_INIT_F
+#define MACH_TYPE_EB_CPUX9K2 1977
+#define CONFIG_MACH_TYPE MACH_TYPE_EB_CPUX9K2
/*--------------------------------------------------------------------------*/
#define CONFIG_SYS_TEXT_BASE 0x00000000
#define CONFIG_SYS_LOAD_ADDR 0x21000000 /* default load address */
--
1.7.3.4
^ permalink raw reply related
* [U-Boot] [PATCH] image: Allow images to indicate they're loadable at any address
From: Simon Glass @ 2011-10-31 18:49 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110311936.20941.marek.vasut@gmail.com>
Hi Marek,
On Mon, Oct 31, 2011 at 11:36 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
>> The legacy uImage format includes an absolute load and entry-
>> point address. When presented with a uImage in memory that
>> isn't loaded at the address in the image's load address,
>> U-Boot will relocate the image to its address in the header.
>>
>> Some payloads can actually be loaded and used at any arbitrary
>> address. An example is an ARM Linux kernel zImage file. This
>> is useful when sharing a single zImage across multiple boards
>> with different memory layouts, or U-Boot builds with different
>> ${load_addr} since sharing a single absolute load address may
>> not be possible.
>>
>> With this config option enabled, an image header may contain a
>> load address of -1/0xffffffff. This indicates the image can
>> operate at any load address, and U-Boot will avoid automtically
>> copying it anywhere. In this case, the entry-point field is
>> specified relative to the start of the image payload.
>>
>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>> ---
>> Wolfgang,
>>
>> This is an much simpler and less invasive alternative to my previous
>> IH_TYPE_KERNEL_REL patch. If it's OK, you can ignore that patch.
>>
>> u-boot.bin sizes for Tegra Seaboard without/with this config option on:
>>
>> ? ?text ? ? ? ? ?data ? ? bss ? ? dec ? ? hex filename
>> ?165858 ? ? ? ? ?3565 ?217016 ?386439 ? 5e587 ./u-boot
>>
>> with:
>>
>> ? ?text ? ? ? ? ?data ? ? bss ? ? dec ? ? hex filename
>> ?165950 ? ? ? ? ?3565 ?217012 ?386527 ? 5e5df ./u-boot
>>
>
> [...]
>
> This one doesn't apply on top of current u-boot master
You need to revert Stephen's clean-up patch 1/2 712fbcf to test this.
Regards,
Simon
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
^ permalink raw reply
* [U-Boot] [PATCH v3] arm926ejs: add NXP LPC32x0 cpu series support
From: Vladimir Zapolskiy @ 2011-10-31 18:44 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EAEDE0B.7090201@aribaud.net>
Hi Albert,
On 31.10.2011 19:42, Albert ARIBAUD wrote:
> Hi Vladimir,
>
> Le 24/10/2011 01:04, Vladimir Zapolskiy a ?crit :
>> Hi Albert,
>>
>> On 22.10.2011 02:31, Albert ARIBAUD wrote:
>>> Hi Vladimir,
>>>
>>> Le 18/10/2011 17:55, Vladimir Zapolskiy a ?crit :
>>>> This change adds initial support for NXP LPC32x0 SoC series.
>>>>
>>>> Signed-off-by: Vladimir Zapolskiy<vz@mleia.com>
>>>> ---
>>>> Changes from v2 to v3:
>>>> * checkpatch.pl reports zero errors and warnings
>>>>
>>>> Changes from v1 to v2:
>>>> * BIT(n) and SBF(s, v) macro are not used anymore
>>>> * removed NS16550 and 14-clock UART definitions from uart.h
>>>> * added devices.c file, which contains standard UART preinitialization
>>>> routine
>>>> * added get_serial_clock() function, it returns actual frequency of
>>>> UART clock
>>>> * __udelay() realization is simplified, no need of interrupt handling
>>>
>>> As it stands, this is dead code until some board uses it; I imagine you
>>> have board waiting for this support. Can you submit the SoC and board
>>> code as a patch set? This way, it will be obvious for all that the SoC
>>> code in this patch has actual use.
>>
>> you're right, I have a board to make support for. However I presume that
>> U-boot maintainers won't be happy to include a board with
>> CONFIG_ENV_IS_NOWHERE, and unfortunately flash driver isn't yet ready
>> for publishing.
>
> CONFIG_ENV_IS_NOWHERE is the board( maintainer)'s business.
>
> Ditto for the FLASH driver, if it is not required for use of the board
> (e.g., if U-Boot can fire up and does not need the FLASH to boot an OS,
> then a broken FLASH driver is an inconvenience, not a showstopper).
I've added CFI flash support to the board, however the environment is
supposed to be stored in NAND flash, and that requires some more LPC32XX
specific stuff to be developed for U-boot soon (basically that's NAND
controller and DMA drivers).
>> I'd like to get an advice, if you think that weakly supported but
>> working U-boot on the board has chances to be included to arm-next I can
>> send the patchset right now for review, otherwise I'll spend some time
>> (one week approximately) to finish NAND driver.
>
> IMO, the acceptable state of a board is the board maintainer's affair,
> with a bare minimum that U-Boot must be able to play its role as a
> bootloader.
>
It's done in my understanding. Hopefully some more addons still should
be implemented, and I'd like to concentrate on them being assured that
the SoC and basic board support are pulled in.
> Anyway, since that is for next, not master, and since you think you can
> add the missing support far before the next merge window, I suggest you
> complete board support and add it to V4.
>
The initial board support was done and published a week ago, please
check http://lists.denx.de/pipermail/u-boot/2011-October/106991.html
And that's my expression of willing to become a board maintainer, sorry
it hasn't been included to the board changeset originally -
http://lists.denx.de/pipermail/u-boot/2011-October/107069.html
I'd like to encourage you to check that the board specific compilation
has zero warnings and checkpatch.pl output is clean.
--
With best wishes,
Vladimir
^ permalink raw reply
* [U-Boot] [PATCH] image: Allow images to indicate they're loadable at any address
From: Marek Vasut @ 2011-10-31 18:36 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319464779-23571-1-git-send-email-swarren@nvidia.com>
> The legacy uImage format includes an absolute load and entry-
> point address. When presented with a uImage in memory that
> isn't loaded at the address in the image's load address,
> U-Boot will relocate the image to its address in the header.
>
> Some payloads can actually be loaded and used at any arbitrary
> address. An example is an ARM Linux kernel zImage file. This
> is useful when sharing a single zImage across multiple boards
> with different memory layouts, or U-Boot builds with different
> ${load_addr} since sharing a single absolute load address may
> not be possible.
>
> With this config option enabled, an image header may contain a
> load address of -1/0xffffffff. This indicates the image can
> operate at any load address, and U-Boot will avoid automtically
> copying it anywhere. In this case, the entry-point field is
> specified relative to the start of the image payload.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> Wolfgang,
>
> This is an much simpler and less invasive alternative to my previous
> IH_TYPE_KERNEL_REL patch. If it's OK, you can ignore that patch.
>
> u-boot.bin sizes for Tegra Seaboard without/with this config option on:
>
> text data bss dec hex filename
> 165858 3565 217016 386439 5e587 ./u-boot
>
> with:
>
> text data bss dec hex filename
> 165950 3565 217012 386527 5e5df ./u-boot
>
[...]
This one doesn't apply on top of current u-boot master
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox