[U-Boot] [PATCH] MAINTAINERS: add me as a maintainer of UBI
Add me for UBI custodian. Signed-off-by: Heiko Schocher h...@denx.de --- MAINTAINERS| 1 + doc/git-mailrc | 1 + 2 files changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7812983..cc06353 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -398,6 +398,7 @@ T: git git://git.denx.de/u-boot-tq-group.git UBI M: Kyungmin Park kmp...@infradead.org +M: Heiko Schocher h...@denx.de S: Maintained T: git git://git.denx.de/u-boot-ubi.git F: drivers/mtd/ubi/ diff --git a/doc/git-mailrc b/doc/git-mailrc index 166fe37..b15e190 100644 --- a/doc/git-mailrc +++ b/doc/git-mailrc @@ -120,6 +120,7 @@ alias mtduboot, hs alias nand uboot, scottwood alias netuboot, jhersh alias spi uboot, jagan +alias ubiuboot, hs alias usbuboot, marex alias video uboot, ag alias patman uboot, sjg -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] arm: odroid: usb: add support for usb host including ethernet
Hi, On 18/11/14 12:30, Suriyan Ramasami wrote: Hello Minkyu Kang/Przemyslaw and of course anyone else who can direct me, Thanks for the commit. I just realized that the code in this particular patch is missing the gpio_request() call before calling the gpio_direction_output() call, and hence fails to initialize the USB3503A hub. This was pointed out by Przemyslaw in another patch of mine (odroid: blue LED) So, my question is, this patch is in u-boot-samsung. To correct the above mentioned error, do I submit a patch directed to u-boot-samsung? Yes. Please send new patch. If so how do I do it? I mean, do I elaborate this in the subject /.body of the mail? sorry, I can't catch the point of your question. Thanks and regards, - Suriyan Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MAINTAINERS: add me as a maintainer of UBI
On 18.11.2014 09:08, Heiko Schocher wrote: Add me for UBI custodian. Signed-off-by: Heiko Schocher h...@denx.de Acked-by: Stefan Roese s...@denx.de Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 1/3] arm, arm926ejs: make thumb mode compileable
in thumb mode compiler says for example for arch/arm/lib/cache-cp15.c
when enabling CONFIG_SYS_THUMB_BUILD:
{standard input}: Assembler messages:
{standard input}:373: Error: selected processor does not support Thumb mode
`mrc p15,0,r4,c1,c0,0'
{standard input}:416: Error: selected processor does not support Thumb mode
`mcr p15,0,r3,c2,c0,0'
so, if caches are disabled, do not use this command on arm926ejs.
used on at91 in SPL, to reduce size of SPL.
Signed-off-by: Heiko Schocher h...@denx.de
---
arch/arm/cpu/arm926ejs/cpu.c | 2 ++
arch/arm/lib/cache.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm/cpu/arm926ejs/cpu.c b/arch/arm/cpu/arm926ejs/cpu.c
index e37e87b..a90ce30 100644
--- a/arch/arm/cpu/arm926ejs/cpu.c
+++ b/arch/arm/cpu/arm926ejs/cpu.c
@@ -45,7 +45,9 @@ int cleanup_before_linux (void)
/* flush I/D-cache */
static void cache_flush (void)
{
+#if !(defined(CONFIG_SYS_ICACHE_OFF) defined(CONFIG_SYS_DCACHE_OFF))
unsigned long i = 0;
asm (mcr p15, 0, %0, c7, c7, 0: :r (i));
+#endif
}
diff --git a/arch/arm/lib/cache.c b/arch/arm/lib/cache.c
index 4e597a4..b016558 100644
--- a/arch/arm/lib/cache.c
+++ b/arch/arm/lib/cache.c
@@ -24,10 +24,12 @@ __weak void flush_cache(unsigned long start, unsigned long
size)
#endif /* CONFIG_ARM1136 */
#ifdef CONFIG_ARM926EJS
+#if !(defined(CONFIG_SYS_ICACHE_OFF) defined(CONFIG_SYS_DCACHE_OFF))
/* test and clean, page 2-23 of arm926ejs manual */
asm(0: mrc p15, 0, r15, c7, c10, 3\n\t bne 0b\n : : : memory);
/* disable write buffer as well (page 2-22) */
asm(mcr p15, 0, %0, c7, c10, 4 : : r (0));
+#endif
#endif /* CONFIG_ARM926EJS */
return;
}
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 2/3] arm, at91: enable thumb mode for taurus board in SPL
Signed-off-by: Heiko Schocher h...@denx.de --- include/configs/taurus.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/configs/taurus.h b/include/configs/taurus.h index 20194ae..06725cd 100644 --- a/include/configs/taurus.h +++ b/include/configs/taurus.h @@ -26,6 +26,11 @@ #define CONFIG_SYS_GENERIC_BOARD +#if defined(CONFIG_SPL_BUILD) +#define CONFIG_SYS_THUMB_BUILD +#define CONFIG_SYS_ICACHE_OFF +#define CONFIG_SYS_DCACHE_OFF +#endif /* * Warning: changing CONFIG_SYS_TEXT_BASE requires * adapting the initial boot program. -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 3/3] taurus, spl: erase also spi flash if recovery button is pressed
if in SPL mode recovery button is pressed, erase also spi flash
from offset 0 to CONFIG_SYS_NAND_U_BOOT_SIZE on the taurus board.
Signed-off-by: Heiko Schocher h...@denx.de
---
board/siemens/taurus/taurus.c | 24 +++-
include/configs/taurus.h | 18 +-
2 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/board/siemens/taurus/taurus.c b/board/siemens/taurus/taurus.c
index b8ff478..013dac2 100644
--- a/board/siemens/taurus/taurus.c
+++ b/board/siemens/taurus/taurus.c
@@ -68,6 +68,7 @@ static void taurus_nand_hw_init(void)
#if defined(CONFIG_SPL_BUILD)
#include spl.h
#include nand.h
+#include spi_flash.h
void matrix_init(void)
{
@@ -81,23 +82,28 @@ void matrix_init(void)
void at91_spl_board_init(void)
{
taurus_nand_hw_init();
+ at91_spi0_hw_init(TAURUS_SPI_MASK);
/* Configure recovery button PINs */
at91_set_gpio_input(AT91_PIN_PA31, 1);
/* check if button is pressed */
if (at91_get_gpio_value(AT91_PIN_PA31) == 0) {
- u32 boot_device;
+ struct spi_flash *flash;
debug(Recovery button pressed\n);
- boot_device = spl_boot_device();
- switch (boot_device) {
-#ifdef CONFIG_SPL_NAND_SUPPORT
- case BOOT_DEVICE_NAND:
- nand_init();
- spl_nand_erase_one(0, 0);
- break;
-#endif
+ nand_init();
+ spl_nand_erase_one(0, 0);
+ flash = spi_flash_probe(CONFIG_SF_DEFAULT_BUS,
+ 0,
+ CONFIG_SF_DEFAULT_SPEED,
+ SPI_MODE_3);
+ if (!flash) {
+ puts(no flash\n);
+ } else {
+ puts(erase spi flash sector 0\n);
+ spi_flash_erase(flash, 0,
+ CONFIG_SYS_NAND_U_BOOT_SIZE);
}
}
}
diff --git a/include/configs/taurus.h b/include/configs/taurus.h
index 06725cd..65468ad 100644
--- a/include/configs/taurus.h
+++ b/include/configs/taurus.h
@@ -142,6 +142,19 @@
#define TAURUS_SPI_MASK (1 4)
#define TAURUS_SPI_CS_PIN AT91_PIN_PA3
+#if defined(CONFIG_SPL_BUILD)
+/* SPL related */
+#undef CONFIG_SPL_OS_BOOT /* Not supported by existing map */
+#define CONFIG_SPL_SPI_SUPPORT
+#define CONFIG_SPL_SPI_FLASH_SUPPORT
+#define CONFIG_SPL_SPI_LOAD
+#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x2
+
+#define CONFIG_SF_DEFAULT_BUS 0
+#define CONFIG_SF_DEFAULT_SPEED 1000
+#define CONFIG_SF_DEFAULT_MODE SPI_MODE_0
+#endif
+
/* load address */
#define CONFIG_SYS_LOAD_ADDR 0x2200
@@ -176,8 +189,11 @@
/* Defines for SPL */
#define CONFIG_SPL_FRAMEWORK
#define CONFIG_SPL_TEXT_BASE 0x0
-#define CONFIG_SPL_MAX_SIZE(11 * 1024)
+#define CONFIG_SPL_MAX_SIZE(14 * 1024)
#define CONFIG_SPL_STACK (16 * 1024)
+#define CONFIG_SYS_SPL_MALLOC_START (CONFIG_SYS_TEXT_BASE - \
+ CONFIG_SYS_MALLOC_LEN)
+#define CONFIG_SYS_SPL_MALLOC_SIZE CONFIG_SYS_MALLOC_LEN
#define CONFIG_SPL_BSS_START_ADDR CONFIG_SPL_MAX_SIZE
#define CONFIG_SPL_BSS_MAX_SIZE(3 * 1024)
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 0/3] arm, at91: taurus board updates
This series enables THUMB mode in SPL for the taurus board. On this hw are 16k only for SPL code, so THUMB mode is needed, because we need to detect the nor flash on the spi bus. This is needed because we want to erase sector 0 of the spi nor flash if the recovery button is pressed in SPL. Heiko Schocher (3): arm, arm926ejs: make thumb mode compileable arm, at91: enable thumb mode for taurus board in SPL taurus, spl: erase also spi flash if recovery button is pressed arch/arm/cpu/arm926ejs/cpu.c | 2 ++ arch/arm/lib/cache.c | 2 ++ board/siemens/taurus/taurus.c | 24 +++- include/configs/taurus.h | 23 ++- 4 files changed, 41 insertions(+), 10 deletions(-) -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [SOLVED] loadb problem.
Dear Wolfgang, Upon looking at the transfers more closely on the scope, I found that the board sometimes answered the PC in the middle of receiving a packet. I found that this was due to a global DEBUG being turned on in the configuration file for the board. When I removed all of the following: #define DEBUG #define CONFIG_DEBUG_DUMP #define CONFIG_DEBUG_DUMP_SYMS #define CONFIG_DEBUG_EARLY_SERIAL #define CONFIG_DEBUG_NULL_PTR #define TESTING the Kermit transfers are fine, with approximately 4 kilobytes per second transfer rate. Thank you for your time. Hopefully this can help someone in the future. /Bo -- View this message in context: http://u-boot.10912.n7.nabble.com/loadb-problem-Hangs-on-START-CHAR-tp195144p196641.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] spi: add common spi3 controller driver
2014-11-17 3:23 GMT+08:00 Jagan Teki jagannadh.t...@gmail.com: Hi Scott, On 25 September 2014 14:55, Scott Jiang scott.jiang.li...@gmail.com wrote: SPI3 controller is not only used on BF609 platform. So we add a common controller driver and leave machine specific configuration in board drivers. Remove obsolete spi6xx.h and select new board driver in configuration file. Signed-off-by: Scott Jiang scott.jiang.li...@gmail.com --- drivers/spi/Makefile |1 + drivers/spi/adi_spi3.c | 222 I think adi_spi3.c is a copy of bfin_spi6xx.c with excluded-ed stuff of bf609 And also the difference is of chipselect and slave setup handling, why can't we use same driver my making this difference stuff in particular macro. Please try in that sense, It's not looking good to have one driver file with only having chip selct handing and slave setup. Would you mind moving spi_cs_is_valid() to arch/xx/include/asm/mach-xxx/spi.h? Because the number of spi controllers and the cs number of each controller might be different for different board. It use macros to do this before, while it's more difficult as boards become more. Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot, fsl_espi.c driver
Ping?
Joakim Tjernlund/Transmode wrote on 2014/10/29 19:43:14:
mingkai...@freescale.com mingkai...@freescale.com wrote on
2014/10/28 12:17:24:
Hi Joakim and York,
Hi yourself, been travelling or a few days.
I apologize for the delayed response and thanks for your catch up,
Joakim
In order to get a higher transfer speed, the eSPI controller was
designed to transfer multiple bytes at one transaction which is not comply
with the SPI framework and the CS can't be inactive until one transfer
finished, so we need to combine the multiple transfers into one transfer,
that's the reason why there are more memory copy back and forth.
hmm, can't make sense of this. If you can memcpy from/to memory you can
also write/read the SPI FIFO
Also writing 4 bytes to the SPI FIFO at a time will not but you much if
anything at all. It just
makes it impossible to use NF flag etc.
Speed will come from keeping the SPI FIFO non empty and not copying
memory back and fourth.
CS can be controlled within the SPI framework already.
The driver has been tested on SPI flash and the transfer length larger
than max_trans_len should be handled but half-duplex
was not handled. Is it possible to provide patch to make it workable for
different devices?
Not as the driver is written today.
0x0b is the FAST READ command. The logic here is to move the pointer
of receive buffer to receive new data when reading from NOR flash and the
reading length is larger than the max_trans_len.
What FAST READ command? Sounds like it is connected to the FLASH rather
than SPI? if so that
need to go from the SPI driver and moved into some board specific addon.
Thanks,
Mingkai
From: Sun York-R58495
Sent: Thursday, October 23, 2014 6:14 AM
To: jagan Teki; Hu Mingkai-B21284
Cc: Joakim Tjernlund; Hou Zhiqiang-B48286; u-boot@lists.denx.de
Subject: Re: u-boot, fsl_espi.c driver
Jagan and Mingkai,
Would you take a look when you have a chance?
York
On 10/22/2014 03:12 PM, Joakim Tjernlund wrote:
York Sun york...@freescale.com wrote on 2014/10/09 20:06:31:
Dear Joakim,
On 10/09/2014 10:43 AM, Joakim Tjernlund wrote:
York Sun york...@freescale.com wrote on 2014/10/09 18:25:40:
Dear Joakim,
Thanks for raising a concern.
It's not fair to blame the last person who submitted a patch. We
are
all
working
No of course not, I just noticed you guys had been in there and
patched up
some problem
so I hoped you would be interested to fix the remaining problems.
This
driver should never
have been committed in the first place.
to make it better as an opensource comminuty. You have done a
good
job
to hack
it to work. Would it be nicer if you can submit this or improved
patch
to u-boot
community for further review and testing, after putting informing
commit
message? The mailing list address is CC'ed.
Main problem with this driver is that TX does not work for:
len max_tran_len (nor does RX)
does not TX the last odd bytes(len % 4 != 0)
Does not work with TX only(RX buf == NULL)
Silently ignores SPI_LSB_FIRST
On top of that it uses malloc all over and copies data back and
forth
for
no good
reason, image a big SPI transfer with many MB(like my FPGA load).
I am not in a good position fix this properly as my FPGA is TX
only so
I
cannot test
RX at all(which is broken by my hack)
Finally, just to illustrate the merits of this driver, after
transmission
is done
there is:
if (*buffer == 0x0b) {
data_in += tran_len;
data_len -= tran_len;
*(int *)buffer += tran_len;
}
what is the magic 0x0b test all about?
Thanks for the report. Driver maintainer (CC'ed) will take a look.
York
No reaction from maintainers, I don't think this driver is still
maintained.
Jocke
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MAINTAINERS: add me as a maintainer of UBI
On Tuesday, November 18, 2014, Stefan Roese s...@denx.de wrote: On 18.11.2014 09:08, Heiko Schocher wrote: Add me for UBI custodian. Signed-off-by: Heiko Schocher h...@denx.de Acked-by: Stefan Roese s...@denx.de Acked-by: Kyungmin Park kyungmin.p...@samsung.com Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] spl: if MMCSD_MODE_RAW fails, try MMCSD_MODE_FS, if available
In SPL MMC, boot modes are exclusive. So, if MMCSD_MODE_RAW fails, the board
hangs. This patch allows to
try MMCSD_MODE_FS then, if available.
It has been tested on a pandaboard (rev. A3).
Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr
Cc: Tom Rini tr...@ti.com
---
common/spl/spl_mmc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index ee71f79..2c34b75 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -101,7 +101,8 @@ void spl_mmc_load_image(void)
err = mmc_load_image_raw(mmc,
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR);
#if defined(CONFIG_SPL_FAT_SUPPORT) || defined(CONFIG_SPL_EXT_SUPPORT)
- } else if (boot_mode == MMCSD_MODE_FS) {
+ }
+ if (err || boot_mode == MMCSD_MODE_FS) {
debug(boot mode - FS\n);
#ifdef CONFIG_SPL_FAT_SUPPORT
#ifdef CONFIG_SPL_OS_BOOT
--
1.8.4.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 0/6] fs: fat/ext4/sandbox - Deal with files greater than 2GB
On Mon 2014-11-17 14:39:33, Suriyan Ramasami wrote: The commands fatls/ext4ls give negative values when dealing with files greater than 2GB. The commands fatsize/ext4size do not update the variable filesize for these files. To deal with this, the fs functions have been modified to take an additional parameter of type * loff_t which is then populated. The return value of th fs functions are used only for error conditions. I dislike additional parameters, but Simon want them, so what... Acked-by: Pavel Machek pa...@denx.de Changes in v8: - No changes. ... - None I don't think it is strictly neccessary to do change lists on the cover letter... And this one looks funny. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] .travis.yml: build u-boot on travis-ci
Hello,
Hi,
Am 14.11.2014 um 14:58 schrieb Roger Meier:
---
Changes for v2:
- use latest device tree compiler (suggested by Daniel Schwierzeck)
- add sandbox (suggested by Daniel Schwierzeck)
- seperate echo and execution of TEST_CMD
- remove BUILD_NCPUS( part of script)
- introduce ${TEST_CONFIG_CMD}
- add libsdl-dev package which is required by sandbox
- use buildman (suggested by Tom Rini)
- generate ~/.buildman
- split ppc into several jobs
- install gcc-arm-linux-gnueabihf
- use --inline-suppr option for cppcheck
Signed-off-by: Roger Meier r.me...@siemens.com
Cc: Wolfgang Denk w...@denx.de
Cc: Tom Rini tr...@ti.com
Cc: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
The Sob was probably meant to go before the first ---?
Yes, however patchworks detected the patch properly.
http://patchwork.ozlabs.org/patch/410846/
What I forgot to mention, here is the build result:
https://travis-ci.org/u-boot/u-boot/builds/41050962
Best!
-roger
PS:
I've also contacted GitHub about the orphan u-boot account and I got it.
So we can have a mirror on GitHub and use travis-ci as a build system.
Here is this patch: https://github.com/u-boot/u-boot/tree/travis2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mxssb: Makefile: build with optimisation (-O2) by default
Signed-off-by: Marc Kleine-Budde m...@pengutronix.de --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index a8dbea3a861b..af3deb920785 100644 --- a/Makefile +++ b/Makefile @@ -1,4 +1,4 @@ -CFLAGS=`pkg-config --cflags libcrypto` -Wall -Wextra +CFLAGS=`pkg-config --cflags libcrypto` -Wall -Wextra -O2 LDFLAGS=`pkg-config --libs libcrypto` mxssb: mxssb.c -- 2.1.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] mxssb: fix uninitialized variables warnings
These warning are generated by: gcc version 4.9.1 (Debian 4.9.1-19)
mxssb.c: In function ‘main’:
mxssb.c:1580:10: warning: ‘ilen’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
ret = sb_build_dcd_block(ictx, cmd, SB_DCD_CHK_EQ | ilen);
^
mxssb.c:1553:12: note: ‘ilen’ was declared here
uint32_t ilen;
^
mxssb.c:1556:28: warning: ‘rptr’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
if (!tok || (strlen(tok) == 0) || (lptr strlen(lptr) != 1)) {
^
mxssb.c:1495:8: note: ‘rptr’ was declared here
char *rptr;
^
Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
---
mxssb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mxssb.c b/mxssb.c
index 14826e7bf84c..3a4c32cf47c9 100644
--- a/mxssb.c
+++ b/mxssb.c
@@ -1492,7 +1492,7 @@ static int sb_parse_line(struct sb_image_ctx *ictx,
struct sb_cmd_list *cmd)
{
char *tok;
char *line = cmd-cmd;
- char *rptr;
+ char *rptr = NULL;
int ret;
/* Analyze the identifier on this line first. */
@@ -1550,7 +1550,7 @@ static int sb_parse_line(struct sb_image_ctx *ictx,
struct sb_cmd_list *cmd)
}
} else if (ictx-in_dcd) {
char *lptr;
- uint32_t ilen;
+ uint32_t ilen = 0;
tok = strtok_r(tok, ., lptr);
if (!tok || (strlen(tok) == 0) || (lptr strlen(lptr) != 1)) {
--
2.1.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] mxssb: trivial fixes
Hey, this is a trivial patch series for the mxssb tool. Please review and apply. regards, Marc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 1/3] arm, am335x, siemens: fix factoryset interpretation
a record could contain other records, so after an (begin mark)
there not always come an end mark , instead a is possible.
Take care of this.
Signed-off-by: Heiko Schocher h...@denx.de
---
board/siemens/common/factoryset.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/board/siemens/common/factoryset.c
b/board/siemens/common/factoryset.c
index 266dbbb..d98e59d 100644
--- a/board/siemens/common/factoryset.c
+++ b/board/siemens/common/factoryset.c
@@ -86,6 +86,7 @@ int get_factory_record_val(unsigned char *eeprom_buf, int
size, uchar *record,
int i, nxt = 0;
int c;
unsigned char end = 0xff;
+ unsigned char tmp;
for (i = 0; fact_get_char(i) != end; i = nxt) {
nxt = i + 1;
@@ -93,6 +94,7 @@ int get_factory_record_val(unsigned char *eeprom_buf, int
size, uchar *record,
int pos;
int endpos;
int z;
+ int level = 0;
c = strncmp((char *)eeprom_buf[i + 1], (char *)record,
strlen((char *)record));
@@ -103,22 +105,30 @@ int get_factory_record_val(unsigned char *eeprom_buf, int
size, uchar *record,
/* search for */
c = -1;
for (z = pos; fact_get_char(z) != end; z++) {
- if ((fact_get_char(z) == '') ||
- (fact_get_char(z) == '')) {
- endpos = z;
- nxt = endpos;
- c = 0;
- break;
+ if (fact_get_char(z) == '') {
+ if (level == 0) {
+ endpos = z;
+ nxt = endpos;
+ c = 0;
+ break;
+ } else {
+ level--;
+ }
}
+ if (fact_get_char(z) == '')
+ level++;
}
+ } else {
+ continue;
}
if (c == 0) {
/* end found - call get_factory_val */
+ tmp = eeprom_buf[endpos];
eeprom_buf[endpos] = end;
ret = get_factory_val(eeprom_buf[pos],
- size - pos, name, buf, len);
+ endpos - pos, name, buf, len);
/* fix buffer */
- eeprom_buf[endpos] = '';
+ eeprom_buf[endpos] = tmp;
debug(%s: %s.%s = %s\n,
__func__, record, name, buf);
return ret;
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 3/3] arm, am335x: siemens boards add FIT support
add FIT support and set boardid from factoryset records
DEV/id and COMP/ver. boardid is used for selecting
which fit configuration gets booted on the board.
Signed-off-by: Heiko Schocher h...@denx.de
---
board/siemens/common/board.c | 9 -
board/siemens/common/factoryset.c | 18 --
board/siemens/common/factoryset.h | 1 +
board/siemens/draco/board.c | 9 +
board/siemens/pxm2/board.c| 34 ++
board/siemens/rut/board.c | 23 +++
include/configs/pxm2.h| 4
include/configs/rut.h | 4
8 files changed, 83 insertions(+), 19 deletions(-)
diff --git a/board/siemens/common/board.c b/board/siemens/common/board.c
index 2782bcc..cc0ac6b 100644
--- a/board/siemens/common/board.c
+++ b/board/siemens/common/board.c
@@ -96,15 +96,6 @@ const struct dpll_params *get_dpll_ddr_params(void)
return dpll_ddr;
}
-#ifdef CONFIG_BOARD_LATE_INIT
-int board_late_init(void)
-{
- omap_nand_switch_ecc(1, 8);
-
- return 0;
-}
-#endif
-
#ifndef CONFIG_SPL_BUILD
#if defined(BOARD_DFU_BUTTON_GPIO)
/*
diff --git a/board/siemens/common/factoryset.c
b/board/siemens/common/factoryset.c
index be0091d..7baac3d 100644
--- a/board/siemens/common/factoryset.c
+++ b/board/siemens/common/factoryset.c
@@ -220,15 +220,6 @@ int factoryset_read_eeprom(int i2c_addr)
printf(DFU USB: VID = 0x%4x, PID = 0x%4x\n, factory_dat.usb_vendor_id,
factory_dat.usb_product_id);
#endif
- if (0 = get_factory_record_val(cp, size, (uchar *)DEV,
- (uchar *)id, buf,
- MAX_STRING_LENGTH)) {
- if (strncmp((const char *)buf, PXM50, 5) == 0)
- factory_dat.pxm50 = 1;
- else
- factory_dat.pxm50 = 0;
- }
- debug(PXM50: %d\n, factory_dat.pxm50);
#if defined(CONFIG_VIDEO)
if (0 = get_factory_record_val(cp, size, (uchar *)DISP1,
(uchar *)name, factory_dat.disp_name,
@@ -248,7 +239,14 @@ int factoryset_read_eeprom(int i2c_addr)
NULL, 16);
debug(version number: %d\n, factory_dat.version);
}
-
+ /* Get ASN from factory set if available */
+ if (0 = get_factory_record_val(cp, size, (uchar *)DEV,
+ (uchar *)id, factory_dat.asn,
+ MAX_STRING_LENGTH)) {
+ debug(factoryset asn: %s\n, factory_dat.asn);
+ } else {
+ factory_dat.asn[0] = 0;
+ }
/* Get COMP/ver from factory set if available */
if (0 = get_factory_record_val(cp, size, (uchar *)COMP,
(uchar *)ver,
diff --git a/board/siemens/common/factoryset.h
b/board/siemens/common/factoryset.h
index 7667b96..3f23d5e 100644
--- a/board/siemens/common/factoryset.h
+++ b/board/siemens/common/factoryset.h
@@ -20,6 +20,7 @@ struct factorysetcontainer {
#endif
unsigned char serial[MAX_STRING_LENGTH];
int version;
+ uchar asn[MAX_STRING_LENGTH];
uchar comp_version[MAX_STRING_LENGTH];
};
diff --git a/board/siemens/draco/board.c b/board/siemens/draco/board.c
index 9be2e34..ede73ba 100644
--- a/board/siemens/draco/board.c
+++ b/board/siemens/draco/board.c
@@ -280,4 +280,13 @@ U_BOOT_CMD(
#endif /* #if defined(CONFIG_DRIVER_TI_CPSW) */
#endif /* #if (defined(CONFIG_DRIVER_TI_CPSW) !defined(CONFIG_SPL_BUILD)) */
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ omap_nand_switch_ecc(1, 8);
+
+ return 0;
+}
+#endif
+
#include ../common/board.c
diff --git a/board/siemens/pxm2/board.c b/board/siemens/pxm2/board.c
index 559af0e..264ba02 100644
--- a/board/siemens/pxm2/board.c
+++ b/board/siemens/pxm2/board.c
@@ -428,4 +428,38 @@ static int board_video_init(void)
return 0;
}
#endif
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ int ret;
+
+ omap_nand_switch_ecc(1, 8);
+
+#ifdef CONFIG_FACTORYSET
+ if (factory_dat.asn[0] != 0) {
+ char tmp[2 * MAX_STRING_LENGTH + 2];
+
+ if (strncmp((const char *)factory_dat.asn, PXM50, 5) == 0)
+ factory_dat.pxm50 = 1;
+ else
+ factory_dat.pxm50 = 0;
+ sprintf(tmp, %s_%s, factory_dat.asn,
+ factory_dat.comp_version);
+ ret = setenv(boardid, tmp);
+ if (ret)
+ printf(error setting board id\n);
+ } else {
+ factory_dat.pxm50 = 1;
+ ret = setenv(boardid, PXM50_1.0);
+ if (ret)
+ printf(error setting board id\n);
+ }
+ debug(PXM50: %d\n, factory_dat.pxm50);
+#endif
+
+ return 0;
+}
+#endif
+
[U-Boot] [PATCH v1 2/3] arm, am335x, siemens: read COMP/ver from factoryset
Signed-off-by: Heiko Schocher h...@denx.de
---
board/siemens/common/factoryset.c | 10 ++
board/siemens/common/factoryset.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/board/siemens/common/factoryset.c
b/board/siemens/common/factoryset.c
index d98e59d..be0091d 100644
--- a/board/siemens/common/factoryset.c
+++ b/board/siemens/common/factoryset.c
@@ -249,6 +249,16 @@ int factoryset_read_eeprom(int i2c_addr)
debug(version number: %d\n, factory_dat.version);
}
+ /* Get COMP/ver from factory set if available */
+ if (0 = get_factory_record_val(cp, size, (uchar *)COMP,
+ (uchar *)ver,
+ factory_dat.comp_version,
+ MAX_STRING_LENGTH)) {
+ debug(factoryset COMP/ver: %s\n, factory_dat.comp_version);
+ } else {
+ strcpy((char *)factory_dat.comp_version, 1.0);
+ }
+
return 0;
err:
diff --git a/board/siemens/common/factoryset.h
b/board/siemens/common/factoryset.h
index 4d6de10..7667b96 100644
--- a/board/siemens/common/factoryset.h
+++ b/board/siemens/common/factoryset.h
@@ -20,6 +20,7 @@ struct factorysetcontainer {
#endif
unsigned char serial[MAX_STRING_LENGTH];
int version;
+ uchar comp_version[MAX_STRING_LENGTH];
};
int factoryset_read_eeprom(int i2c_addr);
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 0/3] arm, am335x: siemens board updates
This series contains some updates for the am335x based boards from siemens. - Patch: arm, am335x, siemens: fix factoryset interpretation fixes an error in the siemens factoryset implementation - Patch: arm, am335x, siemens: read COMP/ver from factoryset reads also the COMP/ver value from the siemens factoryset - Patch: arm, am335x: siemens boards add FIT support - adds FIT support as we now boot kernels with DT - create a u-boot envvariable boardid which is used for selecting the DT from the FIT image. Heiko Schocher (3): arm, am335x, siemens: fix factoryset interpretation arm, am335x, siemens: read COMP/ver from factoryset arm, am335x: siemens boards add FIT support board/siemens/common/board.c | 9 --- board/siemens/common/factoryset.c | 52 ++- board/siemens/common/factoryset.h | 2 ++ board/siemens/draco/board.c | 9 +++ board/siemens/pxm2/board.c| 34 + board/siemens/rut/board.c | 23 + include/configs/pxm2.h| 4 +++ include/configs/rut.h | 4 +++ 8 files changed, 111 insertions(+), 26 deletions(-) -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] arm, at91: corvus board updates
- corvus board fix problems with toshiba nand chips on the corvus board problems with toshiba chips Manufacturer ID: 0x98 Chip ID: 0xdc encounterd. Solve this in the following way: - set other nand timings - enable CONFIG_SYS_NAND_READY_PIN - correct the MACH_TYPE setting Signed-off-by: Heiko Schocher h...@denx.de --- board/siemens/corvus/board.c | 12 +++- include/configs/corvus.h | 4 ++-- 2 files changed, 9 insertions(+), 7 deletions(-) diff --git a/board/siemens/corvus/board.c b/board/siemens/corvus/board.c index 0a11540..f3f6dae 100644 --- a/board/siemens/corvus/board.c +++ b/board/siemens/corvus/board.c @@ -43,13 +43,13 @@ static void corvus_nand_hw_init(void) writel(csa, matrix-ebicsa); /* Configure SMC CS3 for NAND/SmartMedia */ - writel(AT91_SMC_SETUP_NWE(1) | AT91_SMC_SETUP_NCS_WR(0) | - AT91_SMC_SETUP_NRD(1) | AT91_SMC_SETUP_NCS_RD(0), + writel(AT91_SMC_SETUP_NWE(2) | AT91_SMC_SETUP_NCS_WR(0) | + AT91_SMC_SETUP_NRD(2) | AT91_SMC_SETUP_NCS_RD(0), smc-cs[3].setup); - writel(AT91_SMC_PULSE_NWE(4) | AT91_SMC_PULSE_NCS_WR(3) | - AT91_SMC_PULSE_NRD(3) | AT91_SMC_PULSE_NCS_RD(2), + writel(AT91_SMC_PULSE_NWE(4) | AT91_SMC_PULSE_NCS_WR(4) | + AT91_SMC_PULSE_NRD(4) | AT91_SMC_PULSE_NCS_RD(4), smc-cs[3].pulse); - writel(AT91_SMC_CYCLE_NWE(7) | AT91_SMC_CYCLE_NRD(4), + writel(AT91_SMC_CYCLE_NWE(7) | AT91_SMC_CYCLE_NRD(7), smc-cs[3].cycle); writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE | AT91_SMC_MODE_EXNW_DISABLE | @@ -62,9 +62,11 @@ static void corvus_nand_hw_init(void) smc-cs[3].mode); at91_periph_clk_enable(ATMEL_ID_PIOC); + at91_periph_clk_enable(ATMEL_ID_PIOA); /* Enable NandFlash */ at91_set_gpio_output(CONFIG_SYS_NAND_ENABLE_PIN, 1); + at91_set_gpio_input(CONFIG_SYS_NAND_READY_PIN, 1); } #if defined(CONFIG_SPL_BUILD) diff --git a/include/configs/corvus.h b/include/configs/corvus.h index 5b50c1d..ace511f 100644 --- a/include/configs/corvus.h +++ b/include/configs/corvus.h @@ -18,6 +18,7 @@ #define MACH_TYPE_CORVUS 2066 +#define CONFIG_MACH_TYPE MACH_TYPE_CORVUS #define CONFIG_SYS_GENERIC_BOARD /* * Warning: changing CONFIG_SYS_TEXT_BASE requires @@ -106,6 +107,7 @@ /* our CLE is AD22 */ #define CONFIG_SYS_NAND_MASK_CLE (1 22) #define CONFIG_SYS_NAND_ENABLE_PIN AT91_PIN_PC14 +#define CONFIG_SYS_NAND_READY_PIN AT91_PIN_PC8 #endif /* Ethernet */ @@ -171,7 +173,6 @@ #define CONFIG_SPL_BOARD_INIT #define CONFIG_SPL_GPIO_SUPPORT -#define CONFIG_SYS_NAND_ENABLE_PIN_SPL (2*32 + 14) #define CONFIG_SPL_NAND_SUPPORT #define CONFIG_SPL_NAND_DRIVERS #define CONFIG_SPL_NAND_BASE @@ -184,7 +185,6 @@ #define CONFIG_SYS_NAND_U_BOOT_DST CONFIG_SYS_TEXT_BASE #define CONFIG_SYS_NAND_5_ADDR_CYCLE -#define CONFIG_SYS_NAND_SIZE (256*1024*1024) #define CONFIG_SYS_NAND_PAGE_SIZE 2048 #define CONFIG_SYS_NAND_BLOCK_SIZE (128*1024) #define CONFIG_SYS_NAND_PAGE_COUNT (CONFIG_SYS_NAND_BLOCK_SIZE / \ -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] arm, at91, axm: add SPL support for axm
add SPL support also for the axm board. Signed-off-by: Heiko Schocher h...@denx.de --- configs/axm_defconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/configs/axm_defconfig b/configs/axm_defconfig index c0e8da2..076ad0f 100644 --- a/configs/axm_defconfig +++ b/configs/axm_defconfig @@ -1,3 +1,4 @@ +CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=AT91SAM9G20,MACH_TYPE=2068,BOARD_AXM -CONFIG_ARM=y -CONFIG_TARGET_TAURUS=y ++S:CONFIG_ARM=y ++S:CONFIG_TARGET_TAURUS=y -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] arm: odroid: usb: add support for usb host including ethernet
Hello Suriyan, On 11/18/2014 04:30 AM, Suriyan Ramasami wrote: Hello Minkyu Kang/Przemyslaw and of course anyone else who can direct me, Thanks for the commit. I just realized that the code in this particular patch is missing the gpio_request() call before calling the gpio_direction_output() call, and hence fails to initialize the USB3503A hub. This was pointed out by Przemyslaw in another patch of mine (odroid: blue LED) So, my question is, this patch is in u-boot-samsung. To correct the above mentioned error, do I submit a patch directed to u-boot-samsung? If so how do I do it? I mean, do I elaborate this in the subject /.body of the mail? Thanks and regards, - Suriyan Yes, the gpio_request() was missed in your code - it prints errors about it but the HUB works fine. So when you send the fixed version this should be okay. Please check ums command before send. Please also check setting buck value at function board_usb_init(), the buck is disabled and before enable - the value changes two times - probably by mistake. And the gpio_request(...) you can put into board_gpio_init - request gpio only one. The odroid is available on the market, so I would prefer keep some documentation in the doc/README.odroid. Could you please add short section about the USB usage in U-Boot? This would be useful. On Mon, Nov 17, 2014 at 6:02 AM, Minkyu Kang mk7.k...@samsung.com wrote: On 30/10/14 01:22, Suriyan Ramasami wrote: This change adds support for enabling the USB host features of the board. This includes the USB3503A hub and the SMC LAN9730 ethernet controller as well. Signed-off-by: Suriyan Ramasami suriya...@gmail.com --- Changes in v3: * removed set_usb_ethaddr() and related code as the GUID registers do not seem to be documented anywhere. This is sad, as this mechanism allows for each Odroid to boot up with the same MAC address every time, but no two odroids shall have the same MAC address on boot. This ensures multiple odroids in the same LAN to come up without conflicting MAC addresses. * Minkyu - Do not mix cpu_is... and proid_is... Changes in v2: * Jaehoon - Split power.[ch] as a separate patch * Removed an unneeded header file from ehci-exynos.c * Jaehoon - Fix indentation in the dts file Changes in v1: * First try arch/arm/dts/exynos4412-odroid.dts | 11 +++ arch/arm/include/asm/arch-exynos/ehci.h | 13 board/samsung/odroid/odroid.c | 32 +++ drivers/usb/host/ehci-exynos.c | 55 - include/configs/odroid.h| 13 5 files changed, 116 insertions(+), 8 deletions(-) applied to u-boot-samsung. Thanks, Minkyu Kang. Best regards, -- Przemyslaw Marczak Samsung RD Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] arm: odroid: usb: add support for usb host including ethernet
Dear Minkyu, On 11/18/2014 09:14 AM, Minkyu Kang wrote: Hi, On 18/11/14 12:30, Suriyan Ramasami wrote: Hello Minkyu Kang/Przemyslaw and of course anyone else who can direct me, Thanks for the commit. I just realized that the code in this particular patch is missing the gpio_request() call before calling the gpio_direction_output() call, and hence fails to initialize the USB3503A hub. This was pointed out by Przemyslaw in another patch of mine (odroid: blue LED) So, my question is, this patch is in u-boot-samsung. To correct the above mentioned error, do I submit a patch directed to u-boot-samsung? Yes. Please send new patch. If so how do I do it? I mean, do I elaborate this in the subject /.body of the mail? sorry, I can't catch the point of your question. Thanks and regards, - Suriyan Thanks, Minkyu Kang. Could you please wait for the test/ack next time before you merge the patches to the tree? It will prevent before making an additional work on testing or fixing some code. Best regards, -- Przemyslaw Marczak Samsung RD Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/2] fdt_support: Add a fdt_setup_simplefb_node helper function
Hi Simon, On 11/17/2014 07:32 PM, Simon Glass wrote: Hi Hans, On 17 November 2014 15:48, Hans de Goede hdego...@redhat.com wrote: Add a generic helper to fill and enable simplefb nodes. The first user of this will be the sunxi display code. lcd_dt_simplefb_configure_node is also a good candidate to be converted to use this, but that requires someone to run some tests first, as lcd_dt_simplefb_configure_node does not honor #address-cells and #size-cells, but simply assumes 1 and 1 for both. Signed-off-by: Hans de Goede hdego...@redhat.com --- common/fdt_support.c | 65 +++ include/fdt_support.h | 3 +++ 2 files changed, 68 insertions(+) diff --git a/common/fdt_support.c b/common/fdt_support.c index 3f64156..0ffa711 100644 --- a/common/fdt_support.c +++ b/common/fdt_support.c @@ -1523,3 +1523,68 @@ int fdt_read_range(void *fdt, int node, int n, uint64_t *child_addr, return 0; } + +/** + * fdt_setup_simplefb_node - Fill and enable a simplefb node + * + * @fdt: ptr to device tree + * @node: offset of the simplefb node + * @base_address: framebuffer base address + * @width: width in pixels + * @height: height in pixels + * @stride: bytes per line + * @format: pixel format string + * + * Convenience function to fill and enable a simplefb node. + */ +int fdt_setup_simplefb_node(void *fdt, int node, u64 base_address, u32 width, + u32 height, u32 stride, const char *format) Please see lcd_dt_simplefb_configure_node() which seems similar. As mentioned in the commit message already :) lcd_dt_simplefb_configure_node() should be made to use this new helper function eventually. There are several reasons why lcd_dt_simplefb_configure_node() is not usable as a generic helper, and this new function is necessary: 1) It is lcd specific, only available if CONFIG_LCD is set 2) It does not take width / height / stride parameters, instead it reads global variables from lcd.c which are only set if the other common/lcd.c functions are used. 3) It hardcodes the format 4) It does not properly handle #address-cells and #size-cells 4) Is the main reason why I've not included a patch in my patch-set to move lcd_dt_simplefb_configure_node() over to use this new helper, as I'm afraid that may break things. of_bus_default_count_cells() will return different values then the 1/1 the current lcd code assumes when no #address-cells or #size-cells are present in the parent. So my plan is to add this new helper, use it for sunxi, and ask someone who has a board which is using lcd.c + simplefb to test moving lcd.c over to the new helper. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] sunxi: video: Add simplefb support
Hi,
On 11/17/2014 07:39 PM, Simon Glass wrote:
Hi Hans,
On 17 November 2014 15:48, Hans de Goede hdego...@redhat.com wrote:
From: Luc Verhaegen l...@skynet.be
Add simplefb support, note this depends on the kernel having support for
the clocks property which has recently been added to the simplefb devicetree
binding.
Signed-off-by: Luc Verhaegen l...@skynet.be
[hdego...@redhat.com: Use pre-populated simplefb node under /chosen as
disussed on the devicetree list]
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/include/asm/arch-sunxi/display.h | 4
board/sunxi/board.c | 11 +
drivers/video/sunxi_display.c | 39
+++
include/configs/sunxi-common.h| 8 +++
4 files changed, 62 insertions(+)
diff --git a/arch/arm/include/asm/arch-sunxi/display.h
b/arch/arm/include/asm/arch-sunxi/display.h
index 8d80ceb..4c694f8 100644
--- a/arch/arm/include/asm/arch-sunxi/display.h
+++ b/arch/arm/include/asm/arch-sunxi/display.h
@@ -195,4 +195,8 @@ struct sunxi_hdmi_reg {
#define SUNXI_HDMI_PLL_DBG0_PLL3 (0 21)
#define SUNXI_HDMI_PLL_DBG0_PLL7 (1 21)
+#ifdef CONFIG_VIDEO_DT_SIMPLEFB
+void sunxi_simplefb_setup(void *blob);
+#endif
+
#endif /* _SUNXI_DISPLAY_H */
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index e6ec5b8..d4530e8 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -24,6 +24,7 @@
#endif
#include asm/arch/clock.h
#include asm/arch/cpu.h
+#include asm/arch/display.h
#include asm/arch/dram.h
#include asm/arch/gpio.h
#include asm/arch/mmc.h
@@ -237,3 +238,13 @@ int misc_init_r(void)
return 0;
}
#endif
+
+#ifdef CONFIG_OF_BOARD_SETUP
+void
+ft_board_setup(void *blob, bd_t *bd)
+{
+#ifdef CONFIG_VIDEO_DT_SIMPLEFB
+ sunxi_simplefb_setup(blob);
+#endif
+}
+#endif /* CONFIG_OF_BOARD_SETUP */
diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
index 3f46c31..74c4bd3 100644
--- a/drivers/video/sunxi_display.c
+++ b/drivers/video/sunxi_display.c
@@ -13,6 +13,8 @@
#include asm/arch/display.h
#include asm/global_data.h
#include asm/io.h
+#include fdtdec.h
+#include fdt_support.h
#include linux/fb.h
#include video_fb.h
@@ -416,3 +418,40 @@ video_hw_init(void)
return graphic_device;
}
+
+/*
+ * Simplefb support.
+ */
+#if defined(CONFIG_OF_BOARD_SETUP) defined(CONFIG_VIDEO_DT_SIMPLEFB)
+void
+sunxi_simplefb_setup(void *blob)
+{
+ static GraphicDevice *graphic_device = sunxi_display.graphic_device;
+ int offset, ret;
+
+ if (!sunxi_display.enabled)
+ return;
return -ENOENT?
If people want this, I can change the proto to an int and make
sunxi_simplefb_setup
return error codes as you suggest, but this function gets called from
ft_board_setup which is void itself, so there is no where to propagate the
error,
and more-over we do not want simplefb setup errors to be treated as fatal, so
I see little use in having it return error codes.
+
+ /* Find a framebuffer node, with pipeline == de_be0-lcd0-hdmi */
+ offset = fdt_node_offset_by_compatible(blob, -1,
sunxi,framebuffer);
These should convert to DM at some point. To make sure we don't forget
any, you should add this compatible string to fdtdec.c and use the
enum from fdtdec.h and also fdtdec_next_compatible().
Most sunxi boards do not set CONFIG_OF_CONTROL, so the ftddec functions are
not available.
+ while (offset = 0) {
+ ret = fdt_find_string(blob, offset, sunxi,pipeline,
+ de_be0-lcd0-hdmi);
+ if (ret == 0)
+ break;
+ offset = fdt_node_offset_by_compatible(blob, offset,
+ sunxi,framebuffer);
+ }
+ if (offset 0) {
+ eprintf(Cannot setup simplefb: node not found\n);
+ return;
return -ENODEV?
+ }
+
+ ret = fdt_setup_simplefb_node(blob, offset, gd-fb_base,
+ graphic_device-winSizeX, graphic_device-winSizeY,
+ graphic_device-winSizeX *
graphic_device-gdfBytesPP,
+ x8r8g8b8);
+ if (ret 0)
+ eprintf(Cannot setup simplefb: Error setting properties\n);
Can we return the error here? Maybe -EPERM or something like that.
+}
+#endif /* CONFIG_OF_BOARD_SETUP CONFIG_VIDEO_DT_SIMPLEFB */
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 900ef52..d5d907b 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -204,6 +204,9 @@
*/
#define CONFIG_SUNXI_FB_SIZE (8 20)
+/* Do we want to initialize a simple FB? */
+#define CONFIG_VIDEO_DT_SIMPLEFB
+
#define CONFIG_VIDEO_SUNXI
#define CONFIG_CFB_CONSOLE
@@ -217,6 +220,11 @@
Re: [U-Boot] [PATCH v2] odroid: Turn blue LED on
Hello Suriyan, On 11/18/2014 12:50 AM, Suriyan Ramasami wrote: To indicate that U-Boot is active, turn on the blue LED. Signed-off-by: Suriyan Ramasami suriya...@gmail.com --- Changes in v2: - Przemyslaw Marczak, Add gpio_request call. Changes in v1: - First try board/samsung/odroid/odroid.c | 5 + 1 file changed, 5 insertions(+) diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c index 33003ee..e1a86f9 100644 --- a/board/samsung/odroid/odroid.c +++ b/board/samsung/odroid/odroid.c @@ -382,6 +382,11 @@ static void board_gpio_init(void) gpio_set_pull(EXYNOS4X12_GPIO_X31, S5P_GPIO_PULL_UP); gpio_set_drv(EXYNOS4X12_GPIO_X31, S5P_GPIO_DRV_4X); gpio_direction_input(EXYNOS4X12_GPIO_X31); + + /* Blue LED (Odroid X2/U2/U3) */ + gpio_request(EXYNOS4X12_GPIO_C10, Blue LED); + + gpio_direction_output(EXYNOS4X12_GPIO_C10, 0); } static int pmic_init_max77686(void) Acked-by: Przemyslaw Marczak p.marc...@samsung.com Best regards, -- Przemyslaw Marczak Samsung RD Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] sun6i: Make dram clk and zq value Kconfig options
Hi, On 11/17/2014 07:54 PM, Ian Campbell wrote: On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote: +config DRAM_ZQ +int sun6i dram zq value if EXPERT +default 123 == 0x7b, which differs from the previous default of 0x78 (not by much, but still) Right, this is deliberate as I've gotten access to more boards, 123 seems a better default (this is also what most A10 / A13 / A20 boards use). diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig index bef568d..5e245a3 100644 --- a/configs/Colombus_defconfig +++ b/configs/Colombus_defconfig @@ -4,3 +4,5 @@ CONFIG_FDTFILE=sun6i-a31-colombus.dtb +S:CONFIG_ARCH_SUNXI=y +S:CONFIG_MACH_SUN6I=y +S:CONFIG_TARGET_COLOMBUS=y ++S:CONFIG_DRAM_CLK=288 ++S:CONFIG_DRAM_ZQ=379 Do these actually take affect if CONFIG_EXPERT=n? Ugh, I just checked, and no they don't. Perhaps CONFIG_TARGET_COLOMBUS should select DRAM_CLK == 288 and DRAM_CLK should be a hidden option? I would prefer to keep these inside the defconfig's so that for adding a new board only a defconfig needs to be added. Currently the only CONFIG_TARGET_BOARD we actually use in u-boot is the bananapi gmac tx clk delay tweak, and I would actually like to keep things that way. Actually thinking more about this, I think that that should be turned into a GMAC specific Kconfig option and all the CONFIG_TARGET_BOARD stuff should be dropped, as it is just a drag causing extra maintenance going forward. So is there a way to not show a choice to the user unless EXPERT mode is set, and still override it from Kconfig ? If that is not (easily) possible, then I guess we will just need to not make these if EXPERT. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 2/3] Odroid-XU3: Add support for Odroid-XU3
Hello, On 11/18/2014 02:57 AM, Hyungwon Hwang wrote: Dear Przemyslaw Marczak, +/* + * FIXME: The number of bank is actually 8. But there is no way to reserver the + * last 16 Mib in the last bank now. So I just excluded the last bank + * temporally. + */ It's not prober solution, since non-dt kernel could get wrong DRAM size. Please look at board/samsung/odroid/odroid.c - into function exynos_init(). The Odroid U3 has reserved the last 1MB of the last DRAM bank. I agree. It is a temporary solution, and it must be fixed soon. I see the exynos_init() function and adapt the method to fix the problem in Odroid XU3. But it did not work. Figuring out what is wrong, I found that the 2 lines of code in the exynos_init() to reserve the last 1MB does not affect the behavior of Odroid U3. Even after I commented out the codes, it works well. Is it a effective solution to reserve the memory? Is there anything else which I am missing? I really appreciate for your comment. Thanks. Best regards, Hyungwon Hwang. Yes, I also checked now, that this doesn't work for your board. On Odroid U3, there was a problem in the kernel - so dram size passed to the kernel is decreased by 1MB. It don't make a difference for the U-Boot if you don't touch this memory. I can suppose that it depends on secure firmware. If you plan to fix it in the future, then it's ok. In other way it will require some modification of board/samsung/common/board.c dram code. You can leave it as it is, since I plan to send some patches from tizen.org for exynos ram init. And it probably will fix this issue - if dts has decreased last bank size with the 16MiB. Best regards, -- Przemyslaw Marczak Samsung RD Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 1/3] exynos5: fix GPIO information of exynos5420
Hello,
On 11/18/2014 03:29 AM, Hyungwon Hwang wrote:
Thanks for your reviews. I did not know that the code from Simon Glass
is merged. I will remove this patch will be removed from the next
version.
Thanks.
Best regards,
Hyungwon Hwang
On Mon, 17 Nov 2014 10:51:21 +0100
Przemyslaw Marczak p.marc...@samsung.com wrote:
Hello,
Hyungwon, please check my last changes added to those files:
- arch/arm/include/asm/arch-exynos/gpio.h
(Exynos4x12 gpio enum and exynos4x12_gpio_data.)
- arch/arm/include/asm/arch-exynos/cpu.h
(Exynos4x12 gpio base sub parts)
There was an issue with gaps between some of gpio banks, so I added
sub parts definition and it was adequate to *pinctrl.dts and
*pinctrl-uboot.dts description.
First problem is, that device-tree description has some specified
order
- and this is the init order (and next real gpio numbering order).
So if we have dts nodes like this:
- pinctrl@1340 { }
- pinctrl@1341 { }
- pinctrl@1400 { }
- ...
then it means, that gpio init should start from base 1340 - which
is gpy70 tor the E5422... But there is one thing, which should be
taken into account - #include exynos54xx-pinctrl-uboot.dtsi,
and actually the included file [...]uboot.dts, will define the gpio
init order as:
- pinctrl@1401 - gpa00, gpa10, ..., gph00
- pinctrl@1340 - gpy70, gpx00, ..., gpx30 (gpx0-reg=0xc00)
- pinctrl@1341 - gpc00, ..., gpy60
- pinctrl@1400 - gpe00, ..., gpj40
- pinctrl@0386 - gpz00
So, the above gpioXX bind order, should be equal to the enum
exynos5420_gpio_pin { }. This is important, because if you type:
ODROID-XU3 # gpio toggle gpy00
then you will get the a result:
gpio: pin gpy00 (gpio 160) value is 0
Take a notice that gpy00 == gpio 160, but you defined it as 0 in your
enum! So any call to the gpio inside the code, like this one:
gpio_set_value(EXYNOS5420_GPIO_Y70, 0);
like the pinmux do - will pass wrong gpio number to the function.
And if you are lucky - some gpio numbers could work fine:)
On 11/17/2014 08:45 AM, Simon Glass wrote:
Hi Hyungwon,
On 14 November 2014 06:25, Hyungwon Hwang human.hw...@samsung.com
wrote:
This patch fixes wrong GPIO information such as GPIO bank, table
which is used to convert GPIO name to index, bank base address,
and etc.
Signed-off-by: Hyungwon Hwang human.hw...@samsung.com
Tested-by: Lukasz Majewski l.majew...@samsung.com
Acked-by: Lukasz Majewski l.majew...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
---
Changes for v4:
- None
Changes for v5:
- None
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- None
arch/arm/include/asm/arch-exynos/cpu.h | 11 +-
arch/arm/include/asm/arch-exynos/gpio.h | 232
+++- 2 files changed, 117
insertions(+), 126 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/cpu.h
b/arch/arm/include/asm/arch-exynos/cpu.h index 29674ad..48936de
100644 --- a/arch/arm/include/asm/arch-exynos/cpu.h
+++ b/arch/arm/include/asm/arch-exynos/cpu.h
@@ -148,7 +148,7 @@
/* EXYNOS5420 */
#define EXYNOS5420_AUDIOSS_BASE0x0381
-#define EXYNOS5420_GPIO_PART6_BASE 0x0386
+#define EXYNOS5420_GPIO_PART5_BASE 0x0386
#define EXYNOS5420_PRO_ID 0x1000
#define EXYNOS5420_CLOCK_BASE 0x1001
#define EXYNOS5420_POWER_BASE 0x1004
@@ -170,11 +170,10 @@
#define EXYNOS5420_I2S_BASE0x12D6
#define EXYNOS5420_PWMTIMER_BASE 0x12DD
#define EXYNOS5420_SPI_ISP_BASE0x131A
-#define EXYNOS5420_GPIO_PART2_BASE 0x1340
-#define EXYNOS5420_GPIO_PART3_BASE 0x13400C00
-#define EXYNOS5420_GPIO_PART4_BASE 0x1341
-#define EXYNOS5420_GPIO_PART5_BASE 0x1400
-#define EXYNOS5420_GPIO_PART1_BASE 0x1401
+#define EXYNOS5420_GPIO_PART1_BASE 0x1340
+#define EXYNOS5420_GPIO_PART2_BASE 0x1341
+#define EXYNOS5420_GPIO_PART3_BASE 0x1400
+#define EXYNOS5420_GPIO_PART4_BASE 0x1401
#define EXYNOS5420_MIPI_DSIM_BASE 0x1450
#define EXYNOS5420_DP_BASE 0x145B
diff --git a/arch/arm/include/asm/arch-exynos/gpio.h
b/arch/arm/include/asm/arch-exynos/gpio.h index 9699954..aef897d
100644 --- a/arch/arm/include/asm/arch-exynos/gpio.h
+++ b/arch/arm/include/asm/arch-exynos/gpio.h
@@ -1042,83 +1042,7 @@ enum exynos5_gpio_pin {
};
enum exynos5420_gpio_pin {
- /* GPIO_PART1_STARTS */
- EXYNOS5420_GPIO_A00,/* 0 */
Why does this order need to change? I think you might be trying to
remove the device tree work-around that we currently have. See
arch/arm/dts/exynos54xx-pinctrl-uboot.dtsi:
/*
* Replicate the ordering of
arch/arm/include/asm/arch-exynos/gpio.h
* TODO(s...@chromium.org): This ordering ceases to matter
once GPIO
* numbers are not needed in U-Boot for exynos.
*/
pinctrl@1401 {
[U-Boot] [PATCH 2/4] tqma6: add missing include
From: Markus Niebel markus.nie...@tq-group.com Add include needed to have prototype for board_spi_cs_gpio Signed-off-by: Markus Niebel markus.nie...@tq-group.com --- board/tqc/tqma6/tqma6.c | 1 + 1 file changed, 1 insertion(+) diff --git a/board/tqc/tqma6/tqma6.c b/board/tqc/tqma6/tqma6.c index fd1bd59..5e913d7 100644 --- a/board/tqc/tqma6/tqma6.c +++ b/board/tqc/tqma6/tqma6.c @@ -17,6 +17,7 @@ #include asm/gpio.h #include asm/io.h #include asm/imx-common/mxc_i2c.h +#include asm/imx-common/spi.h #include common.h #include fsl_esdhc.h #include libfdt.h -- 2.1.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] tqma6: add warning on failed setup_i2c
From: Markus Niebel markus.nie...@tq-group.com
setup_i2c has a return value. Use it to give feedback
on error.
Signed-off-by: Markus Niebel markus.nie...@tq-group.com
---
board/tqc/tqma6/tqma6.c | 10 --
board/tqc/tqma6/tqma6_mba6.c | 10 --
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/board/tqc/tqma6/tqma6.c b/board/tqc/tqma6/tqma6.c
index 5e913d7..b7f4eb7 100644
--- a/board/tqc/tqma6/tqma6.c
+++ b/board/tqc/tqma6/tqma6.c
@@ -181,8 +181,14 @@ static struct i2c_pads_info tqma6_i2c3_pads = {
static void tqma6_setup_i2c(void)
{
- /* use logical index for bus, e.g. I2C1 - 0 */
- setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, tqma6_i2c3_pads);
+ int ret;
+ /*
+* use logical index for bus, e.g. I2C1 - 0
+* warn on error
+*/
+ ret = setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, tqma6_i2c3_pads);
+ if (ret)
+ printf(setup I2C3 failed: %d\n, ret);
}
int board_early_init_f(void)
diff --git a/board/tqc/tqma6/tqma6_mba6.c b/board/tqc/tqma6/tqma6_mba6.c
index fd59287..6f4cffd 100644
--- a/board/tqc/tqma6/tqma6_mba6.c
+++ b/board/tqc/tqma6/tqma6_mba6.c
@@ -224,8 +224,14 @@ static struct i2c_pads_info mba6_i2c1_pads = {
static void mba6_setup_i2c(void)
{
- /* use logical index for bus, e.g. I2C1 - 0 */
- setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, mba6_i2c1_pads);
+ int ret;
+ /*
+* use logical index for bus, e.g. I2C1 - 0
+* warn on error
+*/
+ ret = setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, mba6_i2c1_pads);
+ if (ret)
+ printf(setup I2C1 failed: %d\n, ret);
}
--
2.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RESEND PATCH 0/4] tqma6: improvements and cleanup
From: Markus Niebel markus.nie...@tq-group.com This series contains some cosmetic and code cleanups. No functional changes. resend because of typo in Mailaddress. Markus Niebel (4): tqma6: (cosmetic) remove CONFIG_FLASH_SECTOR_SIZE tqma6: add missing include tqma6: add warning on failed setup_i2c tqma6: use imx_ddr_size board/tqc/tqma6/tqma6.c | 13 ++--- board/tqc/tqma6/tqma6_mba6.c | 10 -- include/configs/tqma6.h | 28 ++-- 3 files changed, 32 insertions(+), 19 deletions(-) -- 2.1.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] tqma6: use imx_ddr_size
From: Markus Niebel markus.nie...@tq-group.com
Signed-off-by: Markus Niebel markus.nie...@tq-group.com
---
board/tqc/tqma6/tqma6.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/tqc/tqma6/tqma6.c b/board/tqc/tqma6/tqma6.c
index b7f4eb7..e480d57 100644
--- a/board/tqc/tqma6/tqma6.c
+++ b/board/tqc/tqma6/tqma6.c
@@ -51,7 +51,7 @@ DECLARE_GLOBAL_DATA_PTR;
int dram_init(void)
{
- gd-ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
+ gd-ram_size = imx_ddr_size();
return 0;
}
--
2.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] tqma6: (cosmetic) remove CONFIG_FLASH_SECTOR_SIZE
From: Markus Niebel markus.nie...@tq-group.com
This is nowhere documented and only used
by two other boards. Replace it with
TQMA6_SPI_FLASH_SECTOR_SIZE.
Signed-off-by: Markus Niebel markus.nie...@tq-group.com
---
include/configs/tqma6.h | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/include/configs/tqma6.h b/include/configs/tqma6.h
index c94eee1..a099687 100644
--- a/include/configs/tqma6.h
+++ b/include/configs/tqma6.h
@@ -68,6 +68,8 @@
#define CONFIG_SPI_FLASH
#define CONFIG_SPI_FLASH_STMICRO
+#define TQMA6_SPI_FLASH_SECTOR_SIZESZ_64K
+
#define CONFIG_CMD_SF
#define CONFIG_SF_DEFAULT_BUS 0
#define CONFIG_SF_DEFAULT_CS 0
@@ -275,12 +277,10 @@
#elif defined(CONFIG_TQMA6X_SPI_BOOT)
-#define CONFIG_FLASH_SECTOR_SIZE 0x1
-
#define TQMA6_UBOOT_OFFSET 0x400
#define TQMA6_UBOOT_SECTOR_START 0x0
/* max u-boot size: 512k */
-#define TQMA6_UBOOT_SECTOR_SIZECONFIG_FLASH_SECTOR_SIZE
+#define TQMA6_UBOOT_SECTOR_SIZETQMA6_SPI_FLASH_SECTOR_SIZE
#define TQMA6_UBOOT_SECTOR_COUNT 0x8
#define TQMA6_UBOOT_SIZE (TQMA6_UBOOT_SECTOR_SIZE * \
TQMA6_UBOOT_SECTOR_COUNT)
@@ -288,7 +288,7 @@
#define CONFIG_ENV_IS_IN_SPI_FLASH
#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
#define CONFIG_ENV_OFFSET (TQMA6_UBOOT_SIZE)
-#define CONFIG_ENV_SECT_SIZE CONFIG_FLASH_SECTOR_SIZE
+#define CONFIG_ENV_SECT_SIZE TQMA6_SPI_FLASH_SECTOR_SIZE
#define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + \
CONFIG_ENV_SECT_SIZE)
@@ -299,7 +299,7 @@
#define TQMA6_FDT_OFFSET (CONFIG_ENV_OFFSET_REDUND + \
CONFIG_ENV_SECT_SIZE)
-#define TQMA6_FDT_SECT_SIZE(CONFIG_FLASH_SECTOR_SIZE)
+#define TQMA6_FDT_SECT_SIZE(TQMA6_SPI_FLASH_SECTOR_SIZE)
#define TQMA6_FDT_SECTOR_START 0x0a /* 8 Sector u-boot, 2 Sector env */
#define TQMA6_FDT_SECTOR_COUNT 0x01
@@ -320,7 +320,7 @@
setexpr blkc ${filesize} + \
__stringify(TQMA6_UBOOT_OFFSET) ;\
setexpr size ${uboot_sectors} * \
- __stringify(CONFIG_FLASH_SECTOR_SIZE); \
+ __stringify(TQMA6_SPI_FLASH_SECTOR_SIZE);\
if itest ${blkc} = ${size}; then\
sf probe;\
sf erase 0 ${size}; \
@@ -332,9 +332,9 @@
update_kernel=run kernel_name; if tftp ${kernel}; then \
if itest ${filesize} 0; then \
setexpr size ${kernel_sectors} * \
- __stringify(CONFIG_FLASH_SECTOR_SIZE); \
+ __stringify(TQMA6_SPI_FLASH_SECTOR_SIZE);\
setexpr offset ${kernel_start} * \
- __stringify(CONFIG_FLASH_SECTOR_SIZE); \
+ __stringify(TQMA6_SPI_FLASH_SECTOR_SIZE);\
if itest ${filesize} = ${size}; then\
sf probe;\
sf erase ${offset} ${size}; \
@@ -346,9 +346,9 @@
update_fdt=if tftp ${fdt_file}; then \
if itest ${filesize} 0; then \
setexpr size ${fdt_sectors} *\
- __stringify(CONFIG_FLASH_SECTOR_SIZE); \
+ __stringify(TQMA6_SPI_FLASH_SECTOR_SIZE);\
setexpr offset ${fdt_start} *\
- __stringify(CONFIG_FLASH_SECTOR_SIZE); \
+ __stringify(TQMA6_SPI_FLASH_SECTOR_SIZE);\
if itest ${filesize} = ${size}; then\
sf probe;\
sf erase ${offset} ${size}; \
@@ -359,16 +359,16 @@
setenv filesize 0; setenv size ; setenv offset\0 \
loadimage=sf probe; \
setexpr size ${kernel_sectors} * \
- __stringify(CONFIG_FLASH_SECTOR_SIZE); \
+ __stringify(TQMA6_SPI_FLASH_SECTOR_SIZE);\
setexpr offset ${kernel_start} *
Re: [U-Boot] Query on CONFIG_SYS_THUMB_BUILD
On 2014-11-14 15:01, Simon Glass wrote:
Hi Victor,
On 13 November 2014 09:29, Victor Ascroft victorascr...@gmail.com wrote:
Hello,
I am working with a Cortex A5 Freescale Vybrid Processor. Since a thumb
build leads to a saving of almost 1 MB for my u-boot image and consequently
to faster serial downloads I have been looking at this. Currently enabling
this option leads to a hang.
After some debugging I have narrowed the place of hang to ldr pc,
=board_init_r in arch/arm/lib/crt0.S. My debugging procedure was to put a
branch to a small function which just printed a small message with puts,
just before the ldr instruction and then a printing a small message with
puts just at the start of board_init_r in common/board_r.c . For a non thumb
build, the two messages get printed and I can boot to the u-boot prompt. For
a thumb build, only the first message before the ldr instruction gets
printed.
In crt0.S
bl debug_print
ldr pc, =board_init_r
In board_init_r
puts(In board_init_r\n); // Right at start
void debug_print(void)
{
// Defined in board file
puts(Debug print\n);
}
My assembly knowledge is limited and after some consultation with a senior
colleague, he told me things to check.
An object dump of the crt0.o shows a branch to an even address. For thumb,
this is expected to be odd. To just try out, I did a change as below
ldr r3, =board_init_r
add r3, #1
bx r3
No change with this. My expectation was the compiler/linker/assembler would
take care of the requirements, with the CONFIG_SYS_THUMB_BUILD. Frankly
speaking I am not sure if this is the complete issue or only a part of it. I
have seen patches with regards to OMAP send in by Aneesh V, which made
changes of the form .type fn_name, %function to all the low level assembly
functions, but, I couldn't dig up much more or variants thereof. Basically,
from what I understand, this takes care of specifying .thumb_func for a
thumb function or so to speak.
Any pointers?
I tried this on a peach_pi (Samsung Chromebook 2 13) and it worked OK
for me. The code sequence you refer to came out as below for me.
23e01e10 clbss_l:
23e01e10: e151cmp r0, r1
23e01e14: 35802000strcc r2, [r0]
23e01e18: 3284addcc r0, r0, #4
23e01e1c: 3afbbcc 23e01e10 clbss_l
23e01e20: fa000decblx 23e055d8 coloured_LED_init
23e01e24: fb000debblx 23e055da red_led_on
23e01e28: e1a9mov r0, r9
23e01e2c: e5991030ldr r1, [r9, #48] ; 0x30
23e01e30: e59ff008ldr pc, [pc, #8]; 23e01e40
clbss_l+0x30
23e01e34: 02073800.word 0x02073800
23e01e38: 23e41eb0.word 0x23e41eb0
23e01e3c: 23e77bf0.word 0x23e77bf0
23e01e40: 23e057a9.word 0x23e057a9
The 'ldr pc' line is loading from 23e01e40 which does have an odd address.
What toolchain are you using? I tried with gcc 4.8.2 - including
linaro's 2013.10 release.
In arch/arm/cpu/armv7/config.mk there is a fallback to armv5 from
armv7-a, and this may cause it to generate Thumb code instead of Thumb
2. But you should get errors if that happens.
It's hard to debug with such limited visibility. But if I put a puts()
at the start of board_init_r(), I see it on the serial console.
Just checked that on Vybrid, it actually looks good too:
3f408f58 clbss_l:
3f408f58: e151cmp r0, r1
3f408f5c: 35802000strcc r2, [r0]
3f408f60: 3284addcc r0, r0, #4
3f408f64: 3afbbcc 3f408f58 clbss_l
3f408f68: fb000da8blx 3f40c612 coloured_LED_init
3f408f6c: fa000da8blx 3f40c614 red_led_on
3f408f70: e1a9mov r0, r9
3f408f74: e599102cldr r1, [r9, #44] ; 0x2c
3f408f78: e59ff008ldr pc, [pc, #8]; 3f408f88
clbss_l+0x30
3f408f7c: 3f07ff50.word 0x3f07ff50
3f408f80: 3f44c9d0.word 0x3f44c9d0
3f408f84: 3f482fc0.word 0x3f482fc0
3f408f88: 3f40c7c5.word 0x3f40c7c5
According to the map, this is the address of board_init_r
.text.board_init_r
0x3f40c7c4 0x10 common/built-in.o
0x3f40c7c4board_init_r
Currently I use GCC from a old Yocto/Angstrom build linger around. It's
a Linaro 2013.09 GCC 4.7.4.
I will have a look into it what exactly happens here.
--
Stefan
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/17] dm: i2c: Add a uclass for I2C
Hi Simon,
On Tue, 11 Nov 2014 10:46:24 -0700
Simon Glass s...@chromium.org wrote:
The uclass implements the same operations as the current I2C framework but
makes some changes to make it fit driver model better:
- Remove the chip address from API calls
- Remove the address length from API calls
- Remove concept of 'current' I2C bus
- Drop all existing init functions
Signed-off-by: Simon Glass s...@chromium.org
---
+static int i2c_post_probe(struct udevice *dev)
+{
+ struct dm_i2c_bus *i2c = dev-uclass_priv;
+
+ i2c-speed_hz = fdtdec_get_int(gd-fdt_blob, dev-of_offset,
+ clock-frequency, 10);
+
+ return i2c_set_bus_speed(dev, i2c-speed_hz);
+}
This code in drivers/i2c/i2c-uclass.c seems to highly depends on Device Tree.
I am not sure if I understood correctly, but
does this work on non Device Tree SoCs?
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] sun6i: dram: Do not try to initialize a second dram chan on A31s
Hi,
On 11/17/2014 08:00 PM, Ian Campbell wrote:
On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote:
The A31s only has one dram channel, so do not bother with trying to initalize
initialize
Fixed in my local tree.
a second channel.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/cpu/armv7/sunxi/Makefile | 2 +-
arch/arm/cpu/armv7/sunxi/dram_sun6i.c | 11 +--
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile
b/arch/arm/cpu/armv7/sunxi/Makefile
index 3b6ae47..1337b60 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -10,6 +10,7 @@
obj-y += timer.o
obj-y += board.o
obj-y += clock.o
+obj-y += cpu_info.o
obj-y += pinmux.o
obj-$(CONFIG_MACH_SUN6I)+= prcm.o
obj-$(CONFIG_MACH_SUN8I)+= prcm.o
@@ -21,7 +22,6 @@ obj-$(CONFIG_MACH_SUN7I) += clock_sun4i.o
obj-$(CONFIG_MACH_SUN8I)+= clock_sun6i.o
ifndef CONFIG_SPL_BUILD
-obj-y += cpu_info.o
ifdef CONFIG_ARMV7_PSCI
obj-y += psci.o
endif
diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c
b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c
index 30439dc..2ac0b58 100644
--- a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c
+++ b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c
@@ -372,10 +372,15 @@ unsigned long sunxi_dram_init(void)
.rows = 16,
};
+/* A31s only has one channel */
+if (sunxi_get_ss_bonding_id() == SUNXI_SS_BOND_ID_A31S)
+para.chan = 1;
mctl_channel_init seems to contain some auto detection code, I suppose
that doesn't work in this case for some reason? Or is this just an
optimisation? In which case is the benefit just quicker to boot?
My assumption was that it would not work, as the A31s has only one
channel, or so the datasheets claim. But it turned out it does work,
so they may be using the same die in a different package, I'll go
and mail Allwinner and see if they are willing to disclose anything
about this (knowing it is the same die would be useful).
So in the end this is only an optimization.
+
mctl_sys_init();
mctl_dll_init(0, para);
-mctl_dll_init(1, para);
+if (para.chan == 2)
+mctl_dll_init(1, para);
Both this an the next one are basically unrolled for-loops over
0-para.chan now. I suppose it doesn't really matter.
True, note that in mctl_com_init() we've:
if (para-chan == 1) {
/* Shutdown channel 1 */
...
}
So I would prefer to keep this as is (rather then turn it into a loop),
for consistency.
Regards,
Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/17] dm: i2c: Add a uclass for I2C
Hello Masahiro,
Am 18.11.2014 13:32, schrieb Masahiro Yamada:
Hi Simon,
On Tue, 11 Nov 2014 10:46:24 -0700
Simon Glass s...@chromium.org wrote:
The uclass implements the same operations as the current I2C framework but
makes some changes to make it fit driver model better:
- Remove the chip address from API calls
- Remove the address length from API calls
- Remove concept of 'current' I2C bus
- Drop all existing init functions
Signed-off-by: Simon Glass s...@chromium.org
---
+static int i2c_post_probe(struct udevice *dev)
+{
+ struct dm_i2c_bus *i2c = dev-uclass_priv;
+
+ i2c-speed_hz = fdtdec_get_int(gd-fdt_blob, dev-of_offset,
+clock-frequency, 10);
+
+ return i2c_set_bus_speed(dev, i2c-speed_hz);
+}
This code in drivers/i2c/i2c-uclass.c seems to highly depends on Device Tree.
I am not sure if I understood correctly, but
does this work on non Device Tree SoCs?
No. Devie Model is currently (as I understand) useable with
Device Tree ...
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] bootz: fix silent console
From: Markus Niebel markus.nie...@tq-group.com
fixup was lost during split between command code and logic.
Signed-off-by: Markus Niebel markus.nie...@tq-group.com
---
common/bootm.c | 2 +-
common/cmd_bootm.c | 6 ++
include/bootm.h| 2 ++
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/common/bootm.c b/common/bootm.c
index 6b3ea8c..94b9503 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -467,7 +467,7 @@ ulong bootm_disable_interrupts(void)
#define CONSOLE_ARG console=
#define CONSOLE_ARG_LEN (sizeof(CONSOLE_ARG) - 1)
-static void fixup_silent_linux(void)
+void fixup_silent_linux(void)
{
char *buf;
const char *env_val;
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 6723360..d3e410a 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -596,6 +596,12 @@ int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
* disable interrupts ourselves
*/
bootm_disable_interrupts();
+#if defined(CONFIG_SILENT_CONSOLE) !defined(CONFIG_SILENT_U_BOOT_ONLY)
+ /*
+* same goes for fixup_silent_linux
+*/
+ fixup_silent_linux();
+#endif
images.os.os = IH_OS_LINUX;
ret = do_bootm_states(cmdtp, flag, argc, argv,
diff --git a/include/bootm.h b/include/bootm.h
index b3d1a62..8e094b3 100644
--- a/include/bootm.h
+++ b/include/bootm.h
@@ -50,6 +50,8 @@ ulong bootm_disable_interrupts(void);
/* This is a special function used by booti/bootz */
int bootm_find_ramdisk_fdt(int flag, int argc, char * const argv[]);
+/* This function is used also used by bootz */
+void fixup_silent_linux(void);
int do_bootm_states(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
int states, bootm_headers_t *images, int boot_progress);
--
2.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] sun6i: Add new CSQ_CS908 board
Hi, On 11/17/2014 08:03 PM, Ian Campbell wrote: On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote: The CSQ CS908 is an A31s based top-set box, with 1G RAM, 8G NAND, rtl8188etv usb wifi, 2 USB A receptacles (1 connected through the OTG controller), ethernet, 3.5 mm jack with a/v out and hdmi out: http://www.geekbuying.com/item/CS908-Allwinner-A31S-Quad-Core-1-2GHz-Android-4-4-Mini-TV-Box-HDMI-HDD-Player-1G-8G-WIFI-Miracast---Black-95.html Note it has no sdcard slot! What are the implications of that? That we can only fel-boot it. This is mostly a warning to end users to avoid this box if they want a box on which they can easily run Linux. This does mean I got to use make foo_felconfig, works like a charm :) Thanks for the reviews. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] sun6i: Drop some unknown magic from dram init
Hi, On 11/17/2014 08:01 PM, Ian Campbell wrote: On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote: This bit of code is the rtc ram being used to detect coming out of super-standby mode, and if that is the case, going out of self-refresh mode. Since we do not support super-standby mode, this can be dropped. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk (perhaps start the commit log with Allwinner tells us that...? Ack either way) Fixed in my local tree. Regards, Hans --- arch/arm/cpu/armv7/sunxi/dram_sun6i.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c index 2ac0b58..5e163cb 100644 --- a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c +++ b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c @@ -140,9 +140,6 @@ static void mctl_channel_init(int ch_index, struct dram_sun6i_para *para) writel((MCTL_TITMSRST 18) | (MCTL_TDLLLOCK 6) | MCTL_TDLLSRST, mctl_phy-ptr0); -/* Unknown magic performed by boot0 */ -if ((readl(SUNXI_RTC_BASE + 0x20c) 3) == 2) -setbits_le32(mctl_phy-ptr0, 1 18); writel((MCTL_TDINIT1 19) | MCTL_TDINIT0, mctl_phy-ptr1); writel((MCTL_TDINIT3 17) | MCTL_TDINIT2, mctl_phy-ptr2); ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] dm: core: abolish u-boot, dm-pre-reloc property
Hi Simon, On Mon, 17 Nov 2014 18:17:43 + Simon Glass s...@chromium.org wrote: Hi Masahiro, On 17 November 2014 08:19, Masahiro Yamada yamad...@jp.panasonic.com wrote: The driver model provides two ways to pass the device information, platform data and device tree. Either way works to bind devices and drivers, but there is inconsistency in terms of how to pass the pre-reloc flag. In the platform data way, the pre-reloc DM scan checks if each driver has DM_FLAG_PRE_RELOC flag (this was changed to use U_BOOT_DRIVER_F just before). That is, each **driver** has the pre-reloc attribute. In the device tree control, the existence of u-boot,dm-pre-reloc is checked for each device node. The driver flag DM_FLAG_PRE_RELOC is never checked. That is, each **device** owns the pre-reloc attribute. Drivers should generally work both with platform data and device tree, but this inconsistency has made our life difficult. I feel we should use device tree where available, and only fall back to platform data when necessary (no device tree available for platform, for example). No, it is true that device tree is a useful tool, but it should be optional. All the infrastructures of drivers must work perfectly without device tree. The device tree is just one choice of how to give device information. This commit abolishes u-boot,dm-pre-reloc property because: - Having a U-Boot specific property makes it difficult to share the device tree sources between Linux and U-Boot. - The number of devices is generally larger than that of drivers. Each driver often has multiple devices with different base addresses. It seems more reasonable to add the pre-reloc attribute to drivers than devices. The inability for platform data to specify which devices need to be pre-relocation is certainly a limitation. But I'm not sure that the solution is to remove that feature from the device tree. Prior to relocation memory may be severely limited. Things like GPIO and serial can create quite a few devices (e.g. Tegra has 16 for GPIO and 4 for serial), but only a subset may be needed before relocation (on Tegra only 2!). I'm actually pretty comfortable with platform data having a limited subset of functionality, since I believe most platforms will use device tree for one reason or another. Thoughts? No, it is not justified to compel to use device tree unless Linux is the target OS. Even in Linux, limited numbers of architrectures use device trees. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/7] Update gdsys board support
Hi Kim, Hi Stefan, do you see any chance too get this merged soon? mpc83xx: Add gdsys hrcon board fixes a build failure and it would be nice to get it in before rc2. Kim offered to ack mpc83xx: Add gdsys hrcon board. Stefan, can you please get this through your repo afterwards? Cheers Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/7] Update gdsys board support
On 18.11.2014 13:55, Dirk Eibach wrote: do you see any chance too get this merged soon? mpc83xx: Add gdsys hrcon board fixes a build failure and it would be nice to get it in before rc2. Kim offered to ack mpc83xx: Add gdsys hrcon board. Stefan, can you please get this through your repo afterwards? Kim, could you please check this patch again and let me know if you are okay with me pulling it with the complete patch series via my tree? Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6sabresd: Access SRC_SBMR1 register via structure
In U-boot it is preferred to access the register via structure pointer, so convert it such style. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- board/freescale/mx6sabresd/mx6sabresd.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/board/freescale/mx6sabresd/mx6sabresd.c b/board/freescale/mx6sabresd/mx6sabresd.c index d5cd37d..bd8f55a 100644 --- a/board/freescale/mx6sabresd/mx6sabresd.c +++ b/board/freescale/mx6sabresd/mx6sabresd.c @@ -31,8 +31,6 @@ DECLARE_GLOBAL_DATA_PTR; -#define BOOT_CFG 0x020D8004 - #define UART_PAD_CTRL (PAD_CTL_PUS_100K_UP | \ PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | \ PAD_CTL_SRE_FAST | PAD_CTL_HYS) @@ -300,7 +298,8 @@ int board_mmc_init(bd_t *bis) return 0; #else - unsigned reg = readl(BOOT_CFG) 11; + struct src *psrc = (struct src *)SRC_BASE_ADDR; + unsigned reg = readl(psrc-sbmr1) 11; /* * Upon reading BOOT_CFG register the following map is done: * Bit 11 and 12 of BOOT_CFG register can determine the current -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 2/3] Odroid-XU3: Add support for Odroid-XU3
Hello Hyungwon,
On 11/18/2014 12:44 PM, Przemyslaw Marczak wrote:
Hello,
On 11/18/2014 02:57 AM, Hyungwon Hwang wrote:
Dear Przemyslaw Marczak,
+/*
+ * FIXME: The number of bank is actually 8. But there is no way to
reserver the
+ * last 16 Mib in the last bank now. So I just excluded the last
bank
+ * temporally.
+ */
It's not prober solution, since non-dt kernel could get wrong DRAM
size. Please look at board/samsung/odroid/odroid.c - into function
exynos_init().
The Odroid U3 has reserved the last 1MB of the last DRAM bank.
I agree. It is a temporary solution, and it must be fixed soon. I see
the exynos_init() function and adapt the method to fix the problem in
Odroid XU3. But it did not work. Figuring out what is wrong, I found
that the 2 lines of code in the exynos_init() to reserve the last 1MB
does not affect the behavior of Odroid U3. Even after I commented out
the codes, it works well. Is it a effective solution to reserve the
memory? Is there anything else which I am missing?
I really appreciate for your comment. Thanks.
Best regards,
Hyungwon Hwang.
Yes, I also checked now, that this doesn't work for your board.
On Odroid U3, there was a problem in the kernel - so dram size passed to
the kernel is decreased by 1MB. It don't make a difference for the
U-Boot if you don't touch this memory.
I can suppose that it depends on secure firmware.
If you plan to fix it in the future, then it's ok. In other way it will
require some modification of board/samsung/common/board.c dram code.
You can leave it as it is, since I plan to send some patches from
tizen.org for exynos ram init.
And it probably will fix this issue - if dts has decreased last bank
size with the 16MiB.
Best regards,
I made some quick test:
(diff)
for (i = 0; i CONFIG_NR_DRAM_BANKS; i++) {
addr = CONFIG_SYS_SDRAM_BASE + (i * SDRAM_BANK_SIZE);
- gd-ram_size += get_ram_size((long *)addr, SDRAM_BANK_SIZE);
+ if (i == 7)
+ gd-ram_size += (SDRAM_BANK_SIZE - (22 20));
+ else
+ gd-ram_size += SDRAM_BANK_SIZE;
}
return 0;
Similar in dram_init_banksize():
- size = get_ram_size((long *)addr, SDRAM_BANK_SIZE);
+
+ if (i == 7)
+ size = (SDRAM_BANK_SIZE - (22 20));
+ else
+ size = SDRAM_BANK_SIZE;
and this works fine.
I also checked that size of the reserved area is 22MiB.
Best regards,
--
Przemyslaw Marczak
Samsung RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] spl: MMC U-Boot image load from raw partition
On Sat, Nov 15, 2014 at 09:27:20PM +0100, Albert ARIBAUD wrote: Hello Paul, On Thu, 13 Nov 2014 23:16:09 +0100, Paul Kocialkowski cont...@paulk.fr wrote: [snip] Well I think it makes sense to not call this dead code as long as it *can be* enabled and used on another supported board (for that matter, any OMAP3+ board will indeed do). If no board is calling this code right now, that is because none needs it. If none needs it, then it has no reason to be added. The day some board needs this code, the patch to add this code can be submitted along with the patch that calls this code. This is very different from e.g. the regulator code that I submitted, which is only relevant for devices with that particular piece of hardware (so far, none supported by U-Boot). So it makes sense to submit that regulator patch only along with support for a board that uses it. I don't see the difference. But this is where I see a difference, tomorrow. Setting this, or not setting this new behavior is a Kconfig choice (in Kconfig-speak). We do not need a defconfig in-tree for every single possible choice since at some point we'll do like other Kconfig-based projects and have randconfig builds possible to cover odd choices, along with allyesconfig and allnoconfig to cover the things which people clearly need _somewhere_ (and feel the (good!) need to post them in public to help others) but may not be able to post the whole board port (not the case here per-se but see the various RTC drivers that get posted from time to time). -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH ] MMC: fix user capacity for partitioned eMMC card
From: Markus Niebel markus.nie...@tq-group.com
if the card claims to be high capacity and the card
is partitioned the capacity shall still be read from
ext_csd SEC_COUNT even if the resulting capacity is
smaller than 2 GiB
Signed-off-by: Markus Niebel markus.nie...@tq-group.com
---
drivers/mmc/mmc.c | 15 +++
include/mmc.h | 3 +++
2 files changed, 18 insertions(+)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 44a4feb..24b0989 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1022,6 +1022,21 @@ static int mmc_startup(struct mmc *mmc)
mmc-erase_grp_size =
ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] *
MMC_MAX_BLOCK_LEN * 1024;
+ /*
+* if high capacity and partition setting completed
+* SEC_COUNT is valid even if it is smaller than 2 GiB
+* JEDEC Standard JESD84-B45, 6.2.4
+*/
+ if (mmc-high_capacity
+ (ext_csd[EXT_CSD_PARTITION_SETTING]
+EXT_CSD_PARTITION_SETTING_COMPLETED)) {
+ capacity = (ext_csd[EXT_CSD_SEC_CNT]) |
+ (ext_csd[EXT_CSD_SEC_CNT + 1] 8) |
+ (ext_csd[EXT_CSD_SEC_CNT + 2] 16) |
+ (ext_csd[EXT_CSD_SEC_CNT + 3] 24);
+ capacity *= MMC_MAX_BLOCK_LEN;
+ mmc-capacity_user = capacity;
+ }
} else {
/* Calculate the group size from the csd value. */
int erase_gsz, erase_gmul;
diff --git a/include/mmc.h b/include/mmc.h
index d74a190..cb91565 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -147,6 +147,7 @@
* EXT_CSD fields
*/
#define EXT_CSD_GP_SIZE_MULT 143 /* R/W */
+#define EXT_CSD_PARTITION_SETTING 155 /* R/W */
#define EXT_CSD_PARTITIONS_ATTRIBUTE 156 /* R/W */
#define EXT_CSD_PARTITIONING_SUPPORT 160 /* RO */
#define EXT_CSD_RST_N_FUNCTION 162 /* R/W */
@@ -197,6 +198,8 @@
#define EXT_CSD_BOOT_BUS_WIDTH_RESET(x)(x 2)
#define EXT_CSD_BOOT_BUS_WIDTH_WIDTH(x)(x)
+#define EXT_CSD_PARTITION_SETTING_COMPLETED(1 0)
+
#define R1_ILLEGAL_COMMAND (1 22)
#define R1_APP_CMD (1 5)
--
2.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH ] MMC: add MMC_VERSION_5_0
From: Markus Niebel markus.nie...@tq-group.com Signed-off-by: Markus Niebel markus.nie...@tq-group.com --- drivers/mmc/mmc.c | 3 +++ include/mmc.h | 1 + 2 files changed, 4 insertions(+) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 24b0989..144c7f7 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -1001,6 +1001,9 @@ static int mmc_startup(struct mmc *mmc) case 6: mmc-version = MMC_VERSION_4_5; break; + case 7: + mmc-version = MMC_VERSION_5_0; + break; } /* diff --git a/include/mmc.h b/include/mmc.h index cb91565..51ee24b 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -31,6 +31,7 @@ #define MMC_VERSION_4_3(MMC_VERSION_MMC | 0x403) #define MMC_VERSION_4_41 (MMC_VERSION_MMC | 0x429) #define MMC_VERSION_4_5(MMC_VERSION_MMC | 0x405) +#define MMC_VERSION_5_0(MMC_VERSION_MMC | 0x500) #define MMC_MODE_HS(1 0) #define MMC_MODE_HS_52MHz (1 1) -- 2.1.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] arm: odroid: usb: add support for usb host including ethernet
Dear Przemyslaw Marczak, On 18/11/14 20:14, Przemyslaw Marczak wrote: Dear Minkyu, On 11/18/2014 09:14 AM, Minkyu Kang wrote: Hi, On 18/11/14 12:30, Suriyan Ramasami wrote: Hello Minkyu Kang/Przemyslaw and of course anyone else who can direct me, Thanks for the commit. I just realized that the code in this particular patch is missing the gpio_request() call before calling the gpio_direction_output() call, and hence fails to initialize the USB3503A hub. This was pointed out by Przemyslaw in another patch of mine (odroid: blue LED) So, my question is, this patch is in u-boot-samsung. To correct the above mentioned error, do I submit a patch directed to u-boot-samsung? Yes. Please send new patch. If so how do I do it? I mean, do I elaborate this in the subject /.body of the mail? sorry, I can't catch the point of your question. Thanks and regards, - Suriyan Thanks, Minkyu Kang. Could you please wait for the test/ack next time before you merge the patches to the tree? It will prevent before making an additional work on testing or fixing some code. Best regards, It's my bad that I didn't check it carefully. I usually wait somebody's response. But this patch is waited 18 days on the queue. How long will I wait? Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] sun6i: Make dram clk and zq value Kconfig options
On Tue, 2014-11-18 at 12:32 +0100, Hans de Goede wrote: Hi, On 11/17/2014 07:54 PM, Ian Campbell wrote: On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote: +config DRAM_ZQ + int sun6i dram zq value if EXPERT + default 123 == 0x7b, which differs from the previous default of 0x78 (not by much, but still) Right, this is deliberate as I've gotten access to more boards, 123 seems a better default (this is also what most A10 / A13 / A20 boards use). Please mention this in the commit log. diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig index bef568d..5e245a3 100644 --- a/configs/Colombus_defconfig +++ b/configs/Colombus_defconfig @@ -4,3 +4,5 @@ CONFIG_FDTFILE=sun6i-a31-colombus.dtb +S:CONFIG_ARCH_SUNXI=y +S:CONFIG_MACH_SUN6I=y +S:CONFIG_TARGET_COLOMBUS=y ++S:CONFIG_DRAM_CLK=288 ++S:CONFIG_DRAM_ZQ=379 Do these actually take affect if CONFIG_EXPERT=n? Ugh, I just checked, and no they don't. Perhaps CONFIG_TARGET_COLOMBUS should select DRAM_CLK == 288 and DRAM_CLK should be a hidden option? I would prefer to keep these inside the defconfig's so that for adding a new board only a defconfig needs to be added. Currently the only CONFIG_TARGET_BOARD we actually use in u-boot is the bananapi gmac tx clk delay tweak, and I would actually like to keep things that way. Actually thinking more about this, I think that that should be turned into a GMAC specific Kconfig option and all the CONFIG_TARGET_BOARD stuff should be dropped, as it is just a drag causing extra maintenance going forward. Hrm, I'm not sure yet which way I fall on this question. So is there a way to not show a choice to the user unless EXPERT mode is set, and still override it from Kconfig ? Not AFAIK, but I'm not expert (no pun intended) in Kconfig. If that is not (easily) possible, then I guess we will just need to not make these if EXPERT. Probably :-( ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] sun6i: dram: Do not try to initialize a second dram chan on A31s
On Tue, 2014-11-18 at 13:34 +0100, Hans de Goede wrote:
Hi,
On 11/17/2014 08:00 PM, Ian Campbell wrote:
On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote:
The A31s only has one dram channel, so do not bother with trying to
initalize
initialize
Fixed in my local tree.
a second channel.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/cpu/armv7/sunxi/Makefile | 2 +-
arch/arm/cpu/armv7/sunxi/dram_sun6i.c | 11 +--
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile
b/arch/arm/cpu/armv7/sunxi/Makefile
index 3b6ae47..1337b60 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -10,6 +10,7 @@
obj-y += timer.o
obj-y += board.o
obj-y += clock.o
+obj-y += cpu_info.o
obj-y += pinmux.o
obj-$(CONFIG_MACH_SUN6I) += prcm.o
obj-$(CONFIG_MACH_SUN8I) += prcm.o
@@ -21,7 +22,6 @@ obj-$(CONFIG_MACH_SUN7I) += clock_sun4i.o
obj-$(CONFIG_MACH_SUN8I) += clock_sun6i.o
ifndef CONFIG_SPL_BUILD
-obj-y += cpu_info.o
ifdef CONFIG_ARMV7_PSCI
obj-y += psci.o
endif
diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c
b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c
index 30439dc..2ac0b58 100644
--- a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c
+++ b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c
@@ -372,10 +372,15 @@ unsigned long sunxi_dram_init(void)
.rows = 16,
};
+ /* A31s only has one channel */
+ if (sunxi_get_ss_bonding_id() == SUNXI_SS_BOND_ID_A31S)
+ para.chan = 1;
mctl_channel_init seems to contain some auto detection code, I suppose
that doesn't work in this case for some reason? Or is this just an
optimisation? In which case is the benefit just quicker to boot?
My assumption was that it would not work, as the A31s has only one
channel, or so the datasheets claim. But it turned out it does work,
so they may be using the same die in a different package, I'll go
and mail Allwinner and see if they are willing to disclose anything
about this (knowing it is the same die would be useful).
So in the end this is only an optimization.
+
mctl_sys_init();
mctl_dll_init(0, para);
- mctl_dll_init(1, para);
+ if (para.chan == 2)
+ mctl_dll_init(1, para);
Both this an the next one are basically unrolled for-loops over
0-para.chan now. I suppose it doesn't really matter.
True, note that in mctl_com_init() we've:
if (para-chan == 1) {
/* Shutdown channel 1 */
...
}
So I would prefer to keep this as is (rather then turn it into a loop),
for consistency.
OK.
(IMHO that shutdown should be pulled up to before/after the loop, but
lets not block these patches on that.)
Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] sun6i: Add new CSQ_CS908 board
On Tue, 2014-11-18 at 13:47 +0100, Hans de Goede wrote: Hi, On 11/17/2014 08:03 PM, Ian Campbell wrote: On Sun, 2014-11-16 at 17:16 +0100, Hans de Goede wrote: The CSQ CS908 is an A31s based top-set box, with 1G RAM, 8G NAND, rtl8188etv usb wifi, 2 USB A receptacles (1 connected through the OTG controller), ethernet, 3.5 mm jack with a/v out and hdmi out: http://www.geekbuying.com/item/CS908-Allwinner-A31S-Quad-Core-1-2GHz-Android-4-4-Mini-TV-Box-HDMI-HDD-Player-1G-8G-WIFI-Miracast---Black-95.html Note it has no sdcard slot! What are the implications of that? That we can only fel-boot it. This is mostly a warning to end users to avoid this box if they want a box on which they can easily run Linux. Ah, right. Probably best to end the sentence with and therefore can only be fel booted or something then. Presumably In The Fullness Of Time(tm) it'll be possible to boot from NAND too, but lets not muddy those waters here... This does mean I got to use make foo_felconfig, works like a charm :) Oh good ;-) Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 2/4] mx6: thermal: Add i.MX6 CPU thermal sensor support
Hi Stefano, On Mon, Nov 17, 2014 at 10:49 AM, Stefano Babic sba...@denx.de wrote: I have some conceptional question here. This introduces a new set or, better, class of drivers, as we are used to see in kernel as thermal. As we discussed in last u-boot mini summit, the preferred way to introduce new drivers into current u-boot is to use DM (Driver Model), because this is the way u-boot will follow in the future. It will take some time porting the current drivers, but it is easier for drivers introducing new features. It is a good idea to convert this to the driver model, but Nitin is already at v6 and only now this request is made. First version of this patch series was sent back in August: http://lists.denx.de/pipermail/u-boot/2014-August/187685.html Could the conversion to DM be handled later by a separate patch? Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mcf: Fix cppcheck errors about uninitialized variables
On Fri, Nov 14, 2014 at 02:23:46PM +0100, Wolfgang Denk wrote: Dear Albert, In message 20141114134733.01c82023@lilith you wrote: - u8 bootmode; + u8 bootmode = 0; If you set bootmode to the default 0 value at declaration, then the code that follows in the source file can be simplified: u8 bootmode = 0; ---8--- pcrvalue = in_be32(pll-pcr) 0xFF0F0FFF; pfdr = pcrvalue 24; if (pfdr == 0x1E) bootmode = 0; /* Normal Mode */ ---8--- The part between scissors is useless now, and in turn, pfdr becomes unneeded. Exactly. This was my concern, too - otherwise I had provided auch a trivial fix. But I think here some deeper understanding of the intended logic is needed. For clarity, yes, please do a v2 where you've re-organized the code based on what the cppcheck errors point out rather than just a simple silence of the warning, 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 v4 1/2] fdt_support: Add a fdt_setup_simplefb_node helper function
Hi Hans, On 18 November 2014 11:18, Hans de Goede hdego...@redhat.com wrote: Hi Simon, On 11/17/2014 07:32 PM, Simon Glass wrote: Hi Hans, On 17 November 2014 15:48, Hans de Goede hdego...@redhat.com wrote: Add a generic helper to fill and enable simplefb nodes. The first user of this will be the sunxi display code. lcd_dt_simplefb_configure_node is also a good candidate to be converted to use this, but that requires someone to run some tests first, as lcd_dt_simplefb_configure_node does not honor #address-cells and #size-cells, but simply assumes 1 and 1 for both. Signed-off-by: Hans de Goede hdego...@redhat.com --- common/fdt_support.c | 65 +++ include/fdt_support.h | 3 +++ 2 files changed, 68 insertions(+) diff --git a/common/fdt_support.c b/common/fdt_support.c index 3f64156..0ffa711 100644 --- a/common/fdt_support.c +++ b/common/fdt_support.c @@ -1523,3 +1523,68 @@ int fdt_read_range(void *fdt, int node, int n, uint64_t *child_addr, return 0; } + +/** + * fdt_setup_simplefb_node - Fill and enable a simplefb node + * + * @fdt: ptr to device tree + * @node: offset of the simplefb node + * @base_address: framebuffer base address + * @width: width in pixels + * @height: height in pixels + * @stride: bytes per line + * @format: pixel format string + * + * Convenience function to fill and enable a simplefb node. + */ +int fdt_setup_simplefb_node(void *fdt, int node, u64 base_address, u32 width, + u32 height, u32 stride, const char *format) Please see lcd_dt_simplefb_configure_node() which seems similar. As mentioned in the commit message already :) lcd_dt_simplefb_configure_node() should be made to use this new helper function eventually. OK I think we have established that I can't read :-) There are several reasons why lcd_dt_simplefb_configure_node() is not usable as a generic helper, and this new function is necessary: 1) It is lcd specific, only available if CONFIG_LCD is set 2) It does not take width / height / stride parameters, instead it reads global variables from lcd.c which are only set if the other common/lcd.c functions are used. 3) It hardcodes the format 4) It does not properly handle #address-cells and #size-cells 4) Is the main reason why I've not included a patch in my patch-set to move lcd_dt_simplefb_configure_node() over to use this new helper, as I'm afraid that may break things. of_bus_default_count_cells() will return different values then the 1/1 the current lcd code assumes when no #address-cells or #size-cells are present in the parent. So my plan is to add this new helper, use it for sunxi, and ask someone who has a board which is using lcd.c + simplefb to test moving lcd.c over to the new helper. I think it's only used by Raspberry Pi. If you send the patch I can test it next week. But we really shouldn't have two such similar functions. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] sunxi: video: Add simplefb support
Hi Hans,
On 18 November 2014 11:23, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 11/17/2014 07:39 PM, Simon Glass wrote:
Hi Hans,
On 17 November 2014 15:48, Hans de Goede hdego...@redhat.com wrote:
From: Luc Verhaegen l...@skynet.be
Add simplefb support, note this depends on the kernel having support for
the clocks property which has recently been added to the simplefb devicetree
binding.
Signed-off-by: Luc Verhaegen l...@skynet.be
[hdego...@redhat.com: Use pre-populated simplefb node under /chosen as
disussed on the devicetree list]
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/include/asm/arch-sunxi/display.h | 4
board/sunxi/board.c | 11 +
drivers/video/sunxi_display.c | 39
+++
include/configs/sunxi-common.h| 8 +++
4 files changed, 62 insertions(+)
diff --git a/arch/arm/include/asm/arch-sunxi/display.h
b/arch/arm/include/asm/arch-sunxi/display.h
index 8d80ceb..4c694f8 100644
--- a/arch/arm/include/asm/arch-sunxi/display.h
+++ b/arch/arm/include/asm/arch-sunxi/display.h
@@ -195,4 +195,8 @@ struct sunxi_hdmi_reg {
#define SUNXI_HDMI_PLL_DBG0_PLL3 (0 21)
#define SUNXI_HDMI_PLL_DBG0_PLL7 (1 21)
+#ifdef CONFIG_VIDEO_DT_SIMPLEFB
+void sunxi_simplefb_setup(void *blob);
+#endif
+
#endif /* _SUNXI_DISPLAY_H */
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index e6ec5b8..d4530e8 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -24,6 +24,7 @@
#endif
#include asm/arch/clock.h
#include asm/arch/cpu.h
+#include asm/arch/display.h
#include asm/arch/dram.h
#include asm/arch/gpio.h
#include asm/arch/mmc.h
@@ -237,3 +238,13 @@ int misc_init_r(void)
return 0;
}
#endif
+
+#ifdef CONFIG_OF_BOARD_SETUP
+void
+ft_board_setup(void *blob, bd_t *bd)
+{
+#ifdef CONFIG_VIDEO_DT_SIMPLEFB
+ sunxi_simplefb_setup(blob);
+#endif
+}
+#endif /* CONFIG_OF_BOARD_SETUP */
diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
index 3f46c31..74c4bd3 100644
--- a/drivers/video/sunxi_display.c
+++ b/drivers/video/sunxi_display.c
@@ -13,6 +13,8 @@
#include asm/arch/display.h
#include asm/global_data.h
#include asm/io.h
+#include fdtdec.h
+#include fdt_support.h
#include linux/fb.h
#include video_fb.h
@@ -416,3 +418,40 @@ video_hw_init(void)
return graphic_device;
}
+
+/*
+ * Simplefb support.
+ */
+#if defined(CONFIG_OF_BOARD_SETUP) defined(CONFIG_VIDEO_DT_SIMPLEFB)
+void
+sunxi_simplefb_setup(void *blob)
+{
+ static GraphicDevice *graphic_device =
sunxi_display.graphic_device;
+ int offset, ret;
+
+ if (!sunxi_display.enabled)
+ return;
return -ENOENT?
If people want this, I can change the proto to an int and make
sunxi_simplefb_setup
return error codes as you suggest, but this function gets called from
ft_board_setup which is void itself, so there is no where to propagate the
error,
and more-over we do not want simplefb setup errors to be treated as fatal, so
I see little use in having it return error codes.
ft_board_setup() will soon change to return an error. Will likely
merge those patches next week.
+
+ /* Find a framebuffer node, with pipeline == de_be0-lcd0-hdmi */
+ offset = fdt_node_offset_by_compatible(blob, -1,
sunxi,framebuffer);
These should convert to DM at some point. To make sure we don't forget
any, you should add this compatible string to fdtdec.c and use the
enum from fdtdec.h and also fdtdec_next_compatible().
Most sunxi boards do not set CONFIG_OF_CONTROL, so the ftddec functions are
not available.
Actually I was wrong - this is adjust the kernel FDT so ignore my comment.
+ while (offset = 0) {
+ ret = fdt_find_string(blob, offset, sunxi,pipeline,
+ de_be0-lcd0-hdmi);
+ if (ret == 0)
+ break;
+ offset = fdt_node_offset_by_compatible(blob, offset,
+ sunxi,framebuffer);
+ }
+ if (offset 0) {
+ eprintf(Cannot setup simplefb: node not found\n);
+ return;
return -ENODEV?
+ }
+
+ ret = fdt_setup_simplefb_node(blob, offset, gd-fb_base,
+ graphic_device-winSizeX, graphic_device-winSizeY,
+ graphic_device-winSizeX *
graphic_device-gdfBytesPP,
+ x8r8g8b8);
+ if (ret 0)
+ eprintf(Cannot setup simplefb: Error setting
properties\n);
Can we return the error here? Maybe -EPERM or something like that.
+}
+#endif /* CONFIG_OF_BOARD_SETUP CONFIG_VIDEO_DT_SIMPLEFB */
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 900ef52..d5d907b 100644
--- a/include/configs/sunxi-common.h
+++
Re: [U-Boot] [PATCH v3 3/3] arm: odroid: usb: add support for usb host including ethernet
Hello Minkyu, On 11/18/2014 03:05 PM, Minkyu Kang wrote: Dear Przemyslaw Marczak, On 18/11/14 20:14, Przemyslaw Marczak wrote: Dear Minkyu, On 11/18/2014 09:14 AM, Minkyu Kang wrote: Hi, On 18/11/14 12:30, Suriyan Ramasami wrote: Hello Minkyu Kang/Przemyslaw and of course anyone else who can direct me, Thanks for the commit. I just realized that the code in this particular patch is missing the gpio_request() call before calling the gpio_direction_output() call, and hence fails to initialize the USB3503A hub. This was pointed out by Przemyslaw in another patch of mine (odroid: blue LED) So, my question is, this patch is in u-boot-samsung. To correct the above mentioned error, do I submit a patch directed to u-boot-samsung? Yes. Please send new patch. If so how do I do it? I mean, do I elaborate this in the subject /.body of the mail? sorry, I can't catch the point of your question. Thanks and regards, - Suriyan Thanks, Minkyu Kang. Could you please wait for the test/ack next time before you merge the patches to the tree? It will prevent before making an additional work on testing or fixing some code. Best regards, It's my bad that I didn't check it carefully. I usually wait somebody's response. But this patch is waited 18 days on the queue. How long will I wait? Thanks, Minkyu Kang. It's easy to miss something without test on a hardware and this is the reason why the code should be tested before the merge. The 18 days is quite long, I agree with you - but is this a reason for those patches to be merged, without the test? You are a busy person at work, the same as I am, but I hope that ping somebody to check the code is a good manner. And then I believe, we can provide stable and tested master tree as a maintainers of our boards. Best regards, -- Przemyslaw Marczak Samsung RD Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] dm: core: abolish u-boot, dm-pre-reloc property
Hi Masahiro, On 18 November 2014 12:51, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hi Simon, On Mon, 17 Nov 2014 18:17:43 + Simon Glass s...@chromium.org wrote: Hi Masahiro, On 17 November 2014 08:19, Masahiro Yamada yamad...@jp.panasonic.com wrote: The driver model provides two ways to pass the device information, platform data and device tree. Either way works to bind devices and drivers, but there is inconsistency in terms of how to pass the pre-reloc flag. In the platform data way, the pre-reloc DM scan checks if each driver has DM_FLAG_PRE_RELOC flag (this was changed to use U_BOOT_DRIVER_F just before). That is, each **driver** has the pre-reloc attribute. In the device tree control, the existence of u-boot,dm-pre-reloc is checked for each device node. The driver flag DM_FLAG_PRE_RELOC is never checked. That is, each **device** owns the pre-reloc attribute. Drivers should generally work both with platform data and device tree, but this inconsistency has made our life difficult. I feel we should use device tree where available, and only fall back to platform data when necessary (no device tree available for platform, for example). No, it is true that device tree is a useful tool, but it should be optional. All the infrastructures of drivers must work perfectly without device tree. The device tree is just one choice of how to give device information. Which platform(s) are we talking about here? This commit abolishes u-boot,dm-pre-reloc property because: - Having a U-Boot specific property makes it difficult to share the device tree sources between Linux and U-Boot. - The number of devices is generally larger than that of drivers. Each driver often has multiple devices with different base addresses. It seems more reasonable to add the pre-reloc attribute to drivers than devices. The inability for platform data to specify which devices need to be pre-relocation is certainly a limitation. But I'm not sure that the solution is to remove that feature from the device tree. Prior to relocation memory may be severely limited. Things like GPIO and serial can create quite a few devices (e.g. Tegra has 16 for GPIO and 4 for serial), but only a subset may be needed before relocation (on Tegra only 2!). I'm actually pretty comfortable with platform data having a limited subset of functionality, since I believe most platforms will use device tree for one reason or another. Thoughts? No, it is not justified to compel to use device tree unless Linux is the target OS. Even in Linux, limited numbers of architrectures use device trees. Fair enough, but let's look at this when the case comes up. So far the platforms that use I2C and SPI with DM do use device tree in Linux and probably should do in 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 2/2] sunxi: video: Add simplefb support
Hi,
On 11/18/2014 03:32 PM, Simon Glass wrote:
Hi Hans,
On 18 November 2014 11:23, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 11/17/2014 07:39 PM, Simon Glass wrote:
Hi Hans,
On 17 November 2014 15:48, Hans de Goede hdego...@redhat.com wrote:
From: Luc Verhaegen l...@skynet.be
Add simplefb support, note this depends on the kernel having support for
the clocks property which has recently been added to the simplefb
devicetree
binding.
Signed-off-by: Luc Verhaegen l...@skynet.be
[hdego...@redhat.com: Use pre-populated simplefb node under /chosen as
disussed on the devicetree list]
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/include/asm/arch-sunxi/display.h | 4
board/sunxi/board.c | 11 +
drivers/video/sunxi_display.c | 39
+++
include/configs/sunxi-common.h| 8 +++
4 files changed, 62 insertions(+)
diff --git a/arch/arm/include/asm/arch-sunxi/display.h
b/arch/arm/include/asm/arch-sunxi/display.h
index 8d80ceb..4c694f8 100644
--- a/arch/arm/include/asm/arch-sunxi/display.h
+++ b/arch/arm/include/asm/arch-sunxi/display.h
@@ -195,4 +195,8 @@ struct sunxi_hdmi_reg {
#define SUNXI_HDMI_PLL_DBG0_PLL3 (0 21)
#define SUNXI_HDMI_PLL_DBG0_PLL7 (1 21)
+#ifdef CONFIG_VIDEO_DT_SIMPLEFB
+void sunxi_simplefb_setup(void *blob);
+#endif
+
#endif /* _SUNXI_DISPLAY_H */
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index e6ec5b8..d4530e8 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -24,6 +24,7 @@
#endif
#include asm/arch/clock.h
#include asm/arch/cpu.h
+#include asm/arch/display.h
#include asm/arch/dram.h
#include asm/arch/gpio.h
#include asm/arch/mmc.h
@@ -237,3 +238,13 @@ int misc_init_r(void)
return 0;
}
#endif
+
+#ifdef CONFIG_OF_BOARD_SETUP
+void
+ft_board_setup(void *blob, bd_t *bd)
+{
+#ifdef CONFIG_VIDEO_DT_SIMPLEFB
+ sunxi_simplefb_setup(blob);
+#endif
+}
+#endif /* CONFIG_OF_BOARD_SETUP */
diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
index 3f46c31..74c4bd3 100644
--- a/drivers/video/sunxi_display.c
+++ b/drivers/video/sunxi_display.c
@@ -13,6 +13,8 @@
#include asm/arch/display.h
#include asm/global_data.h
#include asm/io.h
+#include fdtdec.h
+#include fdt_support.h
#include linux/fb.h
#include video_fb.h
@@ -416,3 +418,40 @@ video_hw_init(void)
return graphic_device;
}
+
+/*
+ * Simplefb support.
+ */
+#if defined(CONFIG_OF_BOARD_SETUP) defined(CONFIG_VIDEO_DT_SIMPLEFB)
+void
+sunxi_simplefb_setup(void *blob)
+{
+ static GraphicDevice *graphic_device =
sunxi_display.graphic_device;
+ int offset, ret;
+
+ if (!sunxi_display.enabled)
+ return;
return -ENOENT?
If people want this, I can change the proto to an int and make
sunxi_simplefb_setup
return error codes as you suggest, but this function gets called from
ft_board_setup which is void itself, so there is no where to propagate the
error,
and more-over we do not want simplefb setup errors to be treated as fatal, so
I see little use in having it return error codes.
ft_board_setup() will soon change to return an error. Will likely
merge those patches next week.
That is good to hear, but not relevant in this case, as said:
more-over we do not want simplefb setup errors to be treated as fatal
Main reason for this is that older dtb-s do not have the pre-populated
simplefb node. I guess it could be argued that not having the node
should be a warning (and return 0), and the other errors should be
real errors. I can be convinced to make that change, let me know either
way.
Regards,
Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] sunxi: video: Add simplefb support
Hi Hans,
On 18 November 2014 14:54, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 11/18/2014 03:32 PM, Simon Glass wrote:
Hi Hans,
On 18 November 2014 11:23, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 11/17/2014 07:39 PM, Simon Glass wrote:
Hi Hans,
On 17 November 2014 15:48, Hans de Goede hdego...@redhat.com wrote:
From: Luc Verhaegen l...@skynet.be
Add simplefb support, note this depends on the kernel having support for
the clocks property which has recently been added to the simplefb
devicetree
binding.
Signed-off-by: Luc Verhaegen l...@skynet.be
[hdego...@redhat.com: Use pre-populated simplefb node under /chosen as
disussed on the devicetree list]
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/include/asm/arch-sunxi/display.h | 4
board/sunxi/board.c | 11 +
drivers/video/sunxi_display.c | 39
+++
include/configs/sunxi-common.h| 8 +++
4 files changed, 62 insertions(+)
diff --git a/arch/arm/include/asm/arch-sunxi/display.h
b/arch/arm/include/asm/arch-sunxi/display.h
index 8d80ceb..4c694f8 100644
--- a/arch/arm/include/asm/arch-sunxi/display.h
+++ b/arch/arm/include/asm/arch-sunxi/display.h
@@ -195,4 +195,8 @@ struct sunxi_hdmi_reg {
#define SUNXI_HDMI_PLL_DBG0_PLL3 (0 21)
#define SUNXI_HDMI_PLL_DBG0_PLL7 (1 21)
+#ifdef CONFIG_VIDEO_DT_SIMPLEFB
+void sunxi_simplefb_setup(void *blob);
+#endif
+
#endif /* _SUNXI_DISPLAY_H */
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index e6ec5b8..d4530e8 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -24,6 +24,7 @@
#endif
#include asm/arch/clock.h
#include asm/arch/cpu.h
+#include asm/arch/display.h
#include asm/arch/dram.h
#include asm/arch/gpio.h
#include asm/arch/mmc.h
@@ -237,3 +238,13 @@ int misc_init_r(void)
return 0;
}
#endif
+
+#ifdef CONFIG_OF_BOARD_SETUP
+void
+ft_board_setup(void *blob, bd_t *bd)
+{
+#ifdef CONFIG_VIDEO_DT_SIMPLEFB
+ sunxi_simplefb_setup(blob);
+#endif
+}
+#endif /* CONFIG_OF_BOARD_SETUP */
diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
index 3f46c31..74c4bd3 100644
--- a/drivers/video/sunxi_display.c
+++ b/drivers/video/sunxi_display.c
@@ -13,6 +13,8 @@
#include asm/arch/display.h
#include asm/global_data.h
#include asm/io.h
+#include fdtdec.h
+#include fdt_support.h
#include linux/fb.h
#include video_fb.h
@@ -416,3 +418,40 @@ video_hw_init(void)
return graphic_device;
}
+
+/*
+ * Simplefb support.
+ */
+#if defined(CONFIG_OF_BOARD_SETUP) defined(CONFIG_VIDEO_DT_SIMPLEFB)
+void
+sunxi_simplefb_setup(void *blob)
+{
+ static GraphicDevice *graphic_device =
sunxi_display.graphic_device;
+ int offset, ret;
+
+ if (!sunxi_display.enabled)
+ return;
return -ENOENT?
If people want this, I can change the proto to an int and make
sunxi_simplefb_setup
return error codes as you suggest, but this function gets called from
ft_board_setup which is void itself, so there is no where to propagate the
error,
and more-over we do not want simplefb setup errors to be treated as fatal,
so
I see little use in having it return error codes.
ft_board_setup() will soon change to return an error. Will likely
merge those patches next week.
That is good to hear, but not relevant in this case, as said:
more-over we do not want simplefb setup errors to be treated as fatal
Main reason for this is that older dtb-s do not have the pre-populated
simplefb node. I guess it could be argued that not having the node
should be a warning (and return 0), and the other errors should be
real errors. I can be convinced to make that change, let me know either
way.
Yes that sounds right to me.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] mxssb: trivial fixes
On Tuesday, November 18, 2014 at 10:33:44 AM, Marc Kleine-Budde wrote: Hey, Hi! this is a trivial patch series for the mxssb tool. Please review and apply. The mxssb tool is dead, the U-Boot has support for generating the MXS images directly (see tools/mxsimage.[ch]). Can you please verify if your patches still apply to that file (they should) ? Would it be possible for you to prepare a patch for the mxsimage tool instead please ? Thank you for your help! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Query on CONFIG_SYS_THUMB_BUILD
On 2014-11-14 15:01, Simon Glass wrote:
Hi Victor,
On 13 November 2014 09:29, Victor Ascroft victorascr...@gmail.com wrote:
Hello,
I am working with a Cortex A5 Freescale Vybrid Processor. Since a thumb
build leads to a saving of almost 1 MB for my u-boot image and consequently
to faster serial downloads I have been looking at this. Currently enabling
this option leads to a hang.
After some debugging I have narrowed the place of hang to ldr pc,
=board_init_r in arch/arm/lib/crt0.S. My debugging procedure was to put a
branch to a small function which just printed a small message with puts,
just before the ldr instruction and then a printing a small message with
puts just at the start of board_init_r in common/board_r.c . For a non thumb
build, the two messages get printed and I can boot to the u-boot prompt. For
a thumb build, only the first message before the ldr instruction gets
printed.
In crt0.S
bl debug_print
ldr pc, =board_init_r
In board_init_r
puts(In board_init_r\n); // Right at start
void debug_print(void)
{
// Defined in board file
puts(Debug print\n);
}
My assembly knowledge is limited and after some consultation with a senior
colleague, he told me things to check.
An object dump of the crt0.o shows a branch to an even address. For thumb,
this is expected to be odd. To just try out, I did a change as below
ldr r3, =board_init_r
add r3, #1
bx r3
No change with this. My expectation was the compiler/linker/assembler would
take care of the requirements, with the CONFIG_SYS_THUMB_BUILD. Frankly
speaking I am not sure if this is the complete issue or only a part of it. I
have seen patches with regards to OMAP send in by Aneesh V, which made
changes of the form .type fn_name, %function to all the low level assembly
functions, but, I couldn't dig up much more or variants thereof. Basically,
from what I understand, this takes care of specifying .thumb_func for a
thumb function or so to speak.
Any pointers?
I tried this on a peach_pi (Samsung Chromebook 2 13) and it worked OK
for me. The code sequence you refer to came out as below for me.
23e01e10 clbss_l:
23e01e10: e151cmp r0, r1
23e01e14: 35802000strcc r2, [r0]
23e01e18: 3284addcc r0, r0, #4
23e01e1c: 3afbbcc 23e01e10 clbss_l
23e01e20: fa000decblx 23e055d8 coloured_LED_init
23e01e24: fb000debblx 23e055da red_led_on
23e01e28: e1a9mov r0, r9
23e01e2c: e5991030ldr r1, [r9, #48] ; 0x30
23e01e30: e59ff008ldr pc, [pc, #8]; 23e01e40
clbss_l+0x30
23e01e34: 02073800.word 0x02073800
23e01e38: 23e41eb0.word 0x23e41eb0
23e01e3c: 23e77bf0.word 0x23e77bf0
23e01e40: 23e057a9.word 0x23e057a9
The 'ldr pc' line is loading from 23e01e40 which does have an odd address.
What toolchain are you using? I tried with gcc 4.8.2 - including
linaro's 2013.10 release.
In arch/arm/cpu/armv7/config.mk there is a fallback to armv5 from
armv7-a, and this may cause it to generate Thumb code instead of Thumb
2. But you should get errors if that happens.
It's hard to debug with such limited visibility. But if I put a puts()
at the start of board_init_r(), I see it on the serial console.
Ok, turns out the problem with Thumb2 only appear when using
CONFIG_USE_ARCH_MEMCPY (hence added Matthias to CC). Does peach_pi still
works with that config enabled? On the Vybrid board we use that to speed
up NAND access, with the current NAND driver, data get copied by the
CPU.
In setup_reloc, common/board_f.c, probably the first use of memcpy,
things started to get weird. The code after memcpy doesn't get executed,
I think something with the stack goes wrong, but not really sure what
happens.
--
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/8] common: spl: Add interactive DDR debugger support for SPL image
On 11/17/2014 11:02 PM, Albert ARIBAUD wrote: Hello York, On Mon, 17 Nov 2014 15:00:42 -0800, York Sun york...@freescale.com wrote: On 10/27/2014 06:48 PM, Wang Huan-B18965 wrote: Hello, Albert, snip --- Change log: v3: Gave more explaination in the commit. v2: No change. This does not apply cleanly. Could you rebase and resubmit? [Alison Wang] ok, I will rebase and resubmit the set. Thanks. Alison, Where are we on this patch? If you haven't sent an update, I can take this one and resolve the conflict. Albert, This set primarily deals with FSL specific boards. I can take them in if you don't see any issue with the patches (except the conflicts). Thanks York for the proposal, but I would prefer the patch to be rebased and resubmitted, as rebasing does require some changes which could be trivial, and thus be handled by the custodian, or not trivial, and thus require review; best, therefore, to rebase and repost. All right, then. Alison, please send a new set after you test it. I will mark this set change requested. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] arm: odroid: usb: add support for usb host including ethernet
Hello Przemyslaw, On Tue, Nov 18, 2014 at 3:09 AM, Przemyslaw Marczak p.marc...@samsung.com wrote: Hello Suriyan, On 11/18/2014 04:30 AM, Suriyan Ramasami wrote: Hello Minkyu Kang/Przemyslaw and of course anyone else who can direct me, Thanks for the commit. I just realized that the code in this particular patch is missing the gpio_request() call before calling the gpio_direction_output() call, and hence fails to initialize the USB3503A hub. This was pointed out by Przemyslaw in another patch of mine (odroid: blue LED) So, my question is, this patch is in u-boot-samsung. To correct the above mentioned error, do I submit a patch directed to u-boot-samsung? If so how do I do it? I mean, do I elaborate this in the subject /.body of the mail? Thanks and regards, - Suriyan Yes, the gpio_request() was missed in your code - it prints errors about it but the HUB works fine. So when you send the fixed version this should be okay. Please check ums command before send. Sure, will do! Please also check setting buck value at function board_usb_init(), the buck is disabled and before enable - the value changes two times - probably by mistake. I think there is an error in the implementation of max77686_set_buck_mode(..., buck #, OPMODE_OFF), or I have some gap in my understanding of it. I believe that when you set OPMODE_OFF it should turn it OFF right? as in no voltage? This does not seem to be the case. I have to turn the power off and then on, on BUCK8 (LAN9730 feeds off of it), to reset the LAN when a usb reset is issued, else it will not be detected again when usb start is re-issued. Initially, I had max77686_set_buck_mode(p_pmic, 9, OPMODE_OFF); delay; max77686(set_buck_mode(p_pmic, 9, OPMODE_ON); but it did not power recycle the LAN9730 chip. I do not have access to the MAX77686 data sheets to debug this. Hence, in my current code I set the voltage to the lowest possible value, and then bring it back up to 3.3V to simulate a reset. In fact, I can remove the OPMODE_OFF and OPMODE_ON code, and it works. Please let me know if there is any change needed in the OPMODE_OFF code for it to work the way it should, or correct my understanding of what it is supposed to do. Currently, I am thinking of just having: max77686_set_buck_voltage(p_pmic, 8, 75); max77686_set_buck_voltage(p_pmic, 8, 330); and leave the OPMODE_OFF and OPMODE_ON out of it. And the gpio_request(...) you can put into board_gpio_init - request gpio only one. Yes. The odroid is available on the market, so I would prefer keep some documentation in the doc/README.odroid. Could you please add short section about the USB usage in U-Boot? This would be useful. OK! On Mon, Nov 17, 2014 at 6:02 AM, Minkyu Kang mk7.k...@samsung.com wrote: On 30/10/14 01:22, Suriyan Ramasami wrote: This change adds support for enabling the USB host features of the board. This includes the USB3503A hub and the SMC LAN9730 ethernet controller as well. Signed-off-by: Suriyan Ramasami suriya...@gmail.com --- Changes in v3: * removed set_usb_ethaddr() and related code as the GUID registers do not seem to be documented anywhere. This is sad, as this mechanism allows for each Odroid to boot up with the same MAC address every time, but no two odroids shall have the same MAC address on boot. This ensures multiple odroids in the same LAN to come up without conflicting MAC addresses. * Minkyu - Do not mix cpu_is... and proid_is... Changes in v2: * Jaehoon - Split power.[ch] as a separate patch * Removed an unneeded header file from ehci-exynos.c * Jaehoon - Fix indentation in the dts file Changes in v1: * First try arch/arm/dts/exynos4412-odroid.dts | 11 +++ arch/arm/include/asm/arch-exynos/ehci.h | 13 board/samsung/odroid/odroid.c | 32 +++ drivers/usb/host/ehci-exynos.c | 55 - include/configs/odroid.h| 13 5 files changed, 116 insertions(+), 8 deletions(-) applied to u-boot-samsung. Thanks, Minkyu Kang. Best regards, -- Przemyslaw Marczak Samsung RD Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/4] stv0991: Add basic stv0991 architecture support
Thanks Albert,
On 11/17/2014 11:21 PM, Albert ARIBAUD wrote:
Hello Vikas,
On Mon, 17 Nov 2014 17:30:25 -0800, Vikas Manocha
vikas.mano...@st.com wrote:
stv0991 architecture support added. It contains the support for
following blocks
- Timer
- uart
Signed-off-by: Vikas Manocha vikas.mano...@st.com
---
Changes in v4:
- added maintainers info
I don't see the MAINTAINERS file added here; it is in 4/4 which (unless
I've missed requests to the opposite effect) should be merged with 1/4.
You are right, it is mentioned here but actually is in 4/4. I will merge
4/4 with 1/4.
Rgds,
Vikas
- rebased to current master
Changes in v3:
- removed period from commit message
Changes in v2:
- corrected files license to GPL-2.0+
- replaced printf() usage with puts() for string print
arch/arm/Kconfig |5 +
arch/arm/cpu/armv7/stv0991/Makefile|9 ++
arch/arm/cpu/armv7/stv0991/clock.c | 27 +
arch/arm/cpu/armv7/stv0991/lowlevel.S | 12 +++
arch/arm/cpu/armv7/stv0991/pinmux.c| 48 +
arch/arm/cpu/armv7/stv0991/reset.c | 26 +
arch/arm/cpu/armv7/stv0991/timer.c | 114
arch/arm/include/asm/arch-stv0991/hardware.h | 73 +
arch/arm/include/asm/arch-stv0991/stv0991_cgu.h| 80 ++
arch/arm/include/asm/arch-stv0991/stv0991_creg.h | 82 ++
arch/arm/include/asm/arch-stv0991/stv0991_defs.h | 16 +++
arch/arm/include/asm/arch-stv0991/stv0991_gpt.h| 43
arch/arm/include/asm/arch-stv0991/stv0991_periph.h | 43
arch/arm/include/asm/arch-stv0991/stv0991_wdru.h | 28 +
board/st/stv0991/Kconfig | 23
board/st/stv0991/Makefile |8 ++
board/st/stv0991/stv0991.c | 54 ++
configs/stv0991_defconfig |3 +
include/configs/stv0991.h | 58 ++
19 files changed, 752 insertions(+)
create mode 100644 arch/arm/cpu/armv7/stv0991/Makefile
create mode 100644 arch/arm/cpu/armv7/stv0991/clock.c
create mode 100644 arch/arm/cpu/armv7/stv0991/lowlevel.S
create mode 100644 arch/arm/cpu/armv7/stv0991/pinmux.c
create mode 100644 arch/arm/cpu/armv7/stv0991/reset.c
create mode 100644 arch/arm/cpu/armv7/stv0991/timer.c
create mode 100644 arch/arm/include/asm/arch-stv0991/hardware.h
create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_cgu.h
create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_creg.h
create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_defs.h
create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_gpt.h
create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_periph.h
create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_wdru.h
create mode 100644 board/st/stv0991/Kconfig
create mode 100644 board/st/stv0991/Makefile
create mode 100644 board/st/stv0991/stv0991.c
create mode 100644 configs/stv0991_defconfig
create mode 100644 include/configs/stv0991.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3955978..71faf5e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -339,6 +339,10 @@ config TARGET_SPEAR600
bool Support spear600
select CPU_ARM926EJS
+config TARGET_STV0991
+ bool Support stv0991
+ select CPU_V7
+
config TARGET_X600
bool Support x600
select CPU_ARM926EJS
@@ -932,6 +936,7 @@ source board/spear/spear600/Kconfig
source board/spear/x600/Kconfig
source board/st-ericsson/snowball/Kconfig
source board/st-ericsson/u8500/Kconfig
+source board/st/stv0991/Kconfig
source board/sunxi/Kconfig
source board/syteco/jadecpu/Kconfig
source board/syteco/zmx25/Kconfig
diff --git a/arch/arm/cpu/armv7/stv0991/Makefile
b/arch/arm/cpu/armv7/stv0991/Makefile
new file mode 100644
index 000..95641d3
--- /dev/null
+++ b/arch/arm/cpu/armv7/stv0991/Makefile
@@ -0,0 +1,9 @@
+#
+# (C) Copyright 2014
+# Vikas Manocha, ST Microelectronics, vikas.manocha@stcom
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y:= timer.o clock.o pinmux.o reset.o
+obj-y+= lowlevel.o
diff --git a/arch/arm/cpu/armv7/stv0991/clock.c
b/arch/arm/cpu/armv7/stv0991/clock.c
new file mode 100644
index 000..aca6aba
--- /dev/null
+++ b/arch/arm/cpu/armv7/stv0991/clock.c
@@ -0,0 +1,27 @@
+/*
+ * (C) Copyright 2014
+ * Vikas Manocha, ST Micoelectronics, vikas.mano...@st.com.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include asm/io.h
+#include asm/arch/hardware.h
+#include asm/arch/stv0991_cgu.h
+#includeasm/arch/stv0991_periph.h
+
+static struct stv0991_cgu_regs *const stv0991_cgu_regs = \
+ (struct stv0991_cgu_regs *) (CGU_BASE_ADDR);
+
+void clock_setup(int peripheral)
+{
+ switch (peripheral) {
+ case UART_CLOCK_CFG:
+
Re: [U-Boot] [PATCH v4 3/4] stv0991: default + misc command configs enabled
Hello Albert, On 11/17/2014 11:29 PM, Albert ARIBAUD wrote: Hello Vikas, (nitpicking) can you replace '+' in the subject with 'and' ? ok, i will submit the v5. (nitpicking yet more) can you keep the action form for the subject rather than action done, i.e., stv0991: enable default and misc command configs ok. Amicalement, Rgds, Vikas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/4] add support for new arch stv0991
Hello Simon, On 11/17/2014 09:19 PM, Simon Glass wrote: Hi Vikas, On 18 November 2014 01:30, Vikas Manocha vikas.mano...@st.com wrote: This patchset add support for new arch stv0991. Changes in v4: - rebased to current master - added maintainers info Changes in v3: - removed period from commit messages Changes in v2: - corrected files license to GPL-2.0+ - replaced printf() usage with puts() for string print - sorted sourcing of board Kconfig Vikas Manocha (4): stv0991: Add basic stv0991 architecture support stv0991: enable ethernet support stv0991: default + misc command configs enabled stv0991: add maintainer information Can you please look at using driver model for this board? It would be particularly valuable since it looks like you are using the pl011 UART which has not previously been tested with driver model (and it seems you found some problems). To do this you probably only need to adjust a few defines and add platform data for serial. A patch for Raspberry Pi is here: http://patchwork.ozlabs.org/patch/392180/ Sure, Simon. Infact i was also planning to use the driver model. Thanks for sharing the Raspberry patch link. Rgds, Vikas MAINTAINERS|6 + arch/arm/Kconfig |5 + arch/arm/cpu/armv7/stv0991/Makefile|9 ++ arch/arm/cpu/armv7/stv0991/clock.c | 41 +++ arch/arm/cpu/armv7/stv0991/lowlevel.S | 12 ++ arch/arm/cpu/armv7/stv0991/pinmux.c| 62 +++ arch/arm/cpu/armv7/stv0991/reset.c | 26 + arch/arm/cpu/armv7/stv0991/timer.c | 114 +++ arch/arm/include/asm/arch-stv0991/gpio.h | 22 arch/arm/include/asm/arch-stv0991/hardware.h | 73 arch/arm/include/asm/arch-stv0991/stv0991_cgu.h| 116 arch/arm/include/asm/arch-stv0991/stv0991_creg.h | 95 arch/arm/include/asm/arch-stv0991/stv0991_defs.h | 16 +++ arch/arm/include/asm/arch-stv0991/stv0991_gpt.h| 43 arch/arm/include/asm/arch-stv0991/stv0991_periph.h | 44 arch/arm/include/asm/arch-stv0991/stv0991_wdru.h | 28 + board/st/stv0991/Kconfig | 23 board/st/stv0991/MAINTAINERS |5 + board/st/stv0991/Makefile |8 ++ board/st/stv0991/stv0991.c | 91 +++ configs/stv0991_defconfig |3 + include/configs/stv0991.h | 88 +++ 22 files changed, 930 insertions(+) create mode 100644 arch/arm/cpu/armv7/stv0991/Makefile create mode 100644 arch/arm/cpu/armv7/stv0991/clock.c create mode 100644 arch/arm/cpu/armv7/stv0991/lowlevel.S create mode 100644 arch/arm/cpu/armv7/stv0991/pinmux.c create mode 100644 arch/arm/cpu/armv7/stv0991/reset.c create mode 100644 arch/arm/cpu/armv7/stv0991/timer.c create mode 100644 arch/arm/include/asm/arch-stv0991/gpio.h create mode 100644 arch/arm/include/asm/arch-stv0991/hardware.h create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_cgu.h create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_creg.h create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_defs.h create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_gpt.h create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_periph.h create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_wdru.h create mode 100644 board/st/stv0991/Kconfig create mode 100644 board/st/stv0991/MAINTAINERS create mode 100644 board/st/stv0991/Makefile create mode 100644 board/st/stv0991/stv0991.c create mode 100644 configs/stv0991_defconfig create mode 100644 include/configs/stv0991.h Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] driver/ddr/fsl: Fix tMOD calculation for DDR3
JEDEC specifies tMOD = max(12nCK, 15ns) for DDR3. This value is used in mode register set cycle time. Signed-off-by: York Sun york...@freescale.com --- drivers/ddr/fsl/ctrl_regs.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c index 9a156bf..6fa7165 100644 --- a/drivers/ddr/fsl/ctrl_regs.c +++ b/drivers/ddr/fsl/ctrl_regs.c @@ -327,7 +327,12 @@ static void set_timing_cfg_0(fsl_ddr_cfg_regs_t *ddr, */ txp = max(mclk_ps * 3, (mclk_ps 1540 ? 7500 : 6000)); - tmrd_mclk = 4; + /* +* MRS_CYC = max(tMRD, tMOD) +* tMRD = 4nCK, tMOD = max(12nCK, 15ns) +*/ + tmrd_mclk = max(12, picos_to_mclk(15000)); + /* set the turnaround time */ /* -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Query on CONFIG_SYS_THUMB_BUILD
On 2014-11-18 17:07, Stefan Agner wrote:
On 2014-11-14 15:01, Simon Glass wrote:
Hi Victor,
On 13 November 2014 09:29, Victor Ascroft victorascr...@gmail.com wrote:
Hello,
I am working with a Cortex A5 Freescale Vybrid Processor. Since a thumb
build leads to a saving of almost 1 MB for my u-boot image and consequently
to faster serial downloads I have been looking at this. Currently enabling
this option leads to a hang.
After some debugging I have narrowed the place of hang to ldr pc,
=board_init_r in arch/arm/lib/crt0.S. My debugging procedure was to put a
branch to a small function which just printed a small message with puts,
just before the ldr instruction and then a printing a small message with
puts just at the start of board_init_r in common/board_r.c . For a non
thumb build, the two messages get printed and I can boot to the u-boot
prompt. For a thumb build, only the first message before the ldr
instruction gets printed.
In crt0.S
bl debug_print
ldr pc, =board_init_r
In board_init_r
puts(In board_init_r\n); // Right at start
void debug_print(void)
{
// Defined in board file
puts(Debug print\n);
}
My assembly knowledge is limited and after some consultation with a senior
colleague, he told me things to check.
An object dump of the crt0.o shows a branch to an even address. For thumb,
this is expected to be odd. To just try out, I did a change as below
ldr r3, =board_init_r
add r3, #1
bx r3
No change with this. My expectation was the compiler/linker/assembler would
take care of the requirements, with the CONFIG_SYS_THUMB_BUILD. Frankly
speaking I am not sure if this is the complete issue or only a part of it.
I have seen patches with regards to OMAP send in by Aneesh V, which made
changes of the form .type fn_name, %function to all the low level assembly
functions, but, I couldn't dig up much more or variants thereof. Basically,
from what I understand, this takes care of specifying .thumb_func for a
thumb function or so to speak.
Any pointers?
I tried this on a peach_pi (Samsung Chromebook 2 13) and it worked OK
for me. The code sequence you refer to came out as below for me.
23e01e10 clbss_l:
23e01e10: e151cmp r0, r1
23e01e14: 35802000strcc r2, [r0]
23e01e18: 3284addcc r0, r0, #4
23e01e1c: 3afbbcc 23e01e10 clbss_l
23e01e20: fa000decblx 23e055d8 coloured_LED_init
23e01e24: fb000debblx 23e055da red_led_on
23e01e28: e1a9mov r0, r9
23e01e2c: e5991030ldr r1, [r9, #48] ; 0x30
23e01e30: e59ff008ldr pc, [pc, #8]; 23e01e40
clbss_l+0x30
23e01e34: 02073800.word 0x02073800
23e01e38: 23e41eb0.word 0x23e41eb0
23e01e3c: 23e77bf0.word 0x23e77bf0
23e01e40: 23e057a9.word 0x23e057a9
The 'ldr pc' line is loading from 23e01e40 which does have an odd address.
What toolchain are you using? I tried with gcc 4.8.2 - including
linaro's 2013.10 release.
In arch/arm/cpu/armv7/config.mk there is a fallback to armv5 from
armv7-a, and this may cause it to generate Thumb code instead of Thumb
2. But you should get errors if that happens.
It's hard to debug with such limited visibility. But if I put a puts()
at the start of board_init_r(), I see it on the serial console.
Ok, turns out the problem with Thumb2 only appear when using
CONFIG_USE_ARCH_MEMCPY (hence added Matthias to CC). Does peach_pi still
works with that config enabled? On the Vybrid board we use that to speed
up NAND access, with the current NAND driver, data get copied by the
CPU.
In setup_reloc, common/board_f.c, probably the first use of memcpy,
things started to get weird. The code after memcpy doesn't get executed,
I think something with the stack goes wrong, but not really sure what
happens.
It seems that this memcpy implementation is not able to be run in ARM
mode when called from Thumb2 code. Checked the Linux kernel, since
that's where that file comes from, they compile a Thumb2 version of that
file when compiling the kernel in Thumb2 mode. With some changes I also
managed to compile that file in Thumb2 in U-Boot:
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index f0eafd6..ddbc8dc 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -30,6 +30,8 @@ PF_CPPFLAGS_ARM := $(call cc-option, -mthumb
-mthumb-interwork,\
$(call cc-option,-marm,)\
$(call cc-option,-mno-thumb-interwork,)\
)
+AFLAGS_AUTOIT :=$(call
as-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mauto-it)
+PF_CPPFLAGS_ARM += $(AFLAGS_AUTOIT)
else
PF_CPPFLAGS_ARM := $(call cc-option,-marm,) \
$(call cc-option,-mno-thumb-interwork,)
diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
index f655256..fcf028c 100644
---
Re: [U-Boot] [SOLVED] loadb problem.
Dear Bo, In message 1416300182202-196641.p...@n7.nabble.com you wrote: Upon looking at the transfers more closely on the scope, I found that the board sometimes answered the PC in the middle of receiving a packet. I found that this was due to a global DEBUG being turned on in the configuration file for the board. When I removed all of the following: #define DEBUG #define CONFIG_DEBUG_DUMP #define CONFIG_DEBUG_DUMP_SYMS #define CONFIG_DEBUG_EARLY_SERIAL #define CONFIG_DEBUG_NULL_PTR #define TESTING the Kermit transfers are fine, with approximately 4 kilobytes per second transfer rate. Ah, so obviously one of these options spits out data on the serial line, which then breaks the prtocol? We should find and fix that. Let's see... CONFIG_DEBUG_DUMP is only used in arch/blackfin/cpu/traps.c and arch/blackfin/cpu/cpu.c - that should not affect you. CONFIG_DEBUG_DUMP_SYMS is only defined in include/configs/blackstamp.h and include/configs/blackvme.h but not used anywhere. CONFIG_DEBUG_EARLY_SERIAL is also only defined in these two BF boards, and used only in BF code (arch/blackfin/cpu/cpu.c, arch/blackfin/include/asm/serial.h, and drivers/serial/serial_bfin.c). CONFIG_DEBUG_NULL_PTR is only used in arch/blackfin/cpu/cpu.c - that should not affect you. TESTING is nowhere used or defined in mainline code. So unless you have added any such debug code to your own board specific code, the only potential culprit is DEBUG ... But then, I cannot find any DEBUG or debug() or similar code in cmd_load.c ... Can you please verify if you have added any such debug code in your local tree? Thank you for your time. Hopefully this can help someone in the future. You are welcome. 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 Mirrors should reflect a little before throwing back images. - Jean Cocteau ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 1/3] stv0991: Add basic stv0991 architecture support
stv0991 architecture support added. It contains the support for following blocks - Timer - uart Signed-off-by: Vikas Manocha vikas.mano...@st.com --- Changes in v5: - added maintainers info Changes in v4: - added maintainers info - rebased to current master Changes in v3: - removed period from commit message Changes in v2: - corrected files license to GPL-2.0+ - replaced printf() usage with puts() for string print MAINTAINERS|6 ++ arch/arm/Kconfig |5 + arch/arm/cpu/armv7/stv0991/Makefile|9 ++ arch/arm/cpu/armv7/stv0991/clock.c | 27 + arch/arm/cpu/armv7/stv0991/lowlevel.S | 12 +++ arch/arm/cpu/armv7/stv0991/pinmux.c| 48 + arch/arm/cpu/armv7/stv0991/reset.c | 26 + arch/arm/cpu/armv7/stv0991/timer.c | 114 arch/arm/include/asm/arch-stv0991/hardware.h | 73 + arch/arm/include/asm/arch-stv0991/stv0991_cgu.h| 80 ++ arch/arm/include/asm/arch-stv0991/stv0991_creg.h | 82 ++ arch/arm/include/asm/arch-stv0991/stv0991_defs.h | 16 +++ arch/arm/include/asm/arch-stv0991/stv0991_gpt.h| 43 arch/arm/include/asm/arch-stv0991/stv0991_periph.h | 43 arch/arm/include/asm/arch-stv0991/stv0991_wdru.h | 28 + board/st/stv0991/Kconfig | 23 board/st/stv0991/MAINTAINERS |5 + board/st/stv0991/Makefile |8 ++ board/st/stv0991/stv0991.c | 54 ++ configs/stv0991_defconfig |3 + include/configs/stv0991.h | 58 ++ 21 files changed, 763 insertions(+) create mode 100644 arch/arm/cpu/armv7/stv0991/Makefile create mode 100644 arch/arm/cpu/armv7/stv0991/clock.c create mode 100644 arch/arm/cpu/armv7/stv0991/lowlevel.S create mode 100644 arch/arm/cpu/armv7/stv0991/pinmux.c create mode 100644 arch/arm/cpu/armv7/stv0991/reset.c create mode 100644 arch/arm/cpu/armv7/stv0991/timer.c create mode 100644 arch/arm/include/asm/arch-stv0991/hardware.h create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_cgu.h create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_creg.h create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_defs.h create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_gpt.h create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_periph.h create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_wdru.h create mode 100644 board/st/stv0991/Kconfig create mode 100644 board/st/stv0991/MAINTAINERS create mode 100644 board/st/stv0991/Makefile create mode 100644 board/st/stv0991/stv0991.c create mode 100644 configs/stv0991_defconfig create mode 100644 include/configs/stv0991.h diff --git a/MAINTAINERS b/MAINTAINERS index c8386ab..950daf2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -128,6 +128,12 @@ T: git git://git.denx.de/u-boot-stm.git F: arch/arm/cpu/arm926ejs/spear/ F: arch/arm/include/asm/arch-spear/ +ARM STM STV0991 +M: Vikas Manocha vikas.mano...@st.com +S: Maintained +F: arch/arm/cpu/armv7/stv0991/ +F: arch/arm/include/asm/arch-stv0991/ + ARM SUNXI M: Ian Campbell i...@hellion.org.uk M: Hans De Goede hdego...@redhat.com diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3955978..71faf5e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -339,6 +339,10 @@ config TARGET_SPEAR600 bool Support spear600 select CPU_ARM926EJS +config TARGET_STV0991 + bool Support stv0991 + select CPU_V7 + config TARGET_X600 bool Support x600 select CPU_ARM926EJS @@ -932,6 +936,7 @@ source board/spear/spear600/Kconfig source board/spear/x600/Kconfig source board/st-ericsson/snowball/Kconfig source board/st-ericsson/u8500/Kconfig +source board/st/stv0991/Kconfig source board/sunxi/Kconfig source board/syteco/jadecpu/Kconfig source board/syteco/zmx25/Kconfig diff --git a/arch/arm/cpu/armv7/stv0991/Makefile b/arch/arm/cpu/armv7/stv0991/Makefile new file mode 100644 index 000..95641d3 --- /dev/null +++ b/arch/arm/cpu/armv7/stv0991/Makefile @@ -0,0 +1,9 @@ +# +# (C) Copyright 2014 +# Vikas Manocha, ST Microelectronics, vikas.manocha@stcom +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y := timer.o clock.o pinmux.o reset.o +obj-y += lowlevel.o diff --git a/arch/arm/cpu/armv7/stv0991/clock.c b/arch/arm/cpu/armv7/stv0991/clock.c new file mode 100644 index 000..aca6aba --- /dev/null +++ b/arch/arm/cpu/armv7/stv0991/clock.c @@ -0,0 +1,27 @@ +/* + * (C) Copyright 2014 + * Vikas Manocha, ST Micoelectronics, vikas.mano...@st.com. + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include asm/io.h +#include asm/arch/hardware.h +#include asm/arch/stv0991_cgu.h
[U-Boot] [PATCH v5 0/3] add support for new arch stv0991
This patchset add support for new arch stv0991. Changes in v5: - merged maintainers info in first patch of the series - replaced '+' with 'and' in the patch subject line - patch subject changed to active voice from passive Changes in v4: - rebased to current master - added maintainers info Changes in v3: - removed period from commit messages Changes in v2: - corrected files license to GPL-2.0+ - replaced printf() usage with puts() for string print - sorted sourcing of board Kconfig Vikas Manocha (3): stv0991: Add basic stv0991 architecture support stv0991: enable ethernet support stv0991: enable default and misc command configs MAINTAINERS|6 + arch/arm/Kconfig |5 + arch/arm/cpu/armv7/stv0991/Makefile|9 ++ arch/arm/cpu/armv7/stv0991/clock.c | 41 +++ arch/arm/cpu/armv7/stv0991/lowlevel.S | 12 ++ arch/arm/cpu/armv7/stv0991/pinmux.c| 62 +++ arch/arm/cpu/armv7/stv0991/reset.c | 26 + arch/arm/cpu/armv7/stv0991/timer.c | 114 +++ arch/arm/include/asm/arch-stv0991/gpio.h | 22 arch/arm/include/asm/arch-stv0991/hardware.h | 73 arch/arm/include/asm/arch-stv0991/stv0991_cgu.h| 116 arch/arm/include/asm/arch-stv0991/stv0991_creg.h | 95 arch/arm/include/asm/arch-stv0991/stv0991_defs.h | 16 +++ arch/arm/include/asm/arch-stv0991/stv0991_gpt.h| 43 arch/arm/include/asm/arch-stv0991/stv0991_periph.h | 44 arch/arm/include/asm/arch-stv0991/stv0991_wdru.h | 28 + board/st/stv0991/Kconfig | 23 board/st/stv0991/MAINTAINERS |5 + board/st/stv0991/Makefile |8 ++ board/st/stv0991/stv0991.c | 91 +++ configs/stv0991_defconfig |3 + include/configs/stv0991.h | 88 +++ 22 files changed, 930 insertions(+) create mode 100644 arch/arm/cpu/armv7/stv0991/Makefile create mode 100644 arch/arm/cpu/armv7/stv0991/clock.c create mode 100644 arch/arm/cpu/armv7/stv0991/lowlevel.S create mode 100644 arch/arm/cpu/armv7/stv0991/pinmux.c create mode 100644 arch/arm/cpu/armv7/stv0991/reset.c create mode 100644 arch/arm/cpu/armv7/stv0991/timer.c create mode 100644 arch/arm/include/asm/arch-stv0991/gpio.h create mode 100644 arch/arm/include/asm/arch-stv0991/hardware.h create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_cgu.h create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_creg.h create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_defs.h create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_gpt.h create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_periph.h create mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_wdru.h create mode 100644 board/st/stv0991/Kconfig create mode 100644 board/st/stv0991/MAINTAINERS create mode 100644 board/st/stv0991/Makefile create mode 100644 board/st/stv0991/stv0991.c create mode 100644 configs/stv0991_defconfig create mode 100644 include/configs/stv0991.h -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/3] stv0991: enable ethernet support
Signed-off-by: Vikas Manocha vikas.mano...@st.com
---
Changes in v5: None
Changes in v4: None
Changes in v3:
- removed period from commit message
arch/arm/cpu/armv7/stv0991/clock.c | 14
arch/arm/cpu/armv7/stv0991/pinmux.c| 14
arch/arm/include/asm/arch-stv0991/gpio.h | 22
arch/arm/include/asm/arch-stv0991/stv0991_cgu.h| 36 +++
arch/arm/include/asm/arch-stv0991/stv0991_creg.h | 13 +++
arch/arm/include/asm/arch-stv0991/stv0991_periph.h |1 +
board/st/stv0991/stv0991.c | 37
include/configs/stv0991.h | 15 +++-
8 files changed, 151 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/include/asm/arch-stv0991/gpio.h
diff --git a/arch/arm/cpu/armv7/stv0991/clock.c
b/arch/arm/cpu/armv7/stv0991/clock.c
index aca6aba..70b8a8d 100644
--- a/arch/arm/cpu/armv7/stv0991/clock.c
+++ b/arch/arm/cpu/armv7/stv0991/clock.c
@@ -13,6 +13,13 @@
static struct stv0991_cgu_regs *const stv0991_cgu_regs = \
(struct stv0991_cgu_regs *) (CGU_BASE_ADDR);
+void enable_pll1(void)
+{
+ /* pll1 already configured for 1000Mhz, just need to enable it */
+ writel(readl(stv0991_cgu_regs-pll1_ctrl) ~(0x01),
+ stv0991_cgu_regs-pll1_ctrl);
+}
+
void clock_setup(int peripheral)
{
switch (peripheral) {
@@ -20,6 +27,13 @@ void clock_setup(int peripheral)
writel(UART_CLK_CFG, stv0991_cgu_regs-uart_freq);
break;
case ETH_CLOCK_CFG:
+ enable_pll1();
+ writel(ETH_CLK_CFG, stv0991_cgu_regs-eth_freq);
+
+ /* Clock selection for ethernet tx_clk rx_clk*/
+ writel((readl(stv0991_cgu_regs-eth_ctrl) ETH_CLK_MASK)
+ | ETH_CLK_CTRL, stv0991_cgu_regs-eth_ctrl);
+
break;
default:
break;
diff --git a/arch/arm/cpu/armv7/stv0991/pinmux.c
b/arch/arm/cpu/armv7/stv0991/pinmux.c
index 6d4414a..1d086a2 100644
--- a/arch/arm/cpu/armv7/stv0991/pinmux.c
+++ b/arch/arm/cpu/armv7/stv0991/pinmux.c
@@ -41,6 +41,20 @@ int stv0991_pinmux_config(int peripheral)
CFG_GPIOB_16_UART_TX,
stv0991_creg-mux7);
break;
+ case ETH_GPIOB_10_31_C_0_4:
+ writel(readl(stv0991_creg-mux6) 0x00FF,
+ stv0991_creg-mux6);
+ writel(0x, stv0991_creg-mux7);
+ writel(0x, stv0991_creg-mux8);
+ writel(readl(stv0991_creg-mux9) 0xFFF0,
+ stv0991_creg-mux9);
+ /* Ethernet Voltage configuration to 1.8V*/
+ writel((readl(stv0991_creg-vdd_pad1) VDD_ETH_PS_MASK) |
+ ETH_VDD_CFG, stv0991_creg-vdd_pad1);
+ writel((readl(stv0991_creg-vdd_pad1) VDD_ETH_PS_MASK) |
+ ETH_M_VDD_CFG, stv0991_creg-vdd_pad1);
+
+ break;
default:
break;
}
diff --git a/arch/arm/include/asm/arch-stv0991/gpio.h
b/arch/arm/include/asm/arch-stv0991/gpio.h
new file mode 100644
index 000..9131ded
--- /dev/null
+++ b/arch/arm/include/asm/arch-stv0991/gpio.h
@@ -0,0 +1,22 @@
+/*
+ * (C) Copyright 2014
+ * Vikas Manocha, ST Micoelectronics, vikas.mano...@st.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __ASM_ARCH_STV0991_GPIO_H
+#define __ASM_ARCH_STV0991_GPIO_H
+
+enum gpio_direction {
+ GPIO_DIRECTION_IN,
+ GPIO_DIRECTION_OUT,
+};
+
+struct gpio_regs {
+ u32 data; /* offset 0x0 */
+ u32 reserved[0xff]; /* 0x4--0x3fc */
+ u32 dir;/* offset 0x400 */
+};
+
+#endif /* __ASM_ARCH_STV0991_GPIO_H */
diff --git a/arch/arm/include/asm/arch-stv0991/stv0991_cgu.h
b/arch/arm/include/asm/arch-stv0991/stv0991_cgu.h
index 4926395..ddcbb57 100644
--- a/arch/arm/include/asm/arch-stv0991/stv0991_cgu.h
+++ b/arch/arm/include/asm/arch-stv0991/stv0991_cgu.h
@@ -77,4 +77,40 @@ struct stv0991_cgu_regs {
#define UART_CLK_CFG (4 DIV_SHIFT_UART \
| 1 MDIV_SHIFT_UART | CLK_UART_MCLK)
+/* CGU Ethernet clock config */
+#define CLK_ETH_MCLK 0
+#define CLK_ETH_PLL1 1
+#define CLK_ETH_PLL2 2
+
+#define MDIV_SHIFT_ETH 3
+#define DIV_SHIFT_ETH 6
+#define DIV_ETH_1259
+#define DIV_ETH_50 12
+#define DIV_ETH_P2P15
+
+#define ETH_CLK_CFG(4 DIV_ETH_P2P | 4 DIV_ETH_50 \
+ | 1 DIV_ETH_125 \
+ | 0 DIV_SHIFT_ETH \
+ | 3 MDIV_SHIFT_ETH |
[U-Boot] [PATCH v5 3/3] stv0991: enable default and misc command configs
Signed-off-by: Vikas Manocha vikas.mano...@st.com --- Changes in v5: - replaced '+' with 'and' in the patch subject line - patch subject changed to active voice from passive Changes in v4: None Changes in v3: - removed period from commit message Changes in v2: None include/configs/stv0991.h | 21 +++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/include/configs/stv0991.h b/include/configs/stv0991.h index a316f63..f95de06 100644 --- a/include/configs/stv0991.h +++ b/include/configs/stv0991.h @@ -8,7 +8,6 @@ #ifndef __CONFIG_STV0991_H #define __CONFIG_STV0991_H #define CONFIG_SYS_DCACHE_OFF -#define CONFIG_SYS_ICACHE_OFF #define CONFIG_SYS_EXCEPTION_VECTORS_HIGH #define CONFIG_BOARD_EARLY_INIT_F @@ -40,7 +39,7 @@ /* user interface */ #define CONFIG_SYS_PROMPT STV0991 -#define CONFIG_SYS_CBSIZE 256/* Console I/O Buffer Size */ +#define CONFIG_SYS_CBSIZE 1024 #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE \ +sizeof(CONFIG_SYS_PROMPT) + 16) @@ -68,4 +67,22 @@ #define CONFIG_CMD_PING #define CONFIG_PHY_RESET_DELAY 1 /* in usec */ +#include config_cmd_default.h +#undef CONFIG_CMD_SAVEENV + +#define CONFIG_SYS_MEMTEST_START 0x +#define CONFIG_SYS_MEMTEST_END 1024*1024 +#define CONFIG_CMD_MEMTEST + +/* Misc configuration */ +#define CONFIG_SYS_LONGHELP +#define CONFIG_CMDLINE_EDITING + +#define CONFIG_BOOTDELAY 3 +#define CONFIG_BOOTCOMMAND go 0x4004 +#define CONFIG_AUTOBOOT_KEYED +#define CONFIG_AUTOBOOT_STOP_STR +#define CONFIG_AUTOBOOT_PROMPT \ + Hit SPACE in %d seconds to stop autoboot.\n, bootdelay + #endif /* __CONFIG_H */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] PL01x: baudrate line control fixes
Thanks Simon, On 11/17/2014 09:30 PM, Simon Glass wrote: Hi Vikas, On 18 November 2014 00:17, Vikas Manocha vikas.mano...@st.com wrote: This patchset fixes the pl01x driver esp for pl011 baudrate line control. Vikas Manocha (5): serial: pl01x: pass pl01x_type to set baudrate serial: pl01x: fix pl011 baud rate configuration serial: pl01x: move all line control at same place serial: pl01x: disable as per type of pl01x serial: pl01x: avoid pl01x type check two times drivers/serial/serial_pl01x.c | 46 + 1 file changed, 24 insertions(+), 22 deletions(-) Great to see this series. If you have not tested on p1010 I can do this in a week or so (am travelling). At least a few of these looks like bug fixes to my recent refactor so I could bring them through the DM tree if no one else picks them up. I was able to test it only for pl011, don't have any board with pl010. Regards, Simon Rgds, Vikas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: gmac: Update bananapi fixup to the new CONFIG_TARGET_BOARD structure
On Tue, 2014-11-11 at 13:21 +0100, Zoltan HERPAI wrote: The magic bit toucher needs to be updated to reflect the new board Kconfig structure Signed-off-by: Zoltan HERPAI wigy...@uid0.hu Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] spl: MMC U-Boot image load from raw partition
Hello Tom, On Tue, 18 Nov 2014 08:52:37 -0500, Tom Rini tr...@ti.com wrote: On Sat, Nov 15, 2014 at 09:27:20PM +0100, Albert ARIBAUD wrote: Hello Paul, On Thu, 13 Nov 2014 23:16:09 +0100, Paul Kocialkowski cont...@paulk.fr wrote: [snip] Well I think it makes sense to not call this dead code as long as it *can be* enabled and used on another supported board (for that matter, any OMAP3+ board will indeed do). If no board is calling this code right now, that is because none needs it. If none needs it, then it has no reason to be added. The day some board needs this code, the patch to add this code can be submitted along with the patch that calls this code. This is very different from e.g. the regulator code that I submitted, which is only relevant for devices with that particular piece of hardware (so far, none supported by U-Boot). So it makes sense to submit that regulator patch only along with support for a board that uses it. I don't see the difference. But this is where I see a difference, tomorrow. Setting this, or not setting this new behavior is a Kconfig choice (in Kconfig-speak). We do not need a defconfig in-tree for every single possible choice since at some point we'll do like other Kconfig-based projects and have randconfig builds possible to cover odd choices, along with allyesconfig and allnoconfig to cover the things which people clearly need _somewhere_ (and feel the (good!) need to post them in public to help others) but may not be able to post the whole board port (not the case here per-se but see the various RTC drivers that get posted from time to time). I still don't agree, as a Kconfig option is no different from any other addition, so I consider that we should only introduce a Kconfig choice because/when it is needed, not just because it could be needed; but you're the boss. -- Tom Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [SOLVED] loadb problem.
The TESTING variable was defined to debug the Spifilib library that is needed for quad spi flash on lpc cpus. As you can see in the very first post, I made some printfs and a 10 ms delay. I removed those as well, so in the end perhaps they were the culprit. I had a previous loady problem, which was definately solved by commenting out all Debugs. -- View this message in context: http://u-boot.10912.n7.nabble.com/loadb-problem-Hangs-on-START-CHAR-tp195144p196714.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot, fsl_espi.c driver
On 18 November 2014 14:42, Joakim Tjernlund
joakim.tjernl...@transmode.se wrote:
Ping?
Joakim Tjernlund/Transmode wrote on 2014/10/29 19:43:14:
Couldn't understand what discussion is going, does some issue in
driver or any plan to
write new code, please let me know - we can plan accordingly and kill
the thread.
mingkai...@freescale.com mingkai...@freescale.com wrote on
2014/10/28 12:17:24:
Hi Joakim and York,
Hi yourself, been travelling or a few days.
I apologize for the delayed response and thanks for your catch up,
Joakim
In order to get a higher transfer speed, the eSPI controller was
designed to transfer multiple bytes at one transaction which is not comply
with the SPI framework and the CS can't be inactive until one transfer
finished, so we need to combine the multiple transfers into one transfer,
that's the reason why there are more memory copy back and forth.
hmm, can't make sense of this. If you can memcpy from/to memory you can
also write/read the SPI FIFO
Also writing 4 bytes to the SPI FIFO at a time will not but you much if
anything at all. It just
makes it impossible to use NF flag etc.
Speed will come from keeping the SPI FIFO non empty and not copying
memory back and fourth.
CS can be controlled within the SPI framework already.
The driver has been tested on SPI flash and the transfer length larger
than max_trans_len should be handled but half-duplex
was not handled. Is it possible to provide patch to make it workable for
different devices?
Not as the driver is written today.
0x0b is the FAST READ command. The logic here is to move the pointer
of receive buffer to receive new data when reading from NOR flash and the
reading length is larger than the max_trans_len.
What FAST READ command? Sounds like it is connected to the FLASH rather
than SPI? if so that
need to go from the SPI driver and moved into some board specific addon.
Thanks,
Mingkai
From: Sun York-R58495
Sent: Thursday, October 23, 2014 6:14 AM
To: jagan Teki; Hu Mingkai-B21284
Cc: Joakim Tjernlund; Hou Zhiqiang-B48286; u-boot@lists.denx.de
Subject: Re: u-boot, fsl_espi.c driver
Jagan and Mingkai,
Would you take a look when you have a chance?
York
On 10/22/2014 03:12 PM, Joakim Tjernlund wrote:
York Sun york...@freescale.com wrote on 2014/10/09 20:06:31:
Dear Joakim,
On 10/09/2014 10:43 AM, Joakim Tjernlund wrote:
York Sun york...@freescale.com wrote on 2014/10/09 18:25:40:
Dear Joakim,
Thanks for raising a concern.
It's not fair to blame the last person who submitted a patch. We
are
all
working
No of course not, I just noticed you guys had been in there and
patched up
some problem
so I hoped you would be interested to fix the remaining problems.
This
driver should never
have been committed in the first place.
to make it better as an opensource comminuty. You have done a
good
job
to hack
it to work. Would it be nicer if you can submit this or improved
patch
to u-boot
community for further review and testing, after putting informing
commit
message? The mailing list address is CC'ed.
Main problem with this driver is that TX does not work for:
len max_tran_len (nor does RX)
does not TX the last odd bytes(len % 4 != 0)
Does not work with TX only(RX buf == NULL)
Silently ignores SPI_LSB_FIRST
On top of that it uses malloc all over and copies data back and
forth
for
no good
reason, image a big SPI transfer with many MB(like my FPGA load).
I am not in a good position fix this properly as my FPGA is TX
only so
I
cannot test
RX at all(which is broken by my hack)
Finally, just to illustrate the merits of this driver, after
transmission
is done
there is:
if (*buffer == 0x0b) {
data_in += tran_len;
data_len -= tran_len;
*(int *)buffer += tran_len;
}
what is the magic 0x0b test all about?
Thanks for the report. Driver maintainer (CC'ed) will take a look.
York
No reaction from maintainers, I don't think this driver is still
maintained.
Jocke
thanks!
--
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ] MMC: add MMC_VERSION_5_0
Acked-by: Jaehoon Chung jh80.ch...@samsung.com On 11/18/2014 11:13 PM, Markus Niebel wrote: From: Markus Niebel markus.nie...@tq-group.com Signed-off-by: Markus Niebel markus.nie...@tq-group.com --- drivers/mmc/mmc.c | 3 +++ include/mmc.h | 1 + 2 files changed, 4 insertions(+) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 24b0989..144c7f7 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -1001,6 +1001,9 @@ static int mmc_startup(struct mmc *mmc) case 6: mmc-version = MMC_VERSION_4_5; break; + case 7: + mmc-version = MMC_VERSION_5_0; + break; } /* diff --git a/include/mmc.h b/include/mmc.h index cb91565..51ee24b 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -31,6 +31,7 @@ #define MMC_VERSION_4_3 (MMC_VERSION_MMC | 0x403) #define MMC_VERSION_4_41 (MMC_VERSION_MMC | 0x429) #define MMC_VERSION_4_5 (MMC_VERSION_MMC | 0x405) +#define MMC_VERSION_5_0 (MMC_VERSION_MMC | 0x500) #define MMC_MODE_HS (1 0) #define MMC_MODE_HS_52MHz(1 1) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch v2] driver/ddr/fsl: Fix MRC_CYC calculation for DDR3
For DDR controller version 4.7 or newer, MRC_CYC (mode register set
cycle time) is max(tMRD, tMOD). tMRD is 4nCK, or 8nCK (RDIMM). tMOD
is max(12nCK, 15ns) according to JEDEC spec.
DDR4 is not affected by this change.
Signed-off-by: York Sun york...@freescale.com
---
Change log
v2: Apply the change only to DDR controller newer than v4.7
Older DDRC needs to take into account of RDIMM for tMRD
drivers/ddr/fsl/ctrl_regs.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c
index 9a156bf..7b28338 100644
--- a/drivers/ddr/fsl/ctrl_regs.c
+++ b/drivers/ddr/fsl/ctrl_regs.c
@@ -316,6 +316,7 @@ static void set_timing_cfg_0(fsl_ddr_cfg_regs_t *ddr,
#elif defined(CONFIG_SYS_FSL_DDR3)
unsigned int data_rate = get_ddr_freq(0);
int txp;
+ unsigned int ip_rev;
/*
* (tXARD and tXARDS). Empirical?
* The DDR3 spec has not tXARD,
@@ -327,7 +328,25 @@ static void set_timing_cfg_0(fsl_ddr_cfg_regs_t *ddr,
*/
txp = max(mclk_ps * 3, (mclk_ps 1540 ? 7500 : 6000));
- tmrd_mclk = 4;
+ ip_rev = fsl_ddr_get_version();
+ if (ip_rev = 0x40700) {
+ /*
+* MRS_CYC = max(tMRD, tMOD)
+* tMRD = 4nCK (8nCK for RDIMM)
+* tMOD = max(12nCK, 15ns)
+*/
+ tmrd_mclk = max(12, picos_to_mclk(15000));
+ } else {
+ /*
+* MRS_CYC = tMRD
+* tMRD = 4nCK (8nCK for RDIMM)
+*/
+ if (popts-registered_dimm_en)
+ tmrd_mclk = 8;
+ else
+ tmrd_mclk = 4;
+ }
+
/* set the turnaround time */
/*
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Freescale t104x: Do not exclude SGMII
On 10/24/2014 07:49 AM, Joakim Tjernlund wrote:
fman_port_enet_if() tests if FM1_DTSEC2 or FM1_DTSEC4 uses
RGMII or MII and if not returns PHY_INTERFACE_MODE_NONE.
This excludes testing for SGMII further down.
Remove the unconditional else return PHY_INTERFACE_MODE_NONE
so SGMII can be tested too.
Signed-off-by: Joakim Tjernlund joakim.tjernl...@transmode.se
---
drivers/net/fm/t1040.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/net/fm/t1040.c b/drivers/net/fm/t1040.c
index 4cce46d..d2a097e 100644
--- a/drivers/net/fm/t1040.c
+++ b/drivers/net/fm/t1040.c
@@ -25,8 +25,6 @@ phy_interface_t fman_port_enet_if(enum fm_port port)
else if ((rcwsr13 FSL_CORENET_RCWSR13_EC1) ==
FSL_CORENET_RCWSR13_EC1_FM1_DTSEC4_MII)
return PHY_INTERFACE_MODE_MII;
- else
- return PHY_INTERFACE_MODE_NONE;
}
if ((port == FM1_DTSEC4)
@@ -38,8 +36,6 @@ phy_interface_t fman_port_enet_if(enum fm_port port)
else if ((rcwsr13 FSL_CORENET_RCWSR13_EC1) ==
FSL_CORENET_RCWSR13_EC1_FM1_DTSEC4_MII)
return PHY_INTERFACE_MODE_MII;
- else
- return PHY_INTERFACE_MODE_NONE;
}
if (port == FM1_DTSEC5) {
Prabhakar,
Can you test/ack this patch?
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/7] Update gdsys board support
On Tue, 18 Nov 2014 13:59:12 +0100 Stefan Roese s...@denx.de wrote: On 18.11.2014 13:55, Dirk Eibach wrote: do you see any chance too get this merged soon? mpc83xx: Add gdsys hrcon board fixes a build failure and it would be nice to get it in before rc2. Kim offered to ack mpc83xx: Add gdsys hrcon board. Stefan, can you please get this through your repo afterwards? Kim, could you please check this patch again and let me know if you are okay with me pulling it with the complete patch series via my tree? Stefan, thanks - took a brief look: Would have rather seen at least a minimum effort at getting the code migrated to the generic PHY layer, but I don't have time to deal, so..I'm okay if you're okay. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH U-Boot] ARM: rpi_b: detect board revision
Detect the board revision early during boot, and print the decoded
model name.
Eventually, this information can be used for tasks such as:
- Allowing/preventing USB device mode; some models have a USB device on-
board so only host mode makes sense. Others connect the SoC directly
to the USB connector, so device-mode might make sense.
- The on-board USB hub/Ethernet requires different GPIOs to enable it,
although luckily the default appears to be fine so far.
- The compute module contains an on-board eMMC device, so we could store
the environment there. Other models use an SD card and so don't support
saving the environment (unless we store it in a file on the FAT boot
partition...)
Set $fdtfile based on this information. At present, the mainline Linux
kernel doesn't contain a separate DTB for most models, but I hope that
will change soon.
Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
I'm considering renaming rpi_b - rpi in U-Boot since it supports many
models. Hopefully I can persuade U-Boot to load the environment from
different places at run-time, so we won't need different builds based
on whether the environment is in eMMC or not for example.
arch/arm/include/asm/arch-bcm2835/mbox.h | 33 +
board/raspberrypi/rpi_b/rpi_b.c | 122 ++-
include/configs/rpi_b.h | 1 -
3 files changed, 152 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/arch-bcm2835/mbox.h
b/arch/arm/include/asm/arch-bcm2835/mbox.h
index 61f427d914cd..0289ba6a917e 100644
--- a/arch/arm/include/asm/arch-bcm2835/mbox.h
+++ b/arch/arm/include/asm/arch-bcm2835/mbox.h
@@ -119,6 +119,39 @@ struct bcm2835_mbox_tag_hdr {
* };
*/
+#define BCM2835_MBOX_TAG_GET_BOARD_REV 0x00010002
+
+/*
+ * 0x2..0xf from:
+ *
http://raspberryalphaomega.org.uk/2013/02/06/automatic-raspberry-pi-board-revision-detection-model-a-b1-and-b2/
+ * http://www.raspberrypi.org/forums/viewtopic.php?f=63t=32733
+ * 0x10, 0x11 from swarren's testing
+ */
+#define BCM2835_BOARD_REV_B_I2C0_2 0x2
+#define BCM2835_BOARD_REV_B_I2C0_3 0x3
+#define BCM2835_BOARD_REV_B_I2C1_4 0x4
+#define BCM2835_BOARD_REV_B_I2C1_5 0x5
+#define BCM2835_BOARD_REV_B_I2C1_6 0x6
+#define BCM2835_BOARD_REV_A_7 0x7
+#define BCM2835_BOARD_REV_A_8 0x8
+#define BCM2835_BOARD_REV_A_9 0x9
+#define BCM2835_BOARD_REV_B_REV2_d 0xd
+#define BCM2835_BOARD_REV_B_REV2_e 0xe
+#define BCM2835_BOARD_REV_B_REV2_f 0xf
+#define BCM2835_BOARD_REV_B_PLUS 0x10
+#define BCM2835_BOARD_REV_CM 0x11
+
+struct bcm2835_mbox_tag_get_board_rev {
+ struct bcm2835_mbox_tag_hdr tag_hdr;
+ union {
+ struct {
+ } req;
+ struct {
+ u32 rev;
+ } resp;
+ } body;
+};
+
#define BCM2835_MBOX_TAG_GET_MAC_ADDRESS 0x00010003
struct bcm2835_mbox_tag_get_mac_address {
diff --git a/board/raspberrypi/rpi_b/rpi_b.c b/board/raspberrypi/rpi_b/rpi_b.c
index 7445f5318ad2..aaded88b4ba0 100644
--- a/board/raspberrypi/rpi_b/rpi_b.c
+++ b/board/raspberrypi/rpi_b/rpi_b.c
@@ -42,6 +42,12 @@ struct msg_get_arm_mem {
u32 end_tag;
};
+struct msg_get_board_rev {
+ struct bcm2835_mbox_hdr hdr;
+ struct bcm2835_mbox_tag_get_board_rev get_board_rev;
+ u32 end_tag;
+};
+
struct msg_get_mac_address {
struct bcm2835_mbox_hdr hdr;
struct bcm2835_mbox_tag_get_mac_address get_mac_address;
@@ -60,6 +66,67 @@ struct msg_get_clock_rate {
u32 end_tag;
};
+/* See comments in mbox.h for data source */
+static const struct {
+ const char *name;
+ const char *fdtfile;
+} models[] = {
+ [BCM2835_BOARD_REV_B_I2C0_2] = {
+ Model B (no P5),
+ bcm2835-rpi-b-i2c0.dtb,
+ },
+ [BCM2835_BOARD_REV_B_I2C0_3] = {
+ Model B (no P5),
+ bcm2835-rpi-b-i2c0.dtb,
+ },
+ [BCM2835_BOARD_REV_B_I2C1_4] = {
+ Model B,
+ bcm2835-rpi-b.dtb,
+ },
+ [BCM2835_BOARD_REV_B_I2C1_5] = {
+ Model B,
+ bcm2835-rpi-b.dtb,
+ },
+ [BCM2835_BOARD_REV_B_I2C1_6] = {
+ Model B,
+ bcm2835-rpi-b.dtb,
+ },
+ [BCM2835_BOARD_REV_A_7] = {
+ Model A,
+ bcm2835-rpi-a.dtb,
+ },
+ [BCM2835_BOARD_REV_A_8] = {
+ Model A,
+ bcm2835-rpi-a.dtb,
+ },
+ [BCM2835_BOARD_REV_A_9] = {
+ Model A,
+ bcm2835-rpi-a.dtb,
+ },
+ [BCM2835_BOARD_REV_B_REV2_d] = {
+ Model B rev2,
+ bcm2835-rpi-b-rev2.dtb,
+ },
+ [BCM2835_BOARD_REV_B_REV2_e] = {
+ Model B rev2,
+ bcm2835-rpi-b-rev2.dtb,
+ },
+ [BCM2835_BOARD_REV_B_REV2_f] = {
+ Model B rev2,
+ bcm2835-rpi-b-rev2.dtb,
+
[U-Boot] [PATCH v3] .travis.yml: build u-boot on travis-ci
From: Meier, Roger r.me...@siemens.com
Goal:
- building all variants of U-Boot with multiple configurations
- code quality checks and metrics
- https://travis-ci.org/u-boot/u-boot/builds
Changes for v3:
- fix patch format (recognized by Andreas Färber)
- get in touch with GitHub about the orphan u-boot account and get it
- install travis-ci hook on the account https://github.com/u-boot/u-boot/
- push master and travis branch to https://github.com/u-boot/u-boot/
- add Goal to the commit message
Changes for v2:
- use latest device tree compiler (suggested by Daniel Schwierzeck)
- add sandbox (suggested by Daniel Schwierzeck)
- seperate echo and execution of TEST_CMD
- remove BUILD_NCPUS( part of script)
- introduce ${TEST_CONFIG_CMD}
- add libsdl-dev package which is required by sandbox
- use buildman (suggested by Tom Rini)
- generate ~/.buildman
- split ppc into several jobs
- install gcc-arm-linux-gnueabihf
- use --inline-suppr option for cppcheck
Signed-off-by: Roger Meier r.me...@siemens.com
Cc: Wolfgang Denk w...@denx.de
Cc: Tom Rini tr...@ti.com
Cc: Daniel Schwierzeck daniel.schwierz...@gmail.com
Cc: Andreas Färber afaer...@suse.de
---
.travis.yml | 148 +++
1 file changed, 148 insertions(+)
create mode 100644 .travis.yml
diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000..7488a3f
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,148 @@
+# Copyright Roger Meier r.me...@siemens.com
+# SPDX-License-Identifier: GPL-2.0+
+
+# build U-Boot on Travis CI - https://travis-ci.org/
+
+language: c
+
+cache:
+ - apt
+
+install:
+ # install U-Boot build dependencies
+ - sudo apt-get install -qq cppcheck sloccount sparse bc libsdl-dev
gcc-arm-linux-gnueabi gcc-arm-linux-gnueabihf
+ # install latest device tree compiler
+ - git clone --depth=1 https://git.kernel.org/pub/scm/utils/dtc/dtc.git
/tmp/dtc
+ - make -j4 -C /tmp/dtc
+ # prepare buildman environment
+ - export BUILDMAN_ROOT=root:
+ - export BUILDMAN_MIPS=mips:
+ - export BUILDMAN_PPC=ppc:
+ - echo -e [toolchain]\\n${BUILDMAN_ROOT} /\n ~/.buildman
+ - echo -e ${BUILDMAN_MIPS}
/opt/eldk-5.4/mips/sysroots/i686-eldk-linux/usr/bin/mips32-linux/
~/.buildman
+ - echo -e ${BUILDMAN_PPC}
/opt/eldk-5.4/powerpc/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/
~/.buildman
+ - export BUILDMAN_ALIAS=x86:
+ - echo -e [toolchain-alias]\\n${BUILDMAN_ALIAS} i386 ~/.buildman
+ - cat ~/.buildman
+
+env:
+ global:
+- PATH=$PATH:/tmp/dtc
+- BUILD_DIR=build
+- CROSS_COMPILE=
+- HOSTCC=cc
+- HOSTCXX=c++
+- TEST_CONFIG_CMD=
+
+before_script:
+ # install toolchains based on INSTALL_TOOLCHAIN} variable
+ - if [[ ${INSTALL_TOOLCHAIN} == *ppc* ]]; then wget
ftp://ftp.denx.de/pub/eldk/5.4/targets/powerpc/eldk-eglibc-i686-powerpc-toolchain-gmae-5.4.sh
; fi
+ - if [[ ${INSTALL_TOOLCHAIN} == *ppc* ]]; then sh
eldk-eglibc-i686-powerpc-toolchain-gmae-5.4.sh -y ; fi
+ - if [[ ${INSTALL_TOOLCHAIN} == *mips* ]]; then wget
ftp://ftp.denx.de/pub/eldk/5.4/targets/mips/eldk-eglibc-i686-mips-toolchain-gmae-5.4.sh
; fi
+ - if [[ ${INSTALL_TOOLCHAIN} == *mips* ]]; then sh
eldk-eglibc-i686-mips-toolchain-gmae-5.4.sh -y ; fi
+
+script:
+ # the execution sequence for each test
+ - echo ${TEST_CONFIG_CMD}
+ - ${TEST_CONFIG_CMD}
+ - echo ${TEST_CMD}
+ - ${TEST_CMD}
+
+matrix:
+ include:
+ # we need to build by vendor due to 50min time limit for builds
+ # each env setting here is a dedicated build
+- env:
+- TEST_CMD=./MAKEALL -a arm -v atmel
+ CROSS_COMPILE=arm-linux-gnueabi-
+- env:
+- TEST_CMD=./MAKEALL -a arm -v denx
+ CROSS_COMPILE=arm-linux-gnueabi-
+- env:
+- TEST_CMD=./MAKEALL -a arm -v freescale
+ CROSS_COMPILE=arm-linux-gnueabi-
+- env:
+- TEST_CMD=./MAKEALL -a arm -v siemens
+ CROSS_COMPILE=arm-linux-gnueabi-
+- env:
+- TEST_CMD=./MAKEALL -a arm -v ti
+ CROSS_COMPILE=arm-linux-gnueabi-
+- env:
+- TEST_CONFIG_CMD=make sandbox_defconfig
+ TEST_CMD=make -j4
+ HOSTCC = gcc
+ HOSTCXX = g++
+- env:
+- TEST_CONFIG_CMD=make sandbox_defconfig
+ TEST_CMD=make -j4
+ HOSTCC = clang
+ HOSTCXX = clang++
+- env:
+- TEST_CMD=./MAKEALL -a mips
+ INSTALL_TOOLCHAIN=mips
+
CROSS_COMPILE=/opt/eldk-5.4/mips/sysroots/i686-eldk-linux/usr/bin/mips32-linux/mips-linux-
+- env:
+- TEST_CMD=tools/buildman/buildman --list-error-boards atmel
+- env:
+- TEST_CMD=tools/buildman/buildman --list-error-boards denx
+- env:
+- TEST_CMD=tools/buildman/buildman --list-error-boards freescale arm
+- env:
+- TEST_CMD=tools/buildman/buildman --list-error-boards siemens
+- env:
+- TEST_CMD=tools/buildman/buildman --list-error-boards ti
+- env:
+- TEST_CMD=tools/buildman/buildman mips
+
Re: [U-Boot] [PATCH v2 0/7] Update gdsys board support
Hi Kim, thanks for having a look. As I said I am preparing a RFC for migrating things to generic PHY, but this will be bigger step scheduled for v2015.04. Cheers Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] .travis.yml: build u-boot on travis-ci
Dear Roger, In message 1416377222-22192-1-git-send-email-r.me...@siemens.com you wrote: From: Meier, Roger r.me...@siemens.com Goal: - building all variants of U-Boot with multiple configurations - code quality checks and metrics - https://travis-ci.org/u-boot/u-boot/builds Changes for v3: ... Changes for v2: ... This changelog should go below the --- separator line +# search for HACK within source tree and ignore HACKKIT board +- env: +- TEST_CMD=grep -r HACK * I don't see how you ignore MACH_TYPE_HACKKIT etc. here? Is this eventually sstill missing? Except for these two minor comments: thanks a lot for this extremly valuable contribution. Acked-by: Wolfgang Denk w...@denx.de 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 one who says it cannot be done should never interrupt the one who is doing it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] .travis.yml: build u-boot on travis-ci
Dear Roger, In message 1416377222-22192-1-git-send-email-r.me...@siemens.com you wrote: +env: + global: +- PATH=$PATH:/tmp/dtc Should /tmp/dtc not go first in PATH, in case an older version of dtc is already installed on the build host? 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 I've got a bad feeling about this. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Query on CONFIG_SYS_THUMB_BUILD
Hello Stefan, On Tue, 18 Nov 2014 19:37:18 +0100, Stefan Agner ste...@agner.ch wrote: diff --git a/arch/arm/config.mk b/arch/arm/config.mk index f0eafd6..ddbc8dc 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -30,6 +30,8 @@ PF_CPPFLAGS_ARM := $(call cc-option, -mthumb -mthumb-interwork,\ $(call cc-option,-marm,)\ $(call cc-option,-mno-thumb-interwork,)\ ) +AFLAGS_AUTOIT:=$(call as-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mauto-it) +PF_CPPFLAGS_ARM += $(AFLAGS_AUTOIT) else PF_CPPFLAGS_ARM := $(call cc-option,-marm,) \ $(call cc-option,-mno-thumb-interwork,) The main change here is the implicit-it/auto-it functionality. For me it works when enabling that globally. Is it harmful to enable that globally? The other changes need a proper ifdef, but should be ok I guess. -mimplicit-it=always will have no effect on ARM builds as it defaults to 'arm', meaning that IT instructions are already optional in ARM mode, and switching to 'always' changes the behavior only for Thumb mode. For -mauto-it, it is not documented in the gas documentation online or in my current as' --target-help. I'll dig this deeper today, but barring any scream from me, the change above is fine globally in U-Boot. -- Stefan Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ubi: reset relevant globals in ubi_exit()
Hello Andrew, Am 17.11.2014 07:21, schrieb Heiko Schocher: Hello Andrew, Am 14.11.2014 14:31, schrieb Andrew Ruder: On 11/14/2014 12:20 AM, Heiko Schocher wrote: Good catch, but wondering, why this not poped up in my tests, as I did such a test ... Are you on 2014.10? I don't think this issue existed on the 2014.07-rc3 I was using earlier. Yes, I tested currently with current mainline ... Could you please test on your hw with current ML? I could not see this problem, but maybe I have another setup ... thanks! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Query on CONFIG_SYS_THUMB_BUILD
Dear Albert, In message 20141119074214.3d414ce6@lilith you wrote: For -mauto-it, it is not documented in the gas documentation online or in my current as' --target-help. I'll dig this deeper today, but barring any scream from me, the change above is fine globally in U-Boot. Apparently this [1] is where it is coming from; no further documentation there, though. [1] https://sourceware.org/ml/binutils/2009-05/msg00132.html Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If people are good only because they fear punishment, and hope for reward, then we are a sorry lot indeed.- Albert Einstein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] ls102xa: HYP/non-sec: support for ls102xa boards
Hi Albert,
-Original Message-
From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
Sent: Tuesday, November 18, 2014 3:18 PM
To: Xiubo Li-B47053
Cc: Sun York-R58495; Jin Zhengxiong-R64188; u-boot@lists.denx.de
Subject: Re: [PATCH v3 3/5] ls102xa: HYP/non-sec: support for ls102xa boards
Hello li.xi...@freescale.com,
On Tue, 18 Nov 2014 02:01:02 +, li.xi...@freescale.com
li.xi...@freescale.com wrote:
Hi Albert,
+#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
+/* Setting the address at which secondary cores start from.*/
+void smp_set_core_boot_addr(unsigned long addr, int corenr)
+{
+ struct ccsr_gur __iomem *gur = (void
*)(CONFIG_SYS_FSL_GUTS_ADDR);
+
+ /*
+* After setting the secondary cores start address,
+* just release them to boot.
+*/
+ out_be32(gur-scratchrw[0], addr);
+ out_be32(gur-brrl, 0x2);
+}
This function does not exactly [set] the address at which
secondary
cores start from; it sets *a* secondary core's boot address, and
then
it *boots* it.
Okay, I will fix it later.
Why does this version of smp_set_core_boot_addr() need to boot the
core
in addition to setting the address, whereas the existing ones in
virt_v7, vexpress_common and arndale don't boot the cores?
Yes, they don't doing the release operation.
For Low Power Management requirement, maybe only one core will be
used,
and
then
We also make sure that the secondary core must be in low power and
deep
sleep
mode(using wfi). So I just release it here, to make sure that the
wfi
instruction
will be executed as early as possible.
Right after smp_set_core_boot_addr() is called, kick_all_cpus()
isgoing
to be called. Wouldn't that boot your CPUs just as well?
Yes, it will.
But before that we must do the holdoff bit set operation as the SoC's
requirement.
The BRR contains control bits for enabling boot for each core. On
exiting
HRESET or
PORESET, the RCW BOOT_HO field optionally allows for logical core 0 to
be
released
for booting or to remain in boot holdoff. All other cores remain in boot
holdoff until their
corresponding bit is set.
Maybe the comment is not very clear and a bit confusing.
Before I'm lost entirely, do you mean that the comment:
+ /*
+* After setting the secondary cores start address,
+* just release them to boot.
+*/
Is actually wrong, and the instructions that follow it do not actually
boot the secondary core(s)?
The comment should be:
/*
* After setting the secondary core's start address,
* just release it from holdoff.
*/
From my tests, for most time the release instructions will boot the
secondary
core(s) without smp_kick_all_cpus(). One time has failed.
So I think the release can not make sure that it will boot the secondary
core(s).
Thanks for clarifying.
If a holdoff release is the right way to boot a secondary core for you,
then I think the right place to do it is not smp_set_core_boot_addr()
but smp_kick_all_cpus(), of which you could make a strong version which
would do the holdoff release instead of whatever the weak version does.
Yes, I do think a strong version will be okay.
In file arch/arm/cpu/armv7/ls102xa/cpu.c, add the strong version:
+/* Release the secondary core from holdoff state and boot it */
+void smp_kick_all_cpus(void)
+{
+ struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
+
+ out_be32(gur-brrl, 0x2);
+}
+
Is this okay ?
I have test the holdoff release in two boards(including the old one before
I used) for 37 times and all has passed. I have a check the before failed logs,
It is another issue led to the failure. And also get confirmation that the
Holdoff release will do reset and then boot the secondary core.
Thanks,
BRs
Xiubo
That is, unless you also need the weak version to run, in which case
I /still/ think you should find a way for all of this to happen at the
'kick stage (maybe with a .weakref in arch/arm/cpu/armv8/start.S, to
give the weak smp_kick_all_cpus symbol another name that could be
referred to by the strong version).
Thanks,
BRs
Xiubo
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/7] Update gdsys board support
Hi Dirk, On 19.11.2014 07:30, Dirk Eibach wrote: thanks for having a look. As I said I am preparing a RFC for migrating things to generic PHY, but this will be bigger step scheduled for v2015.04. Thanks, that is good to know. I'll pull all your patches into the ppc4xx repository now and push them to Tom. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/7] board: dlvision: Reduce memory footprint
On 13.11.2014 19:21, dirk.eib...@gdsys.cc wrote: From: Dirk Eibach dirk.eib...@gdsys.cc Tune dlvision configuration similar to other gdsys boards to reduce memory footprint. Signed-off-by: Dirk Eibach dirk.eib...@gdsys.cc Applied to u-boot-ppc4xx/master. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/7] mtd: Handle 29LV800BT
On 13.11.2014 19:21, dirk.eib...@gdsys.cc wrote: From: Dirk Eibach dirk.eib...@gdsys.cc The device id makes u-boot think that this chip needs cfi_reverse_geometry(), which is not the case. Add it to jedec_flash, so it is handled properly. Signed-off-by: Dirk Eibach dirk.eib...@gdsys.cc Applied to u-boot-ppc4xx/master. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/7] board: dlvision-10g: Compile fix
On 13.11.2014 19:21, dirk.eib...@gdsys.cc wrote: From: Dirk Eibach dirk.eib...@gdsys.cc Signed-off-by: Dirk Eibach dirk.eib...@gdsys.cc Applied to u-boot-ppc4xx/master. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] common: Fix cmd_fpgad addressing
On 13.11.2014 19:21, dirk.eib...@gdsys.cc wrote: From: Dirk Eibach dirk.eib...@gdsys.cc Addressing was completely broken for cmd_fpgad. Signed-off-by: Dirk Eibach dirk.eib...@gdsys.cc Applied to u-boot-ppc4xx/master. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
