Re: [U-Boot] [PATCH v2] Merge and reformat boards.cfg and MAINTAINERS
Hi Albert Could you send thoses two fixes as as a proper, standalone git patch rather than a reply to another patch, so that they can be properly attributed to you? I received this message from mailing list robot: Message rejected. No base64 encoded MIME text parts allowed. ... I will try the setup another mail client soon. So I did a resend here: http://patchwork.ozlabs.org/patch/274695/ Regards Roger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] Some questions about BootStage functions
Hi, experts: I have some questions about bootstage functions.(common/bootstage.c) 1. mark_bootsage record relocation question board_init_f() will call mark_bootstage() function to record the elapsed time when system From power on to board_init_f point. But after running board_init_f() function, uboot will relocate u-boot code base. So, the boot stage record board_init_f would be abnormal ? ! Because i did not find any code to do relocation operation for boot stage records. 2. how to understand start_us fiedld in bootstage_record struct ? bootstage_start() function will init bootstage_record-start_us. But not find which file will call bootstage_start() . Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] git-mailrc: Update SPI custodian
Update git-mailrc with alias and nick name details. Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com --- doc/git-mailrc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/git-mailrc b/doc/git-mailrc index 2cacaa0..014a413 100644 --- a/doc/git-mailrc +++ b/doc/git-mailrc @@ -18,6 +18,7 @@ alias galak Kumar Gala ga...@kernel.crashing.org alias gruss Graeme Russ graeme.r...@gmail.com alias hs Heiko Schocher h...@denx.de alias iwamatsu Nobuhiro Iwamatsu iwama...@nigauri.org +alias jagan Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com alias jasonjin Jason Jin jason@freescale.com alias jhersh Joe Hershberger joe.hershber...@gmail.com alias kimphill Kim Phillips kim.phill...@freescale.com @@ -106,5 +107,6 @@ alias i2cuboot, hs alias mmcuboot, panto alias nand uboot, scottwood alias netuboot, jhersh +alias spi uboot, jagan alias usbuboot, marex alias video uboot, ag -- 1.8.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec_mxc: Fix timeouts during tftp transfer
On 09/16/2013 03:10 AM, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com Performing tftp transfers on mx28 results in random timeouts. Hector Palacios and Robert Hodaszi analyzed the root cause being related to the alignment of the 'buff' buffer inside fec_recv(). GCC versions such as 4.4/4.5 are more likely to exhibit such problem. Use ALLOC_CACHE_ALIGN_BUFFER() for making the proper alignment of buffer. Reported-by: Hector Palacios hector.palac...@digi.com Tested-by: Oliver Metz oli...@freetz.org Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- drivers/net/fec_mxc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index 690e572..b423ff6 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -794,7 +794,7 @@ static int fec_recv(struct eth_device *dev) uint16_t bd_status; uint32_t addr, size, end; int i; - uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN); + ALLOC_CACHE_ALIGN_BUFFER(uchar, buff, FEC_MAX_PKT_SIZE); /* * Check if any critical events have happened Tested-by: Hector Palacios hector.palac...@digi.com Best regards, -- Hector Palacios ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
于 2013年09月15日 22:18, Marek Vasut 写道:
Dear Huang Shijie,
于 2013年09月04日 23:46, Hector Palacios 写道:
Dear Marek,
On 09/04/2013 04:38 PM, Marek Vasut wrote:
Dear Huang Shijie,
On Wed, Sep 04, 2013 at 04:00:36PM +0200, Marek Vasut wrote:
Dear Huang Shijie,
How come hector was then able to write his JFFS2 partition ?
If he uses the gpmi, he should not write the JFFS2, since the gpmi
does not support the jffs2. He will get the failure in the end.
Hector, can you comment on this?
I don't think I'm following these comments. The facts are:
1) A JFFS2 filesystem image written with nandwrite (mtd-utils v1.5.0)
a) does not mount on kernel v3.10
b) mounts OK on linux-next kernel (v3.12) with the patchset [1] from
Huang
(actually I didn't use linux-next but instead a v3.10 where I merged
all the commits done to MTD in linux-next, which are a lot).
2) A JFFS2 filesystem image written with U-Boot v2013.01
a) mounts OK on old FSL kernel 2.6.35
b) does not mount on kernel v3.10 (neither on v3.8, I believe).
c) does not mount on linux-next with the patchset [1]
The gpmi driver in FSL kernel 2.6.35 is different from the linux-next or
linux v3.10.
We have abandoned the old gpmi driver, and we use the same gpmi code in
current FSL kernel.
Since we swtich to the upstream gpmi code, and it could not support the
jffs2,
and that's why you mount always failed.
With the patchset, mounting the jffs should work again, no? If mounting the jffs
If the jffs2 image is written by the uboot, the mounting should not works.
works with the patchset AND it only works with jffs written using the new
driver, you will need to introduce soem compatibility option or something along
that.
do you mean i should a new dt property for the jffs2 support ?
[1]
http://lists.infradead.org/pipermail/linux-mtd/2013-August/048360.html
Marek, could you please confirm 2b on your side, just in case I'm
doing anything wrong in my custom U-Boot?
So the jffs2 support is compatiable all the time.
Is the old Freescale 2.6.35 GPMI NAND format compatible with the one
after applying this patchset?
Not compatible.
This patch set is still underreview.
So this patch breaks compatiblity with FSL kernel release? This needs
fixing,
otherwise it's impossible to do a drop-in replacement for the ancient
FSL
kernel.
that I could mount with Linux 3.7 and earlier?
I think the mount can be succeeded.
Ok, does that mean that we need this patchset in U-Boot in order to
properly write JFFS2 onto GPMI NAND there? Is that the message you
wanted to relay to us?
Besides this patchset, the u-boot needs more patches to sync with the
kernel mtd code. Such as the full-id features.
Can you elaborate on this more? This is very vague, I would like to
know what
exactly is missing.
92a2645 mtd: add 4 Toshiba nand chips for the full-id case
ec6e87e mtd: add the support to parse out the full-id nand type
Do these really have any impact?
yes. the full-id nand is not supported by the old mtd code.
f22d5f6 mtd: add new fields to nand_flash_dev{}
2febcdf mtd: gpmi: set the BCH's geometry with the ecc info
d1048aa mtd: add the ecc info for some full-id nand chips
5721934 mtd: parse out the ECC info for the full-id nand chips
2dc0bdd mtd: add ECC info for nand_flash_dev{}
e2985fc mtd: replace the hardcode with the onfi_feature()
6dcbe0c mtd: get the ECC info from the Extended Parameter Page
5b40db6 mtd: add a helper to get the supported features for ONFI nand
5138a98 mtd: add data structures for Extended Parameter Page
10c86ba mtd: get the ECC info from the parameter page for ONFI nand
4cfeca2 mtd: add datasheet's ECC information to nand_chip{}
Hector, can you inspect those patches ?
Yes, please, we need more details. This seems to be related with how
the MTD drivers (in Linux and in U-Boot) access the OOB area to store
the JFFS2 cleanmarkers, right?
The error I'm receiving from the kernel is at fs/jffs2/wbuf.c
if (!oinfo || oinfo-oobavail == 0) {
pr_err(inconsistent device description\n);
return -EINVAL;
}
Before apply the patches above, the gpmi will use all the oob, so
oinfo-oobavail == 0 becomes true.
After apply the patches, the gpmi will not use all the oob for the ONFI
SLC nand or the full-id nand,
and it can supports the jffs2 when you apply the other SLC/MLC patchset.
So the patches you listed above are not enough?
It should be enough.
thanks
Huang Shijie
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v10 5/6] remove compiling warnings
From: David Feng feng...@phytium.com.cn
Signed-off-by: David Feng feng...@phytium.com.cn
---
common/cmd_pxe.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c
index a2fb50a..df58522 100644
--- a/common/cmd_pxe.c
+++ b/common/cmd_pxe.c
@@ -57,7 +57,7 @@ static int format_mac_pxe(char *outbuf, size_t outbuf_len)
uchar ethaddr[6];
if (outbuf_len 21) {
- printf(outbuf is too small (%d 21)\n, outbuf_len);
+ printf(outbuf is too small (%zd 21)\n, outbuf_len);
return -EINVAL;
}
@@ -100,7 +100,7 @@ static int get_bootfile_path(const char *file_path, char
*bootfile_path,
path_len = (last_slash - bootfile) + 1;
if (bootfile_path_size path_len) {
- printf(bootfile_path too small. (%d %d)\n,
+ printf(bootfile_path too small. (%zd %zd)\n,
bootfile_path_size, path_len);
return -1;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v10 4/6] 64bit initrd start address support
From: David Feng feng...@phytium.com.cn
Signed-off-by: David Feng feng...@phytium.com.cn
---
common/fdt_support.c | 66 ++
1 file changed, 34 insertions(+), 32 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index b034c98..9bc5821 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -21,6 +21,34 @@
*/
DECLARE_GLOBAL_DATA_PTR;
+/*
+ * Get cells len in bytes
+ * if #-cells property is 2 then len is 8
+ * otherwise len is 4
+ */
+static int get_cells_len(void *blob, char *nr_cells_name)
+{
+ const fdt32_t *cell;
+
+ cell = fdt_getprop(blob, 0, nr_cells_name, NULL);
+ if (cell fdt32_to_cpu(*cell) == 2)
+ return 8;
+
+ return 4;
+}
+
+/*
+ * Write a 4 or 8 byte big endian cell
+ */
+static void write_cell(u8 *addr, u64 val, int size)
+{
+ int shift = (size - 1) * 8;
+ while (size-- 0) {
+ *addr++ = (val shift) 0xff;
+ shift -= 8;
+ }
+}
+
/**
* fdt_getprop_u32_default - Find a node and return it's property or a default
*
@@ -131,9 +159,9 @@ static int fdt_fixup_stdout(void *fdt, int chosenoff)
int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end, int force)
{
- int nodeoffset;
+ int nodeoffset, addr_cell_len;
int err, j, total;
- fdt32_t tmp;
+ fdt64_t tmp;
const char *path;
uint64_t addr, size;
@@ -170,9 +198,11 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong
initrd_end, int force)
return err;
}
+ addr_cell_len = get_cells_len(fdt, #address-cells);
+
path = fdt_getprop(fdt, nodeoffset, linux,initrd-start, NULL);
if ((path == NULL) || force) {
- tmp = cpu_to_fdt32(initrd_start);
+ write_cell((u8 *)tmp, initrd_start, addr_cell_len);
err = fdt_setprop(fdt, nodeoffset,
linux,initrd-start, tmp, sizeof(tmp));
if (err 0) {
@@ -181,7 +211,7 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong
initrd_end, int force)
fdt_strerror(err));
return err;
}
- tmp = cpu_to_fdt32(initrd_end);
+ write_cell((u8 *)tmp, initrd_end, addr_cell_len);
err = fdt_setprop(fdt, nodeoffset,
linux,initrd-end, tmp, sizeof(tmp));
if (err 0) {
@@ -343,34 +373,6 @@ void do_fixup_by_compat_u32(void *fdt, const char *compat,
do_fixup_by_compat(fdt, compat, prop, tmp, 4, create);
}
-/*
- * Get cells len in bytes
- * if #-cells property is 2 then len is 8
- * otherwise len is 4
- */
-static int get_cells_len(void *blob, char *nr_cells_name)
-{
- const fdt32_t *cell;
-
- cell = fdt_getprop(blob, 0, nr_cells_name, NULL);
- if (cell fdt32_to_cpu(*cell) == 2)
- return 8;
-
- return 4;
-}
-
-/*
- * Write a 4 or 8 byte big endian cell
- */
-static void write_cell(u8 *addr, u64 val, int size)
-{
- int shift = (size - 1) * 8;
- while (size-- 0) {
- *addr++ = (val shift) 0xff;
- shift -= 8;
- }
-}
-
#ifdef CONFIG_NR_DRAM_BANKS
#define MEMORY_BANKS_MAX CONFIG_NR_DRAM_BANKS
#else
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v10 2/6] board support of vexpress_aemv8a
From: David Feng feng...@phytium.com.cn
Signed-off-by: David Feng feng...@phytium.com.cn
Signed-off-by: Bhupesh Sharma bhupesh.sha...@freescale.com
---
MAINTAINERS |4 +
board/armltd/dts/vexpress64.dts | 439 ++
board/armltd/vexpress64/Makefile | 27 +++
board/armltd/vexpress64/vexpress64.c | 70 ++
boards.cfg |1 +
include/configs/vexpress_aemv8a.h| 191 +++
6 files changed, 732 insertions(+)
create mode 100644 board/armltd/dts/vexpress64.dts
create mode 100644 board/armltd/vexpress64/Makefile
create mode 100644 board/armltd/vexpress64/vexpress64.c
create mode 100644 include/configs/vexpress_aemv8a.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 6e50fc4..d142307 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1095,6 +1095,10 @@ Sergey Yanovich ynv...@gmail.com
lp8x4x xscale/pxa
+David Feng feng...@phytium.com.cn
+
+ vexpress_aemv8a ARM ARMV8 (Quad Core)
+
-
Unknown / orphaned boards:
diff --git a/board/armltd/dts/vexpress64.dts b/board/armltd/dts/vexpress64.dts
new file mode 100644
index 000..067fea7
--- /dev/null
+++ b/board/armltd/dts/vexpress64.dts
@@ -0,0 +1,439 @@
+/*
+ * ARM Ltd. Fast Models
+ *
+ * Architecture Envelope Model (AEM) ARMv8-A
+ * ARMAEMv8AMPCT
+ *
+ * RTSM_VE_AEMv8A.lisa
+ */
+
+/dts-v1/;
+
+/memreserve/ 0x8000 0x0001;
+
+/ {
+ /* boot configurations for u-boot */
+ config {
+ /*bootdelay = 1;*/
+ kernel-offset = 0x10;
+ rootdisk-offset = 0x80;
+ bootcmd = bootm 0x10 0x80:0x200;
+ };
+};
+
+/ {
+ model = RTSM_VE_AEMv8A;
+ compatible = arm,rtsm_ve,aemv8a, arm,vexpress;
+ interrupt-parent = gic;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ /* chosen */
+ /* generated by u-boot */
+
+
+ aliases {
+ serial0 = v2m_serial0;
+ serial1 = v2m_serial1;
+ serial2 = v2m_serial2;
+ serial3 = v2m_serial3;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 0;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ cpu@1 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 1;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ cpu@2 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 2;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ cpu@3 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 3;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ };
+
+ memory@8000 {
+ device_type = memory;
+ reg = 0x 0x8000 0 0x8000,
+ 0x0008 0x8000 0 0x8000;
+ };
+
+ gic: interrupt-controller@2c001000 {
+ compatible = arm,cortex-a15-gic, arm,cortex-a9-gic;
+ #interrupt-cells = 3;
+ #address-cells = 0;
+ interrupt-controller;
+ reg = 0x0 0x2c001000 0 0x1000,
+ 0x0 0x2c002000 0 0x1000,
+ 0x0 0x2c004000 0 0x2000,
+ 0x0 0x2c006000 0 0x2000;
+ interrupts = 1 9 0xf04;
+ };
+
+ timer {
+ compatible = arm,armv8-timer;
+ interrupts = 1 13 0xff01,
+1 14 0xff01,
+1 11 0xff01,
+1 10 0xff01;
+ clock-frequency = 1;
+ };
+
+ pmu {
+ compatible = arm,armv8-pmuv3;
+ interrupts = 0 60 4,
+0 61 4,
+0 62 4,
+0 63 4;
+ };
+
+ smb {
+ compatible = simple-bus;
+
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0 0x0800 0x0400,
+1 0 0 0x1400 0x0400,
+2 0 0 0x1800 0x0400,
+3 0 0 0x1c00 0x0400,
+4 0 0 0x0c00 0x0400,
+
[U-Boot] [PATCH v10 1/6] core support of arm64
From: David Feng feng...@phytium.com.cn Signed-off-by: David Feng feng...@phytium.com.cn --- arch/arm/config.mk |4 + arch/arm/cpu/armv8/Makefile | 38 + arch/arm/cpu/armv8/cache.S | 130 + arch/arm/cpu/armv8/cache_v8.c | 228 + arch/arm/cpu/armv8/config.mk| 16 +++ arch/arm/cpu/armv8/cpu.c| 67 + arch/arm/cpu/armv8/exceptions.S | 115 +++ arch/arm/cpu/armv8/start.S | 238 +++ arch/arm/cpu/armv8/timer.c | 80 +++ arch/arm/cpu/armv8/tlb.S| 30 arch/arm/cpu/armv8/u-boot.lds | 71 + arch/arm/include/asm/arch-armv8/gpio.h | 11 ++ arch/arm/include/asm/arch-armv8/mmu.h | 106 ++ arch/arm/include/asm/byteorder.h| 12 ++ arch/arm/include/asm/cache.h|5 + arch/arm/include/asm/config.h | 10 ++ arch/arm/include/asm/global_data.h |6 +- arch/arm/include/asm/io.h | 15 +- arch/arm/include/asm/macro.h| 20 +++ arch/arm/include/asm/posix_types.h | 10 ++ arch/arm/include/asm/proc-armv/ptrace.h | 21 +++ arch/arm/include/asm/proc-armv/system.h | 59 +++- arch/arm/include/asm/system.h | 77 ++ arch/arm/include/asm/types.h|4 + arch/arm/include/asm/u-boot.h |4 + arch/arm/include/asm/unaligned.h|2 +- arch/arm/lib/Makefile | 14 ++ arch/arm/lib/board.c| 16 ++- arch/arm/lib/bootm.c| 16 +++ arch/arm/lib/crt0_64.S | 116 +++ arch/arm/lib/interrupts_64.c| 120 arch/arm/lib/relocate_64.S | 57 common/image.c |1 + doc/README.armv8| 18 +++ examples/standalone/stubs.c | 15 ++ include/image.h |1 + 36 files changed, 1743 insertions(+), 10 deletions(-) create mode 100644 arch/arm/cpu/armv8/Makefile create mode 100644 arch/arm/cpu/armv8/cache.S create mode 100644 arch/arm/cpu/armv8/cache_v8.c create mode 100644 arch/arm/cpu/armv8/config.mk create mode 100644 arch/arm/cpu/armv8/cpu.c create mode 100644 arch/arm/cpu/armv8/exceptions.S create mode 100644 arch/arm/cpu/armv8/start.S create mode 100644 arch/arm/cpu/armv8/timer.c create mode 100644 arch/arm/cpu/armv8/tlb.S create mode 100644 arch/arm/cpu/armv8/u-boot.lds create mode 100644 arch/arm/include/asm/arch-armv8/gpio.h create mode 100644 arch/arm/include/asm/arch-armv8/mmu.h create mode 100644 arch/arm/lib/crt0_64.S create mode 100644 arch/arm/lib/interrupts_64.c create mode 100644 arch/arm/lib/relocate_64.S create mode 100644 doc/README.armv8 diff --git a/arch/arm/config.mk b/arch/arm/config.mk index ce3903b..f1c6a7b 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -74,7 +74,9 @@ endif endif # needed for relocation +ifndef CONFIG_ARMV8 LDFLAGS_u-boot += -pie +endif # # FIXME: binutils versions 2.22 have a bug in the assembler where @@ -95,6 +97,8 @@ endif endif # check that only R_ARM_RELATIVE relocations are generated +ifndef CONFIG_ARMV8 ifneq ($(CONFIG_SPL_BUILD),y) ALL-y += checkarmreloc endif +endif diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile new file mode 100644 index 000..b216f27 --- /dev/null +++ b/arch/arm/cpu/armv8/Makefile @@ -0,0 +1,38 @@ +# +# (C) Copyright 2000-2003 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(CPU).o + +START := start.o + +COBJS += cpu.o +COBJS += timer.o +COBJS += cache_v8.o + +SOBJS += exceptions.o +SOBJS += cache.o +SOBJS += tlb.o + +SRCS := $(START:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) +START := $(addprefix $(obj),$(START)) + +all: $(obj).depend $(START) $(LIB) + +$(LIB):$(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/arch/arm/cpu/armv8/cache.S b/arch/arm/cpu/armv8/cache.S new file mode 100644 index 000..419f169 --- /dev/null +++ b/arch/arm/cpu/armv8/cache.S @@ -0,0 +1,130 @@ +/* + * (C) Copyright 2013 + * David Feng feng...@phytium.com.cn + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include asm-offsets.h +#include config.h +#include version.h +#include asm/macro.h +#include linux/linkage.h + +/* + * void __asm_flush_dcache_level(level) + * + * clean and invalidate one level cache. + * + * x0: cache level + * x1~x9: clobbered + */
[U-Boot] [PATCH v10 6/6] add weak entry definition
From: David Feng feng...@phytium.com.cn Signed-off-by: David Feng feng...@phytium.com.cn --- include/linux/linkage.h |4 1 file changed, 4 insertions(+) diff --git a/include/linux/linkage.h b/include/linux/linkage.h index 9ddf830..2a2848a 100644 --- a/include/linux/linkage.h +++ b/include/linux/linkage.h @@ -49,6 +49,10 @@ .globl SYMBOL_NAME(name); \ LENTRY(name) +#define WEAK(name) \ + .weak SYMBOL_NAME(name); \ + LENTRY(name) + #ifndef END #define END(name) \ .size name, .-name -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v10 3/6] generic board patch of manual reloc and zero gd_t
From: David Feng feng...@phytium.com.cn
Signed-off-by: David Feng feng...@phytium.com.cn
---
common/board_f.c | 18 +++---
common/board_r.c | 18 ++
2 files changed, 29 insertions(+), 7 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c
index 0ada1af..f92a39e 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -458,7 +458,7 @@ static int reserve_round_4k(void)
static int reserve_mmu(void)
{
/* reserve TLB table */
- gd-arch.tlb_size = 4096 * 4;
+ gd-arch.tlb_size = PGTABLE_SIZE;
gd-relocaddr -= gd-arch.tlb_size;
/* round down to next 64 kB limit */
@@ -610,7 +610,7 @@ static int reserve_stacks(void)
* TODO(s...@chromium.org): Perhaps create arch_reserve_stack()
* to handle this and put in arch/xxx/lib/stack.c
*/
-# ifdef CONFIG_ARM
+# if defined(CONFIG_ARM) !defined(CONFIG_ARMV8)
# ifdef CONFIG_USE_IRQ
gd-start_addr_sp -= (CONFIG_STACKSIZE_IRQ + CONFIG_STACKSIZE_FIQ);
debug(Reserving %zu Bytes for IRQ stack at: %08lx\n,
@@ -807,11 +807,6 @@ static int mark_bootstage(void)
}
static init_fnc_t init_sequence_f[] = {
-#if !defined(CONFIG_CPM2) !defined(CONFIG_MPC512X) \
- !defined(CONFIG_MPC83xx) !defined(CONFIG_MPC85xx) \
- !defined(CONFIG_MPC86xx) !defined(CONFIG_X86)
- zero_global_data,
-#endif
#ifdef CONFIG_SANDBOX
setup_ram_buf,
#endif
@@ -1005,6 +1000,15 @@ void board_init_f(ulong boot_flags)
gd = data;
#endif
+ /*
+* Zero gd_t first, otherwise the debug print(if DEBUG defined)
+* in initcall_run_list function before zero_global_data is called
+* will go wrong.
+*/
+#ifndef CONFIG_X86
+ zero_global_data();
+#endif
+
gd-flags = boot_flags;
if (initcall_run_list(init_sequence_f))
diff --git a/common/board_r.c b/common/board_r.c
index 86ca1cb..862f8f6 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -157,6 +157,13 @@ static int initr_reloc_global_data(void)
*/
gd-env_addr += gd-relocaddr - CONFIG_SYS_MONITOR_BASE;
#endif
+#ifdef CONFIG_NEEDS_MANUAL_RELOC
+ /*
+* We have to relocate the command table manually
+*/
+ fixup_cmdtable(ll_entry_start(cmd_tbl_t, cmd),
+ ll_entry_count(cmd_tbl_t, cmd));
+#endif /* CONFIG_NEEDS_MANUAL_RELOC */
return 0;
}
@@ -899,6 +906,7 @@ init_fnc_t init_sequence_r[] = {
initr_modem,
#endif
run_main_loop,
+ NULL,
};
void board_init_r(gd_t *new_gd, ulong dest_addr)
@@ -906,6 +914,16 @@ void board_init_r(gd_t *new_gd, ulong dest_addr)
#ifndef CONFIG_X86
gd = new_gd;
#endif
+#ifdef CONFIG_NEEDS_MANUAL_RELOC
+ /*
+* We have to relocate the init_sequence_r table manually
+*/
+ init_fnc_t *init_fnc_ptr;
+ for (init_fnc_ptr = init_sequence_r; *init_fnc_ptr; ++init_fnc_ptr)
+ *(unsigned long *)init_fnc_ptr =
+ (unsigned long)(*init_fnc_ptr) + gd-reloc_off;
+#endif /* CONFIG_NEEDS_MANUAL_RELOC */
+
if (initcall_run_list(init_sequence_r))
hang();
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v10 0/6] arm64 patch
From: David Feng feng...@phytium.com.cn Changes for v10: - add weak definition to include/linux/linkage.h and make setup_el2/setup_el3/lowlevel_init weak routines, so them can be easily overridden by processor specific code. - modify s-o-f of 0002-board-support-of-vexpress_aemv8a which use wrong mail address of Bhupesh Sharma. Changes for v9: - add Signed-off-by information to patch board support of vexpress_aemv8a which SMC9 support is integrated from Sharma Bhupesh's patch. - adjust pt_regs struct and add exception state preservation in exception.S. Changes for v8: - Integrate SMC9 patch of sharma bhupesh. - remove v8_outer_cache* which is not need currently. - Change license tag. - Mov crt0.S/relocate.S/interrupts.c to arm/lib and rename them with _64 suffix. - Make el3/el2 initializing process of start.S as two separate routines. It could be easier to be replaced with processor specific codes. - Remove exception stack save and restore routine, it is unnecessary now. - simplify __weak function declaration. Changes for v7: - Check the patches with checkpatch.pl and get rid of almost all warnings. There are a few warnings still, but I think it should be that. - change printf format in cmd_pxe.c, use %zd indtead of %ld to format size_t type variable. - add macro PGTABLE_SIZE to identify tlb table size. Changes for v6: - Make modification to inappropriate licensed file and bugs according to ScottWood's advice. Thanks Scott for his checking to these patches. - Enable u-boot's running at EL1. - Get rid of compiling warnings originated from cmd_pxe.c. Changes for v5: - fix the generic board_f.c, remove zero_global_data from init_sequence_f array and move it to board_init_f() function with CONFIG_X86 switch. The previous fixup is inaccurate. - Replace __ARMEB__ with __AARCH64EB__ in byteorder.h and unaligned.h, gcc for aarch64 use __AARCH64EB__ and __AARCH64EL__ to identify endian. - Some modification to README.armv8 Changes for v4: - merge arm64 to arm architecture. David Feng (6): core support of arm64 board support of vexpress_aemv8a generic board patch of manual reloc and zero gd_t 64bit initrd start address support remove compiling warnings add weak entry definition MAINTAINERS |4 + arch/arm/config.mk |4 + arch/arm/cpu/armv8/Makefile | 38 +++ arch/arm/cpu/armv8/cache.S | 130 + arch/arm/cpu/armv8/cache_v8.c | 228 arch/arm/cpu/armv8/config.mk| 16 ++ arch/arm/cpu/armv8/cpu.c| 67 + arch/arm/cpu/armv8/exceptions.S | 115 arch/arm/cpu/armv8/start.S | 238 + arch/arm/cpu/armv8/timer.c | 80 ++ arch/arm/cpu/armv8/tlb.S| 30 +++ arch/arm/cpu/armv8/u-boot.lds | 71 + arch/arm/include/asm/arch-armv8/gpio.h | 11 + arch/arm/include/asm/arch-armv8/mmu.h | 106 arch/arm/include/asm/byteorder.h| 12 + arch/arm/include/asm/cache.h|5 + arch/arm/include/asm/config.h | 10 + arch/arm/include/asm/global_data.h |6 +- arch/arm/include/asm/io.h | 15 +- arch/arm/include/asm/macro.h| 20 ++ arch/arm/include/asm/posix_types.h | 10 + arch/arm/include/asm/proc-armv/ptrace.h | 21 ++ arch/arm/include/asm/proc-armv/system.h | 59 - arch/arm/include/asm/system.h | 77 ++ arch/arm/include/asm/types.h|4 + arch/arm/include/asm/u-boot.h |4 + arch/arm/include/asm/unaligned.h|2 +- arch/arm/lib/Makefile | 14 + arch/arm/lib/board.c| 16 +- arch/arm/lib/bootm.c| 16 ++ arch/arm/lib/crt0_64.S | 116 arch/arm/lib/interrupts_64.c| 120 + arch/arm/lib/relocate_64.S | 57 board/armltd/dts/vexpress64.dts | 439 +++ board/armltd/vexpress64/Makefile| 27 ++ board/armltd/vexpress64/vexpress64.c| 70 + boards.cfg |1 + common/board_f.c| 18 +- common/board_r.c| 18 ++ common/cmd_pxe.c|4 +- common/fdt_support.c| 66 ++--- common/image.c |1 + doc/README.armv8| 18 ++ examples/standalone/stubs.c | 15 ++ include/configs/vexpress_aemv8a.h | 191 ++ include/image.h |1 + include/linux/linkage.h |4 + 47 files changed, 2544 insertions(+), 51 deletions(-) create mode 100644 arch/arm/cpu/armv8/Makefile create mode 100644
Re: [U-Boot] [PATCH v5] at91: add support for CDU9G25 board
Dear Jiří Prchal,
On 09/13/2013 04:41 PM, Jiří Prchal wrote:
Dne 13.9.2013 16:10, Andreas Bießmann napsal(a):
On 09/13/2013 03:00 PM, Jiri Prchal wrote:
snip
diff --git a/arch/arm/include/asm/mach-types.h
b/arch/arm/include/asm/mach-types.h
index 440b041..9b274ba 100644
--- a/arch/arm/include/asm/mach-types.h
+++ b/arch/arm/include/asm/mach-types.h
@@ -986,6 +986,7 @@ extern unsigned int __machine_arch_type;
#define MACH_TYPE_VIT_IBOX 3371
#define MACH_TYPE_DM6441_ESP 3372
#define MACH_TYPE_AT91SAM9X5EK 3373
+#define MACH_TYPE_CDU9G25 3373
NAK, please obtain a mach type:
http://www.arm.linux.org.uk/developer/machines/?action=new
Should I register machine? I develop DT only:
NOTE 1:If you are developing a DT-only platform, you do not need to
register a machine type for it.
Please do not register a machine type. Thanks.
Do I need this MACH_TYPE_* at all?
I'm not really familiar with FDT only boards, but I think it is sane to
just use a zero machid then. Could you please check this and if working
just omit the machid setting?
snip
+err_spi_xfer:
+spi_release_bus(slave);
+err_spi_claim_bus:
+spi_free_slave(slave);
+err_spi_setup_slave:
+if (!is_valid_ether_addr(sernum)) {
+eth_random_enetaddr(sernum);
+printf(Using random MAC address %pM\n, sernum);
is that %p formating intended? Shouldn't you print the ethaddr here in
hex rather than the pointer to the memory location?
No, this is no pointer modifier, it's together %pM and it prints ethaddr
like this: 02:22:23:15:86:a5.
Sorry, my fault.
snip
+#define CONFIG_CMD_BOOTZ
+#define CONFIG_OF_LIBFDT
+
+/* general purpose I/O */
+#define CONFIG_ATMEL_LEGACY/* required until (g)pio is fixed */
I doubt you need this for gpio. Could you please check, if it is really
required?
Yes, I knew that, but I have looked many other board files and they use
both GPIO and PIO in one file.
If is necessary I'll re-base it to PIO.
No, nand is not yet prepared for the generic gpio framework. I'll try to
post patches next weeks (for 2014.01), but I'm quite busy right now.
Since your board will also end up in 2014.01 this should go together.
If you have the time I would be grateful if you could prepare patches
for that.
snip
+#define CONFIG_MTD_DEVICE
+#define CONFIG_CMD_MTDPARTS
+#define CONFIG_MTD_PARTITIONS
+#define CONFIG_RBTREE
+#define CONFIG_LZO
+#define CONFIG_CMD_UBI
+#define CONFIG_CMD_UBIFS
+#define CONFIG_CMD_NAND_TRIMFFS
+#define MTDIDS_DEFAULTnand0=nand
+#define MTDPARTS_DEFAULTmtdparts=nand:256k(bootstrap),\
+768k(uboot),256k(ubootenv),\
+4864k(kernel),\
+-(root)
just to mention it:
a) a secondary env is sometimes useful
Is that true? I thought use one copy env, if not then use default.
Well, your point is true, but how about heavily changed env in the
field? If something goes wrong (two bad blocks at worst place, wrong crc
due to too much bit errors, ...) it will fall back to the compiled in
env, which may be completely wrong then.
But it is also true that an enabled secondary env will be read on every
startup and compared to the first env. Also you always need to write two
locations. It depends on your use case, but for me it is careless to
have just one env on NAND.
snip
+#define CONFIG_BOOTCOMMANDnand read 2100 kernel; bootm
+#define CONFIG_BOOTARGSconsole=ttyS0,115200 ubi.mtd=root \
+root=ubi0:root rootfstype=ubifs rw
+#define CONFIG_SERVERIP10.0.1.1
+#define CONFIG_BOOTFILEkernel_cdu9g25
+#define CONFIG_PREBOOTmtdparts default /* for partitions */
Would you really like to always reset a new mtd partitioning on every
boot to the default one?
Does it mean that I don't need run this command if I like use partitions
in nand commands?
No, not fully. You'll need the environment parameter 'mtdparts' with
contend 'mdtparts=...' and respective mtdids env. This could be set by
the command 'mtdparts default', it will set the compiled in values of
MTDIDS_DEFAULT and MTDPARTS_DEFAULT.
If you like to change the nand partitioning in any way you need to
change the mtdparts env. But when you call 'mtdparts default' afterwards
you will reset this to the default value ...
To avoid this we have in our default environment following setting:
---8---
#define CONFIG_EXTRA_ENV_SETTINGS \
mtdparts= MTDPARTS_DEFAULT \0 \
mtdids= MTDIDS_DEFAULT \0 \
...
---8---
Additionally we avoid to use the 'mtdparts default' command.
With this setup one could change the mtdparts environment any time and
it would take effect.
(Just my 2¢, no need to do it that way)
Best regards
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] usb: new board-specific USB init interface
On 09/15/13 16:21, Marek Vasut wrote: I suppose this thread can be concluded by droping the INIT_ALL stuff entirely. Afterall, we do not want to init _ALL_ ports at once, but we want to init them selectively. Best regards, Marek Vasut +1 -- Mateusz Zalega Samsung RD Institute Poland ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] worth correcting spelling of redundand?
again, my pedantry getting the best of me but it makes me cringe
whenever i run across the spelling redundand (tree-wide search):
common/env_ubi.c:#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT
common/env_ubi.c:#else /* ! CONFIG_SYS_REDUNDAND_ENVIRONMENT */
common/env_ubi.c:#endif /* CONFIG_SYS_REDUNDAND_ENVIRONMENT */
common/env_ubi.c:#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT
common/env_ubi.c:#else /* ! CONFIG_SYS_REDUNDAND_ENVIRONMENT */
common/env_ubi.c:#endif /* CONFIG_SYS_REDUNDAND_ENVIRONMENT */
common/env_embedded.c:env_t redundand_environment __PPCENV__ = {
include/environment.h:# define CONFIG_SYS_REDUNDAND_ENVIRONMENT
include/environment.h:# define CONFIG_SYS_REDUNDAND_ENVIRONMENT
include/environment.h:# define CONFIG_SYS_REDUNDAND_ENVIRONMENT
include/environment.h:# define CONFIG_SYS_REDUNDAND_ENVIRONMENT
include/environment.h:#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT
include/environment.h:#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT
include/env_default.h:#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT
include/configs/G2000.h:#else /* DEFAULT: environment in flash, using
redundand flash sectors */
include/configs/km/km_arm.h:#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
include/configs/PPChameleonEVB.h:#else /* DEFAULT: environment in flash, using
redundand flash sectors */
include/configs/mx28evk.h:#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
include/configs/am335x_evm.h:#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
include/configs/omap5_uevm.h:#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
include/configs/igep0033.h:#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
tools/envcrc.c:# define CONFIG_SYS_REDUNDAND_ENVIRONMENT
tools/envcrc.c:#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT
this obviously isn't a cosmetic change as it's used in numerous
#defines, but if it's done all at once, it should be safe. i can
submit a patch unless people feel it's simply too disruptive.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] make distclean doesn't remove CHANGELOG
just noticed that while you can manually generate the CHANGELOG file, make distclean doesn't remove it. i'll leave it up to someone higher up the food chain to determine where that removal should go. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] PCIe:change the method to get the address of a requested capability in configuration space.
Dear Zhao Qiang, In message 1379040166-27997-1-git-send-email-b45...@freescale.com you wrote: Previously, the address of a requested capability is define like that #define PCI_DCR0x78 But, the addresses of capabilities is different with regard to PCIe revs. So this method is not flexible. Now a function to get the address of a requested capability is added and used. It can get the address dynamically by capability ID. The step of this function: 1. Read Status register in PCIe configuration space to confirm that Capabilities List is valid. 2. Find the address of Capabilities Pointer Register. 3. Find the address of requested capability from the first capability. Signed-off-by: Zhao Qiang b45...@freescale.com As far as I can tell, this is the third time you are posting this patch, but with out any indication (there is no version string in the Subject), and without any description of any changes you might have made. Could you please be so kind and read the instructions at [1] and then provide the missing information? [1] http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions Thanks. Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are certain things men must do to remain men. -- Kirk, The Ultimate Computer, stardate 4929.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] usb: new board-specific USB init interface
On 09/15/13 18:44, Marek Vasut wrote: Dear Mateusz Zalega, This commit unifies board-specific USB initialization implementations under one symbol (usb_board_init), declaration of which is available in usb.h. New API allows selective initialization of USB controllers whenever needed. Signed-off-by: Mateusz Zalega m.zal...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Reviewed-by: Lukasz Majewski l.majew...@samsung.com Cc: Marek Vasut ma...@denx.de Cc: Lukasz Majewski l.majew...@samsung.com Change-Id: Ia78a1378f30a55dd14598c9a1a1b4b8a762e2cd8 --- Changes since RFC (v1): - NVIDIA Tegra doesn't postpone its USB init anymore - board_usb_init()'s sole argument name was shortened - networking code comment style (/* blurb...) dropped - squashed RFC changes so that patch won't break bisect v2 changes: - commit message fixup v3 changes: - added 'index' argument to perform selective port initialization v4 changes: - board_usb_init_fail() renamed to board_usb_cleanup() - board_usb_cleanup() accepts controller index and init type - DFU and UMS commands don't init all USB controllers anymore - minor related fixes refactorization --- Looks pretty much OK. Did you test it on a few platforms? I'd like to apply this for -next anyway, since the MW is long closed. Best regards, Marek Vasut I've ran MAKEALL on all arm boards and tested it on Samsung Goni. Everything seems to be OK. -- Mateusz Zalega Samsung RD Institute Poland ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Exynos 5250 Query] Smp Boot
Hi, I was trying to understand the booting (till linux) on samsung exynos 5250. As this is my first on ARM Cortex. I have a few questions, so following is a step by step understanding and [Q] mentions the question I am asking [1] At POR (Power on Reset) the Internal Boot rom code executes, and checks the boot location and if it finds sd card, it copies 14k from the sd card (which is u-boot-spl.bin) into iRAM. [2] the internal boot rom branches pc to the entry point of spl at __start (0x2023400) [3] First instruction at __start is b reset. [4] this takes the route reset | cpu_init_crit | low_level_init | first_cpu [Q 1] At this point what is the state of secondary core, is it held in reset ? As per document, the secondary CPUs (CPU1, CPU2, and CPU3) execute a WFI instruction, which is actually a loop that checks the value of SYS_FLAGS register. I couldnt find the SYS_FLAGS register in Cortex A15 manual, can some one point. [Q 2] The secondary core until the point the boot core calls smp_kick_secondary is just waiting in WFI. [5] the smp_kick_secondary does the following (a) at the address SYSFLAGS_ADDR (0x202) which is not in spl but above it, it write the b reset instruction and (b) Issues a SGI to the secondary core [Q 3] Does this mean that secondary core is listening at address 0x202, I couldnt find that in any document? [6] Supposedly it does and it starts executing the reset function, secondary core would end up in enter_smp_pen. [Q 4] I dont understand what is trying to achieve here, Can some one explain. I am planning to pen down the complete boot sequence, all help appreciated. Thanks in advance. mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] PCIe:change the method to get the address of a requested capability in configuration space.
Previously, the address of a requested capability is define like that
#define PCI_DCR0x78
But, the addresses of capabilities is different with regard to PCIe revs.
So this method is not flexible.
Now a function to get the address of a requested capability is added and used.
It can get the address dynamically by capability ID.
The step of this function:
1. Read Status register in PCIe configuration space to confirm that
Capabilities List is valid.
2. Find the address of Capabilities Pointer Register.
3. Find the address of requested capability from the first capability.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
Changes for v2:
-Put an variable into #ifdef and #endif
Changes for v3:
-Modify the patch description
arch/powerpc/include/asm/fsl_pci.h | 13 +---
drivers/pci/fsl_pci_init.c | 44 +++---
drivers/pci/pci.c | 65 ++
include/pci.h | 10 ++
4 files changed, 108 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_pci.h
b/arch/powerpc/include/asm/fsl_pci.h
index 90b0a2f..6b12afa 100644
--- a/arch/powerpc/include/asm/fsl_pci.h
+++ b/arch/powerpc/include/asm/fsl_pci.h
@@ -32,22 +32,11 @@
/* Freescale-specific PCI config registers */
#define FSL_PCI_PBFR 0x44
-#ifdef CONFIG_SYS_FSL_PCI_VER_3_X
+#ifndef CONFIG_SYS_FSL_PCI_VER_3_X
/* Currently only the PCIe capability is used, so hardcode the offset.
* if more capabilities need to be justified, the capability link method
* should be applied here
*/
-#define FSL_PCIE_CAP_ID0x70
-#define PCI_DCR0x78/* PCIe Device Control Register */
-#define PCI_DSR0x7a/* PCIe Device Status Register */
-#define PCI_LSR0x82/* PCIe Link Status Register */
-#define PCI_LCR0x80/* PCIe Link Control Register */
-#else
-#define FSL_PCIE_CAP_ID0x4c
-#define PCI_DCR0x54/* PCIe Device Control Register */
-#define PCI_DSR0x56/* PCIe Device Status Register */
-#define PCI_LSR0x5e/* PCIe Link Status Register */
-#define PCI_LCR0x5c/* PCIe Link Control Register */
#define FSL_PCIE_CFG_RDY 0x4b0
#endif
#define FSL_PCI_CFG_READY 1 /* Endpoint: allow inbound configuration */
diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
index 76337fe..492efcf 100644
--- a/drivers/pci/fsl_pci_init.c
+++ b/drivers/pci/fsl_pci_init.c
@@ -308,6 +308,15 @@ void fsl_pci_init(struct pci_controller *hose, struct
fsl_pci_info *pci_info)
int enabled, r, inbound = 0;
u16 ltssm;
u8 temp8, pcie_cap;
+ int pcie_cap_pos;
+ int pci_dcr;
+ int pci_dsr;
+ int pci_lsr;
+
+#if defined(CONFIG_FSL_PCIE_DISABLE_ASPM)
+ int pci_lcr;
+#endif
+
volatile ccsr_fsl_pci_t *pci = (ccsr_fsl_pci_t *)cfg_addr;
struct pci_region *reg = hose-regions + hose-region_count;
pci_dev_t dev = PCI_BDF(hose-first_busno, 0, 0);
@@ -380,7 +389,12 @@ void fsl_pci_init(struct pci_controller *hose, struct
fsl_pci_info *pci_info)
hose-region_count++;
/* see if we are a PCIe or PCI controller */
- pci_hose_read_config_byte(hose, dev, FSL_PCIE_CAP_ID, pcie_cap);
+ pcie_cap_pos = pci_hose_find_capability(hose, dev, PCI_CAP_ID_EXP);
+ pci_dcr = pcie_cap_pos + 0x08;
+ pci_dsr = pcie_cap_pos + 0x0a;
+ pci_lsr = pcie_cap_pos + 0x12;
+
+ pci_hose_read_config_byte(hose, dev, pcie_cap_pos, pcie_cap);
#ifdef CONFIG_SRIO_PCIE_BOOT_MASTER
/* boot from PCIE --master */
@@ -419,15 +433,16 @@ void fsl_pci_init(struct pci_controller *hose, struct
fsl_pci_info *pci_info)
* - Master PERR (pci)
* - ICCA (PCIe)
*/
- pci_hose_read_config_dword(hose, dev, PCI_DCR, temp32);
+ pci_hose_read_config_dword(hose, dev, pci_dcr, temp32);
temp32 |= 0xf000e; /* set URR, FER, NFER (but not CER) */
- pci_hose_write_config_dword(hose, dev, PCI_DCR, temp32);
+ pci_hose_write_config_dword(hose, dev, pci_dcr, temp32);
#if defined(CONFIG_FSL_PCIE_DISABLE_ASPM)
+ pci_lcr = pcie_cap_pos + 0x10;
temp32 = 0;
- pci_hose_read_config_dword(hose, dev, PCI_LCR, temp32);
+ pci_hose_read_config_dword(hose, dev, pci_lcr, temp32);
temp32 = ~0x03;/* Disable ASPM */
- pci_hose_write_config_dword(hose, dev, PCI_LCR, temp32);
+ pci_hose_write_config_dword(hose, dev, pci_lcr, temp32);
udelay(1);
#endif
if (pcie_cap == PCI_CAP_ID_EXP) {
@@ -507,7 +522,7 @@ void fsl_pci_init(struct pci_controller *hose, struct
fsl_pci_info *pci_info)
Re: [U-Boot] [PATCH v5] at91: add support for CDU9G25 board
Dear Andreas,
Dne 16.9.2013 10:27, Andreas Bießmann napsal(a):
Dear Jiří Prchal,
On 09/13/2013 04:41 PM, Jiří Prchal wrote:
Dne 13.9.2013 16:10, Andreas Bießmann napsal(a):
On 09/13/2013 03:00 PM, Jiri Prchal wrote:
snip
diff --git a/arch/arm/include/asm/mach-types.h
b/arch/arm/include/asm/mach-types.h
index 440b041..9b274ba 100644
--- a/arch/arm/include/asm/mach-types.h
+++ b/arch/arm/include/asm/mach-types.h
@@ -986,6 +986,7 @@ extern unsigned int __machine_arch_type;
#define MACH_TYPE_VIT_IBOX 3371
#define MACH_TYPE_DM6441_ESP 3372
#define MACH_TYPE_AT91SAM9X5EK 3373
+#define MACH_TYPE_CDU9G25 3373
NAK, please obtain a mach type:
http://www.arm.linux.org.uk/developer/machines/?action=new
Should I register machine? I develop DT only:
NOTE 1:If you are developing a DT-only platform, you do not need to
register a machine type for it.
Please do not register a machine type. Thanks.
Do I need this MACH_TYPE_* at all?
I'm not really familiar with FDT only boards, but I think it is sane to
just use a zero machid then. Could you please check this and if working
just omit the machid setting?
I'm not really familiar with FDT too, but I tested with 0 and it works.
+err_spi_xfer:
+spi_release_bus(slave);
+err_spi_claim_bus:
+spi_free_slave(slave);
+err_spi_setup_slave:
+if (!is_valid_ether_addr(sernum)) {
+eth_random_enetaddr(sernum);
+printf(Using random MAC address %pM\n, sernum);
is that %p formating intended? Shouldn't you print the ethaddr here in
hex rather than the pointer to the memory location?
No, this is no pointer modifier, it's together %pM and it prints ethaddr
like this: 02:22:23:15:86:a5.
Sorry, my fault.
snip
+#define CONFIG_CMD_BOOTZ
+#define CONFIG_OF_LIBFDT
+
+/* general purpose I/O */
+#define CONFIG_ATMEL_LEGACY/* required until (g)pio is fixed */
I doubt you need this for gpio. Could you please check, if it is really
required?
Yes, it's required.
Yes, I knew that, but I have looked many other board files and they use
both GPIO and PIO in one file.
If is necessary I'll re-base it to PIO.
No, nand is not yet prepared for the generic gpio framework. I'll try to
post patches next weeks (for 2014.01), but I'm quite busy right now.
Since your board will also end up in 2014.01 this should go together.
I'll wait for that.
If you have the time I would be grateful if you could prepare patches
for that.
Sorry, but I have look in atmel_nand.c and didn't find any pio. Seems to me
it's prepared to gpio.
So I leave it up to you.
snip
+#define CONFIG_MTD_DEVICE
+#define CONFIG_CMD_MTDPARTS
+#define CONFIG_MTD_PARTITIONS
+#define CONFIG_RBTREE
+#define CONFIG_LZO
+#define CONFIG_CMD_UBI
+#define CONFIG_CMD_UBIFS
+#define CONFIG_CMD_NAND_TRIMFFS
+#define MTDIDS_DEFAULTnand0=nand
+#define MTDPARTS_DEFAULTmtdparts=nand:256k(bootstrap),\
+768k(uboot),256k(ubootenv),\
+4864k(kernel),\
+-(root)
just to mention it:
a) a secondary env is sometimes useful
Is that true? I thought use one copy env, if not then use default.
Well, your point is true, but how about heavily changed env in the
field? If something goes wrong (two bad blocks at worst place, wrong crc
due to too much bit errors, ...) it will fall back to the compiled in
env, which may be completely wrong then.
But it is also true that an enabled secondary env will be read on every
startup and compared to the first env. Also you always need to write two
locations. It depends on your use case, but for me it is careless to
have just one env on NAND.
We use in 99% compiled in env and even if not there is no need to heavily
change env.
snip
+#define CONFIG_BOOTCOMMANDnand read 2100 kernel; bootm
+#define CONFIG_BOOTARGSconsole=ttyS0,115200 ubi.mtd=root \
+root=ubi0:root rootfstype=ubifs rw
+#define CONFIG_SERVERIP10.0.1.1
+#define CONFIG_BOOTFILEkernel_cdu9g25
+#define CONFIG_PREBOOTmtdparts default /* for partitions */
Would you really like to always reset a new mtd partitioning on every
boot to the default one?
Does it mean that I don't need run this command if I like use partitions
in nand commands?
No, not fully. You'll need the environment parameter 'mtdparts' with
contend 'mdtparts=...' and respective mtdids env. This could be set by
the command 'mtdparts default', it will set the compiled in values of
MTDIDS_DEFAULT and MTDPARTS_DEFAULT.
If you like to change the nand partitioning in any way you need to
change the mtdparts env. But when you call 'mtdparts default' afterwards
you will reset this to the default value ...
To avoid this we have in our default environment following setting:
---8---
#define CONFIG_EXTRA_ENV_SETTINGS \
mtdparts= MTDPARTS_DEFAULT \0 \
mtdids= MTDIDS_DEFAULT \0 \
...
---8---
Additionally we avoid to use the 'mtdparts default' command.
Re: [U-Boot] [PATCH v1 2/2] ti814x_evm: enable support for NAND
On Tue, Aug 06, 2013 at 01:45:08PM +0530, Pekon Gupta wrote: ti814x_evm has on-board socket for using Micron (MT29Fxx) family of NAND devices to GPMC interface. This patch - adds NAND related pin-mux configuration for same - adds #defines for NAND partitions to TI814x configs - enables support for NAND in TI814x configs [snip] @@ -186,6 +193,14 @@ #define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 0x200 /* 256 KB */ #define CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION1 #define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAMEu-boot.img + +#ifdef CONFIG_SPL_OS_BOOT +/* nand */ +#define CONFIG_CMD_SPL_NAND_OFS0x00 /* end of u-boot */ +#define CONFIG_SYS_NAND_SPL_KERNEL_OFFS0x28 +#define CONFIG_CMD_SPL_WRITE_SIZE 0x1000 +#endif Since you aren't adding the SD/MMC defines as well, nor setting SPL_OS_BOOT, lets drop these. Sorry but dint get your feedback. Following are used in SPL boot for loading env and kernel in falcon mode. Referring: $UBOOT/common/spl/spl_nand.c - CONFIG_SYS_NAND_SPL_KERNEL_OFFS - CONFIG_CMD_SPL_WRITE_SIZE - CONFIG_CMD_SPL_NAND_OFS May be I put them in wrong place in include/configs/ti814x.h but these are required for NAND SPL boot. Please confirm ? @@ -242,5 +283,32 @@ #define CONFIG_PHY_ADDR1 #define CONFIG_PHY_ET1011C #define CONFIG_PHY_ET1011C_TX_CLK_FIX +#define CONFIG_NAND +/* NAND support */ +#ifdef CONFIG_NAND +#define CONFIG_MTD_NAND_OMAP_BCH +#define CONFIG_CMD_NAND +#define CONFIG_CMD_MTDPARTS +#define MTDIDS_DEFAULT nand0=omap2-nand.0 +#define MTDPARTS_DEFAULT mtdparts=omap2- nand.0:128k(SPL), \ + 128k(u-boot-spl), \ + 2M(u-boot-main), \ + 128k(u-boot-env),4M(kernel),- (rootfs) Lets get the partition tables right, we've still got 4 locations where ROM checks for something, so lets use those for SPL, then U-Boot, then U-Boot Env (redundant as well, please), and a block saved off for device tree/SPL OS args support, then kernel, rootfs. I think TI814x ROM use different NAND layout than AM33xx devices. I used following NAND layout given in link below as reference: http://processors.wiki.ti.com/index.php/TI81XX_PSP_UBOOT_User_Guide#EVM_Switch_Settings These devices belong to omap3 family, but now are merged with am33xx. +#define CONFIG_NAND_OMAP_GPMC +#define GPMC_NAND_ECC_LP_x16_LAYOUT1 +#define NAND_BASE (0x0800) Don't need NAND_BASE. Ok thanks. - Also removing GPMC_NAND_ECC_LP_x16_LAYOUT as predefined nand_ecclayouts in omap_gpmc.h are not used anymore. - Trying to remove dependency on CONFIG_NAND_OMAP_GPMC as except legacy devices all new platform support ELM based ECC schemes. +#define CONFIG_SYS_NAND_BASE (0x0800)/* physical address */ + /* to access nand at */ + /* CS0 */ +#define CONFIG_SYS_MAX_NAND_DEVICE 1 +/* Max number of NANDdevices */ +#define CONFIG_SYS_NAND_BOOT +#if !defined(CONFIG_SPI_BOOT) +#undef CONFIG_ENV_IS_NOWHERE +#define CONFIG_ENV_IS_IN_NAND +#define CONFIG_ENV_OFFSET 0x26 /* environment starts here */ +#define CONFIG_SYS_ENV_SECT_SIZE (128 10) /* 128 KiB */ +#endif +#endif And we don't support SPI boot or anything here, so lets just always do env on NAND until we have support for other things as well. Thanks! Ok. yes I'll remove them.. with regards, pekon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] powerpc/eeprom: update MAX_NUM_PORTS to adapt non-256-bytes EEPROM
-Original Message- From: sun york-R58495 Sent: Friday, September 13, 2013 11:13 PM To: Liu Shengzhou-B36685 Cc: u-boot@lists.denx.de Subject: Re: [PATCH 2/4] powerpc/eeprom: update MAX_NUM_PORTS to adapt non-256- bytes EEPROM I would appreciate it if you update the version number and put a change log under the --- line, even there is no change. With a clear version number and change log, reviewers will be able to identify this is a resend and not spending much time on it. You are also encouraged to mark previous patch as superseded. York Sorry for missing the updated version number, will keep it later. Previous patch has been marked as superseded. Thanks, Shengzhou ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Cosmetic: Fix a number of typoes, no functional changes.
Hi Robert, On Sun, 15 Sep 2013 18:49:23 -0400 (EDT), Robert P. J. Day rpj...@crashcourse.ca wrote: On Sun, 15 Sep 2013, Fabio Estevam wrote: On Sun, Sep 15, 2013 at 7:10 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: Fix various misspellings of things like environment, kernel, default and volatile, and throw in a couple grammar fixes. Isn't there a typo in the subject itself (typoes) ? i believe it's one of those matters of personal taste whether you spell it typos or typoes. but i can resubmit if that's the standard here. Well, I'd slightly out of my realm here as I usually do rigid pedantism in French only :), but it seems like the correct plural form of typo is typos, because, unlike tomato or hero, typo is not a word in itself but an abbreviation, and thus follows the same rule as photo or radio does [1]. Thus I vote for fixing typoes into typos. rday Amicalement, -- Albert. [1] ... or should it be do? :) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Cosmetic: Fix a number of typoes, no functional changes.
(possible resend to fix... a typo. No kidding.) Hi Robert, On Sun, 15 Sep 2013 18:49:23 -0400 (EDT), Robert P. J. Day rpj...@crashcourse.ca wrote: On Sun, 15 Sep 2013, Fabio Estevam wrote: On Sun, Sep 15, 2013 at 7:10 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: Fix various misspellings of things like environment, kernel, default and volatile, and throw in a couple grammar fixes. Isn't there a typo in the subject itself (typoes) ? i believe it's one of those matters of personal taste whether you spell it typos or typoes. but i can resubmit if that's the standard here. Well, I'm slightly out of my realm here as I usually do rigid pedantism in French only :), but it seems like the correct plural form of typo is typos, because, unlike tomato or hero, typo is not a word in itself but an abbreviation, and thus follows the same rule as photo or radio does [1]. Thus I vote for fixing typoes into typos. rday Amicalement, -- Albert. [1] ... or should it be do? :) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Cosmetic: Fix a number of typoes, no functional changes.
On Mon, 16 Sep 2013, Albert ARIBAUD wrote: (possible resend to fix... a typo. No kidding.) Hi Robert, On Sun, 15 Sep 2013 18:49:23 -0400 (EDT), Robert P. J. Day rpj...@crashcourse.ca wrote: On Sun, 15 Sep 2013, Fabio Estevam wrote: On Sun, Sep 15, 2013 at 7:10 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: Fix various misspellings of things like environment, kernel, default and volatile, and throw in a couple grammar fixes. Isn't there a typo in the subject itself (typoes) ? i believe it's one of those matters of personal taste whether you spell it typos or typoes. but i can resubmit if that's the standard here. Well, I'm slightly out of my realm here as I usually do rigid pedantism in French only :), but it seems like the correct plural form of typo is typos, because, unlike tomato or hero, typo is not a word in itself but an abbreviation, and thus follows the same rule as photo or radio does [1]. Thus I vote for fixing typoes into typos. ok, will resubmit as [PATCH v2] shortly. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] worth correcting spelling of redundand?
Hi Robert, On Mon, 16 Sep 2013 04:30:09 -0400 (EDT), Robert P. J. Day rpj...@crashcourse.ca wrote: again, my pedantry getting the best of me but it makes me cringe whenever i run across the spelling redundand (tree-wide search): common/env_ubi.c:#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT [...] this obviously isn't a cosmetic change as it's used in numerous #defines, but if it's done all at once, it should be safe. i can submit a patch unless people feel it's simply too disruptive. As a general rule, you don't need to ask before submitting a patch unless you're really doing intrusive and potentially disruptive work and want some feedback without risking getting bad code mainlined, in which case... you'd still submit a patch, only tagged RFC. :) IOW: just submit the patch; after all, the worst possible outcome is only a NAK if you missed something important. Here, just submit a patch with a summary line / subject like fix CONFIG_SYS_REDUNDAND_ENVIRONMENT typo. rday Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Cosmetic: Fix a number of typos, no functional changes.
Fix various misspellings of things like environment, kernel, default and volatile, and throw in a couple grammar fixes. Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- ok, here's version two ... diff --git a/Makefile b/Makefile index 1365db6..f55f8c0 100644 --- a/Makefile +++ b/Makefile @@ -45,13 +45,13 @@ endif # # -# U-boot build supports producing a object files to the separate external +# U-boot build supports generating object files in a separate external # directory. Two use cases are supported: # # 1) Add O= to the make command line # 'make O=/tmp/build all' # -# 2) Set environement variable BUILD_DIR to point to the desired location +# 2) Set environment variable BUILD_DIR to point to the desired location # 'export BUILD_DIR=/tmp/build' # 'make' # @@ -59,7 +59,7 @@ endif # 'export BUILD_DIR=/tmp/build' # './MAKEALL' # -# Command line 'O=' setting overrides BUILD_DIR environent variable. +# Command line 'O=' setting overrides BUILD_DIR environment variable. # # When none of the above methods is used the local build is performed and # the object files are placed in the source directory. diff --git a/README b/README index ccd47fa..13e3ac0 100644 --- a/README +++ b/README @@ -3360,7 +3360,7 @@ Configuration Settings: the Linux kernel; all data that must be processed by the Linux kernel (bd_info, boot arguments, FDT blob if used) must be put below this limit, unless bootm_low - enviroment variable is defined and non-zero. In such case + environment variable is defined and non-zero. In such case all data for the Linux kernel must be between bootm_low and bootm_low + CONFIG_SYS_BOOTMAPSZ. The environment variable bootm_mapsize will override the value of @@ -3473,7 +3473,7 @@ Configuration Settings: - CONFIG_ENV_FLAGS_LIST_DEFAULT - CONFIG_ENV_FLAGS_LIST_STATIC - Enable validation of the values given to enviroment variables when + Enable validation of the values given to environment variables when calling env set. Variables can be restricted to only decimal, hexadecimal, or boolean. If CONFIG_CMD_NET is also defined, the variables can also be restricted to IP address or MAC address. diff --git a/arch/arm/cpu/arm926ejs/at91/eflash.c b/arch/arm/cpu/arm926ejs/at91/eflash.c index 3e21cdb..3f39264 100644 --- a/arch/arm/cpu/arm926ejs/at91/eflash.c +++ b/arch/arm/cpu/arm926ejs/at91/eflash.c @@ -28,7 +28,7 @@ * by u-Boot commands. * * Note: Redundant environment will not work in this flash since - * it does use partial page writes. Make sure the environent spans + * it does use partial page writes. Make sure the environment spans * whole pages! */ diff --git a/arch/arm/cpu/arm926ejs/kirkwood/cpu.c b/arch/arm/cpu/arm926ejs/kirkwood/cpu.c index cde3172..d4711c0 100644 --- a/arch/arm/cpu/arm926ejs/kirkwood/cpu.c +++ b/arch/arm/cpu/arm926ejs/kirkwood/cpu.c @@ -302,7 +302,7 @@ int arch_cpu_init(void) /* * Configures the I/O voltage of the pads connected to Egigabit * Ethernet interface to 1.8V -* By defult it is set to 3.3V +* By default it is set to 3.3V */ reg = readl(KW_REG_MPP_OUT_DRV_REG); reg |= (1 7); diff --git a/board/RPXlite_dw/README b/board/RPXlite_dw/README index 14296b2..9e2d0f4 100644 --- a/board/RPXlite_dw/README +++ b/board/RPXlite_dw/README @@ -87,9 +87,9 @@ u-boot ~~ -A word on the U-Boot enviroment variable setting and usage : +A word on the U-Boot environment variable setting and usage : -In the beginning, you could just need very simple defult environment variable setting, +In the beginning, you could just need very simple default environment variable setting, like[include/configs/RPXlite.h] : #define CONFIG_BOOTCOMMAND \ diff --git a/board/freescale/mx28evk/README b/board/freescale/mx28evk/README index 524f3fc..0389a1d 100644 --- a/board/freescale/mx28evk/README +++ b/board/freescale/mx28evk/README @@ -29,11 +29,11 @@ Environment Storage There are two targets for mx28evk: -make mx28evk_config - store enviroment variables into MMC +make mx28evk_config - store environment variables into MMC or -make mx28evk_nand_config - store enviroment variables into NAND flash +make mx28evk_nand_config - store environment variables into NAND flash Choose the target accordingly. diff --git a/board/sbc8349/README b/board/sbc8349/README index 2c35919..e2d60cc 100644 --- a/board/sbc8349/README +++ b/board/sbc8349/README @@ -50,7 +50,7 @@ is a summary of that information: trying to preserve your old environment settings and user flash). - Set the start address of the erase/flash
Re: [U-Boot] [PATCH v4 1/5] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform
(apologies for multiple mails, but mails from my client were rejected
due to some client configuration)
On Tue, 2013-09-03 at 11:26 +0530, Pekon Gupta wrote:
diff --git a/doc/README.nand b/doc/README.nand
index 913e9b5..f72f618 100644
--- a/doc/README.nand
+++ b/doc/README.nand
@@ -169,6 +169,19 @@ Configuration Options:
Please convert your driver even if you don't need the extra
flexibility, so that one day we can eliminate the old mechanism.
+ CONFIG_SYS_NAND_ONFI_DETECTION
+ Enables detection of ONFI compliant devices during probe.
+ And fetching device parameters flashed on device, by parsing
+ ONFI parameter page.
I don't see this used anywhere in the patch (defined in config headers,
yes, but not ifdeffed).
What does DETECTION add here, versus just CONFIG_NAND_ONFI?
It should be CONFIG rather than CONFIG_SYS because it just controls
whether the support is built, not making an assertion about the
hardware, right?
This is not the new define, it was already there in generic code (nand_base.c)
But not documented, so I documented it and enabled it for am33xx platform
Please refer: $UBOOT/drivers/mtd/nand/nand_base.c
It was added as part of following commit
commit 0272c718ba69c60a9d719db6806971d98db98090
Author: Florian Fainelli flor...@openwrt.org
AuthorDate: 2011-02-25
+ CONFIG_SYS_NAND_ECCSCHEME
+ specifies which ECC scheme to use.
Specifies it how? What are the possible values?
If the answer involves enum omap_ecc, then OMAP should be
somewhere in the name.
I wanted this define to be generic for all NAND drivers. Therefore CONFIG_SYS_
But I don't know how other drivers would use this.
For AM335x its updated in Patch:
[PATCH v5 5/5] board/ti/am335x/README: update for NAND boot
Instead, should I make it more generic for all SoC ? like
CONFIG_SYS_NAND_ECCSCHEME can take in following strings defining
ECC scheme used by NAND driver in SPL boot:
ham1 - 1 bit hamming code
bch4 - 4-bit BCH ecc code
bch8 - 8-bit BCH ecc code
bch16 - 16-bit BCH ecc code
+/**
+ * omap_select_ecc_scheme - configures driver for particular ecc-scheme
+ * @nand: NAND chip device structure
+ * @ecc_scheme: ecc scheme to configure
+ * @pagesize: number of main-area bytes per page of NAND device
+ * @oobsize: number of OOB/spare bytes per page of NAND device
+ */
[snip]
+ default:
+ debug(nand: error: ecc scheme not enabled or
supported\n);
+ return -EINVAL;
+ }
This will result in NAND_ECC_NONE and likely an eventual NULL pointer
dereference if a bad value is passed and the -EINVAL return path is
taken.
OK, I now see that you've got the caller patching this up in the error
case, but that's awkward and error prone.
Sorry, din't understand your feedback here.
omap_select_ecc_scheme() is common function which is used for
- changing ECC scheme if 'nandecc' like utility is needed later
- selecting ECC scheme during probe.
This function populates all necessary fields in struct *nand_chip
for nand driver to work. During probe (both SPL and u-boot),
'CONFIG_SYS_NAND_ECCSCHEME' is used to determine the ecc-scheme.
'default' statement protects the driver from any invalid or un-supported
ECC scheme selected by user in his board file. So that driver probe cleanly
exits probe instead of causing an exception.
Can you please elaborate, what I'm missing here ?
@@ -767,67 +811,41 @@ void omap_nand_switch_ecc(uint32_t hardware,
uint32_t eccstrength)
{
struct nand_chip *nand;
struct mtd_info *mtd;
+ struct nand_bch_priv *bch;
+ int err = 0;
if (nand_curr_device 0 ||
nand_curr_device = CONFIG_SYS_MAX_NAND_DEVICE ||
!nand_info[nand_curr_device].name) {
- printf(Error: Can't switch ecc, no devices available\n);
+ printf(nand: error: no devices available\n);
return;
}
Why are you making the error message less specific?
There is already another error message in board_nand_init() which will be
flagged when there is problem in selecting ECC.
printf(nand: error: cannot select ecc scheme\n);
But thanks, you pointed out a bug, I should return -ENODEV here,
Otherwise caller would not know that ecc-scheme could not be changed.
diff --git a/include/configs/tricorder.h b/include/configs/tricorder.h
index a9b2714..2b01486 100644
--- a/include/configs/tricorder.h
+++ b/include/configs/tricorder.h
@@ -298,6 +298,8 @@
#define CONFIG_SYS_NAND_ECCSIZE512
#define CONFIG_SYS_NAND_ECCBYTES 13
+#define CONFIG_SYS_NAND_ECCSCHEME 3
+#define CONFIG_SYS_NAND_ONFI_DETECTION
What does 3 mean? Please use a symbolic name.
For AM335x this is updated in board/ti/am335x/README as part of
following patch:
[PATCH v5 5/5] board/ti/am335x/README: update for NAND boot
but would it be better to use strings like bch8 as mentioned above ?
with regards, pekon
[U-Boot] [PATCH 4/5] common/fdt_support.c: avoid unintended return from fdt_fixup_memory_banks()
fdt_fixup_memory_banks() will add and update /memory node in
device tree blob. In the case that /memory node doesn't exist,
after adding a new one, this function returns error.
The correct behavior should be continuing to update its properties.
Signed-off-by: Miao Yan miao@windriver.com
---
common/fdt_support.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index b034c98..a97a705 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -400,10 +400,11 @@ int fdt_fixup_memory_banks(void *blob, u64 start[], u64
size[], int banks)
nodeoffset = fdt_path_offset(blob, /memory);
if (nodeoffset 0) {
nodeoffset = fdt_add_subnode(blob, 0, memory);
- if (nodeoffset 0)
+ if (nodeoffset 0) {
printf(WARNING: could not create /memory: %s.\n,
fdt_strerror(nodeoffset));
- return nodeoffset;
+ return nodeoffset;
+ }
}
err = fdt_setprop(blob, nodeoffset, device_type, memory,
sizeof(memory));
--
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/5] common/cmd_bootm.c: seperate do_bootm_vxworks related code from CONFIG_CMD_ELF.
do_bootm_vxworks now is available under the configuration option
CONFIG_BOOTM_VXWORKS, thus aligned with other operating systems
that supported by bootm command. The bootvx command still depneds
on CONFIG_CMD_ELF.
Signed-off-by: Miao Yan miao@windriver.com
---
common/cmd_bootm.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index b07b0f4..973c9f5 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -120,8 +120,10 @@ static boot_os_fn do_bootm_ose;
#if defined(CONFIG_BOOTM_PLAN9)
static boot_os_fn do_bootm_plan9;
#endif
-#if defined(CONFIG_CMD_ELF)
+#if defined(CONFIG_BOOTM_VXWORKS)
static boot_os_fn do_bootm_vxworks;
+#endif
+#if defined(CONFIG_CMD_ELF)
static boot_os_fn do_bootm_qnxelf;
int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
int do_bootelf(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
@@ -149,8 +151,10 @@ static boot_os_fn *boot_os[] = {
#if defined(CONFIG_BOOTM_PLAN9)
[IH_OS_PLAN9] = do_bootm_plan9,
#endif
-#if defined(CONFIG_CMD_ELF)
+#if defined(CONFIG_BOOTM_VXWORKS)
[IH_OS_VXWORKS] = do_bootm_vxworks,
+#endif
+#if defined(CONFIG_CMD_ELF)
[IH_OS_QNX] = do_bootm_qnxelf,
#endif
#ifdef CONFIG_INTEGRITY
@@ -1683,7 +1687,7 @@ static int do_bootm_plan9(int flag, int argc, char *
const argv[],
}
#endif /* CONFIG_BOOTM_PLAN9 */
-#if defined(CONFIG_CMD_ELF)
+#if defined(CONFIG_BOOTM_VXWORKS)
static int do_bootm_vxworks(int flag, int argc, char * const argv[],
bootm_headers_t *images)
{
@@ -1703,11 +1707,16 @@ static int do_bootm_vxworks(int flag, int argc, char *
const argv[],
sprintf(str, %lx, images-ep); /* write entry-point into string */
setenv(loadaddr, str);
+
+#if defined(CONFIG_CMD_ELF)
do_bootvx(NULL, 0, 0, NULL);
+#endif
return 1;
}
+#endif
+#if defined(CONFIG_CMD_ELF)
static int do_bootm_qnxelf(int flag, int argc, char * const argv[],
bootm_headers_t *images)
{
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5] Add device tree support for VxWorks
Hello Wolfgang and All, The next release of VxWorks will adopt device tree as its hardware description mechanism (for PowerPC and ARM), thus requiring boot interface changes for these two architechtures. And we would like to better support U-Boot with our operating system, because almost all the PowerPC and ARM boards that we support come with U-Boot pre-flashed and we would like to create better experience for our users. Currently, U-Boot provides a 'bootvx' command (bootm internally uses bootvx) to load and run VxWorks image (for both ELF format or raw binary), for example: bootvx 0x100 or just: bootvx if the environmental variable 'loadaddr' is set. The 'bootvx' will setup bootline and jump to the VxWorks entry using the following calling convention: (void)(*entry)(int arg /* 0 */) With the new VxWorks, the kernel entry interface for PowerPC is going to be changed to conform to the ePAPR standard, and for ARM, we need deivce tree's physical address to be passed to the kernel like this: (void)(*entry)(void *fdt_addr) And VxWorks bootline will be saved into deivce tree's 'bootargs' node as specified by the ePAPR (for both PowerPC and ARM). The 'bootvx' commnad stays unchaged, and is still avalaible under the configuration option CONFIG_CMD_ELF for older kernels. A new option CONFIG_BOOTM_VXWORKS is added for bootm to align with other bootm supported operating systems. So the do_bootm_vxworks will work as below: #if (libfdt (ppc || arm)) if (using device tree) boot_vxworks_with_device_tree else #endif bootvx(...); The following patches are rebased on today's master branch (commit 6856254fc05d67f874d08a534724c842f93a605f). Thanks, Miao Yan (5): common/cmd_bootm.c: seperate do_bootm_vxworks related code from CONFIG_CMD_ELF. common/config_defaults.h: make CONFIG_BOOTM_VXWORKS default configuration common/cmd_bootm: extend do_bootm_vxworks to support the new VxWorks boot interface. common/fdt_support.c: avoid unintended return from fdt_fixup_memory_banks() doc/README.vxworks: add a document describing the new VxWorks boot interface arch/arm/lib/bootm.c | 21 +++ arch/powerpc/lib/bootm.c | 52 ++ common/cmd_bootm.c| 90 + common/fdt_support.c |5 ++- doc/README.vxworks| 34 + include/common.h |4 ++ include/config_defaults.h |1 + include/vxworks.h |2 + 8 files changed, 200 insertions(+), 9 deletions(-) create mode 100644 doc/README.vxworks -- 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/5] common/config_defaults.h: make CONFIG_BOOTM_VXWORKS default configuration
Signed-off-by: Miao Yan miao@windriver.com --- include/config_defaults.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/config_defaults.h b/include/config_defaults.h index 567b46c..ad08c1d 100644 --- a/include/config_defaults.h +++ b/include/config_defaults.h @@ -14,6 +14,7 @@ #define CONFIG_BOOTM_NETBSD 1 #define CONFIG_BOOTM_PLAN9 1 #define CONFIG_BOOTM_RTEMS 1 +#define CONFIG_BOOTM_VXWORKS 1 #define CONFIG_GZIP 1 #define CONFIG_ZLIB 1 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] doc/README.vxworks: add a document describing the new VxWorks boot interface
Signed-off-by: Miao Yan miao@windriver.com --- doc/README.vxworks | 34 ++ 1 file changed, 34 insertions(+) create mode 100644 doc/README.vxworks diff --git a/doc/README.vxworks b/doc/README.vxworks new file mode 100644 index 000..08c3813 --- /dev/null +++ b/doc/README.vxworks @@ -0,0 +1,34 @@ +From VxWorks 6.9+ (not include 6.9), VxWorks starts adopting device tree as its hardware +decription mechansim (for PowerPC and ARM), thus requiring boot interface changes. +This section will describe the new interface. + +For PowerPC, the calling convention of the new VxWorks entry point conforms to the ePAPR standard[1], +which is shown below (see ePAPR for more details): + +void (*kernel_entry)(ulong fdt_addr, + ulong r4 /* 0 */, ulong r5 /* 0 */, + ulong r6 /* EPAPR_MAGIC */ + ulong r7 /* boot IMA */, + ulong r8 /* 0 */, ulong r9 /* 0 */) + +For ARM, the calling convention is show below: + +void (*kernel_entry)(void *fdt_addr) + +When booting new VxWorks kernel (uImage format), the parameters passed to bootm is like below: + +bootm kernel image address - device tree address + +for example, booting p2020rdb kernel: (kernel is placed at address 0x100 and device tree blob +is places at address 0xf00) + +setenv bootargs gei(0,0). +tftp 0x100 vxWorks.uboot +tftp 0xf00 p2020rdb.dtb +bootm 0x100 - 0xf00 + +The second parameter to bootm is always '-' for VxWorks (VxWorks kernel doesn't make use of initrd) + +The bootvx command still works as it was for older kernels. + +[1] www.power.org -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] common/cmd_bootm: extend do_bootm_vxworks to support the new VxWorks boot interface.
The next version VxWorks adopts device tree (for PowerPC and ARM) as its
hardware
description mechanism. For PowerPC, the boot interface conforms to
the ePAPR standard, which is:
void (*kernel_entry)(ulong fdt_addr,
ulong r4 /* 0 */,
ulong r5 /* 0 */,
ulong r6 /* EPAPR_MAGIC */, ulong r7 /* IMA size */,
ulong r8 /* 0 */, ulong r9 /* 0 */)
For ARM, the boot interface is:
void (*kernel_entry)(void *fdt_addr)
Signed-off-by: Miao Yan miao@windriver.com
---
arch/arm/lib/bootm.c | 21 +
arch/powerpc/lib/bootm.c | 52
common/cmd_bootm.c | 75 +++---
include/common.h |4 +++
include/vxworks.h|2 ++
5 files changed, 150 insertions(+), 4 deletions(-)
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index eefb456..da432c6 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -308,3 +308,24 @@ int bootz_setup(ulong image, ulong *start, ulong *end)
}
#endif /* CONFIG_CMD_BOOTZ */
+
+#if defined(CONFIG_BOOTM_VXWORKS) defined(CONFIG_OF_LIBFDT)
+void boot_prep_vxworks(bootm_headers_t *images)
+{
+ int off;
+
+ assert(images-ft_addr);
+
+ off = fdt_path_offset(images-ft_addr, /memory);
+ if (off 0) {
+ if (arch_fixup_memory_node(images-ft_addr))
+ puts(## WARNING: fixup memory failed!\n);
+ }
+ cleanup_before_linux();
+}
+void boot_jump_vxworks(bootm_headers_t *images)
+{
+ /* ARM VxWorks requires device tree physical address to be passed */
+ ((void (*)(void *))images-ep)(images-ft_addr);
+}
+#endif
diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
index e7153b0..ebd42b5 100644
--- a/arch/powerpc/lib/bootm.c
+++ b/arch/powerpc/lib/bootm.c
@@ -277,3 +277,55 @@ static void set_clocks_in_mhz (bd_t *kbd)
#endif /* CONFIG_MPC5xxx */
}
}
+
+#if defined(CONFIG_BOOTM_VXWORKS) defined(CONFIG_OF_LIBFDT)
+void boot_prep_vxworks(bootm_headers_t *images)
+{
+ int off;
+ u64 base, size;
+
+ assert(images-ft_addr);
+
+ base = (u64)gd-bd-bi_memstart;
+ size = (u64)gd-bd-bi_memsize;
+
+ off = fdt_path_offset(images-ft_addr, /memory);
+ if (off 0)
+ fdt_fixup_memory(images-ft_addr, base, size);
+
+#if defined(CONFIG_MP)
+#if defined(CONFIG_MPC85xx)
+ ft_fixup_cpu(images-ft_addr, base + size);
+ ft_fixup_num_cores(images-ft_addr);
+#elif defined(CONFIG_MPC86xx)
+ off = fdt_add_mem_rsv(images-ft_addr,
+ determin_mp_bootpg(NULL), (u64)4096);
+ if (off 0)
+ printf(## WARNING %s: %s\n, __func__, fdt_strerror(off));
+ ft_fixup_num_cores(images-ft_addr);
+#endif
+ flush_cache((unsigned long)images-ft_addr, images-ft_len);
+#endif
+}
+
+void boot_jump_vxworks(bootm_headers_t *images)
+{
+ /* PowerPC VxWorks boot interface conforms to the ePAPR standard
+* general purpuse registers:
+*
+* r3: Effective address of the device tree image
+* r4: 0
+* r5: 0
+* r6: ePAPR magic value
+* r7: shall be the size of the boot IMA in bytes
+* r8: 0
+* r9: 0
+* TCR: WRC = 0, no watchdog timer reset will occur
+*/
+ WATCHDOG_RESET();
+
+ ((void (*)(void *, ulong, ulong, ulong,
+ ulong, ulong, ulong))images-ep)(images-ft_addr,
+ 0, 0, EPAPR_MAGIC, getenv_bootm_mapsize(), 0, 0);
+}
+#endif
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 973c9f5..245c0c9 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -23,6 +23,10 @@
#include asm/io.h
#include linux/compiler.h
+#if defined(CONFIG_BOOTM_VXWORKS)
+#include vxworks.h
+#endif
+
#if defined(CONFIG_CMD_USB)
#include usb.h
#endif
@@ -337,7 +341,8 @@ static int bootm_find_other(cmd_tbl_t *cmdtp, int flag, int
argc,
if (((images.os.type == IH_TYPE_KERNEL) ||
(images.os.type == IH_TYPE_KERNEL_NOLOAD) ||
(images.os.type == IH_TYPE_MULTI))
- (images.os.os == IH_OS_LINUX)) {
+ (images.os.os == IH_OS_LINUX ||
+images.os.os == IH_OS_VXWORKS)) {
if (bootm_find_ramdisk(flag, argc, argv))
return 1;
@@ -1688,10 +1693,61 @@ static int do_bootm_plan9(int flag, int argc, char *
const argv[],
#endif /* CONFIG_BOOTM_PLAN9 */
#if defined(CONFIG_BOOTM_VXWORKS)
+
+#if defined(CONFIG_OF_LIBFDT) (defined(CONFIG_PPC) || defined(CONFIG_ARM))
+void do_bootvx_fdt(bootm_headers_t *images)
+{
+ int ret;
+ char *bootline;
+ ulong of_size = images-ft_len;
+ char **of_flat_tree = images-ft_addr;
+ struct lmb *lmb = images-lmb;
+
+ assert(*of_flat_tree);
+
+ boot_fdt_add_mem_rsv_regions(lmb, *of_flat_tree);
+
+ ret = boot_relocate_fdt(lmb,
Re: [U-Boot] *** [u-boot] Error 139 when config NAND relative setting
On 09/13/2013 02:54 AM, Hsin-Hsiang Tseng wrote: Hello, nice to meet everyone. I am new to U-boot development world. i have a s5pv310 soc dk board, and i config. it as origen board. i want to use nand command in u-boot, so i add blow setting in origen.h /*enable nand command*/ #define CONFIG_CMD_NAND #define CONFIG_SYS_MAX_NAND_DEVICE 1 #define CONFIG_SYS_NAND_MAX_CHIPS 1 #define CONFIG_SYS_NAND_SELF_INIT #define CONFIG_SYS_NAND_BASE 0x0CE0 but i got error message about ***[U-boot] Error 139. After searched some solution, some said that Error 139 is the cross compile version is too low. but my cross compile is gcc-arm-none-eabi-4_6-2012q2, i think it is not the version problem. No, its not a version problem. If you look at the output from the link command, you'll see: /usr/v310/uboot_linaro/u-boot-linaro/drivers/mtd/nand/nand.c:104: undefined reference to `board_nand_init' You're missing board_nand_init function... without the nand relative config before i could build u-boot without any problem. could somebody give me some points to fix this error. thanks. ps. i don't know if i could consult building problem here. If u-boot mail-list is not proper to receive building problem please let me know. thanks again. drivers/mtd/nand/libnand.o: In function `nand_init': /usr/v310/uboot_linaro/u-boot-linaro/drivers/mtd/nand/nand.c:104: undefined reference to `board_nand_init' /usr/v310/toolchain/gcc-arm-none-eabi-4_6-2012q2/bin/arm-none-eabi-ld.bfd: BFD (GNU Tools for ARM Embedded Processors) 2.21.1.20120613 assertion fail /home/build/work/jenkins-daily-build/src/binutils/bfd/elf32-arm.c:12274 /usr/v310/toolchain/gcc-arm-none-eabi-4_6-2012q2/bin/arm-none-eabi-ld.bfd: BFD (GNU Tools for ARM Embedded Processors) 2.21.1.20120613 assertion fail /home/build/work/jenkins-daily-build/src/binutils/bfd/elf32-arm.c:12511 /bin/bash: line 1: 3818 Segmentation fault /usr/v310/toolchain/gcc-arm-none-eabi-4_6-2012q2/bin/arm-none-eabi-ld.bfd -pie -T u-boot.lds -Bstatic -Ttext 0x43E0 $UNDEF_LST arch/arm/cpu/armv7/start.o --start-group api/libapi.o arch/arm/cpu/armv7/exynos/libexynos.o arch/arm/cpu/armv7/libarmv7.o arch/arm/cpu/armv7/s5p-common/libs5p-common.o arch/arm/lib/libarm.o board/samsung/common/libsamsung.o common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o drivers/dfu/libdfu.o drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o drivers/usb/ulpi/libusb_ulpi.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o fs/cbfs/libcbfs.o fs/cramfs/libcramfs.o fs/ext4/libext4fs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/libfs.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o fs/zfs/libzfs.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o test/libtest.o board/samsung/origen/liborigen.o --end-group /usr/v310/uboot_linaro/u-boot-linaro/arch/arm/lib/eabi_compat.o -L /usr/v310/toolchain/gcc-arm-none-eabi-4_6-2012q2/bin/../lib/gcc/arm-none-eabi/4.6.2 -lgcc -Map u-boot.map -o u-boot make[1]: *** [u-boot] Error 139 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Peter Barada peter.bar...@logicpd.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix numerous misspellings of redundand and REDUNDAND.
Do a global spelling fix for all spellings of redundand, which is a
functional change since it includes the variable
CONFIG_SYS_REDUNDAND_ENVIRONMENT.
Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca
---
compile-tested, configured for am335x_boneblack_config.
diff --git a/common/env_embedded.c b/common/env_embedded.c
index 91d8ba3..f2953bd 100644
--- a/common/env_embedded.c
+++ b/common/env_embedded.c
@@ -77,7 +77,7 @@
#include env_default.h
#ifdef CONFIG_ENV_ADDR_REDUND
-env_t redundand_environment __PPCENV__ = {
+env_t redundant_environment __PPCENV__ = {
0, /* CRC Sum: invalid */
0, /* Flags: invalid */
{
diff --git a/common/env_ubi.c b/common/env_ubi.c
index f24a96c..fabbc6b 100644
--- a/common/env_ubi.c
+++ b/common/env_ubi.c
@@ -31,7 +31,7 @@ int env_init(void)
}
#ifdef CONFIG_CMD_SAVEENV
-#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT
+#ifdef CONFIG_SYS_REDUNDANT_ENVIRONMENT
static unsigned char env_flags;
int saveenv(void)
@@ -82,7 +82,7 @@ int saveenv(void)
return 0;
}
-#else /* ! CONFIG_SYS_REDUNDAND_ENVIRONMENT */
+#else /* ! CONFIG_SYS_REDUNDANT_ENVIRONMENT */
int saveenv(void)
{
ALLOC_CACHE_ALIGN_BUFFER(env_t, env_new, 1);
@@ -114,10 +114,10 @@ int saveenv(void)
puts(done\n);
return 0;
}
-#endif /* CONFIG_SYS_REDUNDAND_ENVIRONMENT */
+#endif /* CONFIG_SYS_REDUNDANT_ENVIRONMENT */
#endif /* CONFIG_CMD_SAVEENV */
-#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT
+#ifdef CONFIG_SYS_REDUNDANT_ENVIRONMENT
void env_relocate_spec(void)
{
ALLOC_CACHE_ALIGN_BUFFER(char, env1_buf, CONFIG_ENV_SIZE);
@@ -179,7 +179,7 @@ void env_relocate_spec(void)
env_flags = ep-flags;
env_import((char *)ep, 0);
}
-#else /* ! CONFIG_SYS_REDUNDAND_ENVIRONMENT */
+#else /* ! CONFIG_SYS_REDUNDANT_ENVIRONMENT */
void env_relocate_spec(void)
{
ALLOC_CACHE_ALIGN_BUFFER(char, buf, CONFIG_ENV_SIZE);
@@ -201,4 +201,4 @@ void env_relocate_spec(void)
env_import(buf, 1);
}
-#endif /* CONFIG_SYS_REDUNDAND_ENVIRONMENT */
+#endif /* CONFIG_SYS_REDUNDANT_ENVIRONMENT */
diff --git a/include/configs/G2000.h b/include/configs/G2000.h
index 5a74abc..7269c24 100644
--- a/include/configs/G2000.h
+++ b/include/configs/G2000.h
@@ -271,7 +271,7 @@
#define CONFIG_ENV_SIZE0x700 /* 2048 bytes may be used for
env vars*/
/* total size of a CAT24WC16 is 2048 bytes */
-#else /* DEFAULT: environment in flash, using redundand flash sectors */
+#else /* DEFAULT: environment in flash, using redundant flash sectors */
#define CONFIG_ENV_IS_IN_FLASH 1 /* use FLASH for environment vars */
#define CONFIG_ENV_ADDR0xFFFA /* environment starts before
u-boot */
diff --git a/include/configs/PPChameleonEVB.h b/include/configs/PPChameleonEVB.h
index cd9eb4b..cfb7116 100644
--- a/include/configs/PPChameleonEVB.h
+++ b/include/configs/PPChameleonEVB.h
@@ -387,7 +387,7 @@
#define CONFIG_ENV_OFFSET 0x100 /* environment starts at the
beginning of the EEPROM */
#define CONFIG_ENV_SIZE0x700 /* 2048-256 bytes may be used
for env vars (total size of a CAT24WC16 is 2048 bytes)*/
-#else /* DEFAULT: environment in flash, using redundand flash sectors */
+#else /* DEFAULT: environment in flash, using redundant flash sectors */
#define CONFIG_ENV_IS_IN_FLASH 1 /* use FLASH for environment vars */
#define CONFIG_ENV_ADDR0x8000 /* environment starts
at the first small sector */
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 3de30fc..c338a9a 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -333,7 +333,7 @@
*/
#if defined(CONFIG_SPI_BOOT)
#define CONFIG_ENV_IS_IN_SPI_FLASH
-#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
+#define CONFIG_SYS_REDUNDANT_ENVIRONMENT
#define CONFIG_ENV_SPI_MAX_HZ CONFIG_SF_DEFAULT_SPEED
#define CONFIG_ENV_SECT_SIZE (4 10) /* 4 KB sectors */
#define CONFIG_ENV_OFFSET (768 10) /* 768 KiB in */
diff --git a/include/configs/igep0033.h b/include/configs/igep0033.h
index 3e18a65..be1e323 100644
--- a/include/configs/igep0033.h
+++ b/include/configs/igep0033.h
@@ -193,7 +193,7 @@
#define CONFIG_SYS_MAX_NAND_DEVICE 1
#define CONFIG_SYS_NAND_ONFI_DETECTION 1
#define CONFIG_SYS_ENV_SECT_SIZE (128 10) /* 128 KiB */
-#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
+#define CONFIG_SYS_REDUNDANT_ENVIRONMENT
#define CONFIG_ENV_IS_IN_NAND
#define CONFIG_ENV_OFFSET 0x18 /* environment starts here */
#define CONFIG_ENV_ADDR_REDUND (CONFIG_ENV_OFFSET +
CONFIG_SYS_ENV_SECT_SIZE)
diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h
index e0368cb..12a89ad 100644
--- a/include/configs/km/km_arm.h
+++ b/include/configs/km/km_arm.h
@@ -245,7 +245,7 @@ int get_scl(void);
#define CONFIG_ENV_SIZE_REDUND (CONFIG_ENV_SIZE)
Re: [U-Boot] [PATCH v2] doc: README.mxs: Add instruction to install 'libssl-dev'
Dear Fabio Estevam, From: Fabio Estevam fabio.este...@freescale.com Since commit bce883707 (ARM: mxs: tools: Add mkimage support for MXS bootstream) the following build error is seen when doing a MAKEALL build: $ ./MAKEALL mx28evk Configuring for mx28evk - Board: mx28evk, Options: ENV_IS_IN_MMC mxsimage.c:18:25: fatal error: openssl/evp.h: No such file or directory Add an entry about the need of installing the 'libssl-dev' package. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Changes since v1: - Do not remove the 'elftosb' text. doc/README.mxs | 5 + 1 file changed, 5 insertions(+) diff --git a/doc/README.mxs b/doc/README.mxs index 5d9e72f..1e5bc5c 100644 --- a/doc/README.mxs +++ b/doc/README.mxs @@ -63,6 +63,11 @@ copy the binary by hand: Make sure the elftosb binary can be found in your $PATH, in this case this means /usr/local/bin/ has to be in your $PATH. +Install the 'libssl-dev' package as well. On a Ubuntu-based distribution, this +package can be installed as follows: + + $ sudo apt-get install libssl-dev + Since when is Ubuntu not a Debian based distro ? :-( I think you should stick with the roots here, use Debian. 2) Compiling U-Boot for a MXS based board --- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] doc: README.mxs: Add instruction to install 'libssl-dev'
On Mon, Sep 16, 2013 at 10:49 AM, Marek Vasut ma...@denx.de wrote: Since when is Ubuntu not a Debian based distro ? :-( I think you should stick with the roots here, use Debian. Yes, I wrote Debian-based in v1. The change here was not on purpose, so I can fix it in v3. Actually, I have been thinking about this fix: wouldn't it be better to copy the 'openssl/evp.h' header into U-boot tool directory to avoid people getting failures with MAKEALL if they do not have libssl-dev installed? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] usb: new board-specific USB init interface
Dear Mateusz Zalega, On 09/15/13 18:44, Marek Vasut wrote: Dear Mateusz Zalega, This commit unifies board-specific USB initialization implementations under one symbol (usb_board_init), declaration of which is available in usb.h. New API allows selective initialization of USB controllers whenever needed. Signed-off-by: Mateusz Zalega m.zal...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Reviewed-by: Lukasz Majewski l.majew...@samsung.com Cc: Marek Vasut ma...@denx.de Cc: Lukasz Majewski l.majew...@samsung.com Change-Id: Ia78a1378f30a55dd14598c9a1a1b4b8a762e2cd8 --- Changes since RFC (v1): - NVIDIA Tegra doesn't postpone its USB init anymore - board_usb_init()'s sole argument name was shortened - networking code comment style (/* blurb...) dropped - squashed RFC changes so that patch won't break bisect v2 changes: - commit message fixup v3 changes: - added 'index' argument to perform selective port initialization v4 changes: - board_usb_init_fail() renamed to board_usb_cleanup() - board_usb_cleanup() accepts controller index and init type - DFU and UMS commands don't init all USB controllers anymore - minor related fixes refactorization --- Looks pretty much OK. Did you test it on a few platforms? I'd like to apply this for -next anyway, since the MW is long closed. Best regards, Marek Vasut I've ran MAKEALL on all arm boards and tested it on Samsung Goni. Everything seems to be OK. I will also have to run this on PPC at least, since it might break there too. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] doc: README.mxs: Add instruction to install 'libssl-dev'
Since commit bce883707 (ARM: mxs: tools: Add mkimage support for MXS bootstream) the following build error is seen when doing a MAKEALL build: $ ./MAKEALL mx28evk Configuring for mx28evk - Board: mx28evk, Options: ENV_IS_IN_MMC mxsimage.c:18:25: fatal error: openssl/evp.h: No such file or directory Add an entry about the need of installing the 'libssl-dev' package. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Changes since v2: - Use Debian-based Changes since v1: - Do not remove the 'elftosb' text. doc/README.mxs | 5 + 1 file changed, 5 insertions(+) diff --git a/doc/README.mxs b/doc/README.mxs index 5d9e72f..1e5bc5c 100644 --- a/doc/README.mxs +++ b/doc/README.mxs @@ -63,6 +63,11 @@ copy the binary by hand: Make sure the elftosb binary can be found in your $PATH, in this case this means /usr/local/bin/ has to be in your $PATH. +Install the 'libssl-dev' package as well. On a Debian-based distribution, this +package can be installed as follows: + + $ sudo apt-get install libssl-dev + 2) Compiling U-Boot for a MXS based board --- -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] doc: README.mxs: Add instruction to install 'libssl-dev'
Dear Fabio Estevam, Since commit bce883707 (ARM: mxs: tools: Add mkimage support for MXS bootstream) the following build error is seen when doing a MAKEALL build: $ ./MAKEALL mx28evk Configuring for mx28evk - Board: mx28evk, Options: ENV_IS_IN_MMC mxsimage.c:18:25: fatal error: openssl/evp.h: No such file or directory Add an entry about the need of installing the 'libssl-dev' package. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Changes since v2: - Use Debian-based Changes since v1: - Do not remove the 'elftosb' text. doc/README.mxs | 5 + 1 file changed, 5 insertions(+) diff --git a/doc/README.mxs b/doc/README.mxs index 5d9e72f..1e5bc5c 100644 --- a/doc/README.mxs +++ b/doc/README.mxs @@ -63,6 +63,11 @@ copy the binary by hand: Make sure the elftosb binary can be found in your $PATH, in this case this means /usr/local/bin/ has to be in your $PATH. +Install the 'libssl-dev' package as well. On a Debian-based distribution, this +package can be installed as follows: + + $ sudo apt-get install libssl-dev + 2) Compiling U-Boot for a MXS based board --- Acked-by: Marek Vasut ma...@denx.de Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] doc: README.mxs: Add instruction to install 'libssl-dev'
Dear Fabio Estevam, On Mon, Sep 16, 2013 at 10:49 AM, Marek Vasut ma...@denx.de wrote: Since when is Ubuntu not a Debian based distro ? :-( I think you should stick with the roots here, use Debian. Yes, I wrote Debian-based in v1. The change here was not on purpose, so I can fix it in v3. Actually, I have been thinking about this fix: wouldn't it be better to copy the 'openssl/evp.h' header into U-boot tool directory to avoid people getting failures with MAKEALL if they do not have libssl-dev installed? No, because they won't be able to link without the dev package anyway. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 2/5] powerpc/SPL:Allow Parsing of LAW table in both SPL non SPL
SPL does not relocates the CCSRBAR hence it is using CCSRBAR at 0xfe00_.
U-boot relocates CCSRBAR to 0xf_fe00_.
So law talbe needs to be updated again.
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
arch/powerpc/cpu/mpc8xxx/law.c |9 -
1 file changed, 9 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/law.c b/arch/powerpc/cpu/mpc8xxx/law.c
index a401083..d76ba22 100644
--- a/arch/powerpc/cpu/mpc8xxx/law.c
+++ b/arch/powerpc/cpu/mpc8xxx/law.c
@@ -244,15 +244,6 @@ void init_laws(void)
gd-arch.used_laws |= (1 i);
}
-#if (defined(CONFIG_NAND_U_BOOT) !defined(CONFIG_NAND_SPL)) || \
- (defined(CONFIG_SPL) !defined(CONFIG_SPL_BUILD))
- /*
-* in SPL boot we've already parsed the law_table and setup those LAWs
-* so don't do it again.
-*/
- return;
-#endif
-
for (i = 0; i num_law_entries; i++) {
if (law_table[i].index == -1)
set_next_law(law_table[i].addr, law_table[i].size,
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 0/5] powerpc: Add support 2 stage boot loader for corenet platform
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Add support of 2 stage NAND boot loader in cornet platforms using SPL framework. This will be helpful for those SoC which has less internal SRAM(128K). here, PBL initialise the internal SRAM and copy SPL(96K) in SRAM. SPL further initialise DDR using SPD and environment variables and copy u-boot(512 KB) from NAND flash to DDR. Finally SPL transer control to u-boot for futher booting. SPL has following features: - Executes within 128K - SPL size 96K - No relocation required Run time view of SPL framework == --- Area| Address | --- GD, BD | 0xFFFE (1K) | --- HEAP| 0xFFFE0400 (26K) grow downwards | --- STACK | 0xFFFE8000 (5K) grow upwards | --- U-boot SPL | 0xfffe8000 â 0xfffc (96K) | --- 96K + 5K + 26K + 1K = 128K --- This patch set contains:- [RFC 1/5] powerpc:Add support of SPL non-relocation [RFC 2/5] powerpc/SPL:Allow Parsing of LAW table in both SPL non SPL [RFC 3/5] common/env: Point default envirenoment for GD [RFC 4/5] SPL:Defines function required to env read for IFC env_nand [RFC 5/5] B4860QDS: Add support of 2 stage NAND boot loader -- 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 v2] doc: README.mxs: Add instruction to install 'libssl-dev'
Dear Stefano Babic, On 16/09/2013 16:19, Fabio Estevam wrote: On Mon, Sep 16, 2013 at 10:49 AM, Marek Vasut ma...@denx.de wrote: Since when is Ubuntu not a Debian based distro ? :-( I think you should stick with the roots here, use Debian. Yes, I wrote Debian-based in v1. The change here was not on purpose, so I can fix it in v3. Actually, I have been thinking about this fix: wouldn't it be better to copy the 'openssl/evp.h' header into U-boot tool directory to avoid people getting failures with MAKEALL if they do not have libssl-dev installed? I disagree : it is not different if another include file is missing, or the host is not installed. Then the hint is to install build-essential (Ubuntu) or all packages, not to move them inside u-boot. Hey, build-essential is also Debian (lol) ! ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 5/5] B4860QDS: Add support of 2 stage NAND boot loader
Add support of 2 stage NAND boot loader using SPL framework.
here, PBL initialise the internal SRAM and copy SPL(96K). This further
initialise DDR using SPD and environment and copy u-boot(512 kb) from NAND to
DDR.
Finally SPL transer control to u-boot.
Initialise/create followings required for SPL framework
- Add spl.c which defines board_init_f, board_init_r
- update tlb and ddr accordingly
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
This is a prototype done on B4860.It has 512K internal RAM.
We only configured SRAM as 256K and made sure only 128KB is used
throught SPL execution.
board/freescale/b4860qds/Makefile |7 +-
board/freescale/b4860qds/ddr.c|6 +-
board/freescale/b4860qds/spl.c| 128 +
board/freescale/b4860qds/tlb.c| 10 +++
boards.cfg|2 +-
include/configs/B4860QDS.h| 58 +++--
6 files changed, 203 insertions(+), 8 deletions(-)
create mode 100644 board/freescale/b4860qds/spl.c
diff --git a/board/freescale/b4860qds/Makefile
b/board/freescale/b4860qds/Makefile
index a864c0b..42819a6 100644
--- a/board/freescale/b4860qds/Makefile
+++ b/board/freescale/b4860qds/Makefile
@@ -8,10 +8,15 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
+ifdef CONFIG_SPL_BUILD
+COBJS-y += spl.o
+endif
+ifndef CONFIG_SPL_BUILD
COBJS-y+= $(BOARD).o
-COBJS-y+= ddr.o
COBJS-$(CONFIG_B4860QDS)+= eth_b4860qds.o
COBJS-$(CONFIG_PCI)+= pci.o
+endif
+COBJS-y+= ddr.o
COBJS-y+= law.o
COBJS-y+= tlb.o
diff --git a/board/freescale/b4860qds/ddr.c b/board/freescale/b4860qds/ddr.c
index b82b3d4..467be3c 100644
--- a/board/freescale/b4860qds/ddr.c
+++ b/board/freescale/b4860qds/ddr.c
@@ -181,12 +181,16 @@ phys_size_t initdram(int board_type)
puts(Initializingusing SPD\n);
+#ifdef CONFIG_SPL_BUILD
dram_size = fsl_ddr_sdram();
dram_size = setup_ddr_tlbs(dram_size / 0x10);
dram_size *= 0x10;
- puts(DDR: );
+#else
+ puts(DDR has been initialised by pre loader\n);
+ dram_size = 0x8000;
+#endif
return dram_size;
}
diff --git a/board/freescale/b4860qds/spl.c b/board/freescale/b4860qds/spl.c
new file mode 100644
index 000..55891fc
--- /dev/null
+++ b/board/freescale/b4860qds/spl.c
@@ -0,0 +1,128 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * 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 asm/processor.h
+#include asm/mmu.h
+#include ns16550.h
+#include asm/spl.h
+#include asm/fsl_law.h
+#include asm/fsl_ddr_sdram.h
+#include malloc.h
+#include nand.h
+#include i2c.h
+#include ../common/qixis.h
+#include b4860qds_qixis.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+ulong get_effective_memsize(void)
+{
+ return CONFIG_SYS_L3_SIZE;
+}
+
+unsigned long get_board_sys_clk(void)
+{
+ u8 sysclk_conf = QIXIS_READ(brdcfg[1]);
+
+ switch ((sysclk_conf 0x0C) 2) {
+ case QIXIS_CLK_100:
+ return 1;
+ case QIXIS_CLK_125:
+ return 12500;
+ case QIXIS_CLK_133:
+ return 1;
+ }
+ return ;
+}
+
+unsigned long get_board_ddr_clk(void)
+{
+ u8 ddrclk_conf = QIXIS_READ(brdcfg[1]);
+
+ switch (ddrclk_conf 0x03) {
+ case QIXIS_CLK_100:
+ return 1;
+ case QIXIS_CLK_125:
+ return 12500;
+ case QIXIS_CLK_133:
+ return 1;
+ }
+ return ;
+}
+
+void board_init_f(ulong bootflag)
+{
+ u32 plat_ratio, sys_clk, uart_clk;
+ u32 stack = CONFIG_SPL_RELOC_STACK;
+ ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
+
+ console_init_f();
+
+ /* initialize selected port with appropriate baud rate */
+ sys_clk = get_board_sys_clk();
+ /* plat_ratio = 10; */
+ plat_ratio = (in_be32(gur-rcwsr[0]) 25) 0x1f;
+ uart_clk = sys_clk * plat_ratio / 2;
+
+ NS16550_init((NS16550_t)CONFIG_SYS_NS16550_COM1,
+uart_clk / 16 / CONFIG_BAUDRATE);
+
+ /* clear BSS segment */
+ memset(__bss_start, 0, __bss_end - __bss_start);
+
+ /* Set STACK pointer */
+ asm
Re: [U-Boot] [PATCH v2] doc: README.mxs: Add instruction to install 'libssl-dev'
On 16/09/2013 16:19, Fabio Estevam wrote: On Mon, Sep 16, 2013 at 10:49 AM, Marek Vasut ma...@denx.de wrote: Since when is Ubuntu not a Debian based distro ? :-( I think you should stick with the roots here, use Debian. Yes, I wrote Debian-based in v1. The change here was not on purpose, so I can fix it in v3. Actually, I have been thinking about this fix: wouldn't it be better to copy the 'openssl/evp.h' header into U-boot tool directory to avoid people getting failures with MAKEALL if they do not have libssl-dev installed? I disagree : it is not different if another include file is missing, or the host is not installed. Then the hint is to install build-essential (Ubuntu) or all packages, not to move them inside u-boot. Regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 1/5] powerpc:Add support of SPL non-relocation
Current SPL code base has BSS section placed after reset_vector. This means
they have to relocate to use the global variables. This put an implicit
requirement of having SPL size = Memory/2.
To avoid relocation, move bss_section within SPL range.
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
arch/powerpc/cpu/mpc85xx/u-boot-spl.lds | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
index bc13267..ffc6ad3 100644
--- a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
+++ b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
@@ -57,13 +57,34 @@ SECTIONS
. = ALIGN(8);
__init_begin = .;
__init_end = .;
+#ifdef CONFIG_SKIP_RELOCATE_SPL
+ /*
+* Make sure that the bss segment isn't linked at 0x0, otherwise its
+* address won't be updated during relocation fixups.
+*/
+ . |= 0x10;
+
+ . = ALIGN(4);
+ __bss_start = .;
+ .bss : {
+ *(.sbss*)
+ *(.bss*)
+ }
+ . = ALIGN(4);
+ __bss_end = .;
+#endif
/* FIXME for non-NAND SPL */
#if defined(CONFIG_FSL_IFC) /* Restrict bootpg at 4K boundry for IFC */
- .bootpg ADDR(.text) + 0x1000 :
+#ifndef BOOT_PAGE_OFFSET
+#define BOOT_PAGE_OFFSET 0x1000
+#endif
+ .bootpg ADDR(.text) + BOOT_PAGE_OFFSET :
{
arch/powerpc/cpu/mpc85xx/start.o (.bootpg)
}
+#ifndef RESET_VECTOR_OFFSET
#define RESET_VECTOR_OFFSET 0x1ffc /* IFC has 8K sram */
+#endif
#elif defined(CONFIG_FSL_ELBC)
#define RESET_VECTOR_OFFSET 0xffc /* LBC has 4k sram */
#else
@@ -80,6 +101,7 @@ SECTIONS
} = 0x
#endif
+#ifndef CONFIG_SKIP_RELOCATE_SPL
/*
* Make sure that the bss segment isn't linked at 0x0, otherwise its
* address won't be updated during relocation fixups.
@@ -94,4 +116,5 @@ SECTIONS
}
. = ALIGN(4);
__bss_end = .;
+#endif
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 3/5] common/env: Point default envirenoment for GD
GD(Global Data) structure has pointer to envirenoment variable array.
but, it is not being assigned for SPL framwork.
So update GD pointer with env variable array.
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
common/env_common.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/common/env_common.c b/common/env_common.c
index 1ac3377..84843e1 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -162,6 +162,9 @@ int env_import(const char *buf, int check)
if (himport_r(env_htab, (char *)ep-data, ENV_SIZE, '\0', 0,
0, NULL)) {
gd-flags |= GD_FLG_ENV_READY;
+#ifdef CONFIG_SPL_BUILD
+ gd-env_addr = ep-data;
+#endif
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 v2] doc: README.mxs: Add instruction to install 'libssl-dev'
On Mon, Sep 16, 2013 at 12:55 PM, Marek Vasut ma...@denx.de wrote: Dear Stefano Babic, On 16/09/2013 16:19, Fabio Estevam wrote: On Mon, Sep 16, 2013 at 10:49 AM, Marek Vasut ma...@denx.de wrote: Since when is Ubuntu not a Debian based distro ? :-( I think you should stick with the roots here, use Debian. Yes, I wrote Debian-based in v1. The change here was not on purpose, so I can fix it in v3. Actually, I have been thinking about this fix: wouldn't it be better to copy the 'openssl/evp.h' header into U-boot tool directory to avoid people getting failures with MAKEALL if they do not have libssl-dev installed? I disagree : it is not different if another include file is missing, or the host is not installed. Then the hint is to install build-essential (Ubuntu) or all packages, not to move them inside u-boot. Hey, build-essential is also Debian (lol) ! ;-) Debian +1 :-) -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc:sdhci: Fix card ready status timeout.
Hi there, On Sep 13, 2013, at 3:59 PM, Przemyslaw Marczak wrote: Dear Pantelis, On 09/09/2013 02:58 PM, Przemyslaw Marczak wrote: According to JEDEC eMMC specification, after data transfer (multiple or single block) host must wait for card ready status. This is done by waiting for command and data lines to be at idle state after transfer. JEDEC does not specify maximum timeout. Before this change max timeout was 10 ms but in case of UMS - when system does multiple read/write operations on random card blocks - timeout causes I/O errors. The timeout has been increased to 200ms after data transfer. For other transfers it stays unchanged. Default values are now defined with if defined directive so it can be redefined at board config if needed. Tested on Goni and Trats. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Pantelis Antoniou pa...@antoniou-consulting.com Please do not apply this patch yet due to still not enough results on some targets. Timeout value should depends on internal cards operations execution time but this time is unpredictably and that is why JEDEC not specifies it. Maybe u-boot sdhci driver needs some more changes to be more flexible for such operations. In example sdhci background operations timeout at kernel is specified to 4 minutes. I need to make more research. OK, this need to be fleshed out a bit more. Please keep me in the loop cause this sounds board-specific. Perhaps the CONFIG_* option is a sound idea; real world is messy like that. Regards, -- Przemyslaw Marczak Samsung RD Institute Poland Samsung Electronics p.marc...@samsung.com Regards -- Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch v2] powerpc/mpc85xx: Add workaround for erratum A006379
Erratum A006379 says CPCHDBCR0 bit field [10:14] has incorrect default
value after POR. The workaround is to set this field before enabling
CPC to 0x1e.
Erratum A006379 applies to
T4240 rev 1.0
B4860 rev 1.0, 2.0
Signed-off-by: York Sun york...@freescale.com
---
Change log:
v2: Add a list of SoC impacted by this erratum
Add a function to detect whether workaround should be applied at runtime
Add fsl_errata.h to host the prototype of the new function
arch/powerpc/cpu/mpc85xx/cmd_errata.c |5 +
arch/powerpc/cpu/mpc85xx/cpu_init.c |7 +++
arch/powerpc/include/asm/config_mpc85xx.h |2 ++
arch/powerpc/include/asm/fsl_errata.h | 24
arch/powerpc/include/asm/immap_85xx.h |1 +
5 files changed, 39 insertions(+)
create mode 100644 arch/powerpc/include/asm/fsl_errata.h
diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index c441bd2..1e5a43f 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -7,6 +7,7 @@
#include common.h
#include command.h
#include linux/compiler.h
+#include asm/fsl_errata.h
#include asm/processor.h
#include fsl_corenet_serdes.h
@@ -245,6 +246,10 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
#ifdef CONFIG_SYS_FSL_ERRATUM_A006593
puts(Work-around for Erratum A006593 enabled\n);
#endif
+#ifdef CONFIG_SYS_FSL_ERRATUM_A006379
+ if (has_erratum_a006379())
+ puts(Work-around for Erratum A006379 enabled\n);
+#endif
#ifdef CONFIG_SYS_FSL_ERRATUM_SEC_A003571
if (IS_SVR_REV(svr, 1, 0))
puts(Work-around for Erratum A003571 enabled\n);
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 6036333..22c0c54 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -19,6 +19,7 @@
#include asm/io.h
#include asm/cache.h
#include asm/mmu.h
+#include asm/fsl_errata.h
#include asm/fsl_law.h
#include asm/fsl_serdes.h
#include asm/fsl_srio.h
@@ -160,6 +161,12 @@ static void enable_cpc(void)
#ifdef CONFIG_SYS_FSL_ERRATUM_A006593
setbits_be32(cpc-cpchdbcr0, 1 (31 - 21));
#endif
+#ifdef CONFIG_SYS_FSL_ERRATUM_A006379
+ if (has_erratum_a006379()) {
+ setbits_be32(cpc-cpchdbcr0,
+CPC_HDBCR0_SPLRU_LEVEL_EN);
+ }
+#endif
out_be32(cpc-cpccsr0, CPC_CSR0_CE | CPC_CSR0_PE);
/* Read back to sync write */
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
b/arch/powerpc/include/asm/config_mpc85xx.h
index bec8966..6986ade 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -593,6 +593,7 @@
#define CONFIG_SYS_FSL_ERRATUM_A004468
#define CONFIG_SYS_FSL_ERRATUM_A_004934
#define CONFIG_SYS_FSL_ERRATUM_A005871
+#define CONFIG_SYS_FSL_ERRATUM_A006379
#define CONFIG_SYS_FSL_ERRATUM_A006593
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xfe00
#define CONFIG_SYS_FSL_PCI_VER_3_X
@@ -617,6 +618,7 @@
#define CONFIG_SYS_FSL_USB1_PHY_ENABLE
#define CONFIG_SYS_FSL_ERRATUM_A_004934
#define CONFIG_SYS_FSL_ERRATUM_A005871
+#define CONFIG_SYS_FSL_ERRATUM_A006379
#define CONFIG_SYS_FSL_ERRATUM_A006593
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xfe00
diff --git a/arch/powerpc/include/asm/fsl_errata.h
b/arch/powerpc/include/asm/fsl_errata.h
new file mode 100644
index 000..780dfcf
--- /dev/null
+++ b/arch/powerpc/include/asm/fsl_errata.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _ASM_FSL_ERRATA_H
+#define _ASM_FSL_ERRATA_H
+
+#include common.h
+
+#ifdef CONFIG_SYS_FSL_ERRATUM_A006379
+static inline bool has_erratum_a006379(void)
+{
+ u32 svr = get_svr();
+ if (((SVR_SOC_VER(svr) == SVR_T4240) SVR_MAJ(svr) = 1) ||
+ ((SVR_SOC_VER(svr) == SVR_B4860) SVR_MAJ(svr) = 2))
+ return true;
+
+ return false;
+}
+#endif
+
+#endif
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index 3a10d77..a938143 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1671,6 +1671,7 @@ typedef struct cpc_corenet {
#define CPC_HDBCR0_CDQ_SPEC_DIS0x0800
#define CPC_HDBCR0_TAG_ECC_SCRUB_DIS 0x0100
#define CPC_HDBCR0_DATA_ECC_SCRUB_DIS 0x0040
+#define CPC_HDBCR0_SPLRU_LEVEL_EN 0x003c
#endif /* CONFIG_SYS_FSL_CPC */
/* Global Utilities Block */
--
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] cm-t35: move the display code to common place
Compulab OMAP3 boards use the same display initialization code.
Move the display initialization code to live under board/compulab/common
directory.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Tested-by: Nikita Kiryanov nik...@compulab.co.il
---
board/compulab/cm_t35/Makefile | 2 --
board/compulab/common/Makefile | 1 +
board/compulab/{cm_t35/display.c = common/omap3_display.c} | 0
3 files changed, 1 insertion(+), 2 deletions(-)
rename board/compulab/{cm_t35/display.c = common/omap3_display.c} (100%)
diff --git a/board/compulab/cm_t35/Makefile b/board/compulab/cm_t35/Makefile
index 8b922b3..213423e 100644
--- a/board/compulab/cm_t35/Makefile
+++ b/board/compulab/cm_t35/Makefile
@@ -11,8 +11,6 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
-COBJS-$(CONFIG_LCD) += display.o
-
COBJS := cm_t35.o leds.o $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/board/compulab/common/Makefile b/board/compulab/common/Makefile
index ec2e510..b399c8f 100644
--- a/board/compulab/common/Makefile
+++ b/board/compulab/common/Makefile
@@ -15,6 +15,7 @@ endif
LIB= $(obj)lib$(VENDOR).o
COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += eeprom.o
+COBJS-$(CONFIG_LCD) += omap3_display.o
COBJS := $(COBJS-y)
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/board/compulab/cm_t35/display.c
b/board/compulab/common/omap3_display.c
similarity index 100%
rename from board/compulab/cm_t35/display.c
rename to board/compulab/common/omap3_display.c
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] compulab: adjustments before porting more boards
Two more adjustments before porting more Compulab boards to mainline U-Boot.
Move the eeprom code which can be used (and is suitable) by multiple Compulab
boards to a common location.
Move the display initialization code which can be used by multiple Compulab
OMAP based boards.
Igor Grinberg (2):
cm-t35: move the eeprom code to common place
cm-t35: move the display code to common place
board/compulab/cm_t35/Makefile | 3 --
board/compulab/cm_t35/cm_t35.c | 7 ++-
board/compulab/common/Makefile | 36 +++
board/compulab/{cm_t35 = common}/eeprom.c | 51 --
board/compulab/{cm_t35 = common}/eeprom.h | 8 ++--
.../{cm_t35/display.c = common/omap3_display.c} | 0
6 files changed, 70 insertions(+), 35 deletions(-)
create mode 100644 board/compulab/common/Makefile
rename board/compulab/{cm_t35 = common}/eeprom.c (60%)
rename board/compulab/{cm_t35 = common}/eeprom.h (62%)
rename board/compulab/{cm_t35/display.c = common/omap3_display.c} (100%)
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch v3] powerpc/mpc85xx: Add workaround for erratum A006379
Erratum A006379 says CPCHDBCR0 bit field [10:14] has incorrect default
value after POR. The workaround is to set this field before enabling
CPC to 0x1e.
Erratum A006379 applies to
T4240 rev 1.0
B4860 rev 1.0, 2.0
Signed-off-by: York Sun york...@freescale.com
---
Change log:
v3: Include asm/processor.h in fsl_errata.h
Even it is likely included in the callers' file, it is clear the needed
macros are defined.
v2: Add a list of SoC impacted by this erratum
Add a function to detect whether workaround should be applied at runtime
Add fsl_errata.h to host the prototype of the new function
arch/powerpc/cpu/mpc85xx/cmd_errata.c |5 +
arch/powerpc/cpu/mpc85xx/cpu_init.c |7 +++
arch/powerpc/include/asm/config_mpc85xx.h |2 ++
arch/powerpc/include/asm/fsl_errata.h | 25 +
arch/powerpc/include/asm/immap_85xx.h |1 +
5 files changed, 40 insertions(+)
create mode 100644 arch/powerpc/include/asm/fsl_errata.h
diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index c441bd2..1e5a43f 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -7,6 +7,7 @@
#include common.h
#include command.h
#include linux/compiler.h
+#include asm/fsl_errata.h
#include asm/processor.h
#include fsl_corenet_serdes.h
@@ -245,6 +246,10 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
#ifdef CONFIG_SYS_FSL_ERRATUM_A006593
puts(Work-around for Erratum A006593 enabled\n);
#endif
+#ifdef CONFIG_SYS_FSL_ERRATUM_A006379
+ if (has_erratum_a006379())
+ puts(Work-around for Erratum A006379 enabled\n);
+#endif
#ifdef CONFIG_SYS_FSL_ERRATUM_SEC_A003571
if (IS_SVR_REV(svr, 1, 0))
puts(Work-around for Erratum A003571 enabled\n);
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 6036333..22c0c54 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -19,6 +19,7 @@
#include asm/io.h
#include asm/cache.h
#include asm/mmu.h
+#include asm/fsl_errata.h
#include asm/fsl_law.h
#include asm/fsl_serdes.h
#include asm/fsl_srio.h
@@ -160,6 +161,12 @@ static void enable_cpc(void)
#ifdef CONFIG_SYS_FSL_ERRATUM_A006593
setbits_be32(cpc-cpchdbcr0, 1 (31 - 21));
#endif
+#ifdef CONFIG_SYS_FSL_ERRATUM_A006379
+ if (has_erratum_a006379()) {
+ setbits_be32(cpc-cpchdbcr0,
+CPC_HDBCR0_SPLRU_LEVEL_EN);
+ }
+#endif
out_be32(cpc-cpccsr0, CPC_CSR0_CE | CPC_CSR0_PE);
/* Read back to sync write */
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
b/arch/powerpc/include/asm/config_mpc85xx.h
index bec8966..6986ade 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -593,6 +593,7 @@
#define CONFIG_SYS_FSL_ERRATUM_A004468
#define CONFIG_SYS_FSL_ERRATUM_A_004934
#define CONFIG_SYS_FSL_ERRATUM_A005871
+#define CONFIG_SYS_FSL_ERRATUM_A006379
#define CONFIG_SYS_FSL_ERRATUM_A006593
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xfe00
#define CONFIG_SYS_FSL_PCI_VER_3_X
@@ -617,6 +618,7 @@
#define CONFIG_SYS_FSL_USB1_PHY_ENABLE
#define CONFIG_SYS_FSL_ERRATUM_A_004934
#define CONFIG_SYS_FSL_ERRATUM_A005871
+#define CONFIG_SYS_FSL_ERRATUM_A006379
#define CONFIG_SYS_FSL_ERRATUM_A006593
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xfe00
diff --git a/arch/powerpc/include/asm/fsl_errata.h
b/arch/powerpc/include/asm/fsl_errata.h
new file mode 100644
index 000..3cac2d4
--- /dev/null
+++ b/arch/powerpc/include/asm/fsl_errata.h
@@ -0,0 +1,25 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _ASM_FSL_ERRATA_H
+#define _ASM_FSL_ERRATA_H
+
+#include common.h
+#include asm/processor.h
+
+#ifdef CONFIG_SYS_FSL_ERRATUM_A006379
+static inline bool has_erratum_a006379(void)
+{
+ u32 svr = get_svr();
+ if (((SVR_SOC_VER(svr) == SVR_T4240) SVR_MAJ(svr) = 1) ||
+ ((SVR_SOC_VER(svr) == SVR_B4860) SVR_MAJ(svr) = 2))
+ return true;
+
+ return false;
+}
+#endif
+
+#endif
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index 3a10d77..a938143 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1671,6 +1671,7 @@ typedef struct cpc_corenet {
#define CPC_HDBCR0_CDQ_SPEC_DIS0x0800
#define CPC_HDBCR0_TAG_ECC_SCRUB_DIS 0x0100
#define CPC_HDBCR0_DATA_ECC_SCRUB_DIS 0x0040
+#define CPC_HDBCR0_SPLRU_LEVEL_EN 0x003c
#endif /* CONFIG_SYS_FSL_CPC */
/* Global Utilities Block */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] [PATCH 0/5] Add device tree support for VxWorks
Dear Miao Yan, In message 1379325490-3462-1-git-send-email-miao@windriver.com you wrote: The 'bootvx' commnad stays unchaged, and is still avalaible under the configuration option CONFIG_CMD_ELF for older kernels. A new option CONFIG_BOOTM_VXWORKS is added for bootm to align with other bootm supported operating systems. So the do_bootm_vxworks will work as below: #if (libfdt (ppc || arm)) if (using device tree) boot_vxworks_with_device_tree else #endif bootvx(...); I'm not sure I understand what this means. Please correct if my interpretation is incorrect or incomplete: You intend to 1) just keep the existing 'bootvx' command for compatibility with older VxWorks versions, and 2) use plain 'bootm' for new versions, like we do for other OSes? That sounds good to me. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You got to learn three things. What's real, what's not real, and what's the difference. - Terry Pratchett, _Witches Abroad_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] cm-t35: move the eeprom code to common place
Compulab boards use the same eeprom code, so move the eeprom related
code to live under board/compulab/common directory.
Also make several adjustments to eeprom functions namespace, so it will
be generic for compulab boards.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Tested-by: Nikita Kiryanov nik...@compulab.co.il
---
board/compulab/cm_t35/Makefile | 1 -
board/compulab/cm_t35/cm_t35.c | 7 ++--
board/compulab/common/Makefile | 35
board/compulab/{cm_t35 = common}/eeprom.c | 51 --
board/compulab/{cm_t35 = common}/eeprom.h | 8 ++---
5 files changed, 69 insertions(+), 33 deletions(-)
create mode 100644 board/compulab/common/Makefile
rename board/compulab/{cm_t35 = common}/eeprom.c (60%)
rename board/compulab/{cm_t35 = common}/eeprom.h (62%)
diff --git a/board/compulab/cm_t35/Makefile b/board/compulab/cm_t35/Makefile
index 6d07947..8b922b3 100644
--- a/board/compulab/cm_t35/Makefile
+++ b/board/compulab/cm_t35/Makefile
@@ -11,7 +11,6 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
-COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += eeprom.o
COBJS-$(CONFIG_LCD) += display.o
COBJS := cm_t35.o leds.o $(COBJS-y)
diff --git a/board/compulab/cm_t35/cm_t35.c b/board/compulab/cm_t35/cm_t35.c
index 3caa5be..a6d4aba 100644
--- a/board/compulab/cm_t35/cm_t35.c
+++ b/board/compulab/cm_t35/cm_t35.c
@@ -33,7 +33,7 @@
#include asm/ehci-omap.h
#include asm/gpio.h
-#include eeprom.h
+#include ../common/eeprom.h
DECLARE_GLOBAL_DATA_PTR;
@@ -160,7 +160,7 @@ static u32 cm_t3x_rev;
u32 get_board_rev(void)
{
if (!cm_t3x_rev)
- cm_t3x_rev = cm_t3x_eeprom_get_board_rev();
+ cm_t3x_rev = cl_eeprom_get_board_rev();
return cm_t3x_rev;
};
@@ -509,7 +509,7 @@ static int handle_mac_address(void)
if (rc)
return 0;
- rc = cm_t3x_eeprom_read_mac_addr(enetaddr);
+ rc = cl_eeprom_read_mac_addr(enetaddr);
if (rc)
return rc;
@@ -598,5 +598,4 @@ int ehci_hcd_stop(void)
{
return omap_ehci_hcd_stop();
}
-
#endif /* CONFIG_USB_EHCI_OMAP */
diff --git a/board/compulab/common/Makefile b/board/compulab/common/Makefile
new file mode 100644
index 000..ec2e510
--- /dev/null
+++ b/board/compulab/common/Makefile
@@ -0,0 +1,35 @@
+#
+# (C) Copyright 2011 - 2013 CompuLab, Ltd. www.compulab.co.il
+#
+# Author: Igor Grinberg grinb...@compulab.co.il
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+include $(TOPDIR)/config.mk
+
+ifneq ($(OBJTREE),$(SRCTREE))
+$(shell mkdir -p $(obj)board/$(VENDOR)/common)
+endif
+
+LIB= $(obj)lib$(VENDOR).o
+
+COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += eeprom.o
+
+COBJS := $(COBJS-y)
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+all: $(LIB)
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+# This is for $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/compulab/cm_t35/eeprom.c b/board/compulab/common/eeprom.c
similarity index 60%
rename from board/compulab/cm_t35/eeprom.c
rename to board/compulab/common/eeprom.c
index df91acd..5aa3dbd 100644
--- a/board/compulab/cm_t35/eeprom.c
+++ b/board/compulab/common/eeprom.c
@@ -22,30 +22,30 @@
#define LAYOUT_INVALID 0
#define LAYOUT_LEGACY 0xff
-static int eeprom_layout; /* Implicitly LAYOUT_INVALID */
+static int cl_eeprom_layout; /* Implicitly LAYOUT_INVALID */
-static int cm_t3x_eeprom_read(uint offset, uchar *buf, int len)
+static int cl_eeprom_read(uint offset, uchar *buf, int len)
{
return i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, offset,
CONFIG_SYS_I2C_EEPROM_ADDR_LEN, buf, len);
}
-static int eeprom_setup_layout(void)
+static int cl_eeprom_setup_layout(void)
{
int res;
- if (eeprom_layout != LAYOUT_INVALID)
+ if (cl_eeprom_layout != LAYOUT_INVALID)
return 0;
- res = cm_t3x_eeprom_read(EEPROM_LAYOUT_VER_OFFSET,
- (uchar *)eeprom_layout, 1);
+ res = cl_eeprom_read(EEPROM_LAYOUT_VER_OFFSET,
+(uchar *)cl_eeprom_layout, 1);
if (res) {
- eeprom_layout = LAYOUT_INVALID;
+ cl_eeprom_layout = LAYOUT_INVALID;
return res;
}
- if (eeprom_layout == 0 || eeprom_layout = 0x20)
- eeprom_layout = LAYOUT_LEGACY;
+ if (cl_eeprom_layout == 0 || cl_eeprom_layout = 0x20)
+ cl_eeprom_layout = LAYOUT_LEGACY;
return 0;
}
@@ -56,12 +56,14 @@ void get_board_serial(struct tag_serialnr *serialnr)
uint offset;
memset(serialnr, 0,
Re: [U-Boot] powerpc SPL framework: Avoiding relocate_code
On Fri, 2013-09-13 at 15:23 +0530, Prabhakar Kushwaha wrote: On 09/12/2013 11:28 PM, Scott Wood wrote: On Mon, 2013-09-09 at 16:43 +0530, Prabhakar Kushwaha wrote: Hi, SPL framework is used to support multi-stage booting. Where first level boot loader is created via SPL having relocate_code() function. I am working on a Freescale's SoC which has less internal SRAM. I don't want to use relocate_code() as to support this function, I need to reduce SPL bin to SRAM/2 size. is there way to avoid relocate_code function ? I tried with below sequence, but it is not working for me :( .globlrelocate_code relocate_code: mrr1,r3/* Set new stack pointer*/ mrr9,r4/* Save copy of Init Data pointer*/ mrr10,r5/* Save copy of Destination Address*/ GET_GOT #ifndef CONFIG_SPL_BUILD -- -- #endif .globlin_ram in_ram: Well, you certainly don't want to disable it for all SPLs... it should be disabled for those SPL which relocate itself in SRAM, for other no Hmm? Any SPL that does relocate itself would need this. The reason is bss variables which are mapped to 0x_ onwards because bsssection are mapped after 0xfffc in lds. They are not available during SPL execution. is there way to relocate bss section in the execution range of SPL? Are you talking about a scenario in which the SPL is loaded into SRAM rather than (e.g.) the NAND buffer? In that case, why is U-Boot not linked at the actual SRAM address? No copy should be needed in that case, and the BSS will not be at zero. I am linking SPL with the address of SRAM as I want resetvec at 0xfffc but still I am finding bss at 0x0 What address do we start at when PBI loads something into SRAM? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 4/5] SPL:Defines function required to env read for IFC env_nand
fsl_ifs_spl.c reads data from NAND and store at a memory location in raw mode.
It does not used MTD layer.
To read env variable from NAND MTD layer read/write required.
Hence, add mtd_block_isbad nand_read_skip_bad function required during
env variable read.
Also, avoid nand_info during env read for SPL
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
common/env_nand.c |7 ---
drivers/mtd/nand/Makefile |2 +-
drivers/mtd/nand/fsl_ifc_spl.c | 22 ++
3 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/common/env_nand.c b/common/env_nand.c
index 7530962..7a7107f 100644
--- a/common/env_nand.c
+++ b/common/env_nand.c
@@ -246,11 +246,13 @@ int readenv(size_t offset, u_char *buf)
u_char *char_ptr;
blocksize = nand_info[0].erasesize;
+#ifndef CONFIG_SPL_BUILD
if (!blocksize)
return 1;
-
len = min(blocksize, CONFIG_ENV_SIZE);
-
+#else
+ len = CONFIG_ENV_SIZE;
+#endif
while (amount_loaded CONFIG_ENV_SIZE offset end) {
if (nand_block_isbad(nand_info[0], offset)) {
offset += blocksize;
@@ -396,7 +398,6 @@ void env_relocate_spec(void)
return;
}
#endif
-
ret = readenv(CONFIG_ENV_OFFSET, (u_char *)buf);
if (ret) {
set_default_env(!readenv() failed);
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 366dee6..06d5d14 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -24,6 +24,7 @@ COBJS-$(CONFIG_SPL_NAND_LOAD) += nand_spl_load.o
COBJS-$(CONFIG_SPL_NAND_ECC) += nand_ecc.o
COBJS-$(CONFIG_SPL_NAND_BASE) += nand_base.o
COBJS-$(CONFIG_SPL_NAND_INIT) += nand.o
+COBJS-$(CONFIG_NAND_FSL_IFC) += fsl_ifc_spl.o
else # not spl
@@ -68,7 +69,6 @@ COBJS-$(CONFIG_NAND_DOCG4) += docg4.o
else # minimal SPL drivers
COBJS-$(CONFIG_NAND_FSL_ELBC) += fsl_elbc_spl.o
-COBJS-$(CONFIG_NAND_FSL_IFC) += fsl_ifc_spl.o
COBJS-$(CONFIG_NAND_MXC) += mxc_nand_spl.o
endif # drivers
diff --git a/drivers/mtd/nand/fsl_ifc_spl.c b/drivers/mtd/nand/fsl_ifc_spl.c
index d462265..e7edacf 100644
--- a/drivers/mtd/nand/fsl_ifc_spl.c
+++ b/drivers/mtd/nand/fsl_ifc_spl.c
@@ -11,6 +11,28 @@
#include asm/io.h
#include asm/fsl_ifc.h
#include linux/mtd/nand.h
+#ifndef CONFIG_SPL_INIT_MINIMAL
+#include linux/mtd/mtd.h
+#endif
+
+static void nand_load(unsigned int offs, int uboot_size, uchar *dst);
+
+#ifndef CONFIG_SPL_INIT_MINIMAL
+struct mtd_info nand_info[CONFIG_SYS_MAX_NAND_DEVICE];
+
+int mtd_block_isbad(struct mtd_info *mtd, loff_t ofs)
+{
+ return 0;
+}
+
+int nand_read_skip_bad(struct mtd_info *nand, loff_t offset, size_t *length,
+ size_t *actual, loff_t lim, u_char *buffer)
+{
+ nand_load(offset, *length, buffer);
+ return 0;
+}
+#endif
+
static inline int is_blank(uchar *addr, int page_size)
{
--
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 1/5] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform
On Fri, 2013-09-13 at 07:02 +, Gupta, Pekon wrote:
(resending to u-boot maillist as previous mail was discarded by mailman
due to mail-encoding issue.)
On Tue, 2013-09-03 at 11:26 +0530, Pekon Gupta wrote:
diff --git a/doc/README.nand b/doc/README.nand
index 913e9b5..f72f618 100644
--- a/doc/README.nand
+++ b/doc/README.nand
@@ -169,6 +169,19 @@ Configuration Options:
Please convert your driver even if you don't need the extra
flexibility, so that one day we can eliminate the old mechanism.
+ CONFIG_SYS_NAND_ONFI_DETECTION
+ Enables detection of ONFI compliant devices during probe.
+ And fetching device parameters flashed on device, by parsing
+ ONFI parameter page.
I don't see this used anywhere in the patch (defined in config headers,
yes, but not ifdeffed).
What does DETECTION add here, versus just CONFIG_NAND_ONFI?
It should be CONFIG rather than CONFIG_SYS because it just controls
whether the support is built, not making an assertion about the
hardware, right?
This is not the new define, it was already there in generic code (nand_base.c)
But not documented, so I documented it and enabled it for am33xx platform
Please refer: $UBOOT/drivers/mtd/nand/nand_base.c
It was added as part of following commit
commit 0272c718ba69c60a9d719db6806971d98db98090
Author: Florian Fainelli flor...@openwrt.org
AuthorDate: 2011-02-25
Oops... I looked for it and didn't see it, but maybe I was looking at
the Linux version or something similarly silly.
+ CONFIG_BCH
+ Enables software based BCH ECC algorithm present in lib/bch.c
+ This is used by SoC platforms which do not have in-build hardware
+ engine to calculate and correct BCH ECC.
s/in-build/a built-in/
+ CONFIG_SYS_NAND_ECCSCHEME
+ specifies which ECC scheme to use.
Specifies it how? What are the possible values?
If the answer involves enum omap_ecc, then OMAP should be
somewhere in the name.
This is generic define which can be used by all NAND drivers to specify
ECC scheme for SPL boot. Therefore CONFIG_SYS_
How each device/driver will use it depends should be mentioned in
its board level document. For AM335x its updated in Patch:
[PATCH v5 5/5] board/ti/am335x/README: update for NAND boot
Do you want it to be made omap specific ?
Yes, it should be omap specific. If the semantics are not generic I
don't see the value in making the name be generic and splitting the
documentation in two places.
+/**
+ * omap_select_ecc_scheme - configures driver for particular ecc-scheme
+ * @nand: NAND chip device structure
+ * @ecc_scheme: ecc scheme to configure
+ * @pagesize: number of main-area bytes per page of NAND device
+ * @oobsize: number of OOB/spare bytes per page of NAND device
+ */
+static int omap_select_ecc_scheme(struct nand_chip *nand, int
ecc_scheme,
+ unsigned int pagesize, unsigned int oobsize) {
+ struct nand_bch_priv*bch= nand-priv;
+ struct nand_ecclayout *ecclayout = nand-ecc.layout;
+ int i;
+
+ /* Reset ecc interface */
+ nand-ecc.mode = NAND_ECC_NONE;
+ nand-ecc.read_page = NULL;
+ nand-ecc.write_page= NULL;
+ nand-ecc.read_oob = NULL;
+ nand-ecc.write_oob = NULL;
+ nand-ecc.hwctl = NULL;
+ nand-ecc.correct = NULL;
+ nand-ecc.calculate = NULL;
+
+ switch (ecc_scheme) {
+ case OMAP_ECC_HAM1_CODE_SW:
+ debug(nand: selected OMAP_ECC_HAM1_CODE_SW\n);
+ nand-ecc.mode = NAND_ECC_SOFT;
+ nand-ecc.layout= NULL;
+ nand-ecc.size = 0;
+ nand-ecc.strength = 1;
+ bch-ecc_scheme =
OMAP_ECC_HAM1_CODE_SW;
+ break;
+ case OMAP_ECC_HAM1_CODE_HW_ROMCODE:
+ debug(nand: selected
OMAP_ECC_HAM1_CODE_HW_ROMCODE\n);
+ nand-ecc.mode = NAND_ECC_HW;
+ nand-ecc.strength = 1;
+ nand-ecc.size = 512;
+ nand-ecc.bytes = 3;
+ nand-ecc.hwctl = omap_enable_hwecc;
+ nand-ecc.correct = omap_correct_data;
+ nand-ecc.calculate = omap_calculate_ecc;
+ /* define ecc-layout */
+ ecclayout-eccbytes = nand-ecc.bytes *
+ (pagesize / SECTOR_BYTES);
+ for (i = 0; i ecclayout-eccbytes; i++)
+ ecclayout-eccpos[i] = i +
+
BADBLOCK_MARKER_LENGTH;
+ ecclayout-oobfree[0].offset = i +
+
BADBLOCK_MARKER_LENGTH;
+ ecclayout-oobfree[0].length = oobsize - nand-ecc.bytes -
+
BADBLOCK_MARKER_LENGTH;
+ bch-ecc_scheme =
OMAP_ECC_HAM1_CODE_HW_ROMCODE;
+ break;
+#ifdef CONFIG_BCH
+ case
[U-Boot] [RFC PATCH 0/3] i.MX6 (DQ/DLS): consolidate mux and pad names
This patch set begins the process of consolidating mux and pad declarations for the i.MX6 Dual/Quad and Dual-Lite/Solo processor variants. Patch 1 replaces the mux/pad names with their equivalents from the Linux kernel (from linux-next). This Patch 2 removes a set of completely useless pad declarations Patch 3 adds a number of registers that are defined in the Linux kernel and in the DLS variant, but not in the DQ. After this patch, there are still more than 400 pad differences between the two variants. These represent mux/pad declarations that are not present in the Linux kernel. A combined list of these is available at: http://linode.boundarydevices.com/u-boot-pads.lst The majority of these are diagnostic settings and a large number of these appear unlikely to ever be used. The primary reason this is being sent as an RFC is to get feedback about what should be done with them: 1. Delete them all 2. Walk through them and delete some and add others 3. Add them all and consolidate the names. The file above has the names grouped somewhat by mux/pad functions to provide a sense of the various functions. Note to reviewers: Because the majority of the changes in this patch set are simple name changes, using the '--word-diff' git parameter makes review much easier: ~/u-boot$ git diff HEAD^^^ --word-diff Eric Nelson (3): i.MX6DQ/DLS: replace pad names with their Linux kernel equivalents i.MX6DQ/DLS: remove useless mux/pad declarations i.MX6DQ: Add Pinmux settings that are present in Linux and Dual-Lite/Solo arch/arm/include/asm/arch-mx6/mx6dl_pins.h| 1904 - arch/arm/include/asm/arch-mx6/mx6q_pins.h | 1803 --- board/boundary/nitrogen6x/nitrogen6x.c| 164 +-- board/congatec/cgtqmx6eval/cgtqmx6eval.c | 40 +- board/freescale/mx6qarm2/mx6qarm2.c | 66 +- board/freescale/mx6qsabreauto/mx6qsabreauto.c | 60 +- board/freescale/mx6sabresd/mx6sabresd.c | 90 +- board/freescale/titanium/titanium.c | 106 +- board/wandboard/wandboard.c | 54 +- 9 files changed, 2076 insertions(+), 2211 deletions(-) -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 2/3] i.MX6DQ/DLS: remove useless mux/pad declarations
With no pad, mux, or input register, these declarations are completely
useless.
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
arch/arm/include/asm/arch-mx6/mx6dl_pins.h | 78
arch/arm/include/asm/arch-mx6/mx6q_pins.h | 82 --
2 files changed, 160 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
b/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
index 94f49c0..63ea4da 100644
--- a/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
@@ -424,70 +424,6 @@ enum {
MX6_PAD_DRAM_CAS__MMDC_DRAM_CAS = IOMUX_PAD(0x0464, NO_MUX_I,
0, 0x, 0, 0),
MX6_PAD_DRAM_CS0__MMDC_DRAM_CS_0= IOMUX_PAD(0x0468, NO_MUX_I,
0, 0x, 0, 0),
MX6_PAD_DRAM_CS1__MMDC_DRAM_CS_1= IOMUX_PAD(0x046C, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D0__MMDC_DRAM_D_0 = IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D1__MMDC_DRAM_D_1 = IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D10__MMDC_DRAM_D_10= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D11__MMDC_DRAM_D_11= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D12__MMDC_DRAM_D_12= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D13__MMDC_DRAM_D_13= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D14__MMDC_DRAM_D_14= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D15__MMDC_DRAM_D_15= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D16__MMDC_DRAM_D_16= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D17__MMDC_DRAM_D_17= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D18__MMDC_DRAM_D_18= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D19__MMDC_DRAM_D_19= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D2__MMDC_DRAM_D_2 = IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D20__MMDC_DRAM_D_20= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D21__MMDC_DRAM_D_21= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D22__MMDC_DRAM_D_22= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D23__MMDC_DRAM_D_23= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D24__MMDC_DRAM_D_24= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D25__MMDC_DRAM_D_25= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D26__MMDC_DRAM_D_26= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D27__MMDC_DRAM_D_27= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D28__MMDC_DRAM_D_28= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D29__MMDC_DRAM_D_29= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D3__MMDC_DRAM_D_3 = IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D30__MMDC_DRAM_D_30= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D31__MMDC_DRAM_D_31= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D32__MMDC_DRAM_D_32= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D33__MMDC_DRAM_D_33= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D34__MMDC_DRAM_D_34= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D35__MMDC_DRAM_D_35= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D36__MMDC_DRAM_D_36= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D37__MMDC_DRAM_D_37= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D38__MMDC_DRAM_D_38= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D39__MMDC_DRAM_D_39= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D4__MMDC_DRAM_D_4 = IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D40__MMDC_DRAM_D_40= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D41__MMDC_DRAM_D_41= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D42__MMDC_DRAM_D_42= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D43__MMDC_DRAM_D_43= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D44__MMDC_DRAM_D_44= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D45__MMDC_DRAM_D_45= IOMUX_PAD(NO_PAD_I, NO_MUX_I,
0, 0x, 0, 0),
- MX6_PAD_DRAM_D46__MMDC_DRAM_D_46=
[U-Boot] [RFC PATCH 3/3] i.MX6DQ: Add Pinmux settings that are present in Linux and Dual-Lite/Solo
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
arch/arm/include/asm/arch-mx6/mx6q_pins.h | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/include/asm/arch-mx6/mx6q_pins.h
b/arch/arm/include/asm/arch-mx6/mx6q_pins.h
index 5cbcdab..19a4e28 100644
--- a/arch/arm/include/asm/arch-mx6/mx6q_pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6q_pins.h
@@ -132,6 +132,7 @@ enum {
MX6_PAD_EIM_D19__ECSPI1_SS1 = IOMUX_PAD(0x03B0, 0x009C, 1,
0x0804, 0, 0),
MX6_PAD_EIM_D19__IPU1_DI0_PIN08 = IOMUX_PAD(0x03B0, 0x009C, 2,
0x, 0, 0),
MX6_PAD_EIM_D19__IPU2_CSI1_DATA16 = IOMUX_PAD(0x03B0, 0x009C, 3,
0x08C8, 0, 0),
+ MX6_PAD_EIM_D19__UART1_CTS_B= IOMUX_PAD(0x03B0, 0x009C, 4,
0x, 0, 0),
MX6_PAD_EIM_D19__UART1_RTS_B= IOMUX_PAD(0x03B0, 0x009C, 4,
0x091C, 0, 0),
MX6_PAD_EIM_D19__GPIO3_IO19 = IOMUX_PAD(0x03B0, 0x009C, 5,
0x, 0, 0),
MX6_PAD_EIM_D19__EPIT1_OUT = IOMUX_PAD(0x03B0, 0x009C, 6,
0x, 0, 0),
@@ -162,6 +163,7 @@ enum {
MX6_PAD_EIM_D22__PL301MX6QPER1_HWRITE = IOMUX_PAD(0x03BC, 0x00A8, 7,
0x, 0, 0),
MX6_PAD_EIM_D23__EIM_DATA23 = IOMUX_PAD(0x03C0, 0x00AC, 0, 0x,
0, 0),
MX6_PAD_EIM_D23__IPU1_DI0_D0_CS = IOMUX_PAD(0x03C0, 0x00AC, 1, 0x,
0, 0),
+ MX6_PAD_EIM_D23__UART3_CTS_B= IOMUX_PAD(0x03C0, 0x00AC, 2,
0x, 0, 0),
MX6_PAD_EIM_D23__UART3_RTS_B= IOMUX_PAD(0x03C0, 0x00AC, 2,
0x092C, 0, 0),
MX6_PAD_EIM_D23__UART1_DCD_B= IOMUX_PAD(0x03C0, 0x00AC, 3,
0x, 0, 0),
MX6_PAD_EIM_D23__IPU2_CSI1_DATA_EN = IOMUX_PAD(0x03C0, 0x00AC, 4,
0x08D8, 0, 0),
@@ -188,6 +190,7 @@ enum {
MX6_PAD_EIM_D24__UART1_DTR_B= IOMUX_PAD(0x03C8, 0x00B4, 7,
0x, 0, 0),
MX6_PAD_EIM_D25__EIM_DATA25 = IOMUX_PAD(0x03CC, 0x00B8, 0, 0x,
0, 0),
MX6_PAD_EIM_D25__ECSPI4_SS3 = IOMUX_PAD(0x03CC, 0x00B8, 1,
0x, 0, 0),
+ MX6_PAD_EIM_D25__UART3_TX_DATA = IOMUX_PAD(0x03CC, 0x00B8, 2,
0x, 0, 0),
MX6_PAD_EIM_D25__UART3_RX_DATA = IOMUX_PAD(0x03CC, 0x00B8, 2,
0x0930, 1, 0),
MX6_PAD_EIM_D25__ECSPI1_SS3 = IOMUX_PAD(0x03CC, 0x00B8, 3,
0x080C, 0, 0),
MX6_PAD_EIM_D25__ECSPI2_SS3 = IOMUX_PAD(0x03CC, 0x00B8, 4,
0x, 0, 0),
@@ -207,6 +210,7 @@ enum {
MX6_PAD_EIM_D27__IPU1_DI1_PIN13 = IOMUX_PAD(0x03D4, 0x00C0, 1, 0x,
0, 0),
MX6_PAD_EIM_D27__IPU1_CSI0_DATA00 = IOMUX_PAD(0x03D4,
0x00C0, 2, 0x, 0, 0),
MX6_PAD_EIM_D27__IPU2_CSI1_DATA13 = IOMUX_PAD(0x03D4, 0x00C0, 3,
0x08BC, 0, 0),
+ MX6_PAD_EIM_D27__UART2_TX_DATA = IOMUX_PAD(0x03D4, 0x00C0, 4,
0x, 0, 0),
MX6_PAD_EIM_D27__UART2_RX_DATA = IOMUX_PAD(0x03D4, 0x00C0, 4,
0x0928, 1, 0),
MX6_PAD_EIM_D27__GPIO3_IO27 = IOMUX_PAD(0x03D4, 0x00C0, 5,
0x, 0, 0),
MX6_PAD_EIM_D27__IPU1_SISG3 = IOMUX_PAD(0x03D4, 0x00C0, 6,
0x, 0, 0),
@@ -216,6 +220,7 @@ enum {
MX6_PAD_EIM_D28__ECSPI4_MOSI= IOMUX_PAD(0x03D8, 0x00C4, 2,
0x, 0, 0),
MX6_PAD_EIM_D28__IPU2_CSI1_DATA12 = IOMUX_PAD(0x03D8, 0x00C4, 3,
0x08B8, 0, 0),
MX6_PAD_EIM_D28__UART2_DTE_CTS_B= IOMUX_PAD(0x03D8,
0x00C4, 4, 0x0924, 0, 0),
+ MX6_PAD_EIM_D28__UART2_DTE_RTS_B= IOMUX_PAD(0x03D8, 0x00C4, 4,
0x, 0, 0),
MX6_PAD_EIM_D28__GPIO3_IO28 = IOMUX_PAD(0x03D8, 0x00C4, 5,
0x, 0, 0),
MX6_PAD_EIM_D28__IPU1_EXT_TRIG = IOMUX_PAD(0x03D8, 0x00C4, 6,
0x, 0, 0),
MX6_PAD_EIM_D28__IPU1_DI0_PIN13 = IOMUX_PAD(0x03D8, 0x00C4, 7, 0x,
0, 0),
@@ -231,6 +236,7 @@ enum {
MX6_PAD_EIM_D30__IPU1_DISP1_DATA21 = IOMUX_PAD(0x03E0, 0x00CC, 1,
0x, 0, 0),
MX6_PAD_EIM_D30__IPU1_DI0_PIN11 = IOMUX_PAD(0x03E0, 0x00CC, 2, 0x,
0, 0),
MX6_PAD_EIM_D30__IPU1_CSI0_DATA03 = IOMUX_PAD(0x03E0,
0x00CC, 3, 0x, 0, 0),
+ MX6_PAD_EIM_D30__UART3_CTS_B= IOMUX_PAD(0x03E0, 0x00CC, 4,
0x, 0, 0),
MX6_PAD_EIM_D30__UART3_RTS_B= IOMUX_PAD(0x03E0, 0x00CC, 4,
0x092C, 2, 0),
MX6_PAD_EIM_D30__GPIO3_IO30 = IOMUX_PAD(0x03E0, 0x00CC, 5,
0x, 0, 0),
MX6_PAD_EIM_D30__USB_H1_OC = IOMUX_PAD(0x03E0, 0x00CC, 6, 0x0948,
0, 0),
@@ -726,6 +732,7 @@ enum {
MX6_PAD_ENET_REF_CLK__GPIO1_IO23= IOMUX_PAD(0x04E8, 0x01D4, 5,
0x, 0, 0),
MX6_PAD_ENET_REF_CLK__SPDIF_SR_CLK = IOMUX_PAD(0x04E8, 0x01D4, 6,
0x, 0, 0),
MX6_PAD_ENET_REF_CLK__USBPHY1_RX_SQH= IOMUX_PAD(0x04E8, 0x01D4, 7,
0x, 0, 0),
+ MX6_PAD_ENET_RX_ER__USB_OTG_ID = IOMUX_PAD(0x04EC, 0x01D8, 0,
0x, 0, 0),
MX6_PAD_ENET_RX_ER__ENET_RX_ER = IOMUX_PAD(0x04EC,
Re: [U-Boot] [PATCH v4 1/5] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform
On Mon, 2013-09-16 at 11:19 +, Gupta, Pekon wrote: Instead, should I make it more generic for all SoC ? like CONFIG_SYS_NAND_ECCSCHEME can take in following strings defining ECC scheme used by NAND driver in SPL boot: ham1 - 1 bit hamming code bch4 - 4-bit BCH ecc code bch8 - 8-bit BCH ecc code bch16 - 16-bit BCH ecc code Most drivers would probably prefer symbolically-defined numbers rather than strings. Plus, there could be more subtle variations such as layout differences. Best to keep it OMAP-specific. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/28] sf: Add common probe support
Request for atmel, eon, gigadevice, macronix, ramtron flash user/developer please test these new changes on your hw. Your comment is very valuable for me to push confidently on master. On Sun, Sep 15, 2013 at 11:45 PM, Jagannadha Sutradharudu Teki jagannadha.sutradharudu-t...@xilinx.com wrote: Hi All, This is a v3 series for sf: Add common probe support I am u-boot/spi custodian, I removed all flash drivers files(except ramtron, handled in a separate driver) and implemented a common probe support. Tested SST, STMICR, SPANSION, WINBOND from my side, REQUEST FOR ALL SPI CODE FLASH_UESRS/CONTRIBUTORS/REST_USER, PLEASE TEST THESE CHANGES W.R.T YOUR HW IF POSSIBLE. Please use the below branch for testing: http://git.denx.de/?p=u-boot/u-boot-spi.git;a=shortlog;h=refs/heads/master-test-new $ git clone git://git.denx.de/u-boot-spi.git $ cd u-boot-spi $ git checkout -b master-test-new origin/master-test-new Please let me know for any issues/concerns/questions. -- Thanks, Jagan. Jagannadha Sutradharudu Teki (28): sf: Divide spi_flash into multiple parts sf: probe: Add new spi_flash_probe support sf: probe: Add support for M25P* flash parts sf: probe: Add support for EN25Q* flash parts sf: probe: Add support for GD25* flash parts sf: probe: Add support for MX25L* flash parts sf: probe: Add support for W25* flash parts sf: probe: Add support for S25FL* flash parts sf: probe: Add support for SST25* flash parts sf: probe: Add support for AT45DB* flash parts sf: probe: Give proper spacing on flash table params sf: probe: Add support for SST_WP sf: probe: Add support to clear flash BP# bits sf: probe: Add support for erase sector selection flag sf: probe: Add support for flag status polling sf: probe: Move BAR config to spi_flash_validate_ids sf: Add proper comment style on spi_flash structure sf: ramtron: Add support for separate flash driver sf: Remove unneeded flash drivers files sf: probe: Add support for EN25Q64 sf: probe: Add support for S25FL256S_256K sf: probe: Add support for S25FL512S_256K sf: probe: Use print_size arg as page_size sf: probe: Print erase_size while printing flash details sf: probe: Simply the BAR configuration logic sf: ops: Add static qualifier to spi_flash_cmd_bankaddr_write sf: probe: Add support for MX25L25635F sf: probe: Add support for MX25L51235F drivers/mtd/spi/.nfs02e4f8b67c0e | Bin 0 - 16384 bytes drivers/mtd/spi/Makefile | 13 +- drivers/mtd/spi/atmel.c | 544 - drivers/mtd/spi/eon.c| 60 --- drivers/mtd/spi/gigadevice.c | 65 --- drivers/mtd/spi/macronix.c | 98 - drivers/mtd/spi/ramtron.c| 123 +- drivers/mtd/spi/spansion.c | 141 --- drivers/mtd/spi/spi_flash.c | 571 +-- drivers/mtd/spi/spi_flash_internal.h | 29 +- drivers/mtd/spi/spi_flash_ops.c | 403 +++ drivers/mtd/spi/spi_flash_probe.c| 357 + drivers/mtd/spi/sst.c| 238 --- drivers/mtd/spi/stmicro.c| 202 -- drivers/mtd/spi/winbond.c| 141 --- include/configs/top9000.h| 1 - include/spi_flash.h | 76 ++-- 17 files changed, 947 insertions(+), 2115 deletions(-) create mode 100644 drivers/mtd/spi/.nfs02e4f8b67c0e delete mode 100644 drivers/mtd/spi/atmel.c delete mode 100644 drivers/mtd/spi/eon.c delete mode 100644 drivers/mtd/spi/gigadevice.c delete mode 100644 drivers/mtd/spi/macronix.c delete mode 100644 drivers/mtd/spi/spansion.c create mode 100644 drivers/mtd/spi/spi_flash_ops.c create mode 100644 drivers/mtd/spi/spi_flash_probe.c delete mode 100644 drivers/mtd/spi/sst.c delete mode 100644 drivers/mtd/spi/stmicro.c delete mode 100644 drivers/mtd/spi/winbond.c -- 1.8.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Thanks, Jagan. Jagannadha Sutradharudu Teki, E: jagannadh.t...@gmail.com, P: +91-9676773388 Engineer - System Software Hacker U-boot - SPI Custodian and Zynq APSOC Ln: http://www.linkedin.com/in/jaganteki ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/28] sf: probe: Add support for SST25* flash parts
On 09/15/2013 11:15 AM, Jagannadha Sutradharudu Teki wrote:
Added SST25* parts are which are avilable in spi_flash_probe_legacy.c.
Updated the sector_size attributes as per the flash parts.
Looks fine for with this sector_size for computing the size
of flash.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v3:
- none
Changes for v2:
- Enable CONFIG_SPI_FLASH_SST
drivers/mtd/spi/spi_flash_probe.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/spi_flash_probe.c
b/drivers/mtd/spi/spi_flash_probe.c
index 6f0dd84..62c9d0a 100644
--- a/drivers/mtd/spi/spi_flash_probe.c
+++ b/drivers/mtd/spi/spi_flash_probe.c
@@ -88,6 +88,18 @@ static const struct spi_flash_params
spi_flash_params_table[] = {
{N25Q1024, 0x20ba21, 0x0, 64 * 1024, 2048},
{N25Q1024A, 0x20bb21, 0x0, 64 * 1024, 2048},
#endif
+#ifdef CONFIG_SPI_FLASH_SST/* SST */
+ {SST25VF040B, 0xbf258d, 0x0, 64 * 1024, 8},
+ {SST25VF080B, 0xbf258e, 0x0, 64 * 1024, 16},
+ {SST25VF016B, 0xbf2541, 0x0, 64 * 1024, 32},
+ {SST25VF032B, 0xbf254a, 0x0, 64 * 1024, 64},
+ {SST25VF064C, 0xbf254b, 0x0, 64 * 1024,128},
+ {SST25WF512,0xbf2501, 0x0, 64 * 1024, 1},
+ {SST25WF010,0xbf2502, 0x0, 64 * 1024, 2},
+ {SST25WF020,0xbf2503, 0x0, 64 * 1024, 4},
+ {SST25WF040,0xbf2504, 0x0, 64 * 1024, 8},
+ {SST25WF080,0xbf2505, 0x0, 64 * 1024, 16},
+#endif
#ifdef CONFIG_SPI_FLASH_WINBOND /* WINBOND */
{W25P80,0xef2014, 0x0, 64 * 1024, 16},
{W25P16,0xef2015, 0x0, 64 * 1024, 32},
@@ -125,7 +137,6 @@ static const struct spi_flash_params
spi_flash_params_table[] = {
* TODO:
* ATMEL
* RAMTRON
-* SST
*/
};
Tested-by: Eric Nelson eric.nel...@boundarydevices.com
Tested on i.MX6Q (nitrogen6q) and i.MX6S (nitrogen6s) with
p/n SST25VF016B.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] HACK: enable HYP mode on OMAP5
---
arch/arm/lib/bootm.c | 89 ++--
1 file changed, 87 insertions(+), 2 deletions(-)
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index eefb456..63395c3 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -8,6 +8,9 @@
* Marius Groeger mgroe...@sysgo.de
*
* Copyright (C) 2001 Erik Mouw (j.a.k.m...@its.tudelft.nl)
+ * HYP entry (C) 2012 Ian Molton ian.mol...@codethink.co.uk
+ *and Clemens Fischer clemens.fisc...@h-da.de
+ * (C) 2013 Alexander Tarasikov alexander.tarasi...@gmail.com
*
* SPDX-License-Identifier:GPL-2.0+
*/
@@ -26,6 +29,89 @@ DECLARE_GLOBAL_DATA_PTR;
static struct tag *params;
+/*
+ * function called by cpu 1 after wakeup
+ */
+extern void __hyp_init_sec(void);
+
+asm (
+ .pushsection .text\n
+ .global __hyp_init_sec\n
+ __hyp_init_sec:\n
+ ldr r12, =0x102\n
+ adr r0, hyp_init_cont\n
+ dsb\n
+ isb\n
+ dmb\n
+ smc #0\n
+ hyp_init_cont: ldr r1, =0x48281800\n // AUX_CORE_BOOT_0
+ mov r2, #0\n
+ str r2, [r1, #4]\n
+ dsb\n
+ isb\n
+ dmb\n
+ wait: wfe\n
+ ldr r2, [r1, #4]\n
+ cmp r2, #0\n
+ movne pc, r2\n
+ b wait\n
+ .popsection\n
+);
+
+/*
+ * Enable HYP mode on the OMAP5 CPU
+ *
+ * FIXME: this needs to test to make sure its running on an OMAP5
+ *
+ * We wake up CPU1 at __hyp_init_sec which allows us to put it into HYP
+ * mode.
+ *
+ * CPU1 then clears AUX_CORE_BOOT_0 and enters WFE, until the kernel wakes it.
+ *
+ * In order to avoid CPU1 continuing execution on just about any event, we
+ * wait for AUX_CORE_BOOT_0 to contain a non-zero address, at which point
+ * we continue execution at that address.
+ *
+ */
+
+static void hyp_enable(void) {
+/*Wake up CPU1 and enable HYP on CPU0. */
+ asm(
+ ldr r1, =0x48281800\n // AUX_CORE_BOOT_1
+ ldr r2, =__hyp_init_sec\n
+ str r2, [r1, #4]\n
+ mov r2, #0x20\n
+ str r2, [r1]\n// AUX_CORE_BOOT_0
+ isb\n
+ dmb\n
+ dsb\n
+ sev\n // Wake CPU1
+ adr r1, hyp_stack\n
+ stm r1, {r4-r14}\n //save registers on the temporary stack
+ ldr r12, =0x102\n //start hypervisor SMC code
+ adr r0, hyp_ena_cont\n //address after SMC instruction
+ dsb\n
+ isb\n
+ dmb\n
+ smc #0\n // CPU0 - HYP mode
+ hyp_stack:\n
+ .word 0x0\n
+ .word 0x0\n
+ .word 0x0\n
+ .word 0x0\n
+ .word 0x0\n
+ .word 0x0\n
+ .word 0x0\n
+ .word 0x0\n
+ .word 0x0\n
+ .word 0x0\n
+ .word 0x0\n
+ hyp_ena_cont: adr r1,hyp_stack\n
+ ldm r1, {r4-r14}\n
+ :::r0, r1, r2, r3, cc, memory
+ );
+};
+
static ulong get_sp(void)
{
ulong ret;
@@ -144,7 +230,6 @@ static void setup_initrd_tag(bd_t *bd, ulong initrd_start,
ulong initrd_end)
params-u.initrd.start = initrd_start;
params-u.initrd.size = initrd_end - initrd_start;
-
params = tag_next (params);
}
@@ -185,7 +270,6 @@ __weak void setup_board_tags(struct tag **in_params) {}
static void boot_prep_linux(bootm_headers_t *images)
{
char *commandline = getenv(bootargs);
-
if (IMAGE_ENABLE_OF_LIBFDT images-ft_len) {
#ifdef CONFIG_OF_LIBFDT
debug(using: FDT\n);
@@ -246,6 +330,7 @@ static void boot_jump_linux(bootm_headers_t *images, int
flag)
else
r2 = gd-bd-bi_boot_params;
+ hyp_enable();
if (!fake)
kernel_entry(0, machid, r2);
}
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFD] OMAP5: Working HYP mode
Hello, u-boot developers! I am attaching a patch to enable the HYP (hypervisor) mode on the OMAP5 CPU. It is based on a previous patch by Ian Molton. For some reason, Ian's patch was incorrect (loading PC with the wrong address, missing memory barriers, and, most importantly, using the wrong SMC call). I think it is because Ian was using some early omap5 prototype, and I was using the SVT OMAP5432UEVM board which is commercially available. Since this is a gross hack, I neither expect nor want it to be merged, but I think people experimenting with ARM virtualization will find it useful. I have KVM working on OMAP5 as of now (using KVM patches from openvirtualization and some linux kernel bugfixes of my own) and I plan to write a blog post soon about how to repeat my steps. My plan is to publish the patches to fix the bugs I've found. I would like to receive comments on what is the planned way to implement the HYP switching in u-boot and whether it is possible without using the TrustZone SMC calls. Have fun ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v10 1/6] core support of arm64
On Mon, 2013-09-16 at 16:08 +0800, feng...@phytium.com.cn wrote: From: David Feng feng...@phytium.com.cn Signed-off-by: David Feng feng...@phytium.com.cn --- You've still got CONFIG_ARMV8 in places that should be CONFIG_ARM64 diff --git a/arch/arm/cpu/armv8/exceptions.S b/arch/arm/cpu/armv8/exceptions.S new file mode 100644 index 000..b2f62c9 --- /dev/null +++ b/arch/arm/cpu/armv8/exceptions.S @@ -0,0 +1,115 @@ +/* + * (C) Copyright 2013 + * David Feng feng...@phytium.com.cn + * + * SPDX-License-Identifier: GPL-2.0+ + */ Note that Tom said he'd be OK with using GPL2-only code from Linux, as long as it's properly attributed. +2. GOT is used to relocate u-boot and CONFIG_NEEDS_MANUAL_RELOC is needed. + +3. Fdt should be placed at a 2-megabyte boundary and within the first 512 + megabytes from the start of the kernel image. So, fdt_high should be + defined specially. + Please reference linux/Documentation/arm64/booting.txt for detail. + +4. Generic board is supported. + +Contributor: + Tom Rini tr...@ti.com + Scott Wood scottw...@freescale.com + Sharma Bhupesh b45...@freescale.com + Rob Herringrobherri...@gmail.com Should it be: Bhupesh Sharma bhupesh.sha...@freescale.com ? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] i2c: port i2c driver to new subsystem
On 09/15/2013 12:09 PM, Philippe Reynes wrote: This serie is composed of two patches: - one to port the i2c mxc driver to new subsystem - one to update all configurations with i2c mxc driver This serie was tested with success on armadeus apf27. Philippe Reynes (2): i2c: move to new subsystem i2c: update config using mxc driver to new subsystem README|3 + arch/arm/cpu/armv7/mx5/clock.c|2 +- arch/arm/cpu/armv7/mx6/clock.c|2 +- arch/arm/imx-common/Makefile |2 +- drivers/i2c/Makefile |2 +- drivers/i2c/mxc_i2c.c | 109 + include/configs/apf27.h |5 +- include/configs/flea3.h |6 +- include/configs/imx31_phycore.h |6 +- include/configs/m53evk.h |6 +- include/configs/mx25pdk.h |6 +- include/configs/mx35pdk.h |6 +- include/configs/mx53ard.h |6 +- include/configs/mx53evk.h |6 +- include/configs/mx53loco.h|6 +- include/configs/mx53smd.h |6 +- include/configs/mx6qsabreauto.h |3 +- include/configs/nitrogen6x.h |3 +- include/configs/titanium.h|3 +- include/configs/vf610twr.h|6 +- include/configs/woodburn_common.h |6 +- 21 files changed, 98 insertions(+), 102 deletions(-) Tested-by: Eric Nelson eric.nel...@boundarydevices.com Tested on i.MX6Q (nitrogen6q) and i.MX6S (nitrogen6s) against I2C busses 0-2 and a variety of devices (HDMI, touch controllers). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 4/5] SPL:Defines function required to env read for IFC env_nand
On Mon, 2013-09-16 at 21:35 +0530, Prabhakar Kushwaha wrote:
fsl_ifs_spl.c reads data from NAND and store at a memory location in raw mode.
It does not used MTD layer.
To read env variable from NAND MTD layer read/write required.
Hence, add mtd_block_isbad nand_read_skip_bad function required during
env variable read.
Also, avoid nand_info during env read for SPL
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
common/env_nand.c |7 ---
drivers/mtd/nand/Makefile |2 +-
drivers/mtd/nand/fsl_ifc_spl.c | 22 ++
3 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/common/env_nand.c b/common/env_nand.c
index 7530962..7a7107f 100644
--- a/common/env_nand.c
+++ b/common/env_nand.c
@@ -246,11 +246,13 @@ int readenv(size_t offset, u_char *buf)
u_char *char_ptr;
blocksize = nand_info[0].erasesize;
+#ifndef CONFIG_SPL_BUILD
if (!blocksize)
return 1;
-
len = min(blocksize, CONFIG_ENV_SIZE);
-
+#else
+ len = CONFIG_ENV_SIZE;
+#endif
Use positive logic (ifdef/else, not ifndef/else).
Are you sure that CONFIG_ENV_SIZE will always be appropriate? Shouldn't
you use CONFIG_SYS_NAND_BLOCK_SIZE in place of nand_info[0].erasesize?
@@ -396,7 +398,6 @@ void env_relocate_spec(void)
return;
}
#endif
-
ret = readenv(CONFIG_ENV_OFFSET, (u_char *)buf);
if (ret) {
set_default_env(!readenv() failed);
Remove unrelated whitespace changes.
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 366dee6..06d5d14 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -24,6 +24,7 @@ COBJS-$(CONFIG_SPL_NAND_LOAD) += nand_spl_load.o
COBJS-$(CONFIG_SPL_NAND_ECC) += nand_ecc.o
COBJS-$(CONFIG_SPL_NAND_BASE) += nand_base.o
COBJS-$(CONFIG_SPL_NAND_INIT) += nand.o
+COBJS-$(CONFIG_NAND_FSL_IFC) += fsl_ifc_spl.o
No, it's still a minimal NAND driver (i.e. it doesn't use fsl_ifc.o).
Minimal NAND drivers are not related to minimal SPL init.
diff --git a/drivers/mtd/nand/fsl_ifc_spl.c b/drivers/mtd/nand/fsl_ifc_spl.c
index d462265..e7edacf 100644
--- a/drivers/mtd/nand/fsl_ifc_spl.c
+++ b/drivers/mtd/nand/fsl_ifc_spl.c
@@ -11,6 +11,28 @@
#include asm/io.h
#include asm/fsl_ifc.h
#include linux/mtd/nand.h
+#ifndef CONFIG_SPL_INIT_MINIMAL
+#include linux/mtd/mtd.h
+#endif
+
+static void nand_load(unsigned int offs, int uboot_size, uchar *dst);
+
+#ifndef CONFIG_SPL_INIT_MINIMAL
+struct mtd_info nand_info[CONFIG_SYS_MAX_NAND_DEVICE];
+
+int mtd_block_isbad(struct mtd_info *mtd, loff_t ofs)
+{
+ return 0;
+}
+
+int nand_read_skip_bad(struct mtd_info *nand, loff_t offset, size_t *length,
+ size_t *actual, loff_t lim, u_char *buffer)
+{
+ nand_load(offset, *length, buffer);
+ return 0;
+}
+#endif
What does this have to do with minimal init?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ANN] v2013.10-rc3
Hey all, I've put v2013.10-rc3 out and tarballs should be out soon. I wasn't able to get as much re-syncing done myself as I hoped as some other issue arose, but I'll get my own queue cleaned out, both for TI and for general bits in time for rc4. Please let us all know if something has stopped working. Thanks all! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/19] First step towards Kbuild: Use Kbuild style makefiles
Hello Gerhard.
This test only proves that the code compiles, nothing else. Even
for a single board you may not run-test all features, given the
many functions and high interactivity and options that U-Boot
provides. This becomes worse when your change affects several
more boards or even the whole tree (which is the case here).
I'd suggest a more formal approach to test or verification.
Being able to build the code (not having broken the compile
phase) is just a prerequisite. But you want to prove that no
harm was done, i.e. that the code still is operational (at least
that it works as good as it did before the manipulation).
I thought compiling with no errors/warnings means no harm
because no source files except makefiles were touched
in this patch series.
That's why I believed the only build check is sufficient
and I did not try run-test.
But your suggestion sounds interesting.
If we could programmatically compare the generated executables
in an easy way, that would be worth checking.
So I gave it a try.
Finally it turned out to be much harder than I had expected. (Almost nightware)
Anyway, let's see what I did one by one.
(1) Time stamp
Because U-boot executable includes a timestamp,
Everytime U-Boot is compiled, include/generated/timestamp_autogenerated.h
is updated, which results in different outcome.
So, I tweaked include/timestamp.h not to include it:
#ifndef DO_DEPS_ONLY
-#include generated/timestamp_autogenerated.h
+/* #include generated/timestamp_autogenerated.h */
+#define U_BOOT_DATE DUMMY
+#define U_BOOT_TIME DUMMY
#endif
(2) Git commit hash
Git commit hash is contained in include/generated/version_autogenerated.h.
So, I also modified include/version.h not to include it as follows:
#ifndef DO_DEPS_ONLY
-#include generated/version_autogenerated.h
+/* #include generated/version_autogenerated.h */
+#define PLAIN_VERSION __DUMMY__
+#define U_BOOT_VERSION __DUMMY__
+#define CC_VERSION_STRING __DUMMY__
+#define LD_VERSION_STRING __DUMMY__
#endif
(3) Show md5sum
I added a line to MAKEALL script to show md5sum of u-boot and u-boot-spl.
${CROSS_COMPILE}size ${OBJS} | tee -a ${LOG_DIR}/$target.MAKELOG
+md5sum ${OBJS}
+
[ -e ${LOG_DIR}/${target}.ERR ] cat ${LOG_DIR}/${target}.ERR
(4) Make sure to build in the same path
The output executables (ELF) depends on the directory path where it was built.
(Of course, the u-boot.bin does not carry this information.)
So, we need to make sure to build in the same path in order to get indentical
ELF files.
(5) Take care of the difference of symbols order
The output file depends on the order of the object files at the link stage.
Even if you change the order of the *.o files, you can still get a correct
outcome.
But now we want to compare md5sum, so we must keep the same order.
Let's closely look some makefiles.
Some of makefiles sort object files before linking, and others do not.
For example, let's see common/Makefile first.
COBJS := $(sort $(COBJS-y))
--- snip ---
OBJS:= $(addprefix $(obj),$(COBJS))
--- snip ---
$(LIB): $(obj).depend $(OBJS)
$(call cmd_link_o_target, $(OBJS))
Before linked into common/libcommon.o, the object files
are sorted in alphabetical order by $(sort ...) function.
For another example, let's take a look arch/arm/cpu/armv7/am33xx/Makefile.
COBJS-$(CONFIG_AM33XX) += clock_am33xx.o
COBJS-$(CONFIG_TI814X) += clock_ti814x.o
COBJS-$(CONFIG_AM43XX) += clock_am43xx.o
ifneq ($(CONFIG_AM43XX)$(CONFIG_AM33XX),)
COBJS += clock.o
endif
COBJS-$(CONFIG_TI816X) += clock_ti816x.o
COBJS += sys_info.o
COBJS += mem.o
COBJS += ddr.o
COBJS += emif4.o
COBJS += board.o
COBJS += mux.o
COBJS-$(CONFIG_NAND_OMAP_GPMC) += elm.o
SRCS:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS:= $(addprefix $(obj),$(COBJS) $(COBJS-y) $(SOBJS))
Be aware that both COBJS-y and COBJS are used
and $(COBJS) $(COBJS-y) are added in this order to $(OBJS).
So the resulting $(OBJS) contains the *.o files in the following order:
clock.o sys_info.o mem.o ddr.o emif4.o board.o mux.o
clock_am33xx.o clock_ti814.o .
In this commit series, I converted both COBJS-y and COBJS into obj-y.
So, after applying this patch series, the object files are listed in
different order.
In the conventional U-Boot Makefiles, the order of object files
which are linked together is depending on makefiles.
- Some of them sort objects in alphabetical order with $(sort ...) function.
- Some of them keep the order in which they apper.
- Other cases (like arch/arm/cpu/armv7/am33xx/Makefile)
This variation makes it very difficult to programatically compare the output
files.
So, I standerdized the order of the object files to alphabetical order.
I added $(sort ...) function to the linkage rule in each sub makefile like
follows:
Re: [U-Boot] Pull request: u-boot-spi/master
On Sun, Sep 15, 2013 at 10:49:06PM +0530, Jagannadha Sutradharudu Teki wrote: Hi Tom, Small pull request, planning to send next bunch of request for next pull. Thanks, Jagan. The following changes since commit 2b26201a2aef0b310b7c04702b0dba5dea493f77: env_nand.c: support falling back to redundant env when writing (2013-08-22 17:49:47 -0500) are available in the git repository at: git://git.denx.de/u-boot-spi.git master for you to fetch changes up to b95f958d7d06b3cd117647b29b288cf168aa2ee9: cmd_sf: let sf update preserve the final part of the last sector (2013-08-27 19:39:39 +0530) Gerlando Falauto (1): cmd_sf: let sf update preserve the final part of the last sector Marek Vasut (1): spi: mxs_spi: Configure chipselect after block reset common/cmd_sf.c | 13 - drivers/spi/mxs_spi.c | 12 +++- 2 files changed, 15 insertions(+), 10 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Merge and reformat boards.cfg and MAINTAINERS
Hello Albert, Tom. Commit 27af930e9 added Active/Orphan status in the first column of boards.cfg. Could you tell the definition of Active and Orphan. At first I imagined Orphan means a board without maintainer. But the maintainer information is missing from lots of Active boards. So I could not find the difference between Active and Orphan. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Understanding uboot child makefiles
PS: Last message was sent without body, please ignore 0 down vote favorite I am trying to understand a second level makefile of uboot (this makefile was in a sub directory) a) What is the difference between $(COBJS:.o=.c) and COBJS := test_main.o b) What is the meaning of $(call cmd_link_o_target, $(OBJS)). What is the cmd_link_o_target and what is the call statement doing c) Does this line creating 2 targets ? ALL := $(obj).depend $(LIB) ===Makefile=== include $(TOPDIR)/config.mk LIB = $(obj)libtest.o SOBJS := test.o COBJS := test_main.o COBJS += diagnostic.o SRCS:= $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS:= $(addprefix $(obj),$(COBJS) $(SOBJS)) ALL := $(obj).depend $(LIB) all:$(ALL) $(LIB): $(OBJS) $(call cmd_link_o_target, $(OBJS)) # # defines $(obj).depend target include $(SRCTREE)/rules.mk sinclude $(obj).depend # -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Exynos 5250 Query] Smp Boot
Reminder, Please can anyone respond On 9/16/13, MJ embd mj.e...@gmail.com wrote: Hi, I was trying to understand the booting (till linux) on samsung exynos 5250. As this is my first on ARM Cortex. I have a few questions, so following is a step by step understanding and [Q] mentions the question I am asking [1] At POR (Power on Reset) the Internal Boot rom code executes, and checks the boot location and if it finds sd card, it copies 14k from the sd card (which is u-boot-spl.bin) into iRAM. [2] the internal boot rom branches pc to the entry point of spl at __start (0x2023400) [3] First instruction at __start is b reset. [4] this takes the route reset | cpu_init_crit | low_level_init | first_cpu [Q 1] At this point what is the state of secondary core, is it held in reset ? As per document, the secondary CPUs (CPU1, CPU2, and CPU3) execute a WFI instruction, which is actually a loop that checks the value of SYS_FLAGS register. I couldnt find the SYS_FLAGS register in Cortex A15 manual, can some one point. [Q 2] The secondary core until the point the boot core calls smp_kick_secondary is just waiting in WFI. [5] the smp_kick_secondary does the following (a) at the address SYSFLAGS_ADDR (0x202) which is not in spl but above it, it write the b reset instruction and (b) Issues a SGI to the secondary core [Q 3] Does this mean that secondary core is listening at address 0x202, I couldnt find that in any document? [6] Supposedly it does and it starts executing the reset function, secondary core would end up in enter_smp_pen. [Q 4] I dont understand what is trying to achieve here, Can some one explain. I am planning to pen down the complete boot sequence, all help appreciated. Thanks in advance. mj -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Understanding uboot child Makefiles
-- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec_mxc: Fix timeouts during tftp transfer
Dear Fabio Estevam, From: Fabio Estevam fabio.este...@freescale.com Performing tftp transfers on mx28 results in random timeouts. Hector Palacios and Robert Hodaszi analyzed the root cause being related to the alignment of the 'buff' buffer inside fec_recv(). GCC versions such as 4.4/4.5 are more likely to exhibit such problem. Use ALLOC_CACHE_ALIGN_BUFFER() for making the proper alignment of buffer. Reported-by: Hector Palacios hector.palac...@digi.com Tested-by: Oliver Metz oli...@freetz.org Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- drivers/net/fec_mxc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index 690e572..b423ff6 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -794,7 +794,7 @@ static int fec_recv(struct eth_device *dev) uint16_t bd_status; uint32_t addr, size, end; int i; - uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN); + ALLOC_CACHE_ALIGN_BUFFER(uchar, buff, FEC_MAX_PKT_SIZE); OK, it's gonna be safer this way, still what's the root cause of the issue? FEC_MAX_PKT_SIZE is 1536 (which is aligned to 32b and even 64b) __aligned(ARCH_DMA_MINALIGN) aligns the stuff to 32b or 64b depending on CPU So how can the above not properly align the buffer? Is that a compiler bug then? btw. using ALLOC_CACHE_ALIGN_BUFFER will be safer were someone to change FEC_MAX_PKT_SIZE, the buffer would still be safe for cache flush/inval ops. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/10] usb: Move 'bmRequestType' USB device request macros from EHCI header
Dear Vivek Gautam, Macros defining bmRequestType field of USB device request, given in table 9.2 USB 2.0 spec, are rather generic macros which can be further used by other Host controller stacks. So moving them to usb_defs header. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Julius Werner jwer...@chromium.org Cc: Simon Glass s...@chromium.org Cc: Minkyu Kang mk7.k...@samsung.com Cc: Dan Murphy dmur...@ti.com Cc: Marek Vasut ma...@denx.de Why not just use include/usb.h ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/10] USB: XHCI: Add xHCI host controller stack driver
Hi Minkyu, do you want to pick the exynos adjustments (04..10/10) via -samsung tree or shall I take the whole set via -usb ? I'd be inclined to the later, since it will make things easier to keep in sync, but it might produce a merge conflict. Nonetheless, I'd like to apply this only for -next. Thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/10] usb: Move 'bmRequestType' USB device request macros from EHCI header
Hi Marek, On Tue, Sep 17, 2013 at 8:32 AM, Marek Vasut ma...@denx.de wrote: Dear Vivek Gautam, Macros defining bmRequestType field of USB device request, given in table 9.2 USB 2.0 spec, are rather generic macros which can be further used by other Host controller stacks. So moving them to usb_defs header. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Julius Werner jwer...@chromium.org Cc: Simon Glass s...@chromium.org Cc: Minkyu Kang mk7.k...@samsung.com Cc: Dan Murphy dmur...@ti.com Cc: Marek Vasut ma...@denx.de Why not just use include/usb.h ? The bit field definitions for usb-types usb-recipient, and directions are itself defined in usb_defs.h; so i thought of keeping their combination just below it, so that it would not be difficult to reference. Please let me know if you want me to move them to include/usb.h Best regards, Marek Vasut -- Best Regards Vivek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Add device tree support for VxWorks
Hello Wolfgang,
You intend to 1) just keep the existing 'bootvx' command for
compatibility with older VxWorks versions, and 2) use plain 'bootm'
for new versions, like we do for other OSes?
Yes, this is what I intended to implement, sorry for not being
more clear. The pesdo-code is like this:
int do_bootm_vxworks(bootm_headers_t *images)
{
if (images-ft_addr)
do_bootvx_fdt(images);
else
do_bootvx(NULL, 0, 0, NULL);
}
So 'bootm' works with new versions of VxWorks if device tree blob
is provided, otherwise it falls back to 'bootvx'.
The original idea was to separate 'bootvx' from 'bootm' entirely,
but I am not sure how many users out there that depend on the old
behavior, so I am inclined to keep it and not break anyone.
Could you help review the patches ? Thank you very much.
Miao
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v10 1/6] core support of arm64
Dear Scott, In message 1379373546.2536.199.ca...@snotra.buserror.net you wrote: + * + * SPDX-License-Identifier:GPL-2.0+ + */ Note that Tom said he'd be OK with using GPL2-only code from Linux, as long as it's properly attributed. But we do prefer GPL-2.0+ whenever we can have it. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If I have seen further it is by standing on the shoulders of giants. - Isaac Newton, Letter to Robert Hooke, 5 February 1676 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/3] dfu: unify mmc/nand read/write ops enum
Hello Afzal, Sorry for the late replay ... Am 13.09.2013 18:59, schrieb Afzal Mohammed: MMC and NAND independently defines same enumerators for read/write. Unify them by defining enum in dfu header. RAM support that is being added newly also can make use of it. Signed-off-by: Afzal Mohammedafzal.mohd...@gmail.com Cc: Heiko Schocherh...@denx.de Cc: Marek Vasutma...@denx.de Cc: Lukasz Majewskil.majew...@samsung.com Cc: Pantelis Antonioupa...@antoniou-consulting.com Acked-by: Lukasz Majewskil.majew...@samsung.com Acked-by: Marek Vasutma...@denx.de --- v4: collect more tag v3: collected tag v2: new drivers/dfu/dfu_mmc.c | 9 ++--- drivers/dfu/dfu_nand.c | 7 +-- include/dfu.h | 5 + 3 files changed, 8 insertions(+), 13 deletions(-) Thanks! Acked-by: Heiko Schocher h...@denx.de bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/3] dfu: ram support
Hello Afzal, Am 13.09.2013 19:00, schrieb Afzal Mohammed: DFU spec mentions it as a method to upgrade firmware (software stored in writable non-volatile memory). It also says other potential uses of DFU is beyond scope of the spec. Here such a beyond the scope use is being attempted - directly pumping binary images from host via USB to RAM. This facility is a developer centric one in that it gives advantage over upgrading non-volatile memory for testing new images every time during development and/or testing. Directly putting image onto RAM would speed up upgrade process. This and convenience was the initial thoughts that led to doing this, speed improvement over MMC was only 1 second though - 6 sec on RAM as opposed to 7 sec on MMC in beagle bone, perhaps enabling cache and/or optimizing DFU framework to avoid multiple copy for ram (if worth) may help, and on other platforms and other boot media like NAND maybe improvement would be higher. And for a platform that doesn't yet have proper DFU suppport for non-volatile media's, DFU to RAM can be used. Another minor advantage would be to increase life of mmc/nand as it would be less used during development/testing. usage:image name ramstart address size eg. kernel ram 0x8100 0x100 Downloading images to RAM using DFU is not something new, this is acheived in openmoko also. DFU on RAM can be used for extracting RAM contents to host using dfu upload. Perhaps this can be extended to io for squeezing out register dump through usb, if it is worth. Signed-off-by: Afzal Mohammedafzal.mohd...@gmail.com Cc: Heiko Schocherh...@denx.de Cc: Marek Vasutma...@denx.de Cc: Lukasz Majewskil.majew...@samsung.com Cc: Pantelis Antonioupa...@antoniou-consulting.com Cc: Gerhard Sittigg...@denx.de Acked-by: Marek Vasutma...@denx.de Acked-by: Lukasz Majewskil.majew...@samsung.com --- v4: avoid doing prefix increment in argument of simple_strtoul() collect more tags v3: error used instead of printf v2: remove read/write enumerator define's, instead use new common ones drivers/dfu/Makefile | 1 + drivers/dfu/dfu.c | 7 +++-- drivers/dfu/dfu_ram.c | 77 +++ include/dfu.h | 18 4 files changed, 101 insertions(+), 2 deletions(-) create mode 100644 drivers/dfu/dfu_ram.c Thanks for this work! Hmm... minor comment. Could you add a entry in README? Beside of that: Acked-by: Heiko Schocher h...@denx.de bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] i2c: move to new subsystem
Hello Philippe,
added stefano babic, as he is the imx custodian, to cc
Am 15.09.2013 21:09, schrieb Philippe Reynes:
Signed-off-by: Philippe Reynestrem...@yahoo.fr
---
README |3 +
arch/arm/cpu/armv7/mx5/clock.c |2 +-
arch/arm/cpu/armv7/mx6/clock.c |2 +-
arch/arm/imx-common/Makefile |2 +-
drivers/i2c/Makefile |2 +-
drivers/i2c/mxc_i2c.c | 109 ++-
6 files changed, 57 insertions(+), 63 deletions(-)
First, thanks for this work!
Could you please change your subject in something like
i2c, mxc: switch to new multibus/multiadapter framework ?
diff --git a/README b/README
index 63706be..7c734ba 100644
--- a/README
+++ b/README
@@ -1995,6 +1995,9 @@ CBFS (Coreboot Filesystem) support
- CONFIG_SYS_I2C_PPC4XX_CH0 activate hardware channel 0
- CONFIG_SYS_I2C_PPC4XX_CH1 activate hardware channel 1
+ - drivers/i2c/i2c_mxc.c
+- activate this driver with CONFIG_SYS_I2C_MXC
+
You should use some new defines for the speed setting ... did you?
If not please add them, thanks.
additional defines:
CONFIG_SYS_NUM_I2C_BUSES
[...]
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 37ccbd1..f9fcebe 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -14,7 +14,7 @@ COBJS-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o
COBJS-$(CONFIG_DW_I2C) += designware_i2c.o
COBJS-$(CONFIG_I2C_MVTWSI) += mvtwsi.o
COBJS-$(CONFIG_I2C_MV) += mv_i2c.o
-COBJS-$(CONFIG_I2C_MXC) += mxc_i2c.o
+COBJS-$(CONFIG_SYS_I2C_MXC) += mxc_i2c.o
Please keep this list sorted.
COBJS-$(CONFIG_I2C_MXS) += mxs_i2c.o
COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o
COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o
diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index 06ba4e3..3ac1865 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -153,21 +153,6 @@ static int bus_i2c_set_bus_speed(void *base, int speed)
return 0;
}
-/*
- * Get I2C Speed
- */
-static unsigned int bus_i2c_get_bus_speed(void *base)
-{
- struct mxc_i2c_regs *i2c_regs = (struct mxc_i2c_regs *)base;
- u8 clk_idx = readb(i2c_regs-ifdr);
- u8 clk_div;
-
- for (clk_div = 0; i2c_clk_div[clk_div][1] != clk_idx; clk_div++)
- ;
-
- return mxc_get_clock(MXC_I2C_CLK) / i2c_clk_div[clk_div][0];
-}
-
#define ST_BUS_IDLE (0 | (I2SR_IBB 8))
#define ST_BUS_BUSY (I2SR_IBB | (I2SR_IBB 8))
#define ST_IIF (I2SR_IIF | (I2SR_IIF 8))
@@ -410,20 +395,30 @@ struct sram_data {
*/
static struct sram_data __attribute__((section(.data))) srdata;
-void *get_base(void)
-{
-#ifdef CONFIG_SYS_I2C_BASE
-#ifdef CONFIG_I2C_MULTI_BUS
- void *ret = srdata.i2c_data[srdata.curr_i2c_bus].base;
- if (ret)
- return ret;
-#endif
- return (void *)CONFIG_SYS_I2C_BASE;
-#elif defined(CONFIG_I2C_MULTI_BUS)
- return srdata.i2c_data[srdata.curr_i2c_bus].base;
+static void * const i2c_bases[] = {
+#if defined(CONFIG_MX25)
+ (void *)IMX_I2C_BASE,
+ (void *)IMX_I2C2_BASE,
+ (void *)IMX_I2C3_BASE
+#elif defined(CONFIG_MX27)
+ (void *)IMX_I2C1_BASE,
+ (void *)IMX_I2C2_BASE
+#elif defined(CONFIG_MX31) || defined(CONFIG_MX35) || \
+ defined(CONFIG_MX51) || defined(CONFIG_MX53) || \
+ defined(CONFIG_MX6)
+ (void *)I2C1_BASE_ADDR,
+ (void *)I2C2_BASE_ADDR,
+ (void *)I2C3_BASE_ADDR
+#elif defined(CONFIG_VF610)
+ (void *)I2C0_BASE_ADDR
#else
- return srdata.i2c_data[0].base;
+#error architecture not supported
#endif
+};
+
+void *i2c_get_base(struct i2c_adapter *adap)
+{
+ return i2c_bases[adap-hwadapnr];
}
static struct i2c_parms *i2c_get_parms(void *base)
@@ -448,39 +443,26 @@ static int i2c_idle_bus(void *base)
return 0;
}
-#ifdef CONFIG_I2C_MULTI_BUS
-unsigned int i2c_get_bus_num(void)
+int mxc_i2c_read(struct i2c_adapter *adap, uint8_t chip,
static now
+ uint addr, int alen, uint8_t *buffer,
+ int len)
{
- return srdata.curr_i2c_bus;
+ return bus_i2c_read(i2c_get_base(adap), chip, addr, alen, buffer, len);
}
-int i2c_set_bus_num(unsigned bus_idx)
-{
- if (bus_idx= ARRAY_SIZE(srdata.i2c_data))
- return -1;
- if (!srdata.i2c_data[bus_idx].base)
- return -1;
- srdata.curr_i2c_bus = bus_idx;
- return 0;
-}
-#endif
-
-int i2c_read(uchar chip, uint addr, int alen, uchar *buf, int len)
+int mxc_i2c_write(struct i2c_adapter *adap, uint8_t chip,
static now
+ uint addr, int alen, uint8_t *buffer,
+ int len)
{
- return bus_i2c_read(get_base(), chip, addr, alen, buf, len);
-}
-
-int i2c_write(uchar chip, uint addr, int alen, uchar *buf, int len)
-{
- return
Re: [U-Boot] [PATCH 2/2] i2c: update config using mxc driver to new subsystem
Hello Phillipe,
added Stefano Babic to cc
Am 15.09.2013 21:09, schrieb Philippe Reynes:
Signed-off-by: Philippe Reynestrem...@yahoo.fr
---
include/configs/apf27.h |5 ++---
include/configs/flea3.h |6 +++---
include/configs/imx31_phycore.h |6 +++---
include/configs/m53evk.h |6 +++---
include/configs/mx25pdk.h |6 +++---
include/configs/mx35pdk.h |6 +++---
include/configs/mx53ard.h |6 +++---
include/configs/mx53evk.h |6 +++---
include/configs/mx53loco.h|6 +++---
include/configs/mx53smd.h |6 +++---
include/configs/mx6qsabreauto.h |3 ++-
include/configs/nitrogen6x.h |3 ++-
include/configs/titanium.h|3 ++-
include/configs/vf610twr.h|6 +++---
include/configs/woodburn_common.h |6 +++---
15 files changed, 41 insertions(+), 39 deletions(-)
diff --git a/include/configs/apf27.h b/include/configs/apf27.h
index e7e258f..7e0a8a8 100644
--- a/include/configs/apf27.h
+++ b/include/configs/apf27.h
@@ -321,9 +321,8 @@
*/
#ifdef CONFIG_CMD_I2C
-#define CONFIG_HARD_I2C
-#define CONFIG_I2C_MXC
-#define CONFIG_SYS_I2C_BASEIMX_I2C1_BASE
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
#define CONFIG_SYS_I2C_SPEED 10 /* 100 kHz */
#define CONFIG_SYS_I2C_SLAVE 0x7F
#define CONFIG_SYS_I2C_NOPROBES { }
diff --git a/include/configs/flea3.h b/include/configs/flea3.h
index cfcaf1b..d91fdab 100644
--- a/include/configs/flea3.h
+++ b/include/configs/flea3.h
@@ -50,9 +50,9 @@
/*
* Hardware drivers
*/
-#define CONFIG_HARD_I2C
-#define CONFIG_I2C_MXC
-#define CONFIG_SYS_I2C_BASEI2C3_BASE_ADDR
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
+#define CONFIG_SYS_SPD_BUS_NUM 2
#define CONFIG_SYS_I2C_SPEED 10
#define CONFIG_SYS_I2C_SLAVE 0xfe
Ah, here we have a different slave address as before - we need this settings
configurable. Speed setting is equal for all boards, so we need only the slave
addr configurable at the moment.
#define CONFIG_MXC_SPI
diff --git a/include/configs/imx31_phycore.h b/include/configs/imx31_phycore.h
index 720e1bf..bf1a2cb 100644
--- a/include/configs/imx31_phycore.h
+++ b/include/configs/imx31_phycore.h
@@ -35,9 +35,9 @@
* Hardware drivers
*/
-#define CONFIG_HARD_I2C
-#define CONFIG_I2C_MXC
-#define CONFIG_SYS_I2C_BASEI2C2_BASE_ADDR
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
+#define CONFIG_SYS_SPD_BUS_NUM 1
#define CONFIG_SYS_I2C_CLK_OFFSET I2C2_CLK_OFFSET
#define CONFIG_SYS_I2C_SPEED 10
diff --git a/include/configs/m53evk.h b/include/configs/m53evk.h
index ccb07e3..4e06537 100644
--- a/include/configs/m53evk.h
+++ b/include/configs/m53evk.h
@@ -161,9 +161,9 @@
* I2C
*/
#ifdef CONFIG_CMD_I2C
-#define CONFIG_HARD_I2C
-#define CONFIG_I2C_MXC
-#define CONFIG_SYS_I2C_BASEI2C2_BASE_ADDR
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
+#define CONFIG_SYS_SPD_BUS_NUM 1
#define CONFIG_SYS_I2C_SPEED 10
#endif
diff --git a/include/configs/mx25pdk.h b/include/configs/mx25pdk.h
index 543c415..22fb31b 100644
--- a/include/configs/mx25pdk.h
+++ b/include/configs/mx25pdk.h
@@ -111,9 +111,9 @@
/* I2C Configs */
#define CONFIG_CMD_I2C
-#define CONFIG_HARD_I2C
-#define CONFIG_I2C_MXC
-#define CONFIG_SYS_I2C_BASEIMX_I2C_BASE
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
+#define CONFIG_SYS_SPD_BUS_NUM 0
#define CONFIG_SYS_I2C_SPEED 10
/* RTC */
diff --git a/include/configs/mx35pdk.h b/include/configs/mx35pdk.h
index 68b225a..f9387a3 100644
--- a/include/configs/mx35pdk.h
+++ b/include/configs/mx35pdk.h
@@ -41,9 +41,9 @@
/*
* Hardware drivers
*/
-#define CONFIG_HARD_I2C
-#define CONFIG_I2C_MXC
-#define CONFIG_SYS_I2C_BASEI2C1_BASE_ADDR
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
+#define CONFIG_SYS_SPD_BUS_NUM 0
#define CONFIG_SYS_I2C_SPEED 10
#define CONFIG_MXC_SPI
#define CONFIG_MXC_GPIO
diff --git a/include/configs/mx53ard.h b/include/configs/mx53ard.h
index 122ffd0..e74fc5a 100644
--- a/include/configs/mx53ard.h
+++ b/include/configs/mx53ard.h
@@ -44,9 +44,9 @@
/* I2C Configs */
#define CONFIG_CMD_I2C
-#define CONFIG_HARD_I2C
-#define CONFIG_I2C_MXC
-#define CONFIG_SYS_I2C_BASEI2C2_BASE_ADDR
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
+#define CONFIG_SYS_SPD_BUS_NUM 1
#define CONFIG_SYS_I2C_SPEED10
/* MMC Configs */
diff --git a/include/configs/mx53evk.h b/include/configs/mx53evk.h
index d39ce7b..c7582f9 100644
--- a/include/configs/mx53evk.h
+++ b/include/configs/mx53evk.h
@@ -37,9 +37,9 @@
/* I2C Configs */
#define CONFIG_CMD_I2C
-#define CONFIG_HARD_I2C
-#define CONFIG_I2C_MXC
-#define CONFIG_SYS_I2C_BASEI2C2_BASE_ADDR
+#define
Re: [U-Boot] [Exynos 5250 Query] Smp Boot
Hi, You could try to cc whoever wrote the code. You can use git blame to find out. But it sounds like you are on the right track. I may be able to help, will email tomorrow if so. Regards, Simon On Sep 16, 2013 8:26 PM, MJ embd mj.e...@gmail.com wrote: Reminder, Please can anyone respond On 9/16/13, MJ embd mj.e...@gmail.com wrote: Hi, I was trying to understand the booting (till linux) on samsung exynos 5250. As this is my first on ARM Cortex. I have a few questions, so following is a step by step understanding and [Q] mentions the question I am asking [1] At POR (Power on Reset) the Internal Boot rom code executes, and checks the boot location and if it finds sd card, it copies 14k from the sd card (which is u-boot-spl.bin) into iRAM. [2] the internal boot rom branches pc to the entry point of spl at __start (0x2023400) [3] First instruction at __start is b reset. [4] this takes the route reset | cpu_init_crit | low_level_init | first_cpu [Q 1] At this point what is the state of secondary core, is it held in reset ? As per document, the secondary CPUs (CPU1, CPU2, and CPU3) execute a WFI instruction, which is actually a loop that checks the value of SYS_FLAGS register. I couldnt find the SYS_FLAGS register in Cortex A15 manual, can some one point. [Q 2] The secondary core until the point the boot core calls smp_kick_secondary is just waiting in WFI. [5] the smp_kick_secondary does the following (a) at the address SYSFLAGS_ADDR (0x202) which is not in spl but above it, it write the b reset instruction and (b) Issues a SGI to the secondary core [Q 3] Does this mean that secondary core is listening at address 0x202, I couldnt find that in any document? [6] Supposedly it does and it starts executing the reset function, secondary core would end up in enter_smp_pen. [Q 4] I dont understand what is trying to achieve here, Can some one explain. I am planning to pen down the complete boot sequence, all help appreciated. Thanks in advance. mj -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
