[U-Boot] [PATCH v3 0/3] apf27: add support of armadeus apf27
Difference between v3 and v2: - rebase on imx branch - merge support and spl patch - clean code of apf27_gpio_init - clean code of start.S - enable only 64MB of ram so it could work on all apf27 Difference between v1 and v2: - use spl instead of nand_spl - use gpio api - remove use of useless CONFIG_SYS - remove use of config.mk - remove dead code Philippe Reynes (3): apf27: add missing constant to mx27 apf27: add support for the armadeus APF27 board apf27: add FPGA support for the apf27 board MAINTAINERS |5 + arch/arm/cpu/arm926ejs/mx27/asm-offsets.c | 34 ++ arch/arm/include/asm/arch-mx27/imx-regs.h | 11 +- arch/arm/include/asm/arch-mx27/mxc_nand.h | 83 + board/armadeus/apf27/Makefile | 51 +++ board/armadeus/apf27/apf27.c | 363 +++ board/armadeus/apf27/apf27.h | 477 + board/armadeus/apf27/fpga.c | 262 ++ board/armadeus/apf27/fpga.h | 39 ++ board/armadeus/apf27/start.S | 538 + board/armadeus/apf27/u-boot-spl.lds | 86 + boards.cfg|1 + include/configs/apf27.h | 445 13 files changed, 2394 insertions(+), 1 deletions(-) create mode 100644 arch/arm/include/asm/arch-mx27/mxc_nand.h create mode 100644 board/armadeus/apf27/Makefile create mode 100644 board/armadeus/apf27/apf27.c create mode 100644 board/armadeus/apf27/apf27.h create mode 100644 board/armadeus/apf27/fpga.c create mode 100644 board/armadeus/apf27/fpga.h create mode 100644 board/armadeus/apf27/start.S create mode 100644 board/armadeus/apf27/u-boot-spl.lds create mode 100644 include/configs/apf27.h -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] apf27: add missing constant to mx27
Add some missing constant (chip select, ...), and
a file mxc_nand.h with the NFC constant.
Signed-off-by: Philippe Reynes
Signed-off-by: Eric Jarrige
---
arch/arm/cpu/arm926ejs/mx27/asm-offsets.c | 34
arch/arm/include/asm/arch-mx27/imx-regs.h | 11 -
arch/arm/include/asm/arch-mx27/mxc_nand.h | 83 +
3 files changed, 127 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/include/asm/arch-mx27/mxc_nand.h
diff --git a/arch/arm/cpu/arm926ejs/mx27/asm-offsets.c
b/arch/arm/cpu/arm926ejs/mx27/asm-offsets.c
index f3a8d7b..b95c58c 100644
--- a/arch/arm/cpu/arm926ejs/mx27/asm-offsets.c
+++ b/arch/arm/cpu/arm926ejs/mx27/asm-offsets.c
@@ -34,6 +34,7 @@ int main(void)
DEFINE(PCDR1, IMX_PLL_BASE + offsetof(struct pll_regs, pcdr1));
DEFINE(PCCR0, IMX_PLL_BASE + offsetof(struct pll_regs, pccr0));
DEFINE(PCCR1, IMX_PLL_BASE + offsetof(struct pll_regs, pccr1));
+ DEFINE(CCSR, IMX_PLL_BASE + offsetof(struct pll_regs, ccsr));
DEFINE(ESDCTL0_ROF, offsetof(struct esdramc_regs, esdctl0));
DEFINE(ESDCFG0_ROF, offsetof(struct esdramc_regs, esdcfg0));
@@ -41,5 +42,38 @@ int main(void)
DEFINE(ESDCFG1_ROF, offsetof(struct esdramc_regs, esdcfg1));
DEFINE(ESDMISC_ROF, offsetof(struct esdramc_regs, esdmisc));
+ DEFINE(GPCR, IMX_SYSTEM_CTL_BASE +
+ offsetof(struct system_control_regs, gpcr));
+ DEFINE(FMCR, IMX_SYSTEM_CTL_BASE +
+ offsetof(struct system_control_regs, fmcr));
+ DEFINE(DSCR2, IMX_SYSTEM_CTL_BASE +
+ offsetof(struct system_control_regs, dscr2));
+ DEFINE(DSCR3, IMX_SYSTEM_CTL_BASE +
+ offsetof(struct system_control_regs, dscr3));
+ DEFINE(DSCR7, IMX_SYSTEM_CTL_BASE +
+ offsetof(struct system_control_regs, dscr7));
+ DEFINE(DSCR10, IMX_SYSTEM_CTL_BASE +
+ offsetof(struct system_control_regs, dscr10));
+
+ DEFINE(CS0U, IMX_WEIM_BASE + offsetof(struct weim_regs, cs0u));
+ DEFINE(CS0L, IMX_WEIM_BASE + offsetof(struct weim_regs, cs0l));
+ DEFINE(CS0A, IMX_WEIM_BASE + offsetof(struct weim_regs, cs0a));
+ DEFINE(CS1U, IMX_WEIM_BASE + offsetof(struct weim_regs, cs1u));
+ DEFINE(CS1L, IMX_WEIM_BASE + offsetof(struct weim_regs, cs1l));
+ DEFINE(CS1A, IMX_WEIM_BASE + offsetof(struct weim_regs, cs1a));
+ DEFINE(CS2U, IMX_WEIM_BASE + offsetof(struct weim_regs, cs2u));
+ DEFINE(CS2L, IMX_WEIM_BASE + offsetof(struct weim_regs, cs2l));
+ DEFINE(CS2A, IMX_WEIM_BASE + offsetof(struct weim_regs, cs2a));
+ DEFINE(CS3U, IMX_WEIM_BASE + offsetof(struct weim_regs, cs3u));
+ DEFINE(CS3L, IMX_WEIM_BASE + offsetof(struct weim_regs, cs3l));
+ DEFINE(CS3A, IMX_WEIM_BASE + offsetof(struct weim_regs, cs3a));
+ DEFINE(CS4U, IMX_WEIM_BASE + offsetof(struct weim_regs, cs4u));
+ DEFINE(CS4L, IMX_WEIM_BASE + offsetof(struct weim_regs, cs4l));
+ DEFINE(CS4A, IMX_WEIM_BASE + offsetof(struct weim_regs, cs4a));
+ DEFINE(CS5U, IMX_WEIM_BASE + offsetof(struct weim_regs, cs5u));
+ DEFINE(CS5L, IMX_WEIM_BASE + offsetof(struct weim_regs, cs5l));
+ DEFINE(CS5A, IMX_WEIM_BASE + offsetof(struct weim_regs, cs5a));
+ DEFINE(EIM, IMX_WEIM_BASE + offsetof(struct weim_regs, eim));
+
return 0;
}
diff --git a/arch/arm/include/asm/arch-mx27/imx-regs.h
b/arch/arm/include/asm/arch-mx27/imx-regs.h
index 2f6c823..d3a14e1 100644
--- a/arch/arm/include/asm/arch-mx27/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx27/imx-regs.h
@@ -185,7 +185,7 @@ struct iim_regs {
struct fuse_bank {
u32 fuse_regs[0x20];
u32 fuse_rsvd[0xe0];
- } bank[1];
+ } bank[2];
};
struct fuse_bank0_regs {
@@ -511,4 +511,13 @@ struct fuse_bank0_regs {
#define IIM_ERR_SNSE (1 << 2)
#define IIM_ERR_PARITYE(1 << 1)
+/*
+ * Memory areas of the NFC
+ */
+#define IMX_NFC_BASE(0xD800)
+#define IMX_NFC_MAIN_AREA0 (0xD800)
+#define IMX_NFC_MAIN_AREA1 (0xD8000200)
+#define IMX_NFC_SPARE_AREA0 (0xD8000800)
+#define IMX_NFC_REGS(0xD8000E00)
+
#endif /* _IMX_REGS_H */
diff --git a/arch/arm/include/asm/arch-mx27/mxc_nand.h
b/arch/arm/include/asm/arch-mx27/mxc_nand.h
new file mode 100644
index 000..564419e
--- /dev/null
+++ b/arch/arm/include/asm/arch-mx27/mxc_nand.h
@@ -0,0 +1,83 @@
+/*
+ * (c) 2012 Philippe Reynes
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty
[U-Boot] [PATCH v3 3/3] apf27: add FPGA support for the apf27 board
Signed-off-by: Philippe Reynes
Signed-off-by: Eric Jarrige
---
board/armadeus/apf27/Makefile |3 +
board/armadeus/apf27/apf27.c | 16 +++
board/armadeus/apf27/fpga.c | 262 +
board/armadeus/apf27/fpga.h | 39 ++
4 files changed, 320 insertions(+), 0 deletions(-)
create mode 100644 board/armadeus/apf27/fpga.c
create mode 100644 board/armadeus/apf27/fpga.h
diff --git a/board/armadeus/apf27/Makefile b/board/armadeus/apf27/Makefile
index f57f405..9d356a3 100644
--- a/board/armadeus/apf27/Makefile
+++ b/board/armadeus/apf27/Makefile
@@ -29,6 +29,9 @@ LIB = $(obj)lib$(BOARD).o
ifndef CONFIG_SPL_BUILD
COBJS := apf27.o
+ifdef CONFIG_FPGA
+COBJS += fpga.o
+endif
endif
SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/board/armadeus/apf27/apf27.c b/board/armadeus/apf27/apf27.c
index cbd09a7..e375a76 100644
--- a/board/armadeus/apf27/apf27.c
+++ b/board/armadeus/apf27/apf27.c
@@ -30,6 +30,7 @@
#include
#include "apf27.h"
#include "crc.h"
+#include "fpga.h"
DECLARE_GLOBAL_DATA_PTR;
@@ -310,6 +311,21 @@ misc_init_r(void)
struct mtd_device *dev;
struct part_info *part;
+#if defined(CONFIG_FPGA)
+ /* init and download fpga */
+ if ((autoload) && (0 == strcmp(autoload, "1"))) {
+ if (mtdparts_init() == 0)
+ if (find_dev_and_part("firmware",
+ &dev, &pnum, &part) == 0) {
+ size = part->size;
+ if (nand_read_skip_bad(&nand_info[0],
+ part->offset, &size, firmware_buffer))
+ size = 0;
+ }
+ }
+ APF27_init_fpga(firmware_buffer, size);
+#endif
+
/* detect compatibility issue of environment version */
s = getenv("env_version");
if ((NULL == s) || (0 != strcmp(s, CONFIG_ENV_VERSION))) {
diff --git a/board/armadeus/apf27/fpga.c b/board/armadeus/apf27/fpga.c
new file mode 100644
index 000..d5c27a7
--- /dev/null
+++ b/board/armadeus/apf27/fpga.c
@@ -0,0 +1,262 @@
+/*
+ * (C) Copyright 2002-2012
+ * Eric Jarrige
+ * Rich Ireland, Enterasys Networks, rirel...@enterasys.com.
+ * Keith Outwater, keith_outwa...@mvis.com.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include "fpga.h"
+#include
+#include "apf27.h"
+
+/*
+ * Note that these are pointers to code that is in Flash. They will be
+ * relocated at runtime.
+ * Spartan2 code is used to download our Spartan 3 :) code is compatible.
+ * Just take care about the file size
+ */
+Xilinx_Spartan3_Slave_Parallel_fns fpga_fns = {
+ fpga_pre_fn,
+ fpga_pgm_fn,
+ fpga_init_fn,
+ NULL,
+ fpga_done_fn,
+ fpga_clk_fn,
+ fpga_cs_fn,
+ fpga_wr_fn,
+ fpga_rdata_fn,
+ fpga_wdata_fn,
+ fpga_busy_fn,
+ fpga_abort_fn,
+ fpga_post_fn,
+};
+
+Xilinx_desc fpga[CONFIG_FPGA_COUNT] = {
+ {Xilinx_Spartan3,
+slave_parallel,
+1196128l/8,
+(void *) &fpga_fns,
+0}
+};
+
+/*
+ * Initialize GPIO port B before download
+ */
+int
+fpga_pre_fn(int cookie)
+{
+ /* Initialize GPIO pins */
+ gpio_set_value(ACFG_FPGA_PWR, 1);
+ imx_gpio_mode(ACFG_FPGA_INIT | GPIO_IN | GPIO_PUEN | GPIO_GPIO);
+ imx_gpio_mode(ACFG_FPGA_DONE | GPIO_IN | GPIO_PUEN | GPIO_GPIO);
+ imx_gpio_mode(ACFG_FPGA_PRG | GPIO_OUT | GPIO_PUEN | GPIO_GPIO);
+ imx_gpio_mode(ACFG_FPGA_CLK | GPIO_OUT | GPIO_PUEN | GPIO_GPIO);
+ imx_gpio_mode(ACFG_FPGA_RW | GPIO_OUT | GPIO_PUEN | GPIO_GPIO);
+ imx_gpio_mode(ACFG_FPGA_CS | GPIO_OUT | GPIO_PUEN | GPIO_GPIO);
+ imx_gpio_mode(ACFG_FPGA_SUSPEND|GPIO_OUT|GPIO_PUEN|GPIO_GPIO);
+ gpio_set_value(ACFG_FPGA_RESET, 1);
+ imx_gpio_mode(ACFG_FPGA_RESET | GPIO_OUT | GPIO_PUEN | GPIO_GPIO);
+ imx_gpio_mode(ACFG_FPGA_PWR | GPIO_OUT | GPIO_PUEN | GPIO_GPIO);
+ gpio_set_value(ACFG_FPGA_PRG, 1);
+ gpio_set_value(ACFG_FPGA_CLK, 1);
+ gpio_set_value(ACFG_FPGA_RW, 1);
+ gpio_set_value(A
[U-Boot] Please pull u-boot-x86.git
The following changes since commit b8715d8def240014da5614a4f940130ec06d9ebf: Merge branch 'master' of git://git.denx.de/u-boot-fdt (2012-11-29 06:41:56 -0700) are available in the git repository at: git://git.denx.de/u-boot-x86.git master Gabe Black (6): x86: Allow compiling out realmode/bios code x86: Add an fdt pointer to the global data structure x86: Add a minimal device tree for alex x86 x86: Add a default implementation for cleanup_before_linux() x86: Add a dummy implementation for timer_get_us x86: Include types.h explicitly in the i386 version of io.h Simon Glass (4): x86: coreboot: Decode additional coreboot sysinfo tags x86: Select stdio devices for coreboot x86: Remove coreboot start16 code x86: Define CONFIG_SYS_VSNPRINTF for coreboot Stefan Reinauer (4): x86: coreboot: Drop sysinfo.c x86: video: Add coreboot framebuffer support x86: Fix typo in pcat_timer.c x86: Don't spam POST80 codes with slow IO functions Vadim Bendebury (2): x86: Add CBMEM console driver for coreboot x86: Add console command to display CBMEM console buffer README |6 + arch/x86/cpu/Makefile|2 +- arch/x86/cpu/coreboot/Makefile |1 - arch/x86/cpu/coreboot/sysinfo.c | 39 --- arch/x86/cpu/coreboot/tables.c | 117 ++ arch/x86/cpu/cpu.c |5 + arch/x86/cpu/timer.c | 17 +++ arch/x86/include/asm/arch-coreboot/sysinfo.h | 34 +-- arch/x86/include/asm/arch-coreboot/tables.h | 74 ++ arch/x86/include/asm/global_data.h |1 + arch/x86/include/asm/io.h|4 +- arch/x86/include/asm/u-boot-x86.h|1 + arch/x86/lib/Makefile|9 +- arch/x86/lib/pcat_timer.c|2 +- arch/x86/lib/video.c |2 + arch/x86/lib/zimage.c|4 +- board/chromebook-x86/coreboot/Makefile |1 - board/chromebook-x86/coreboot/coreboot_start16.S | 33 -- board/chromebook-x86/dts/x86-alex.dts| 30 ++ common/stdio.c |4 +- drivers/misc/Makefile|1 + drivers/misc/cbmem_console.c | 67 drivers/video/Makefile |1 + drivers/video/coreboot_fb.c | 101 +++ include/configs/coreboot.h | 13 +++ include/stdio_dev.h |3 + 26 files changed, 460 insertions(+), 112 deletions(-) delete mode 100644 arch/x86/cpu/coreboot/sysinfo.c create mode 100644 arch/x86/cpu/timer.c delete mode 100644 board/chromebook-x86/coreboot/coreboot_start16.S create mode 100644 board/chromebook-x86/dts/x86-alex.dts create mode 100644 drivers/misc/cbmem_console.c create mode 100644 drivers/video/coreboot_fb.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 20/23] Add command to show DRAM configuration
Hi, On Thu, Nov 22, 2012 at 11:13 AM, Simon Glass wrote: > The new meminfo command shows details memory information. It is implemented > by board_show_dram(), which should be implemented by the board. > > This is a rewrite of the patch: > >arm: Add option to display customised memory information > > according to feedback on the mailing list. > > Signed-off-by: Simon Glass I have ended up with two of these patches since I neglected to drop it from the arm series. So I would like to drop this one please. I will mark it superseded in patchwork. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/23] Add stricmp() and strnicmp()
Hi Scott, On Tue, Nov 27, 2012 at 2:12 PM, Scott Wood wrote: > On 11/22/2012 01:12:53 PM, Simon Glass wrote: >> >> strnicmp() is present but disabled. Make it available and define stricmp() >> also. There is a only a small performance penalty to having stricmp() >> call strnicmp(), so do this instead of a standalone function, to save code >> space. > > > Both POSIX and the Linux kernel call this strcasecmp() rather than > stricmp()... > Yes, I will fix this. I will also need to tidy up a few prototypes in other archs. Regards, Simon > -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] JFFS2 seems to drop nand data with ECC corrections
I had a few boards with NAND related problems. In Linux a file was written to a JFFS2 partition in NAND, but u-boot was unable to read the same file correctly from the JFFS2. This happened to be often the case if the NAND had a few bad blocks in the JFFS2 partition. Upon further examination it turned out Linux still was able to read the file 100% correctly from the partition, but u-boot wasn't. I did get a lot of "read_nand_cache: error reading nand off ..." messages in u-boot. When debugging further it appears that read_nand_cached(...) in /fs/jffs2/jffs2_1pass.c throws away the data if nand_read (/drivers/ mtd/nand/nand_base.c) doesn't return 0. This happens in case of an uncorrectable ECC error (-EBADMSG) or a correctable ECC error(-EUCLEAN). (see nand_do_read_ops in /drivers/ mtd/nand/nand_base.c) So this would mean that data gets thrown away in case of a correctable ECC error, which doesn't seem the right thing to do and probably does not match with how linux is behaving. I patched the code to not throw away data with correctable ECC errors and this seems to fix it for the two boards that had this issue. If it matters: the correctable ECC errors appeared in good blocks (but often close to a bad block). So would my understanding be 'correct'? Regards, Stephane Deltour PS: Sorry about the disclaimer, it is out of my control DISCLAIMER: Unless indicated otherwise, the information contained in this message is privileged and confidential, and is intended only for the use of the addressee(s) named above and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message and/or attachments is strictly prohibited. The company accepts no liability for any damage caused by any virus transmitted by this email. Furthermore, the company does not warrant a proper and complete transmission of this information, nor does it accept liability for any delays. If you have received this message in error, please contact the sender and delete the message. Thank you. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86.git
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/01/12 09:38, Simon Glass wrote: > The following changes since commit > b8715d8def240014da5614a4f940130ec06d9ebf: > > Merge branch 'master' of git://git.denx.de/u-boot-fdt (2012-11-29 > 06:41:56 -0700) > > are available in the git repository at: > > git://git.denx.de/u-boot-x86.git master > > Gabe Black (6): x86: Allow compiling out realmode/bios code x86: > Add an fdt pointer to the global data structure x86: Add a minimal > device tree for alex x86 x86: Add a default implementation for > cleanup_before_linux() x86: Add a dummy implementation for > timer_get_us x86: Include types.h explicitly in the i386 version of > io.h > > Simon Glass (4): x86: coreboot: Decode additional coreboot sysinfo > tags x86: Select stdio devices for coreboot x86: Remove coreboot > start16 code x86: Define CONFIG_SYS_VSNPRINTF for coreboot > > Stefan Reinauer (4): x86: coreboot: Drop sysinfo.c x86: video: Add > coreboot framebuffer support x86: Fix typo in pcat_timer.c x86: > Don't spam POST80 codes with slow IO functions > > Vadim Bendebury (2): x86: Add CBMEM console driver for coreboot > x86: Add console command to display CBMEM console buffer I know there's outstanding x86 work, but was all of this in some series that was posted before the merge window closed? Thanks! - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQuk0gAAoJENk4IS6UOR1WhSQQAIrj9V6WFTYTGP2I4/1KvTIZ 9MDou2S1okgYXkr0xIiNQdas9QFRTd3Z2xEVOlb5gPJhY8llDqs0TUrzTVlRoomd bb1Aaq4C+CKmVqNH2LdH4zWCJhSAmZPXigLu8UsUXZcMquzz7CPKmlYyid5psdYF 78OmAihoqsZEpYM/YdBg5koJ2dqi72Wud7IGeXGl3XwWGrMNKtuylCLIRLiuslAp 3u0Bet/lNQ/5fVXxmsPDVMrSr5Kd9To7zCVSXownrlGZVLKr3GV3H4plPdbqcqr5 kI4ZZhZLULMLFcMsbl9BN800Ud5Rv53O4ltW/WTtFRdxpdJeXuzZ2L9ooiRyHEPa E7YPXF3Ty1ovZZqMZR3zeLTbZS3fy6Kf7K/Kcw6+VFnf+XOvkbjaGuRr4LqHnKHw eIg/w9qUvafbxSno6OVzvx5AJypGI6h+jTg/hPiBiwKBRpiXTWaXxtv5X9NmGb9+ 2XcL9c3EMTf1UL2TFtdgQs+0qRn+nHQEyP45wEbnPzPcAynZBeOHxsT7NUtINNIX PFJ6G4w1UON8tV8gm3CytE/mTDAK2uQZzlrXxEXKCmOanyvMZjjT6IrxUMaexy1N +c5f8V9fMxjO91agt7qJXUSzbny4QdeLxZuwNs41xXhKa8/OIjXy0TJ6V5shsD8V 7mjKkkpLUCizvae3DNyU =h6IE -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/11] arm: ks8695eth: Use MAC address from environment
Hi Yann,
On Mon, Nov 19, 2012 at 5:42 AM, Yann Vernier wrote:
> On Fri, 26 Oct 2012 23:37:28 +0200
> Albert ARIBAUD wrote:
>
>> Hi Yann,
>>
>> On Fri, 19 Oct 2012 10:02:09 +0200, Yann Vernier
>> wrote:
>>
>> > On Thu, 18 Oct 2012 15:55:31 -0500
>> > Joe Hershberger wrote:
>> >
>> > > Hi Yann,
>> > >
>> > > On Fri, Oct 5, 2012 at 7:09 AM, Yann Vernier
>> > > wrote:
>> > > > Removed board specific MAC reading code from driver.
>> > > > Should move the reading to the cm4008/cm41xx board code.
>> > > > ---
>> > > > drivers/net/ks8695eth.c | 38
>> > > > +- 1 file changed, 9
>> > > > insertions(+), 29 deletions(-)
>> > > >
>> > > > diff --git a/drivers/net/ks8695eth.c b/drivers/net/ks8695eth.c
>> > > > index b4904b6..2dda7ab 100644
>> > > > --- a/drivers/net/ks8695eth.c
>> > > > +++ b/drivers/net/ks8695eth.c
>> > > > @@ -71,30 +71,13 @@ volatile uint8_t
>> > > > ks8695_bufs[BUFSIZE*(TXDESCS+RXDESCS)] __attribute__((aligned(2
>> > > >
>> > > >
>> > > > //
>> > > >
>> > > > -/*
>> > > > - * Ideally we want to use the MAC address stored in flash.
>> > > > - * But we do some sanity checks in case they are not
>> > > > present
>> > > > - * first.
>> > > > - */
>> > > > -unsigned char eth_mac[] = {
>> > > > - 0x00, 0x13, 0xc6, 0x00, 0x00, 0x00
>> > > > -};
>> > > > -
>> > > > -void ks8695_getmac(void)
>> > > > +static int ks8695_set_mac_address(struct eth_device *dev)
>> > > > {
>> > > > - unsigned char *fp;
>> > > > - int i;
>> > > > -
>> > > > - /* Check if flash MAC is valid */
>> > > > - fp = (unsigned char *) 0x0201c000;
>> > > > - for (i = 0; (i < 6); i++) {
>> > > > - if ((fp[i] != 0) && (fp[i] != 0xff))
>> > > > - break;
>> > > > - }
>> > > > -
>> > > > - /* If we found a valid looking MAC address then use it
>> > > > */
>> > > > - if (i < 6)
>> > > > - memcpy(ð_mac[0], fp, 6);
>> > > > + /* Set MAC address */
>> > > > + ks8695_write(KS8695_LAN_MAC_LOW, (dev->enetaddr[5] |
>> > > > (dev->enetaddr[4] << 8) |
>> > > > + (dev->enetaddr[3] << 16) | (dev->enetaddr[2] <<
>> > > > 24)));
>> > > > + ks8695_write(KS8695_LAN_MAC_HIGH, (dev->enetaddr[1] |
>> > > > (dev->enetaddr[0] << 8)));
>> > > > + return 0;
>> > > > }
>> > > >
>> > > >
>> > > > //
>> > > > @@ -109,12 +92,8 @@ static int ks8695_eth_init(struct eth_device
>> > > > *dev, bd_t *bd) ks8695_write(KS8695_LAN_DMA_TX, 0x8000);
>> > > > ks8695_write(KS8695_LAN_DMA_RX, 0x8000);
>> > > >
>> > > > - ks8695_getmac();
>> > > > -
>> > > > /* Set MAC address */
>> > > > - ks8695_write(KS8695_LAN_MAC_LOW, (eth_mac[5] |
>> > > > (eth_mac[4] << 8) |
>> > > > - (eth_mac[3] << 16) | (eth_mac[2] << 24)));
>> > > > - ks8695_write(KS8695_LAN_MAC_HIGH, (eth_mac[1] |
>> > > > (eth_mac[0] << 8)));
>> > > > + ks8695_set_mac_address(dev);
>> > >
>> > > Why do you set the MAC address here? It should be set for you by
>> > > the network infrastructure without this call.
>> >
>> > Simply because I was not aware of this at the time. Before the
>> > changes here the generic infrastructure could not do it, as
>> > write_hwaddr was unimplemented, and I was just trying to preserve
>> > function. The main reason I started poking at the network driver
>> > was that it loaded the MAC from a hardcoded address in ROM,
>> > obviously board specific (this is the magic number in [PATCH 11/11]
>> > arm: cm4008, cm41xx: read MAC address from flash). It also has a
>> > bug where it stops working after one command (i.e. can't tftp
>> > twice), which I have not tracked down as yet.
>> >
>> > > > /* Turn the 4 port switch on */
>> > > > i = ks8695_read(KS8695_SWITCH_CTRL0);
>> > > > @@ -150,7 +129,7 @@ static int ks8695_eth_init(struct eth_device
>> > > > *dev, bd_t *bd) ks8695_write(KS8695_LAN_DMA_RX, 0x71);
>> > > > ks8695_write(KS8695_LAN_DMA_RX_START, 0x1);
>> > > >
>> > > > - printf("KS8695 ETHERNET: %pM\n", eth_mac);
>> > > > + printf("KS8695 ETHERNET: %pM\n", dev->enetaddr);
>> > > > return 0;
>> > > > }
>> > > >
>> > > > @@ -234,6 +213,7 @@ int ks8695_eth_initialize(void)
>> > > > dev->halt = ks8695_eth_halt;
>> > > > dev->send = ks8695_eth_send;
>> > > > dev->recv = ks8695_eth_recv;
>> > > > + dev->write_hwaddr = ks8695_set_mac_address;
>> > > > strcpy(dev->name, "ks8695eth");
>> > > >
>> > > > eth_register(dev);
>> > > > --
>> > > > 1.7.10.4
>> > >
>> > > -Joe
>>
>> What is the status for this patch? Are you going to drop it or submit
>> a new version?
>>
>> Amicalement,
>
> After some testing, I can conclude that removing the call to
> set_mac_address actually breaks this code. This is bec
Re: [U-Boot] [PATCH v2 10/23] Add generic hash API
Hi Simon,
On Thu, Nov 22, 2012 at 1:12 PM, Simon Glass wrote:
> We have a SHA1 command and want to add a SHA256 command also. Instead of
> duplicating the code, create a generic hash API which can process
> commands for different algorithms.
>
> Signed-off-by: Simon Glass
> ---
> Changes in v2:
> - Add generic hash API to allow SHA256 command to be added without duplication
>
> common/Makefile |1 +
> common/hash.c | 221
> +++
> include/hash.h | 69 +
> 3 files changed, 291 insertions(+), 0 deletions(-)
> create mode 100644 common/hash.c
> create mode 100644 include/hash.h
>
> diff --git a/common/Makefile b/common/Makefile
> index 84968f8..eb175c1 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -31,6 +31,7 @@ COBJS-y += main.o
> COBJS-y += command.o
> COBJS-y += exports.o
> COBJS-$(CONFIG_SYS_HUSH_PARSER) += hush.o
> +COBJS-y += hash.o
Why not put them in alphabetical order?
> COBJS-y += s_record.o
> COBJS-y += xyzModem.o
> COBJS-y += cmd_disk.o
> diff --git a/common/hash.c b/common/hash.c
> new file mode 100644
> index 000..9a844b8
> --- /dev/null
> +++ b/common/hash.c
> @@ -0,0 +1,221 @@
> +/*
> + * Copyright (c) 2012 The Chromium OS Authors.
> + *
> + * (C) Copyright 2011
> + * Joe Hershberger, National Instruments, joe.hershber...@ni.com
> + *
> + * (C) Copyright 2000
> + * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> + *
> + * 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
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * These are the hash algorithms we support. Chips which support accelerated
> + * crypto could perhaps add named version of these algorithms here.
> + */
> +static struct hash_algo hash_algo[] = {
> +#ifdef CONFIG_SHA1
> + {
> + "SHA1",
> + SHA1_SUM_LEN,
> + sha1_csum_wd,
> + CHUNKSZ_SHA1,
> + },
> +#endif
> +#ifdef CONFIG_SHA256
> + {
> + "SHA256",
> + SHA256_SUM_LEN,
> + sha256_csum_wd,
> + CHUNKSZ_SHA256,
> + },
> +#endif
> +};
> +
> +/**
> + * store_result: Store the resulting sum to an address or variable
> + *
> + * @algo: Hash algorithm being used
> + * @sum: Hash digest (algo->digest_size bytes)
> + * @dest: Destination, interpreted as a hex address if it starts
> + * with * or otherwise as an environment variable.
> + */
> +static void store_result(struct hash_algo *algo, const u8 *sum,
> +const char *dest)
> +{
> + unsigned int i;
> +
> + if (*dest == '*') {
> + u8 *ptr;
> +
> + ptr = (u8 *)simple_strtoul(dest + 1, NULL, 16);
> + memcpy(ptr, sum, algo->digest_size);
> + } else {
> + char str_output[HASH_MAX_DIGEST_SIZE * 2 + 1];
> + char *str_ptr = str_output;
> +
> + for (i = 0; i < algo->digest_size; i++) {
> + sprintf(str_ptr, "%02x", sum[i]);
> + str_ptr += 2;
> + }
> + str_ptr = '\0';
> + setenv(dest, str_output);
> + }
> +}
> +
> +/**
> + * parse_verify_sum: Parse a hash verification parameter
> + *
> + * @algo: Hash algorithm being used
> + * @verify_str:Argument to parse. If it starts with * then
> it is
> + * interpreted as a hex address containing the hash.
> + * If the length is exactly the right number of hex
> digits
> + * for the digest size, then we assume it is a hex
> digest.
> + * Otherwise we assume it is an environment variable, and
> + * look up its value (it must contain a hex digest).
> + * @vsum: Returns binary digest value (algo->digest_size bytes)
> + * @return 0 if ok, non-zero on error
> + */
> +static int parse_verify_sum(struct hash_algo *algo, char *verify_str, u8
> *vsum)
> +{
> + if (*verify_str == '*') {
> + u8 *ptr;
> +
> + ptr = (u8 *)simple_strtoul(verify_str + 1, NULL, 16);
> + memcpy(vsum,
Re: [U-Boot] [PATCH v2 12/23] Add hash command to perform hashing using various algorithms
Hi Simon,
On Thu, Nov 22, 2012 at 1:12 PM, Simon Glass wrote:
> This new command supports hashing SHA1 and SHA256. It could be extended
> to others such as MD5 and the CRC algorithms. The syntax is modeled on
> those:
>
>hash[* | ]
>
> to calculate a hash, and:
>
>hash -v[* | ]
>
> to verify a hash.
>
> Use CONFIG_CMD_HASH to enable the command, CONFIG_SHA1 to enable SHA1 and
> CONFIG_SHA256 to enable SHA256.
>
> The existing sha1sum command remains.
>
> Signed-off-by: Simon Glass
> ---
> Changes in v2:
> - Add new hash command to support generic hash API
>
> README | 18 +
> common/Makefile |1 +
> common/cmd_hash.c| 63
> ++
> include/config_cmd_all.h |1 +
> 4 files changed, 83 insertions(+), 0 deletions(-)
> create mode 100644 common/cmd_hash.c
>
> diff --git a/README b/README
> index 6378101..2a0098d 100644
> --- a/README
> +++ b/README
> @@ -822,6 +822,7 @@ The following options need to be configured:
> CONFIG_CMD_GETTIME * Get time since boot
> CONFIG_CMD_GO * the 'go' command (exec code)
> CONFIG_CMD_GREPENV * search environment
> + CONFIG_CMD_HASH * calculate hash / digest
> CONFIG_CMD_HWFLOW * RTS/CTS hw flow control
> CONFIG_CMD_I2C * I2C serial bus support
> CONFIG_CMD_IDE * IDE harddisk support
> @@ -2391,6 +2392,23 @@ CBFS (Coreboot Filesystem) support
> A better solution is to properly configure the firewall,
> but sometimes that is not allowed.
>
> +- Hashing support:
> + CONFIG_CMD_HASH
> +
> + This enables a generic 'hash' command which can produce
> + hashes / digests from a few algorithms (e.g. SHA1, SHA256).
> +
> + CONFIG_HASH_VERIFY
> +
> + Enable the hash verify command (hash -v). This adds to code
> + size a little.
> +
> + CONFIG_SHA1 - support SHA1 hashing
> + CONFIG_SHA256 - support SHA256 hashing
> +
> + Note: There is also a sha1sum command, which should perhaps
> + be deprecated in favour of 'hash sha1'.
> +
> - Show boot progress:
> CONFIG_SHOW_BOOT_PROGRESS
>
> diff --git a/common/Makefile b/common/Makefile
> index eb175c1..56ec4e4 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -104,6 +104,7 @@ COBJS-$(CONFIG_CMD_FS_GENERIC) += cmd_fs.o
> COBJS-$(CONFIG_CMD_GETTIME) += cmd_gettime.o
> COBJS-$(CONFIG_CMD_GPIO) += cmd_gpio.o
> COBJS-$(CONFIG_CMD_I2C) += cmd_i2c.o
> +COBJS-$(CONFIG_CMD_HASH) += cmd_hash.o
> COBJS-$(CONFIG_CMD_IDE) += cmd_ide.o
> COBJS-$(CONFIG_CMD_IMMAP) += cmd_immap.o
> COBJS-$(CONFIG_CMD_INI) += cmd_ini.o
> diff --git a/common/cmd_hash.c b/common/cmd_hash.c
> new file mode 100644
> index 000..10ce03e
> --- /dev/null
> +++ b/common/cmd_hash.c
> @@ -0,0 +1,63 @@
> +/*
> + * Copyright (c) 2012 The Chromium OS Authors.
> + *
> + * (C) Copyright 2011
> + * Joe Hershberger, National Instruments, joe.hershber...@ni.com
> + *
> + * (C) Copyright 2000
> + * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> + *
> + * 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
> +#include
> +#include
> +
> +static int do_hash(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> +{
> +#ifdef CONFIG_HASH_VERIFY
> + int verify = 0;
> +
> + if (!strcmp(argv[1], "-v")) {
> + verify = 1;
> + argc--;
> + argv++;
> + }
> +#endif
> + /* Move forward to 'algorithm' parameter */
> + argc--;
> + argv++;
> + return hash_command(*argv, verify, cmdtp, flag, argc - 1, argv + 1);
> +}
> +
> +#ifdef CONFIG_HASH_VERIFY
> +U_BOOT_CMD(
> + hash, 6, 1, do_hash,
> + "compute hash message digest",
> + "algorithm address count [[*]sum_dest]\n"
> + "- compute message digest [save to env var / *address]\n"
> + "sha1sum -v algorithm address count [*]sum\n"
The command is now hash, not sha1sum.
> + "- verify sha1sum of memory area with
Re: [U-Boot] Please pull u-boot-x86.git
Hi Tom, On Sat, Dec 1, 2012 at 10:32 AM, Tom Rini wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 12/01/12 09:38, Simon Glass wrote: >> The following changes since commit >> b8715d8def240014da5614a4f940130ec06d9ebf: >> >> Merge branch 'master' of git://git.denx.de/u-boot-fdt (2012-11-29 >> 06:41:56 -0700) >> >> are available in the git repository at: >> >> git://git.denx.de/u-boot-x86.git master >> >> Gabe Black (6): x86: Allow compiling out realmode/bios code x86: >> Add an fdt pointer to the global data structure x86: Add a minimal >> device tree for alex x86 x86: Add a default implementation for >> cleanup_before_linux() x86: Add a dummy implementation for >> timer_get_us x86: Include types.h explicitly in the i386 version of >> io.h >> >> Simon Glass (4): x86: coreboot: Decode additional coreboot sysinfo >> tags x86: Select stdio devices for coreboot x86: Remove coreboot >> start16 code x86: Define CONFIG_SYS_VSNPRINTF for coreboot >> >> Stefan Reinauer (4): x86: coreboot: Drop sysinfo.c x86: video: Add >> coreboot framebuffer support x86: Fix typo in pcat_timer.c x86: >> Don't spam POST80 codes with slow IO functions >> >> Vadim Bendebury (2): x86: Add CBMEM console driver for coreboot >> x86: Add console command to display CBMEM console buffer > > I know there's outstanding x86 work, but was all of this in some > series that was posted before the merge window closed? Thanks! This set of patches was posted between 13th and 20th October. I actually have more patches in my todo list on patchwork (mostly newer ones to 3 November, but a few very old like 4 of those in the first pull request this week). I took over as maintainer right near the end of the merge window and sorted out repo access 10 days ago, so I am definitely playing catch up. All going well I should work through the rest next week. While talking about patches I see that the patman patches are assigned to me. I will of course review them, but what should I do after that, as they are not x86? Also they are outside the merge window for this release, but will you accept 'next' pull requests at some point? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/18] Add environment call-back and flags capability
Hi Wolfgang,
On Fri, Nov 2, 2012 at 5:40 PM, Wolfgang Denk wrote:
> Dear Joe Hershberger,
>
> In message <1351787996-24560-1-git-send-email-joe.hershber...@ni.com> you
> wrote:
>>
>> When a variable with a registered callback is inserted, deleted, or
>> overwritten the callback is called and gives the system an opportunity
>> to do something in response to the change. It also has the opportunuty
>> to reject the change by returning non-zero.
>
> I applied the patch series against current top of tree and tested on a
> PPC board ("sequoia"). It hangs without printing any message.
I am seeing a hang on my ARM boards that are using NAND flash for the
env. The hang seems to be env contents dependent. I'm still
investigating, but it could be related to the issue you're seeing.
For me it hangs (sometimes, depending on env) after mmc init and
before console init traces anything.
> Guess I need to attach a BDI ...
Did you get around to looking at it with the debugger?
Thanks,
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] arm: Question regarding empty isb() in set_cr
Hello,
I have noticed an issue in ARM code base, described below. If appropriate,
I would be glad to submit a patch. But some discussion seems appropriate
first. Quite likely there is some explanation for the existing code.
#define isb() __asm__ __volatile__ ("" : : : "memory")
is in arch/arm/include/asm/system.h. In my build, that is going into
set_cr(), producing no instruction. It has been in code since
http://lists.denx.de/pipermail/u-boot/2009-March/049870.html
Is it correct for isb() to be no-operation here?
It looks like isb() is used only in set_cr. Other points in the code have
nonempty code for ISB, for example
#define CP15ISBasm volatile ("mcr p15, 0, %0, c7, c5, 4" : : "r"
(0))
which is in armv7.h
I don't have a standard reference platform to experiment with. The platform
that I do have uses a Cortex-A9 core, u-boot.2012.07 is ported and running.
There are some intermittent issues there relating to enabling MMU/cache,
lack of instruction barriers would be a plausible explanation. Adding
CP15ISB (or equivalently ISB SY) into set_cr doesn't fix my issues, but it
looks like a step in right direction.
If someone could explain, or point me to email, I would appreciate it.
Thanks in advance, Joe Kulikauskas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/15] x86: Add function to read time stamp counter
Hi Graeme,
On Tue, Oct 23, 2012 at 9:24 PM, Graeme Russ wrote:
> Hi Simon,
>
> On Wed, Oct 24, 2012 at 3:04 PM, Simon Glass wrote:
>> From: Vadim Bendebury
>>
>> Put this function in the u-boot-x86.h header file. We could instead create
>> timer.h perhaps.
>>
>> We support setting a base time, and reading the time relative to this base.
>>
>> Signed-off-by: Vadim Bendebury
>> Signed-off-by: Stefan Reinauer
>> Signed-off-by: Simon Glass
>> ---
>> arch/x86/include/asm/u-boot-x86.h | 12
>> arch/x86/lib/timer.c | 17 +
>> 2 files changed, 29 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/u-boot-x86.h
>> b/arch/x86/include/asm/u-boot-x86.h
>> index a4a5ae0..11be5c3 100644
>> --- a/arch/x86/include/asm/u-boot-x86.h
>> +++ b/arch/x86/include/asm/u-boot-x86.h
>> @@ -68,4 +68,16 @@ int video_init(void);
>> void board_init_f_r_trampoline(ulong) __attribute__ ((noreturn));
>> void board_init_f_r(void) __attribute__ ((noreturn));
>>
>> +/* Read the time stamp counter */
>> +static inline uint64_t rdtsc(void)
>> +{
>> + uint32_t high, low;
>> + __asm__ __volatile__("rdtsc" : "=a" (low), "=d" (high));
>> + return (((uint64_t)high) << 32) | low;
>> +}
>
> What CPUs support the rdtsc opcode? I know the AMD SC520 does not
> (it's a 486 core). Wikipedia tells me the Pentium CPU was the first to
> implement it. The Pentium was released in March 1993, so rdtsc is
> nearly 20 years now. But not all non-Intel CPUs are guaranteed to
> support it. Oh, and for CPUs that change speed, the internal clock
> read by rdtsc may not be constant.
>
> I'm happy to draw a line in the sand and say 'x86 CPUs before
> xx/xx/xxx are not supported' - If someone comes along later wanting to
> add support, we can mess with the plumbing then (the likelyhood is
> practically zero, so I'm not too concerned about how hard that will
> be). Given that, perhaps we should look at HPET instead? I have a
> patch I worked on 6 month ago (attached below) if you feel like using
> it
OK - well it seems that HPET is *very* new in comparison. Even so, it
seems to me that it should be safe to move to this since we are
probably not that interested in old hardware, but perhaps we should do
this in the next release to give us a chance to test, etc.?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] WIP: Test version of buildman - U-Boot builder
Hi, On Thu, Nov 1, 2012 at 4:29 PM, Tom Rini wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/01/12 14:01, Simon Glass wrote: >> Hi Andy / Tom, >> >> On Wed, Oct 31, 2012 at 9:17 PM, Andy Fleming >> wrote: >>> On Wed, Oct 31, 2012 at 8:18 PM, Tom Rini wrote: On Wed, Oct 31, 2012 at 05:11:51PM -0700, Simon Glass wrote: [snip] > Also rather than running with 'make -j40' or whatever, it > uses 'make -j1' but with 40 threads. This increases CPU > utilisation quite substantially (almost 50%) - I think this > was discussed some time ago, MAKEALL supports this, but doesn't default to it, today. I'm wondering if we ought to make it the default for all non-single board builds. The winning point is right around boards-to-build == `grep -c processor /proc/cpuinfo` and I think is right around setting NBUILDS to that value, both on consumer multicore and heavy-duty 32/64 core boxes. >>> >>> Yeah, I usually set BUILD_NBUILDS to 24-50 on my 24-thread >>> system, and then set BUILD_NCPUS to 1-4. It's nice to offer a >>> little bit of parallelism on the individual builds, sometimes. I >>> did a bunch of tests, but not in a scientific fashion. Enough to >>> agree with you that maxing out builds seems to win for u-boot. >> >> As a bit of an unscientific test, what sort of time does it take >> to build all 1000-or-so boards on your systems? > > My setup using MAKEALL does 921 boards (arm/powerpc/mips) with ELDK > 5.2 in 54min wall-clock with 397% CPU util (on a 6 core machine). buildman is best at building a series of commits at once. I suspect with just one commit its performance would be similar to MAKEALL. I use it to verify a series so that I know it will bisect correctly. Has anyone given it a try? I have found one bug where it gets confused when a builder thread moved from one architecture to another. Apart from that I am thinking of cleaning up the series and submitting some proper patches. Any comments? Regards, Simon > > - -- > Tom > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJQkwXKAAoJENk4IS6UOR1Ws+oP/A2Estr8LHk2zt3cclDrshwI > 9iNpiMvwJ2a/Qj3DzK6q3tuLKIJq/Chfsgczrz3wlv6RGqN5SB8U/Cbl9/OAg9oC > jmSEjpGxT3pJyRKscyf/78cjMb06BadHVybPjkMtmfdlay3+H4CLLFkVahM1BKut > +7MxTFtQIkPkHtXUwcTSYXuIhwwz61d6R65colHoHWVIbtRWpksaWa64107mEg3K > 0A4Ite+FYoMK0BeswA1mPGknDCCLfgE32oXI4k4tQBAXrLcYWKlxLcirGydiZ46l > Mrqh+62EA4U2FEVj3VbRjB2JtqRiqtbYYNSk9fwkdU0Fa/eYZacYYxStZVnVTfaQ > RgZd0Gq7knJUed8bS0RvptDKLnMCadc0CgVEQ6Svj2JgfeZ9l/HOJkUX/MI7bCmv > eKrtQQium4cJfXx2fGGdR2O21g+oQML/V0UTHkq78qMr3Z9Bqj3wRRyVGc5ch7kb > 3P8aYjlJG8qU6OtDiwvRNIMvAQzovetJu18L+F/X3lgxqsvrEjk1Ugdach0smmkl > TcM9U21la7oOAxhFg4J5W6aatdDx6kKU6s4K68kpcvpQ0MJjQ6bhjKASzf/VFuTl > 6vLXUiN+qHc/2yBmuxgMluRfAzFEsLWZ3Y6r3bQC4f3mfmUZxt7CJ8D+rYqSQKUW > TDHABRVdUDJxbypUaA8q > =VhSN > -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/15] x86: Add basic cache operations
Hi Graeme,
On Tue, Oct 23, 2012 at 9:44 PM, Graeme Russ wrote:
> Hi Simon,
>
> On Wed, Oct 24, 2012 at 3:04 PM, Simon Glass wrote:
>> From: Stefan Reinauer
>>
>> Add functions to enable/disable the data cache.
>>
>> Signed-off-by: Stefan Reinauer
>> Signed-off-by: Simon Glass
>> ---
>> arch/x86/cpu/interrupts.c|8 +--
>> arch/x86/include/asm/cache.h | 47
>> ++
>> 2 files changed, 48 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/x86/cpu/interrupts.c b/arch/x86/cpu/interrupts.c
>> index 43ec3f8..710b653 100644
>> --- a/arch/x86/cpu/interrupts.c
>> +++ b/arch/x86/cpu/interrupts.c
>> @@ -28,6 +28,7 @@
>> */
>>
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -50,13 +51,6 @@
>> */
>> static unsigned long __force_order;
>>
>> -static inline unsigned long read_cr0(void)
>> -{
>> - unsigned long val;
>> - asm volatile("mov %%cr0,%0\n\t" : "=r" (val), "=m" (__force_order));
>> - return val;
>> -}
>> -
>
> Happy to move read_cr0 out of interrupts.c
>
>> static inline unsigned long read_cr2(void)
>> {
>> unsigned long val;
>
> But please move them all...
>
>> diff --git a/arch/x86/include/asm/cache.h b/arch/x86/include/asm/cache.h
>> index 87c9e0b..9836856 100644
>> --- a/arch/x86/include/asm/cache.h
>> +++ b/arch/x86/include/asm/cache.h
>> @@ -32,4 +32,51 @@
>> #define ARCH_DMA_MINALIGN 64
>> #endif
>>
>> +/* The memory clobber prevents the GCC from reordering the read/write order
>> + * of CR0
>> + */
>> +static inline unsigned long read_cr0(void)
>> +{
>> + unsigned long cr0;
>> +
>> + asm volatile ("movl %%cr0, %0" : "=r" (cr0) : : "memory");
>> + return cr0;
>> +}
>> +
>> +static inline void write_cr0(unsigned long cr0)
>> +{
>> + asm volatile ("movl %0, %%cr0" : : "r" (cr0) : "memory");
>> +}
>
> ...to another header (control_registers.h)
Will do, that makes sense. I will move the debug registers also.
>
>> +
>> +static inline void wbinvd(void)
>> +{
>> + asm volatile ("wbinvd" : : : "memory");
>> +}
>> +
>> +static inline void invd(void)
>> +{
>> + asm volatile("invd" : : : "memory");
>> +}
>> +
>> +static inline void enable_cache(void)
>> +{
>> + unsigned long cr0;
>> +
>> + cr0 = read_cr0();
>> + cr0 &= 0x9fff;
>> + write_cr0(cr0);
>> +}
>> +
>> +static inline void disable_cache(void)
>> +{
>> + /* Disable and write back the cache */
>> + unsigned long cr0;
>> +
>> + cr0 = read_cr0();
>> + cr0 |= 0x4000;
>> + wbinvd();
>> + write_cr0(cr0);
>> + wbinvd();
>> +}
>
> These already exist in cpu.c as weak functions (some systems need to
> do funky things when fiddling with caching, like updating MMTRs) with
> pure inline assembly. Please fix up those implementations to use the
> proper cr0 accessors
OK, I will send a new patch for this.
>
>> +
>> #endif /* __X86_CACHE_H__ */
>> --
>> 1.7.7.3
>>
>
> Regards,
>
> Graeme
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot for MIPS AR7161
Hello again Here I tried to create the bootloader. http://dioptimizer.narod.ru/files/ap96/u-boot.bin http://dioptimizer.narod.ru/files/ap96/u-boot.md5 For tftp: 192.168.1.1 -router ip 192.168.1.2 -must be your ethernet ip It must be loaded into memory at address: 0xa001 Then in OpenOCD (telnet) put: resume 0xa001 By the way you can check the boot on the work device, it's faster: tftpboot 0xa001 u-boot.bin go 0xa001 2012/12/1, Drassal, Allan : > I think I made a little more progress... > Using the following commands I can get output from the UART... > # set GPIO 9 & 10 as UART > mww 0xb804 0x400 > mww 0xb8040028 0x100 > > mww 0xb8020004 0x0 > mww 0xb802000c 0x83 > mww 0xb802 0x51 > mww 0xb8020004 0x0 > mww 0xb802000c 0x3 > mww 0xb8020008 0xc1 > > mww 0xb802 0x54 > mww 0xb802 0x45 > mww 0xb802 0x53 > mww 0xb802 0x54 > mww 0xb802 0x0D > mww 0xb802 0x0A > > After executing the first two commands, then running the loader program I > can get UART output, but it is all garbled. > It is like I have not selected the correct BAUD, but I have tried all > speeds. > Possibly there is a mismatch in the internal clock calibration and the way > the loader is calculating UART speeds. > Is this the PLL configuration that I should be looking at? > > From: u-boot-boun...@lists.denx.de [u-boot-boun...@lists.denx.de] on behalf > of Drassal, Allan [dra...@wsu.edu] > Sent: Friday, November 30, 2012 20:14 > To: Dmytro > Cc: Luka Perkov; U-Boot Mailing List > Subject: Re: [U-Boot] U-Boot for MIPS AR7161 > > Hi Dmytro, > > Thanks for your detailed response. I corrected some details in the > ar71xx.cfg file and am posting them below this message. > With this, I am convinced that my JTAG interface is working and the DRAM > controller is getting setup correctly. > Now, I am just needing some code to load into the processor. > I would like to port U-Boot over to this platform, but it is a little above > my experience level at the moment. > Perhaps it has already been done and I am not looking in the right place. > This platform is technically based on AP96 I believe though. > > I connected up the two devices today and did these checks, these are the > results... > However, the response from the two devices is slightly different... > You can see the results below... > > I needed to do a "reset init" before the file would load successfully... > I assume the DRAM controller is initialized at this point and not if I just > open up openOCD. > if I just did a straight "halt" without a "reset init", then the PC is > different > > On the non-functioning device I am assuming it begins to execute code at > 0xbfc00380, but runs into something it can't execute and either loops or > freezes there. > >> reset > JTAG tap: ar71xx.cpu tap/device found: 0x0001 (mfg: 0x000, part: 0x, > ver: 0x0) >> halt > target state: halted > target halted in MIPS32 mode due to debug-request, pc: 0xbfc00380 > > > results from broken device >> halt > target state: halted > target halted in MIPS32 mode due to debug-request, pc: 0xbfc00380 >> mdw 0xb800 0x10 > 0xb800: 77bc8cd0 81d106a8 0133 0002 2000 00ff > 0081 > 0xb820: 0081 0081 0081 > >> mdw 0xb805 > 0xb805: 001040a3 >> mdw 0xb8050008 > 0xb8050008: >> mdw 0xb805000c > 0xb805000c: > > results from working device > ar7100> md 0xb800 0x10 > b800: 77b8884e 812cd6a8 0033 w..N.,.3 > b810: 44a6 00ff 0007..D. > b820: 0007 0007 0007 > b830: > ar7100> md 0xb805 0x1 > b805: c0140180 > ar7100> md 0xb8050008 0x1 > b8050008: > ar7100> md 0xb805000c 0x1 > b805000c: > ar7100> > > results of loading a file and checking the read memory is the same >> reset init > JTAG tap: ar71xx.cpu tap/device found: 0x0001 (mfg: 0x000, part: 0x, > ver: 0x0) > target state: halted > target halted in MIPS32 mode due to debug-request, pc: 0xbfc0 >> load_image mtd0.bin 0xa001 > 327680 bytes written at address 0xa001 > downloaded 327680 bytes in 3.917356s (81.688 KiB/s) >> mdw 0xa001 0x10 > 0xa001: 10ff 10fd 1dbb 1db9 > > 0xa0010020: 1db7 1db5 1db3 1db1 > >> mdw 0xa001 0x10 > 0xa001: 10ff 10fd 1dbb 1db9 > > 0xa0010020: 1db7 1db5 1db3 1db1 > >> mdw 0xa001 0x10 > 0xa001: 10ff 10fd 1dbb 1db9 > > 0xa0010020: 1db7 1db5 1db3 1db1 > > > >
Re: [U-Boot] [PATCH] cm-t35: add USB host support
Hi Marek Vasut, On 11/29/2012 12:36 AM, Marek Vasut wrote: Dear Nikita Kiryanov, [...] + twl4030_i2c_read_u8(TWL4030_CHIP_GPIO, &val, + TWL4030_BASEADD_GPIO + 0x03); + val |= 0xC0; What are these magic values here please? val |= 0xC0 is simply setting bits 7 and 6 to 1. As for TWL4030_BASEADD_GPIO + 0x03/0x0C, I'll address them in a V2. + /* Set GPIO6 and GPIO7 of TPS65930 as output */ + twl4030_i2c_write_u8(TWL4030_CHIP_GPIO, val, + TWL4030_BASEADD_GPIO + 0x03); + /* Take both PHYs out of reset */ + twl4030_i2c_write_u8(TWL4030_CHIP_GPIO, 0xC0, + TWL4030_BASEADD_GPIO + 0x0C); + udelay(1); + + return omap_ehci_hcd_init(&usbhs_bdata); [...] Best regards, Marek Vasut -- Regards, Nikita. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cm-t35: add USB host support
Dear Nikita Kiryanov, > Hi Marek Vasut, > > On 11/29/2012 12:36 AM, Marek Vasut wrote: > > Dear Nikita Kiryanov, > > > > [...] > > > >> + twl4030_i2c_read_u8(TWL4030_CHIP_GPIO, &val, > >> + TWL4030_BASEADD_GPIO + 0x03); > >> + val |= 0xC0; > > > > What are these magic values here please? > > val |= 0xC0 is simply setting bits 7 and 6 to 1. > > As for TWL4030_BASEADD_GPIO + 0x03/0x0C, I'll address them in a V2. [...] Please do, thank you! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
