Re: [U-Boot] U-Boot panasonic repo
Hi. I am trying to push to the newly-created u-boot-uniphier repo but I am in trouble. masahiro@oscar:~/workspace/u-boot-uniphier$ git push ssh://gu-uniph...@git.denx.de/u-boot-uniphier.git X11 forwarding request failed on channel 0 Total 0 (delta 0), reused 0 (delta 0) remote: error: refusing to update checked out branch: refs/heads/master remote: error: By default, updating the current branch in a non-bare repository remote: error: is denied, because it will make the index and work tree inconsistent remote: error: with what you pushed, and will require 'git reset --hard' to match remote: error: the work tree to HEAD. remote: error: remote: error: You can set 'receive.denyCurrentBranch' configuration variable to remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into remote: error: its current branch; however, this is not recommended unless you remote: error: arranged to update its work tree to match what you pushed in some remote: error: other way. remote: error: remote: error: To squelch this message and still keep the default behaviour, set remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'. To ssh://gu-uniph...@git.denx.de/u-boot-uniphier.git ! [remote rejected] master - master (branch is currently checked out) error: failed to push some refs to 'ssh://gu-uniph...@git.denx.de/u-boot-uniphier.git' According to this error message, it looks like the u-boot-uniphier on the denx server has been created as a non-bare repository, right? The message also recommended to do git config receive.denyCurrentBranch ignore on the remote repo, but I seems impossible for me to do that. Someone, give me a tip if I am missing something. Perhaps, the repo should be re-created as a bare one? Or could you add receive.denyCurrentBranch ignore configuration, Wolfgang? -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx
On Thu, Sep 25, 2014 at 09:27:52AM -0700, York Sun wrote: Tom, The following changes since commit 47d3debe1ab8315dc9ade22279e02f60eceda25b: Merge git://git.denx.de/u-boot-dm (2014-09-23 15:21:43 -0400) are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master for you to fetch changes up to 039b77396abb0ed78af34dadbd0786dfaf0e6aa9: powerpc: add --bss-plt to LDFLAGS (2014-09-25 09:22:37 -0700) Chris Packham (1): powerpc: add --bss-plt to LDFLAGS Ebony Zhu (1): powerpc/mpc85xx: Serdes protocol 00 is supported Priyanka Jain (2): powerpc/t104xrdb: Set DDR ODT to 75ohm board/t1040qds: Add sgmii ports support in 0xA7 protocol Shaveta Leekha (2): powerpc/b4860: Updated default hwconfig to enable only cpc2 B4860QDS: Enable mac command support ramneek mehresh (1): powerpc/8xxx: Fix in USB device-tree fixup vijay rai (2): powerpc/t104xrdb: Add Support of rcw for T1042RDB in u-boot powerpc/t104xrdb: Add T1042RDB board support arch/powerpc/config.mk |1 + arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c |5 - arch/powerpc/cpu/mpc8xxx/fdt.c | 20 +--- board/freescale/t1040qds/eth.c |4 board/freescale/t104xrdb/MAINTAINERS |1 + board/freescale/t104xrdb/README| 23 ++- board/freescale/t104xrdb/ddr.c |4 ++-- board/freescale/t104xrdb/eth.c | 10 ++ board/freescale/t104xrdb/t1042_pi_rcw.cfg |7 +++ board/freescale/t104xrdb/t1042_rcw.cfg |8 configs/T1042RDB_defconfig |4 drivers/net/fm/t1040.c |2 -- include/configs/B4860QDS.h | 12 ++-- include/configs/T104xRDB.h | 20 14 files changed, 82 insertions(+), 39 deletions(-) create mode 100644 board/freescale/t104xrdb/t1042_pi_rcw.cfg create mode 100644 configs/T1042RDB_defconfig 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] Please pull u-boot-fsl-qoriq
On Thu, Sep 25, 2014 at 01:57:16PM -0700, York Sun wrote: Tom, The following changes since commit 47d3debe1ab8315dc9ade22279e02f60eceda25b: Merge git://git.denx.de/u-boot-dm (2014-09-23 15:21:43 -0400) are available in the git repository at: u-boot git://git.denx.de/u-boot-fsl-qoriq.git master for you to fetch changes up to c7eae7fcb11bc7dab519fca8d8902f1fbc5c3c76: board/ls1021aqds: Add DDR4 support (2014-09-25 09:12:12 -0700) Arnab Basu (2): fdt_support: Move of_read_number to fdt_support.h fdt_support: Make of_bus_default_count_cells non static Prabhakar Kushwaha (3): board/ls2085a: Update env_addr after NOR flash relocation driver/mtd: Use generic timer API for FSL IFC, eLBC board/ls2085a: Add support of NOR and NAND flash for simulator York Sun (8): driver/ddr: Restruct driver to allow standalone memory space ARMv8/ls2085a_emu: Enable DP-DDR as standalone memory block driver/ddr/fsl: Fix tXP and tCKE armv8/fsl-lsch3: Release secondary cores from boot hold off with Boot Page ARMv8/ls2085a: Enable secondary cores ARMv8/ls2085a: Move u-boot location to make room for RCW driver/ddr/fsl: Fix DDR4 driver board/ls1021aqds: Add DDR4 support README|6 + arch/arm/cpu/armv8/fsl-lsch3/Makefile |2 + arch/arm/cpu/armv8/fsl-lsch3/cpu.c| 13 ++ arch/arm/cpu/armv8/fsl-lsch3/cpu.h|1 + arch/arm/cpu/armv8/fsl-lsch3/fdt.c| 58 + arch/arm/cpu/armv8/fsl-lsch3/lowlevel.S | 125 +-- arch/arm/cpu/armv8/fsl-lsch3/mp.c | 168 ++ arch/arm/cpu/armv8/fsl-lsch3/mp.h | 36 +++ arch/arm/cpu/armv8/transition.S | 63 +- arch/arm/include/asm/arch-fsl-lsch3/config.h |6 +- arch/arm/include/asm/arch-fsl-lsch3/immap_lsch3.h | 35 +++ arch/arm/include/asm/arch-ls102xa/config.h|5 + arch/arm/include/asm/macro.h | 93 arch/arm/lib/gic_64.S | 10 +- arch/powerpc/cpu/mpc85xx/cpu.c|4 +- board/freescale/ls1021aqds/MAINTAINERS|1 + board/freescale/ls1021aqds/ddr.c |9 +- board/freescale/ls1021aqds/ddr.h | 10 + board/freescale/ls2085a/ddr.c | 34 ++- board/freescale/ls2085a/ddr.h | 29 +++ board/freescale/ls2085a/ls2085a.c | 21 +- common/fdt_support.c | 11 +- configs/ls1021aqds_ddr4_nor_defconfig |3 + drivers/ddr/fsl/ctrl_regs.c | 37 +++- drivers/ddr/fsl/ddr4_dimm_params.c| 12 +- drivers/ddr/fsl/fsl_ddr_gen4.c|3 +- drivers/ddr/fsl/interactive.c |2 - drivers/ddr/fsl/main.c| 244 ++--- drivers/ddr/fsl/options.c | 27 ++- drivers/ddr/fsl/util.c| 26 ++- drivers/mtd/nand/fsl_elbc_nand.c |8 +- drivers/mtd/nand/fsl_ifc_nand.c | 21 +- include/configs/ls1021aqds.h |4 +- include/configs/ls2085a_common.h | 87 +++- include/configs/ls2085a_emu.h |1 + include/configs/ls2085a_simu.h|9 + include/fdt_support.h | 12 + include/fsl_ddr.h | 15 +- include/fsl_ddr_sdram.h | 18 +- 39 files changed, 1018 insertions(+), 251 deletions(-) create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/fdt.c create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/mp.c create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/mp.h create mode 100644 configs/ls1021aqds_ddr4_nor_defconfig 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] Please pull u-boot-dm.git branch for-tom
On Fri, Sep 26, 2014 at 05:52:11PM -0600, Simon Glass wrote: Hi Tom, Here are the changes that were reviewed by Jagan (SPI maintainer). Branch is 'for-tom' as I had trouble with master (see below). The following changes since commit f9860cf081efdf32c8a01b9fc271fe55e2a79f8d: nand/denali: Document CONFIG symbols (2014-09-25 13:54:58 -0500) are available in the git repository at: git://git.denx.de/u-boot-dm.git for you to fetch changes up to 248a0488bfbb2eb16dee408a976d5f4b5546bb51: spi: Add brackets and tidy defines in spi.h (2014-09-26 15:01:15 -0600) Simon Glass (4): sandbox: Convert SPI flash emulation to use sf_params sandbox: config: Enable all SPI flash chips dm: spi: Move cmd device code into its own function spi: Add brackets and tidy defines in spi.h common/cmd_spi.c | 53 - drivers/mtd/spi/sandbox.c | 114 ++ include/configs/sandbox.h | 8 +++- include/spi.h | 24 4 files changed, 89 insertions(+), 110 deletions(-) Here's the error I got with master: git push dm HEAD:master Counting objects: 19, done. Delta compression using up to 32 threads. Compressing objects: 100% (19/19), done. Writing objects: 100% (19/19), 3.19 KiB | 0 bytes/s, done. Total 19 (delta 15), reused 0 (delta 0) remote: error: refusing to update checked out branch: refs/heads/master remote: error: By default, updating the current branch in a non-bare repository remote: error: is denied, because it will make the index and work tree inconsistent remote: error: with what you pushed, and will require 'git reset --hard' to match remote: error: the work tree to HEAD. remote: error: remote: error: You can set 'receive.denyCurrentBranch' configuration variable to remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into remote: error: its current branch; however, this is not recommended unless you remote: error: arranged to update its work tree to match what you pushed in some remote: error: other way. remote: error: remote: error: To squelch this message and still keep the default behaviour, set remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'. 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] tools: mkimage can read input on /dev/stdin
Dear Julien, In message CADF714agpUedt_o3iXcGBRBc5CaV6TBUn=1ogeqjj3h2b+f...@mail.gmail.com you wrote: I would like to give /dev/stdin to the flag -d of mkimage. The only What would be the benefit of doing so? Do you have an example for a practical use case where this makes sense? This patch replaces the use of mmap(2) with read(2). If accepted, I could give a look to accept /dev/stdout as output file (which is currently also required to be a file). What is the size and performance impact of the suggested change for typical use cases? 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 Q: Why do PCs have a reset button on the front? A: Because they are expected to run Microsoft operating systems. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot panasonic repo
Dear Masahiro, In message camhh57rx8vlz9fl6oxeyjmwwnsktg36dterenm0yvqclpru...@mail.gmail.com you wrote: I am trying to push to the newly-created u-boot-uniphier repo but I am in trouble. masahiro@oscar:~/workspace/u-boot-uniphier$ git push ssh://gu-uniph...@git.denx.de/u-boot-uniphier.git ... remote: error: By default, updating the current branch in a non-bare repository remote: error: is denied, because it will make the index and work tree inconsistent I recommend to always explicitly tell which branch you are trying to push where. For example, if your local branch which you are preparing for a pull request is for-upstream, then your push command would look like this: git push ssh://gu-uniph...@git.denx.de/u-boot-uniphier for-upstream:master 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 It is your destiny. - Darth Vader ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: mkimage can read input on /dev/stdin
On Sat, Sep 27, 2014 at 2:54 PM, Wolfgang Denk w...@denx.de wrote: What would be the benefit of doing so? Do you have an example for a practical use case where this makes sense? In my case, I have a TFTP server that dyncamically generates uboot bootfiles when a specific file is requested. The input template file being generated, I need to create a temporary file to store it before calling mkimage. Except the mmap, there's no technical restriction for mkimage to be able to read on a pipe. What is the size and performance impact of the suggested change for typical use cases? None. The behaviour is exactly the same. -- Julien Castets +33 (0)6.85.20.10.03 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tools: mkimage can read input on /dev/stdin
Hi,
I would like to give /dev/stdin to the flag -d of mkimage. The only
thing that prevent doing it is the function copy_file of mkimage.c,
which:
- calls stat(2) on the file to get the input file size
- calls mmap(2) with this size as length
When the file is a pipe, its size is set to 0 and mmap(2) fails.
This patch replaces the use of mmap(2) with read(2). If accepted, I
could give a look to accept /dev/stdout as output file (which is
currently also required to be a file).
From e107bdc73ee7b2159956cfc753328f9f03c058e8 Mon Sep 17 00:00:00 2001
From: Julien Castets castet...@gmail.com
Date: Fri, 26 Sep 2014 11:28:49 +0200
Subject: [PATCH] tools: mkimage can read input on /dev/stdin
Use a sequential read(2) instead of a mmap(2) in copy_file.
Signed-off-by: Julien Castets castet...@gmail.com
---
tools/mkimage.c | 64 +++
1 file changed, 31 insertions(+), 33 deletions(-)
diff --git a/tools/mkimage.c b/tools/mkimage.c
index c70408c..bb35110 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -522,14 +522,14 @@ static void
copy_file (int ifd, const char *datafile, int pad)
{
int dfd;
-struct stat sbuf;
-unsigned char *ptr;
int tail;
int zero = 0;
uint8_t zeros[4096];
-int offset = 0;
-int size;
struct image_type_params *tparams = mkimage_get_type (params.type);
+unsigned char buf[4096];
+ssize_t nbytes;
+ssize_t i;
+ssize_t size = 0;
if (pad = sizeof(zeros)) {
fprintf(stderr, %s: Can't pad to %d\n,
@@ -549,63 +549,62 @@ copy_file (int ifd, const char *datafile, int pad)
exit (EXIT_FAILURE);
}
-if (fstat(dfd, sbuf) 0) {
-fprintf (stderr, %s: Can't stat %s: %s\n,
-params.cmdname, datafile, strerror(errno));
-exit (EXIT_FAILURE);
-}
-
-ptr = mmap(0, sbuf.st_size, PROT_READ, MAP_SHARED, dfd, 0);
-if (ptr == MAP_FAILED) {
-fprintf (stderr, %s: Can't read %s: %s\n,
-params.cmdname, datafile, strerror(errno));
-exit (EXIT_FAILURE);
-}
-
if (params.xflag) {
-unsigned char *p = NULL;
/*
* XIP: do not append the image_header_t at the
* beginning of the file, but consume the space
* reserved for it.
*/
+nbytes = read(dfd, buf, tparams-header_size);
+if (nbytes == -1) {
+fprintf (stderr, %s: Can't read XIP header of %s: %s\n,
+ params.cmdname, datafile, strerror(errno));
+exit (EXIT_FAILURE);
+}
-if ((unsigned)sbuf.st_size tparams-header_size) {
+if (nbytes tparams-header_size) {
fprintf (stderr,
%s: Bad size: \%s\ is too small for XIP\n,
params.cmdname, datafile);
exit (EXIT_FAILURE);
}
-for (p = ptr; p ptr + tparams-header_size; p++) {
-if ( *p != 0xff ) {
+for (i = 0; i nbytes; ++i) {
+if (buf[i] != 0xff) {
fprintf (stderr,
%s: Bad file: \%s\ has invalid buffer for XIP\n,
params.cmdname, datafile);
exit (EXIT_FAILURE);
}
}
+}
-offset = tparams-header_size;
+while ((nbytes = read(dfd, buf, sizeof(buf))) 0) {
+if (write(ifd, buf, nbytes) != nbytes) {
+fprintf (stderr, %s: Write error on %s: %s\n,
+ params.cmdname, params.imagefile, strerror(errno));
+exit (EXIT_FAILURE);
+}
+size += nbytes;
}
-size = sbuf.st_size - offset;
-if (write(ifd, ptr + offset, size) != size) {
-fprintf (stderr, %s: Write error on %s: %s\n,
-params.cmdname, params.imagefile, strerror(errno));
-exit (EXIT_FAILURE);
+if (nbytes == -1) {
+fprintf (stderr, %s: Read error on %s: %s\n,
+ params.cmdname, params.imagefile, strerror(errno));
+ exit (EXIT_FAILURE);
}
tail = size % 4;
if ((pad == 1) (tail != 0)) {
-
-if (write(ifd, (char *)zero, 4-tail) != 4-tail) {
+if (write(ifd, (char *)zero, 4 - tail) != 4 - tail) {
fprintf (stderr, %s: Write error on %s: %s\n,
-params.cmdname, params.imagefile,
-strerror(errno));
+ params.cmdname, params.imagefile,
+ strerror(errno));
exit (EXIT_FAILURE);
}
-} else if (pad 1) {
+}
+
+else if (pad 1) {
if (write(ifd, (char *)zeros, pad) != pad) {
fprintf(stderr, %s: Write error on %s: %s\n,
params.cmdname, params.imagefile,
@@ -614,7 +613,6 @@ copy_file (int ifd, const char *datafile, int pad)
}
}
-(void) munmap((void *)ptr, sbuf.st_size);
(void) close (dfd);
}
--
1.7.9.5
--
Julien Castets
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] [PATCH] tools: mkimage can read input on /dev/stdin
Dear Julien, In message cadf714bj6-wvjbsd1u8ua-zt+h0tuo5vqo3_-6q34yujvbk...@mail.gmail.com you wrote: On Sat, Sep 27, 2014 at 2:54 PM, Wolfgang Denk w...@denx.de wrote: What would be the benefit of doing so? Do you have an example for a practical use case where this makes sense? In my case, I have a TFTP server that dyncamically generates uboot bootfiles when a specific file is requested. The input template file being generated, I need to create a temporary file to store it before calling mkimage. Except the mmap, there's no technical restriction for mkimage to be able to read on a pipe. Sorry, but I don't understand this. Where are the image(s) coming from, then? Who or what is feeding the pipe? What is the size and performance impact of the suggested change for typical use cases? None. The behaviour is exactly the same. I don't believe you. Sizes rare certainly not identical, and neither is the performance. Did you do any real measurements? 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 All women should know how to take care of children. Most of them will have a husband some day. - Franklin P. Jones ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot panasonic repo
Hi Wolfgang, 2014-09-27 22:00 GMT+09:00 Wolfgang Denk w...@denx.de: Dear Masahiro, In message camhh57rx8vlz9fl6oxeyjmwwnsktg36dterenm0yvqclpru...@mail.gmail.com you wrote: I am trying to push to the newly-created u-boot-uniphier repo but I am in trouble. masahiro@oscar:~/workspace/u-boot-uniphier$ git push ssh://gu-uniph...@git.denx.de/u-boot-uniphier.git ... remote: error: By default, updating the current branch in a non-bare repository remote: error: is denied, because it will make the index and work tree inconsistent I recommend to always explicitly tell which branch you are trying to push where. For example, if your local branch which you are preparing for a pull request is for-upstream, then your push command would look like this: git push ssh://gu-uniph...@git.denx.de/u-boot-uniphier for-upstream:master I am afraid your recommendation won't solve the problem I am having now. I can create a new branch on the remote u-boot-uniphier.git but I cannot update the master branch. $ git --version git version 1.9.1 masahiro@oscar:~/workspace/u-boot-uniphier$ git branch * master masahiro@oscar:~/workspace/u-boot-uniphier$ git describe v2014.10-rc2-274-gf9860cf masahiro@oscar:~/workspace/u-boot-uniphier$ git push ssh://gu-uniph...@git.denx.de/u-boot-uniphier.git master:master X11 forwarding request failed on channel 0 Total 0 (delta 0), reused 0 (delta 0) remote: error: refusing to update checked out branch: refs/heads/master remote: error: By default, updating the current branch in a non-bare repository remote: error: is denied, because it will make the index and work tree inconsistent remote: error: with what you pushed, and will require 'git reset --hard' to match remote: error: the work tree to HEAD. remote: error: remote: error: You can set 'receive.denyCurrentBranch' configuration variable to remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into remote: error: its current branch; however, this is not recommended unless you remote: error: arranged to update its work tree to match what you pushed in some remote: error: other way. remote: error: remote: error: To squelch this message and still keep the default behaviour, set remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'. To ssh://gu-uniph...@git.denx.de/u-boot-uniphier.git ! [remote rejected] master - master (branch is currently checked out) error: failed to push some refs to 'ssh://gu-uniph...@git.denx.de/u-boot-uniphier.git' masahiro@oscar:~/workspace/u-boot-uniphier$ git checkout -b for-upstream Switched to a new branch 'for-upstream' masahiro@oscar:~/workspace/u-boot-uniphier$ git branch * for-upstream master masahiro@oscar:~/workspace/u-boot-uniphier$ git push ssh://gu-uniph...@git.denx.de/u-boot-uniphier.git for-upstream:master X11 forwarding request failed on channel 0 Total 0 (delta 0), reused 0 (delta 0) remote: error: refusing to update checked out branch: refs/heads/master remote: error: By default, updating the current branch in a non-bare repository remote: error: is denied, because it will make the index and work tree inconsistent remote: error: with what you pushed, and will require 'git reset --hard' to match remote: error: the work tree to HEAD. remote: error: remote: error: You can set 'receive.denyCurrentBranch' configuration variable to remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into remote: error: its current branch; however, this is not recommended unless you remote: error: arranged to update its work tree to match what you pushed in some remote: error: other way. remote: error: remote: error: To squelch this message and still keep the default behaviour, set remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'. To ssh://gu-uniph...@git.denx.de/u-boot-uniphier.git ! [remote rejected] for-upstream - master (branch is currently checked out) error: failed to push some refs to 'ssh://gu-uniph...@git.denx.de/u-boot-uniphier.git' masahiro@oscar:~/workspace/u-boot-uniphier$ git push ssh://gu-uniph...@git.denx.de/u-boot-uniphier.git for-upstream:for-upstream X11 forwarding request failed on channel 0 Total 0 (delta 0), reused 0 (delta 0) To ssh://gu-uniph...@git.denx.de/u-boot-uniphier.git * [new branch] for-upstream - for-upstream The error message is saying that the remote u-boot-uniphier is a non-bare repository and the 'master' branch is already checked out (commit 9170818a4e004af7893fa0113f6e5b4afafded55). That is why I cannot update the master branch, I think. When I create a repo just for pushing to and fetching from, I use --bare option. Why not for the u-boot-uniphier.git on git.denx.de ? Is anyone doing his work on that repo? -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-dm.git branch for-tom
Hi Simon, Felipe, 2014-09-27 9:57 GMT+09:00 Felipe Balbi ba...@ti.com: On Fri, Sep 26, 2014 at 05:52:11PM -0600, Simon Glass wrote: Hi Tom, Here are the changes that were reviewed by Jagan (SPI maintainer). Branch is 'for-tom' as I had trouble with master (see below). The following changes since commit f9860cf081efdf32c8a01b9fc271fe55e2a79f8d: nand/denali: Document CONFIG symbols (2014-09-25 13:54:58 -0500) are available in the git repository at: git://git.denx.de/u-boot-dm.git for you to fetch changes up to 248a0488bfbb2eb16dee408a976d5f4b5546bb51: spi: Add brackets and tidy defines in spi.h (2014-09-26 15:01:15 -0600) Simon Glass (4): sandbox: Convert SPI flash emulation to use sf_params sandbox: config: Enable all SPI flash chips dm: spi: Move cmd device code into its own function spi: Add brackets and tidy defines in spi.h common/cmd_spi.c | 53 - drivers/mtd/spi/sandbox.c | 114 ++ include/configs/sandbox.h | 8 +++- include/spi.h | 24 4 files changed, 89 insertions(+), 110 deletions(-) Here's the error I got with master: git push dm HEAD:master Counting objects: 19, done. Delta compression using up to 32 threads. Compressing objects: 100% (19/19), done. Writing objects: 100% (19/19), 3.19 KiB | 0 bytes/s, done. Total 19 (delta 15), reused 0 (delta 0) remote: error: refusing to update checked out branch: refs/heads/master why isn't u-boot-dm.git a bare repository ? Seems like you have refs/heads/master checked out. Odd. Me too. I cannot push to git.denx.de/u-boot-uniphier.git because the 'master' branch is checked out. http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/ -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot panasonic repo
Dear Masahiro, In message camhh57tp302tcpwtfpu5stnzcbh491t8tdleesb-7xhmzub...@mail.gmail.com you wrote: I can create a new branch on the remote u-boot-uniphier.git but I cannot update the master branch. Please try again now. 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 The use of Microsoft crippleware systems is a sin that carries with it its own punishment. -- Tom Christiansen in 6bo3fr$pj8$5...@csnews.cs.colorado.edu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4] ARM: mx6: Add support for Kosagi Novena
I asked Bunnie about this, and the routing is 50 ohms.
On 24 September, 2014 5:40:59 pm GMT+08:00, Marek Vasut ma...@denx.de wrote:
On Wednesday, September 24, 2014 at 04:46:42 AM, Nikolay Dimitrov
wrote:
Hi Marek,
Following are some comments about FEC Ethernet:
On 09/23/2014 01:18 PM, Marek Vasut wrote:
+#define ENET_PAD_CTRL \
+ (PAD_CTL_PKE | PAD_CTL_PUE |\
+ PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
+ PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
+
PAD_CTL_SPEED_MED falls on reserved bits (7-6).
Special note: PAD_CTL_DSE_40ohm is defined as 0b110, which is
documented
as 37/27 ohm @2.5V. I didn't saw any notes on the PHY spec or the
Novena schematic about the routing guidelines of the RGMII data
lines,
but I can extrapolate that if the 125 MHz reference clock is routed
as
50-ohm line (this one is documented in the datasheet), then the data
lines are probably routed in a similar way. So the DSE value should
be
0b100, which is 57/43 ohm @ 2.5V, which in turn is defined in the
headers as PAD_CTL_DSE_60ohm (this is either a bug in the header, or
I'm
reading an updated FSL PDF).
Sean, can you comment on this ?
+static void novena_spl_setup_iomux_enet(void)
+{
+ imx_iomux_v3_setup_multiple_pads(enet_pads1,
ARRAY_SIZE(enet_pads1));
+ imx_iomux_v3_setup_multiple_pads(enet_pads2,
ARRAY_SIZE(enet_pads2));
+
+ gpio_direction_output(IMX_GPIO_NR(3, 23), 0);
+ gpio_direction_output(IMX_GPIO_NR(6, 30), 1);
+ gpio_direction_output(IMX_GPIO_NR(6, 25), 1);
+ gpio_direction_output(IMX_GPIO_NR(6, 27), 1);
+ gpio_direction_output(IMX_GPIO_NR(6, 28), 1);
+ gpio_direction_output(IMX_GPIO_NR(6, 29), 1);
+ gpio_direction_output(IMX_GPIO_NR(6, 24), 1);
+}
I think that setting the iomuxes immediately one after the other
doesn't
achieve the intended goal. After the 2nd iomux setup, the pads are
connected to the FEC, not to the GPIOs.
There's one more issue here - when you get the PHY out of reset,
you'll
have to both de-assert the RESET line while keeping the strapping
signals stable so the PHY can read them, but at the same time the PHY
RX
pins are becoming outputs and driving the same lines, which is not
good.
I'm giving a proposal how to fix this in the end.
+int board_early_init_f(void)
+{
+#if defined(CONFIG_VIDEO_IPUV3)
+ setup_display();
+#endif
+
+ /* Bring Ethernet PHY out of reset. */
+ gpio_set_value(IMX_GPIO_NR(3, 23), 1);
+
+ return 0;
+}
Getting the PHY out of reset at this point causes unpredictable reset
timing - e.g. you can't guarantee how much time the chip was held in
reset. The PHY datasheet is quite unclear about this reset timing,
the
only mentioned time is min. 10ms after power-on, and nothing about
RESET
assertion/de-assertion. I can throw a wild guess that the reset pulse
should have similar duration, e.g. 10ms.
Here's my proposal how to fix both (line driving conflict and reset
timing) issues:
#define ENET_PHY_CFG_PC \
(PAD_CTL_HYS | PAD_CTL_PUS_22K_UP | PAD_CTL_PUE | PAD_CTL_PKE)
static iomux_v3_cfg_t enet_pads1[] = {
MX6_PAD_ENET_MDIO__ENET_MDIO| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_MDC__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TXC__RGMII_TXC| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TD0__RGMII_TD0| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TD1__RGMII_TD1| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TD2__RGMII_TD2| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TD3__RGMII_TD3| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_REF_CLK__ENET_TX_CLK | MUX_PAD_CTRL(ENET_PAD_CTRL),
/* pin 35, PHY_AD2 */
MX6_PAD_RGMII_RXC__GPIO6_IO30 | MUX_PAD_CTRL(ENET_PHY_CFG_PC),
/* pin 32, MODE0 */
MX6_PAD_RGMII_RD0__GPIO6_IO25 | MUX_PAD_CTRL(ENET_PHY_CFG_PC),
/* pin 31, MODE1 */
MX6_PAD_RGMII_RD1__GPIO6_IO27 | MUX_PAD_CTRL(ENET_PHY_CFG_PC),
/* pin 28, MODE2 */
MX6_PAD_RGMII_RD2__GPIO6_IO28 | MUX_PAD_CTRL(ENET_PHY_CFG_PC),
/* pin 27, MODE3 */
MX6_PAD_RGMII_RD3__GPIO6_IO29 | MUX_PAD_CTRL(ENET_PHY_CFG_PC),
/* pin 33, CLK125_EN */
MX6_PAD_RGMII_RX_CTL__GPIO6_IO24| MUX_PAD_CTRL(ENET_PHY_CFG_PC),
/* PHY nRST */
MX6_PAD_EIM_D23__GPIO3_IO23 | MUX_PAD_CTRL(NO_PAD_CTRL),
};
static void novena_spl_setup_iomux_enet(void)
{
imx_iomux_v3_setup_multiple_pads(enet_pads1,
ARRAY_SIZE(enet_pads1));
/* Assert Ethernet PHY nRST */
gpio_direction_output(IMX_GPIO_NR(3, 23), 0);
/* Using imx6 internal pull-ups to drive PHY config pins during PHY
reset */
gpio_direction_input(IMX_GPIO_NR(6, 30)); /* PHY_AD2 = 1 */
gpio_direction_input(IMX_GPIO_NR(6, 25)); /* MODE0 = 1 */
gpio_direction_input(IMX_GPIO_NR(6, 27)); /* MODE1
Re: [U-Boot] [PATCH] tools: mkimage can read input on /dev/stdin
On Sat, Sep 27, 2014 at 3:25 PM, Wolfgang Denk w...@denx.de wrote: Sorry, but I don't understand this. Where are the image(s) coming from, then? Who or what is feeding the pipe? Sorry, I wrote quickly. In my situation: - I have a Python implementation of a TFTP server - when the file named uboot.bootscript is requested, a template is rendered. Currently, this template is stored in a temporary file - A new process is created to call mkimage, with the temporary file as input and another temporary file as output (mkimage -A arm -O linux -a 0 -e 0 -T script -C none -n 'comment' -d tmp_input tmp_output) - Finally, the output file content is returned to the client Instead of creating two temporary file, two pipes could be used (-d /dev/stdin /dev/stdout), which, in my case, would be more efficient (even if I don't really have performance issues). What is the size and performance impact of the suggested change for typical use cases? None. The behaviour is exactly the same. I don't believe you. Sizes rare certainly not identical, and neither is the performance. Did you do any real measurements? mmap is useful when you need to make random access in a file, or to optimize memory: when a file is mmapped, the kernel only loads the parts of the file that are accessed. In the case of mkimage, the file is read sequentially (meaning all of it will be retrieved from the disk). -- Julien Castets +33 (0)6.85.20.10.03 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: mkimage can read input on /dev/stdin
Dear Julien, In message CADF714bpHv6x8wUxs=7h-st3-thpcebwbzvo_-uoqcdws6w...@mail.gmail.com you wrote: I don't believe you. Sizes rare certainly not identical, and neither is the performance. Did you do any real measurements? mmap is useful when you need to make random access in a file, or to optimize memory: when a file is mmapped, the kernel only loads the parts of the file that are accessed. In the case of mkimage, the file is read sequentially (meaning all of it will be retrieved from the disk). OK, so you don't have any real data, but make a very specific statement: exactly the same. Sorry, but this is not an answer I'm going to buy. 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 In an infinite universe all things are possible, including the possi- bility that the universe does not exist. - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARM, SPL: gd / sp setup mostly omap (and sunxi)
Hi, In the clang serie I left out the changes regarding gd [well almost all, besides one just to brick Toms board ;), and for the record not intentionally], since they are not a clang problem, it might need some general cleanup. On ARM/omap there are several points setting up sp / gd: - arch/arm/cpu/armv7/lowlevel_init.S sets both of them before calling s_init. - arch/arm/cpu/armv7/omap3/lowlevel_init.S doesn't setup gd, so omap boards typically setup their own gd again. - arch/arm/lib/crt0.S setups both of them again. - the board_init_f in SPL typically sets gd again. - the common/board_f.c used to set it again (fixed) - the common/board_r.c used to set it again (fixed) And to make it more interesting, they don't point to the same location perse. My preference would be to only do this once, preferably by calling main as soon as possible. As far as I can see this should not cause any problem. e.g. We could add a system_init_f in boards_f.c and arch/arm/lib/spl.c so it gets called after sp and gd are valid, so they don't have to do their own magic. Perhaps I am missing something, comments are welcome. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: mkimage can read input on /dev/stdin
On Sep 27, 2014 8:24 PM, Wolfgang Denk OK, so you don't have any real data, but make a very specific statement: exactly the same. Sorry, but this is not an answer I'm going to buy. I'm not sure to understand what you mean. In both cases, the file is copied. What is bothering you? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] ARM: rpi_b: query internal MAC address from firmware
On Saturday, September 27, 2014 at 04:51:39 AM, Stephen Warren wrote:
The built-in SMSC 95xx chip doesn't know its own MAC address. Instead,
we must query it from the VC firmware; it's probably encoded in fuses
on the BCM2835.
Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
v2: Don't set usbethaddr if it's already set
---
arch/arm/include/asm/arch-bcm2835/mbox.h | 14 ++
board/raspberrypi/rpi_b/rpi_b.c | 29
+ include/configs/rpi_b.h |
1 +
3 files changed, 44 insertions(+)
diff --git a/arch/arm/include/asm/arch-bcm2835/mbox.h
b/arch/arm/include/asm/arch-bcm2835/mbox.h index dded857..61f427d 100644
--- a/arch/arm/include/asm/arch-bcm2835/mbox.h
+++ b/arch/arm/include/asm/arch-bcm2835/mbox.h
@@ -119,6 +119,20 @@ struct bcm2835_mbox_tag_hdr {
* };
*/
+#define BCM2835_MBOX_TAG_GET_MAC_ADDRESS 0x00010003
+
+struct bcm2835_mbox_tag_get_mac_address {
+ struct bcm2835_mbox_tag_hdr tag_hdr;
+ union {
+ struct {
+ } req;
+ struct {
+ u8 mac[6];
+ u8 pad[2];
+ } resp;
Well, can't this be a simple u32 here ?
[...]
Who will pick this series , shall I pick it ?
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/3] arm: fix exception handling
Hi, This series fixes the exception handling on ARM. First of all, it makes the symbols of the exception vectors relocatable. Then, it ensures that the exception vectors are relocated. To do so, we copy or move the exception vectors depending on the processor capability. Also, this series configures correctly the IRQ and the FIQ stack pointers. Regards, Georges Changes in v2: - Relocate exception vectors also on processors which do not support security extensions - Reword the commit messages Georges Savoundararadj (3): arm: make .vectors section allocatable arm: relocate the exception vectors arm: interrupt_init: set sp in IRQ/FIQ modes arch/arm/cpu/armv7/start.S | 6 -- arch/arm/lib/interrupts.c | 19 +++ arch/arm/lib/relocate.S| 30 ++ arch/arm/lib/vectors.S | 2 +- 4 files changed, 50 insertions(+), 7 deletions(-) -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] arm: make .vectors section allocatable
A regression was introduced in commit 41623c91. The consequence of that is the non-relocation of the section .vectors symbols : _undefined_instruction, _software_interrupt, _prefetch_abort, _data_abort, _not_used, _irq and _fiq. Before commit 41623c91, the exception vectors were in a .text section. The .text section has the attributes allocatable and executable [1]. In commit 41623c91, a specific section is created, called .vectors, with the attribute executable only. What have changed between commit 41623c91^ and 41623c91 is the attribute of the section which contains the exception vectors. An allocatable section is a section [that] occupies memory during process execution [1] which is the case of the section .vectors. Adding the lacking attribute (SHF_ALLOC or a) for the definition of the section .vectors fixed the issue. To summarize, the fix has to mark .vectors as allocatable because the exception vectors reside in memory during execution and they need to be relocated. [1] http://man7.org/linux/man-pages/man5/elf.5.html Signed-off-by: Georges Savoundararadj savou...@gmail.com Cc: Albert Aribeau albert.u.b...@aribaud.net --- Changes in v2: - Reword the commit message arch/arm/lib/vectors.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/lib/vectors.S b/arch/arm/lib/vectors.S index 0cb87ce..49238ed 100644 --- a/arch/arm/lib/vectors.S +++ b/arch/arm/lib/vectors.S @@ -33,7 +33,7 @@ * */ - .section .vectors, x + .section .vectors, ax /* * -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] arm: relocate the exception vectors
This commit relocates the exception vectors.
As ARM1176 and ARMv7 have the security extensions, it uses VBAR. For
the other ARM processors, it copies the relocated exception vectors to
the correct address: 0x or 0x.
Signed-off-by: Georges Savoundararadj savou...@gmail.com
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Tom Warren twar...@nvidia.com
---
This patch needs some tests because it impacts many boards. I have
tested it with my raspberry pi in the two cases: using VBAR and
using the copied exception vectors.
Changes in v2:
- Relocate exception vectors also on processors which do not support
security extensions
- Reword the commit message
arch/arm/cpu/armv7/start.S | 6 --
arch/arm/lib/relocate.S| 30 ++
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index fedd7c8..fdc05b9 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -81,12 +81,6 @@ ENTRY(c_runtime_cpu_setup)
mcr p15, 0, r0, c7, c10, 4 @ DSB
mcr p15, 0, r0, c7, c5, 4 @ ISB
#endif
-/*
- * Move vector table
- */
- /* Set vector address in CP15 VBAR register */
- ldr r0, =_start
- mcr p15, 0, r0, c12, c0, 0 @Set VBAR
bx lr
diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 8035251..88a478e 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -6,6 +6,8 @@
* SPDX-License-Identifier:GPL-2.0+
*/
+#include asm-offsets.h
+#include config.h
#include linux/linkage.h
/*
@@ -52,6 +54,34 @@ fixnext:
cmp r2, r3
blo fixloop
+ /*
+* Relocate the exception vectors
+*/
+#if (defined(CONFIG_ARM1176) || defined(CONFIG_ARMV7))
+ /*
+* If the ARM processor has the security extensions,
+* use VBAR to relocate the exception vectors.
+*/
+ ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd-relocaddr */
+ mcr p15, 0, r0, c12, c0, 0 /* Set VBAR */
+#else
+ /*
+* Copy the relocated exception vectors to the
+* correct address
+* CP15 c1 V bit gives us the location of the vectors:
+* 0x or 0x.
+*/
+ ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd-relocaddr */
+ mrc p15, 0, r2, c1, c0, 0 /* V bit (bit[13]) in CP15 c1 */
+ andsr2, r2, #(1 13)
+ ldreq r1, =0x /* If V=0 */
+ ldrne r1, =0x /* If V=1 */
+ ldmia r0!, {r2-r8,r10}
+ stmia r1!, {r2-r8,r10}
+ ldmia r0!, {r2-r8,r10}
+ stmia r1!, {r2-r8,r10}
+#endif
+
relocate_done:
#ifdef __XSCALE__
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] arm: interrupt_init: set sp in IRQ/FIQ modes
Before this commit, the stack addresses for IRQ and FIQ modes, IRQ_STACK_START and FIQ_STACK_START, were computed in interrupt_init but they were not used. This commit sets the stack pointers for IRQ and FIQ modes. Signed-off-by: Georges Savoundararadj savou...@gmail.com Cc: Albert Aribaud albert.u.b...@aribaud.net --- Changes in v2: - Reword the commit message arch/arm/lib/interrupts.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/arch/arm/lib/interrupts.c b/arch/arm/lib/interrupts.c index f6b7c03..49c1bf3 100644 --- a/arch/arm/lib/interrupts.c +++ b/arch/arm/lib/interrupts.c @@ -34,6 +34,25 @@ int interrupt_init (void) IRQ_STACK_START_IN = gd-irq_sp + 8; FIQ_STACK_START = IRQ_STACK_START - CONFIG_STACKSIZE_IRQ; + __asm__ __volatile__(msr cpsr_c, %0\n +mov sp, %1\n +: +: r (IRQ_MODE | I_BIT | F_BIT), + r (IRQ_STACK_START) +: memory); + + __asm__ __volatile__(msr cpsr_c, %0\n +mov sp, %1\n +: +: r (FIQ_MODE | I_BIT | F_BIT), + r (FIQ_STACK_START) +: memory); + + __asm__ __volatile__(msr cpsr_c, %0 +: +: r (SVC_MODE | I_BIT | F_BIT) +: memory); + return arch_interrupt_init(); } -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4] ARM: mx6: Add support for Kosagi Novena
On Saturday, September 27, 2014 at 06:46:24 PM, Sean Cross wrote: I asked Bunnie about this, and the routing is 50 ohms. On 24 September, 2014 5:40:59 pm GMT+08:00, Marek Vasut ma...@denx.de wrote: On Wednesday, September 24, 2014 at 04:46:42 AM, Nikolay Dimitrov wrote: Hi Marek, Following are some comments about FEC Ethernet: On 09/23/2014 01:18 PM, Marek Vasut wrote: +#define ENET_PAD_CTRL \ +(PAD_CTL_PKE | PAD_CTL_PUE |\ +PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \ +PAD_CTL_DSE_40ohm | PAD_CTL_HYS) + PAD_CTL_SPEED_MED falls on reserved bits (7-6). Fixed. [...] + +gpio_direction_output(IMX_GPIO_NR(3, 23), 0); +gpio_direction_output(IMX_GPIO_NR(6, 30), 1); +gpio_direction_output(IMX_GPIO_NR(6, 25), 1); +gpio_direction_output(IMX_GPIO_NR(6, 27), 1); +gpio_direction_output(IMX_GPIO_NR(6, 28), 1); +gpio_direction_output(IMX_GPIO_NR(6, 29), 1); +gpio_direction_output(IMX_GPIO_NR(6, 24), 1); +} I think that setting the iomuxes immediately one after the other doesn't achieve the intended goal. After the 2nd iomux setup, the pads are connected to the FEC, not to the GPIOs. Good point, moved the second mux below the GPIO settings. But what about the reset timing? 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] ARM: mx6: Add support for Kosagi Novena
On Wednesday, September 24, 2014 at 06:57:06 PM, Sean Cross wrote:
[...]
+
+int drv_keyboard_init(void)
+{
+ int error;
+ struct stdio_dev dev = {
+ .name = button,
+ .flags = DEV_FLAGS_INPUT | DEV_FLAGS_SYSTEM,
+ .start = novena_gpio_button_init,
+ .getc = novena_gpio_button_getc,
+ .tstc = novena_gpio_button_tstc,
+ };
+
+ error = input_init(button_input, 0);
+ if (error) {
+ debug(%s: Cannot set up input\n, __func__);
+ return -1;
+ }
+ button_input.read_keys = novena_gpio_button_read_keys;
+
+ /* Register the device. init_tegra_keyboard() will be called soon */
This may have been answered already, but will the function named
init_tegra_keyboard() be called? Or is there some more generic name?
This was addressed already, yes.
+ error = input_stdio_register(dev);
+ if (error)
+ return error;
+
+ return 0;
+}
+#endif
+
[...]
+int board_early_init_f(void)
+{
+#if defined(CONFIG_VIDEO_IPUV3)
+ setup_display();
+#endif
If board_early_init_f() gets called early, then this is where you should
set DISP0_DAT13 (GPIO5 IO13) to low, in order to ensure the FPGA is in
reset, so it isn't pulling the DDR3 I2C lines low.
Actually, this can be done in the SPL.
This would also be a good time to bring the sound chip out of reset, by
driving GPIO5 IO17 high, When the sound chip is in reset, the EEPROM
cannot be read.
This is already done in the SPL.
[...]
+/* setup board specific PMIC */
+int power_init_board(void)
+{
+ struct pmic *p;
+ u32 reg;
+ int ret;
+
+ power_pfuze100_init(1);
+ p = pmic_get(PFUZE100_PMIC);
+ if (!p)
+ return -EINVAL;
+
+ ret = pmic_probe(p);
+ if (ret)
+ return ret;
+
+ pmic_reg_read(p, PFUZE100_DEVICEID, reg);
+ printf(PMIC: PFUZE100 ID=0x%02x\n, reg);
+
+ /* Set VGEN1 to 1.5V and enable */
VGEN1 is unused in this system. VGEN5 is, however, hooked up to the
power LED. It defaults to ON, which allows for software to turn the
power LED off once the system is booted. You can leave everything alone
except for SWBST, which is required for USB.
Removed the VGEN1 enabling.
[...]
+#define NOVENA_AUDIO_PWRON IMX_GPIO_NR(5, 17)
+#define NOVENA_HDMI_GHOST_HPD IMX_GPIO_NR(5, 4)
+#define NOVENA_PCIE_RESET_GPIO IMX_GPIO_NR(3, 29)
+#define NOVENA_PCIE_POWER_ON_GPIO IMX_GPIO_NR(7, 12)
+#define NOVENA_PCIE_WAKE_UP_GPIO IMX_GPIO_NR(3, 22)
+#define NOVENA_PCIE_DISABLE_GPIO IMX_GPIO_NR(2, 16)
Add NOVENA_FPGA_RESET_N_GPIO IMX_GPIO_NR(5, 7). If the FPGA has a
program loaded that doesn't let the I2C pins float, then the DDR3 SPD
will be unable to be read.
Added and I am now setting this GPIO to 0 so the FPGA is in reset throughout
the
SPL operation. It can be brought out of reset in U-Boot itself and only when
it's actually used, right ?
+
+/*
+ * Audio
+ */
+static iomux_v3_cfg_t audio_pads[] = {
+ /* AUD_PWRON */
+ MX6_PAD_DISP0_DAT23__GPIO5_IO17 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
+static void novena_spl_setup_iomux_audio(void)
+{
+ imx_iomux_v3_setup_multiple_pads(audio_pads, ARRAY_SIZE(audio_pads));
+ gpio_direction_output(NOVENA_AUDIO_PWRON, 1);
+}
+
+/*
+ * ENET
+ */
+static iomux_v3_cfg_t enet_pads1[] = {
+ MX6_PAD_ENET_MDIO__ENET_MDIO| MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_ENET_MDC__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_RGMII_TXC__RGMII_TXC| MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_RGMII_TD0__RGMII_TD0| MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_RGMII_TD1__RGMII_TD1| MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_RGMII_TD2__RGMII_TD2| MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_RGMII_TD3__RGMII_TD3| MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_ENET_REF_CLK__ENET_TX_CLK | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ /* pin 35 - 1 (PHY_AD2) on reset */
+ MX6_PAD_RGMII_RXC__GPIO6_IO30 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ /* pin 32 - 1 - (MODE0) all */
+ MX6_PAD_RGMII_RD0__GPIO6_IO25 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ /* pin 31 - 1 - (MODE1) all */
+ MX6_PAD_RGMII_RD1__GPIO6_IO27 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ /* pin 28 - 1 - (MODE2) all */
+ MX6_PAD_RGMII_RD2__GPIO6_IO28 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ /* pin 27 - 1 - (MODE3) all */
+ MX6_PAD_RGMII_RD3__GPIO6_IO29 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ /* pin 33 - 1 - (CLK125_EN) 125Mhz clockout enabled */
+ MX6_PAD_RGMII_RX_CTL__GPIO6_IO24| MUX_PAD_CTRL(NO_PAD_CTRL),
+ /* pin 42 PHY nRST */
+ MX6_PAD_EIM_D23__GPIO3_IO23 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
+static iomux_v3_cfg_t
Re: [U-Boot] [PATCH] tools: mkimage can read input on /dev/stdin
Dear Julien, In message cadf714blg21jobjtnbubwqsyj3xbzl+fb+wbfcrq8yh4-ug...@mail.gmail.com you wrote: I'm not sure to understand what you mean. In both cases, the file is copied. What is bothering you? I asked: | What is the size and performance impact of the suggested change for | typical use cases? Can you please provide values for the size of the binary and the execution time? It's not really critical, but I'd like to understand the impact of your changes. You use case is pretty exotic, so it seems a valid question to me to try to understand what the extended functionality costs. 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 There's no future in time travel. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: mkimage can read input on /dev/stdin
On Saturday, September 27, 2014 at 11:56:55 PM, Wolfgang Denk wrote: Hello Wolfgang, Dear Julien, In message CADF714bLG21jobjTnbUbWqsyj3xbzL+Fb+WBfcrq8YH4- ug...@mail.gmail.com you wrote: I'm not sure to understand what you mean. In both cases, the file is copied. What is bothering you? I asked: | What is the size and performance impact of the suggested change for | typical use cases? Can you please provide values for the size of the binary and the execution time? It's not really critical, but I'd like to understand the impact of your changes. You use case is pretty exotic, so it seems a valid question to me to try to understand what the extended functionality costs. Won't it be better to focus on the overall concept first and dig in the finer details later ? I think right now, the question is -- do we want to support stdin as a source of payload for mkimage or not at all? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] lsxl: convert to generic board and fix typo
Besides converting the LS-XHL and LS-CHLv2 to generic board, fix a typo which accidentally reverted the bootsource to 'hdd' although the default bootsource should be 'legacy'. Cc: Tom Rini tr...@ti.com Cc: Prafulla Wadaskar prafu...@marvell.com Signed-off-by: Michael Walle mich...@walle.cc --- Hi Tom, Hi Prafulla, could this patch be merged before the 2014.10 release? Maybe Tom could pick it directly. If not, it's ok; it is my fault to be so late ;) michael --- include/configs/lsxl.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/configs/lsxl.h b/include/configs/lsxl.h index bf5c1a1..a14bfe3 100644 --- a/include/configs/lsxl.h +++ b/include/configs/lsxl.h @@ -8,6 +8,8 @@ #ifndef _CONFIG_LSXL_H #define _CONFIG_LSXL_H +#define CONFIG_SYS_GENERIC_BOARD + /* * Version number information */ @@ -157,7 +159,7 @@ standard_env=setenv ipaddr; setenv netmask; setenv serverip; \ setenv ncip; setenv gatewayip; setenv ethact; \ setenv bootfile; setenv dnsip;\ - setenv bootsource hdd; run ser\0 \ + setenv bootsource legacy; run ser\0 \ restore_env=run standard_env; saveenv; reset\0\ ser=setenv stdin serial; setenv stdout serial;\ setenv stderr serial\0\ -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: mkimage can read input on /dev/stdin
Dear Marek, In message 201409280001.26383.ma...@denx.de you wrote: Can you please provide values for the size of the binary and the execution time? It's not really critical, but I'd like to understand the impact of your changes. You use case is pretty exotic, so it seems a valid question to me to try to understand what the extended functionality costs. Won't it be better to focus on the overall concept first and dig in the finer details later ? I think right now, the question is -- do we want to support stdin as a source of payload for mkimage or not at all? The general approach to new features in U-Boot is: 1) is it useful at least to some? and 2) does it not hurt others? Re 1), I think the use case is pretty exostic, but apparently there is at least one user for that. Re 2), we need some numbers. Plain mmap() on a regular file is supposed to be the fastest possible I/O method in a Unix OS, so we should understand how much a change costs, or if it makes sense to provide different implementations depending on input type (read() for stdin vs. mmap() for regular files). Or if the differences are so small that this is all not worth the time we spend here. 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 One difference between a man and a machine is that a machine is quiet when well oiled. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: mkimage can read input on /dev/stdin
Thanks for your comments, On Sat, Sep 27, 2014 at 11:56 PM, Wolfgang Denk w...@denx.de wrote: Can you please provide values for the size of the binary and the execution time? Without the patch, with mmap: $ dd if=/dev/zero of=test bs=1M count=10 $ time ./mkimage -A arm -O linux -a 0 -e 0 -T script -C none -n 'test' -d test test_out ... real0m0.168s user0m0.027s sys 0m0.023s With the patch, with read: $ dd if=/dev/zero of=test bs=1M count=10 $ time ./mkimage -A arm -O linux -a 0 -e 0 -T script -C none -n 'test' -d test test_out ... real0m0.160s user0m0.025s sys 0m0.016s In both cases, the binary mkimage size is 144k bytes (147333 with mmap, 147421 with read). Compiled with make sandbox_defconfig and make_tools. It's not really critical, but I'd like to understand the impact of your changes. You use case is pretty exotic, so it seems a valid question to me to try to understand what the extended functionality costs. I understand the use case, in its globality, is pretty exotic. However, I don't really get why giving /dev/stdin as input is. Regards, -- Julien Castets ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] powerpc/mpc85xx: modify erratum A007212
On 09/27/2014 12:02 AM, York Sun wrote: -Original Message- From: Sun York-R58495 Sent: Saturday, September 27, 2014 12:02 AM To: Zhao Qiang-B45475; u-boot@lists.denx.de Cc: Xie Xiaobo-R63061 Subject: Re: [PATCH 2/2] powerpc/mpc85xx: modify erratum A007212 On 09/25/2014 10:55 PM, Zhao Qiang-B45475 wrote: On 9/26/14 1:01 PM, York Sun wrote: -Original Message- From: Sun York-R58495 Sent: Friday, September 26, 2014 1:01 PM To: Zhao Qiang-B45475; u-boot@lists.denx.de Cc: Xie Xiaobo-R63061; Zhao Qiang-B45475 Subject: Re: [PATCH 2/2] powerpc/mpc85xx: modify erratum A007212 On 9/25/14 9:37 PM, Zhao Qiang b45...@freescale.com wrote: T2080 v1.0 has this errata while v1.1 has fixed this errata by hardware, add a new function to check the SVR_SOC_VER, SVR_MAJ and SVR_MIN first, if the cpu is T2080 and version is not v1.0, doesn't run the a007212 errata_workaround. Signed-off-by: Zhao Qiang b45...@freescale.com --- Qiang, I don't agree with your analysis. This workaround has two parts. One part is to to disable DDR PLL in RCW. The second part is to detect DDR PLL is disabled and to implement the software workaround to bring DDR up. U-boot has the second part, it is safe to apply to all versions for affected SoC. I put in the comments. Your patch detects the SVR and decide if the workaround should be applied. This is wrong. It should detect if DDR PLL is disabled. In case an old RCW is used, you don't want to end up with a dead board because DDR is disabled. OK , got it , I will modify it for v2. Thanks for you comment. Qiang, I don't think you even need a patch for this. The logic for u-boot code is: Regardless of the SVR, the workaround is not be applied if RCW doesn't disable DDR PLL. Regardless of the SVR, the workaround is and should be applied if RCW disables DDR PLL. And how about the file arch/powerpc/cpu/mpc85xx/speed.c. The code doesn't detect if the DDR PLL is disabled, it will config the mem_pll_rat. York Best Regards Zhao Qiang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] powerpc/mpc85xx: modify erratum A007212
On 9/27/14 6:56 PM, Zhao Qiang-B45475 qiang.z...@freescale.com wrote: On 09/27/2014 12:02 AM, York Sun wrote: -Original Message- From: Sun York-R58495 Sent: Saturday, September 27, 2014 12:02 AM To: Zhao Qiang-B45475; u-boot@lists.denx.de Cc: Xie Xiaobo-R63061 Subject: Re: [PATCH 2/2] powerpc/mpc85xx: modify erratum A007212 On 09/25/2014 10:55 PM, Zhao Qiang-B45475 wrote: On 9/26/14 1:01 PM, York Sun wrote: -Original Message- From: Sun York-R58495 Sent: Friday, September 26, 2014 1:01 PM To: Zhao Qiang-B45475; u-boot@lists.denx.de Cc: Xie Xiaobo-R63061; Zhao Qiang-B45475 Subject: Re: [PATCH 2/2] powerpc/mpc85xx: modify erratum A007212 On 9/25/14 9:37 PM, Zhao Qiang b45...@freescale.com wrote: T2080 v1.0 has this errata while v1.1 has fixed this errata by hardware, add a new function to check the SVR_SOC_VER, SVR_MAJ and SVR_MIN first, if the cpu is T2080 and version is not v1.0, doesn't run the a007212 errata_workaround. Signed-off-by: Zhao Qiang b45...@freescale.com --- Qiang, I don't agree with your analysis. This workaround has two parts. One part is to to disable DDR PLL in RCW. The second part is to detect DDR PLL is disabled and to implement the software workaround to bring DDR up. U-boot has the second part, it is safe to apply to all versions for affected SoC. I put in the comments. Your patch detects the SVR and decide if the workaround should be applied. This is wrong. It should detect if DDR PLL is disabled. In case an old RCW is used, you don't want to end up with a dead board because DDR is disabled. OK , got it , I will modify it for v2. Thanks for you comment. Qiang, I don't think you even need a patch for this. The logic for u-boot code is: Regardless of the SVR, the workaround is not be applied if RCW doesn't disable DDR PLL. Regardless of the SVR, the workaround is and should be applied if RCW disables DDR PLL. And how about the file arch/powerpc/cpu/mpc85xx/speed.c. The code doesn¹t detect if the DDR PLL is disabled, it will config the mem_pll_rat. If you look closely in this file, you will see code guarded by macro CONFIG_SYS_FSL_ERRATUM_A007212. In case mem_pll_rat is detected as 0, a reserved field is used for DDR PLL ratio. It is written in erratum workaround. It wasn't in original document but should be updated a while ago. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] powerpc/mpc85xx: modify erratum A007186
T2080 v1.0 has this errata while v1.1 has fixed
this errata by hardware, add a new function has_errata_a007186
to check the SVR_SOC_VER, SVR_MAJ and SVR_MIN first,
if the sil has errata a007186, then run the errata code,
if not, doesn't run the code.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
Changes for v2:
- use has_errata_a007186 instead of not_has_errata_a007186
arch/powerpc/cpu/mpc85xx/cmd_errata.c | 3 +-
arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c | 210 ++---
arch/powerpc/include/asm/fsl_errata.h | 22 +++
3 files changed, 138 insertions(+), 97 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index 3a04a89..0774461 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -270,7 +270,8 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
puts(Work-around for Erratum USB14 enabled\n);
#endif
#ifdef CONFIG_SYS_FSL_ERRATUM_A007186
- puts(Work-around for Erratum A007186 enabled\n);
+ if (has_erratum_a007186())
+ puts(Work-around for Erratum A007186 enabled\n);
#endif
#ifdef CONFIG_SYS_FSL_ERRATUM_A006593
puts(Work-around for Erratum A006593 enabled\n);
diff --git a/arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c
b/arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c
index d1fc76a..ac030be 100644
--- a/arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c
+++ b/arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c
@@ -11,6 +11,7 @@
#include asm/processor.h
#include asm/fsl_law.h
#include asm/errno.h
+#include asm/fsl_errata.h
#include fsl_corenet2_serdes.h
#ifdef CONFIG_SYS_FSL_SRDS_1
@@ -203,108 +204,125 @@ u64 serdes_init(u32 sd, u32 sd_addr, u32 sd_prctl_mask,
u32 sd_prctl_shift)
* This workaround for the protocols and rates that only have the Ring VCO.
*/
#ifdef CONFIG_SYS_FSL_ERRATUM_A007186
- sfp_spfr0 = in_be32(sfp_regs-fsl_spfr0);
- debug(A007186: sfp_spfr0= %x\n, sfp_spfr0);
+ if (has_erratum_a007186()) {
+ sfp_spfr0 = in_be32(sfp_regs-fsl_spfr0);
+ debug(A007186: sfp_spfr0= %x\n, sfp_spfr0);
- sel = (sfp_spfr0 FUSE_VAL_SHIFT) FUSE_VAL_MASK;
+ sel = (sfp_spfr0 FUSE_VAL_SHIFT) FUSE_VAL_MASK;
- if (sel == 0x01 || sel == 0x02) {
- for (pll_num = 0; pll_num SRDS_MAX_BANK; pll_num++) {
- pll_status = in_be32(srds_regs-bank[pll_num].pllcr0);
- debug(A007186: pll_num=%x pllcr0=%x\n,
- pll_num, pll_status);
- /* STEP 1 */
- /* Read factory pre-set SerDes calibration values
-* from fuse block(SFP scratch register-sfp_spfr0)
-*/
- switch (pll_status SRDS_PLLCR0_FRATE_SEL_MASK) {
- case SRDS_PLLCR0_FRATE_SEL_3_0:
- case SRDS_PLLCR0_FRATE_SEL_3_072:
- debug(A007186: 3.0/3.072 protocol rate\n);
- bc = (sfp_spfr0 BC1_SHIFT) BC_MASK;
- dc = (sfp_spfr0 DC1_SHIFT) DC_MASK;
- fc = (sfp_spfr0 FC1_SHIFT) FC_MASK;
- break;
- case SRDS_PLLCR0_FRATE_SEL_3_125:
- debug(A007186: 3.125 protocol rate\n);
- bc = (sfp_spfr0 BC2_SHIFT) BC_MASK;
- dc = (sfp_spfr0 DC2_SHIFT) DC_MASK;
- fc = (sfp_spfr0 FC2_SHIFT) FC_MASK;
- break;
- case SRDS_PLLCR0_FRATE_SEL_3_75:
- debug(A007186: 3.75 protocol rate\n);
- bc = (sfp_spfr0 BC1_SHIFT) BC_MASK;
- dc = (sfp_spfr0 DC1_SHIFT) DC_MASK;
- fc = (sfp_spfr0 FC1_SHIFT) FC_MASK;
- break;
- default:
- continue;
- }
+ if (sel == 0x01 || sel == 0x02) {
+ for (pll_num = 0; pll_num SRDS_MAX_BANK; pll_num++) {
+ pll_status = in_be32(srds_regs-
+bank[pll_num].pllcr0);
+ debug(A007186: pll_num=%x pllcr0=%x\n,
+ pll_num, pll_status);
+ /* STEP 1 */
+ /* Read factory pre-set SerDes calibration
+* values from fuse block(SFP scratch
+* register-sfp_spfr0)
+*/
+ switch (pll_status
+
Re: [U-Boot] [GENERIC_BOARD] env problems before relocation with ppc8360
Hi, On 26 August 2014 09:17, Valentin Longchamp valentin.longch...@keymile.com wrote: Hello, Here is the outcome of my debug session today: On 08/25/2014 05:42 PM, Valentin Longchamp wrote: Hello, I am currently porting all the Keymile boards to CONFIG_SYS_GENERIC_BOARD. On u-boot 2014.10-rc1 I have all of them working quite well (at least booting and showing no obvious problem), except for our boards using a MPC8360 from Freescale (kmcoge5ne and kmeter1, both using km8360.h as config) that do not boot at all. I have found out that u-boot crashes as soon as a getenv function call happens before relocation. When I disable them, u-boot seems to work fine. I am currently trying to debug further, but it's not clear yet exactly what causes the crash. So the problem is that for an unknown reason, the gd-flags are not correct and getenv actually calls hsearch_h to look for the desired env variable. This fails before relocation (due to the small stack ?). If I replace the board_f getenv_ulong calls in board_f.c with my getenv_f_ulong function that explicitely calls getenv_f the board boots up nicely. Now the question is, why are my gd-flags not correct/corrupted ? Has someone already seen something similar ? I unfortunateley cannot access gd easily with the BDI, since it is located in the INIT_RAM which is a data cache, for which I have no LAW configured (could work on that). I just saw this. There is condition code at the start of board_init_f() in board_f.c that might exclude your board. So your global data might not be zeroed. We also have quite a few MPC8321 boards (for instance tuxx1.h or suvd3.h) and there the problem is not present, while the environment is also in the NOR flash as on km8360 and their core also a e300 (so their initialization is VERY similar). I have checked and there it's clearly getenv_f that gets called by getenv before relocation. That's why no problem is seen there. Valentin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4] ARM: mx6: Add support for Kosagi Novena
Hi Marek,
Here are my last findings:
On 09/23/2014 01:18 PM, Marek Vasut wrote:
+static void novena_spl_setup_iomux_sdhc(void)
+{
+ imx_iomux_v3_setup_multiple_pads(usdhc2_pads, ARRAY_SIZE(usdhc2_pads));
+ imx_iomux_v3_setup_multiple_pads(usdhc3_pads, ARRAY_SIZE(usdhc3_pads));
+
+ /* Micro SD card detect */
+ gpio_direction_input(IMX_GPIO_NR(7, 0));
+
+ /* Big SD card detect */
+ gpio_direction_input(IMX_GPIO_NR(1, 4));
+}
I think that you mentioned elsewhere in the source, that microSD card
doesn't have CD. Also, GPIO7_IO00 is not connected to anything.
+#define NOVENA_USB_HUB_RESET IMX_GPIO_NR(7, 12)
Can you please double-check this one, it seems that GPIO7_IO12 is
actually connected as PCIE_PWRON on the schematic.
+/*
+ * USB
+ */
+#ifdef CONFIG_USB_EHCI_MX6
+int board_ehci_hcd_init(int port)
+{
+ /* Reset USB hub */
+ if (port == 1) {
+ gpio_set_value(NOVENA_USB_HUB_RESET, 0);
+ mdelay(2);
+ gpio_set_value(NOVENA_USB_HUB_RESET, 1);
+ }
+ return 0;
+}
+#endif
Can you verify this - USB hubs seems to be reset not by this pin, but
via RESETBMCU.
+#define NOVENA_AUDIO_PWRONIMX_GPIO_NR(5, 17)
This signal is not connected to the audio power switch, because R30A is
marked as DNP. The audio power switch seems to be controlled by
KEY_ROW1, which is not configured by uboot, I think.
+#define NOVENA_HDMI_GHOST_HPD IMX_GPIO_NR(5, 4)
...
+static void novena_spl_setup_iomux_video(void)
+{
+ imx_iomux_v3_setup_multiple_pads(hdmi_pads, ARRAY_SIZE(hdmi_pads));
+ gpio_direction_input(NOVENA_HDMI_GHOST_HPD);
+}
Is there any added value of having this pin initialized? It should be
already configured as input on reset.
+ * Environment is on MMC, starting at offset 64KiB from start of the
card.
...
+#define CONFIG_ENV_OFFSET (512 * 1024)
Comments and code say different things about the ENV offset - which one
is the correct value?
I don't have any more comments on v4. Sorry it took so long, but it
takes ages to cross-check the code, schematic and datasheets, you
know... Thanks for your patience. Please tell me if I can help more.
Kind regards,
Nikolay
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot panasonic repo
Hi Wolfgang, 2014-09-28 0:57 GMT+09:00 Wolfgang Denk w...@denx.de: Dear Masahiro, In message camhh57tp302tcpwtfpu5stnzcbh491t8tdleesb-7xhmzub...@mail.gmail.com you wrote: I can create a new branch on the remote u-boot-uniphier.git but I cannot update the master branch. Please try again now. Everything looks working fine now. Thank you!! -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
