[U-Boot] kwboot: Boot Marvell Kirkwood SoCs over a serial link.
Hey. I wrote a utility to boot Marvell SoCs over serial. If that sounds generally useful, would you be so kind to merge git://github.com/dns42/u-boot.git at dns/kwboot-1 If it's missing sth for that to happen, lemme know. Cheers, Daniel PS: Sorry if you received this twice, first mail got stuck in moderation. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] kwboot: Boot Marvell Kirkwood SoCs over a serial link.
The kwboot program boots boards based on Marvell's Kirkwood platform via Xmodem over their integrated UART. Signed-off-by: Daniel Stodden daniel.stod...@googlemail.com --- doc/kwboot.1 | 84 +++ tools/Makefile |6 + tools/kwboot.c | 750 3 files changed, 840 insertions(+) create mode 100644 doc/kwboot.1 create mode 100644 tools/kwboot.c diff --git a/doc/kwboot.1 b/doc/kwboot.1 new file mode 100644 index 000..0d3eccd --- /dev/null +++ b/doc/kwboot.1 @@ -0,0 +1,84 @@ +.TH KWBOOT 1 2012-03-05 + +.SH NAME +kwboot \- Boot Marvell Kirkwood SoCs over a serial link. +.SH SYNOPSIS +.B kwboot +.RB [ -b \fIimage\fP ] +.RB [ -t ] +.RB [...] +.RB [\fITTY\fP] +.SH DESCRIPTION + +The +.B kwboot +program boots boards based on Marvell's Kirkwood platform over their +integrated UART. Boot image files will typically contain a second +stage boot loader, such as U-Boot. The image file must conform to +Marvell's BootROM firmware image format (\fIkwbimage\fP), created +using a tool such as +.B mkimage. + +Following power-up or a system reset, system BootROM code polls the +UART for a brief period of time, sensing a handshake message which +initiates an image upload. This program sends this boot message until +it receives a positive acknowledgement. The image is transfered using +Xmodem. + +Additionally, this program implements a minimal terminal mode, which +can be used either standalone, or entered immediately following boot +image transfer completion. This is often useful to catch early boot +messages, or to manually interrupt a default boot procedure performed +by the second-stage loader. + +.SH OPTIONS + +.TP +.BI \-b \fIimage\fP +Handshake; then upload file \fIimage\fP over \fITTY\fP. + +Note that for the encapsulated boot code to be executed, \fIimage\fP +must be of type UART boot (0x69). Boot images of different types, +such as backup images of vendor firmware downloaded from flash memory +(type 0x8B), will not work (or not as expected). See \fB-p\fP for a +workaround. + +Unless \fB-q\fP is provided, this mode writes handshake status and +upload progress indication to stdout. + +.TP +.BI \-p +In combination with \fB-b\fP, patches the header in \fIimage\fP prior +to upload, to UART boot type. + +This option attempts on-the-fly conversion of some none-UART image +types, such as images which were originally formatted to be stored in +flash memory. + +Conversion is performed in-core. The contents of \fIimage\fP will not +be altered. + +.TP +.BI \-t +Run a terminal program, connecting standard input and output to +.RB \fITTY\fP. + +If used in combination with \fB-b\fP, terminal mode is entered +immediately following a successful image upload. + +If standard I/O streams connect to a console, this mode will terminate +after receiving 'ctrl-\\' followed by 'c' from console input. + +.TP +.BI \-B \fIbaudrate\fP +Adjust the baud rate on \fITTY\fP. Default rate is 115200. + +.SH SEE ALSO +.PP +\fBmkimage\fP(1) + +.SH AUTHORS + +Daniel Stodden daniel.stod...@gmail.com + + diff --git a/tools/Makefile b/tools/Makefile index 8993fdd..2a976f7 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -68,6 +68,7 @@ BIN_FILES-$(CONFIG_CMD_LOADS) += img2srec$(SFX) BIN_FILES-$(CONFIG_XWAY_SWAP_BYTES) += xway-swap-bytes$(SFX) BIN_FILES-y += mkenvimage$(SFX) BIN_FILES-y += mkimage$(SFX) +BIN_FILES-y += kwboot$(SFX) BIN_FILES-$(CONFIG_SMDK5250) += mksmdk5250spl$(SFX) BIN_FILES-$(CONFIG_MX28) += mxsboot$(SFX) BIN_FILES-$(CONFIG_NETCONSOLE) += ncb$(SFX) @@ -101,6 +102,7 @@ OBJ_FILES-$(CONFIG_NETCONSOLE) += ncb.o NOPED_OBJ_FILES-y += os_support.o OBJ_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1.o NOPED_OBJ_FILES-y += ublimage.o +OBJ_FILES-y += kwboot.o # Don't build by default #ifeq ($(ARCH),ppc) @@ -234,6 +236,10 @@ $(obj)ncb$(SFX): $(obj)ncb.o $(obj)ubsha1$(SFX):$(obj)os_support.o $(obj)sha1.o $(obj)ubsha1.o $(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^ +$(obj)kwboot$(SFX): $(obj)kwboot.o + $(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^ + $(HOSTSTRIP) $@ + # Some of the tool objects need to be accessed from outside the tools directory $(obj)%.o: $(SRCTREE)/common/%.c $(HOSTCC) -g $(HOSTCFLAGS_NOPED) -c -o $@ $ diff --git a/tools/kwboot.c b/tools/kwboot.c new file mode 100644 index 000..65c50d2 --- /dev/null +++ b/tools/kwboot.c @@ -0,0 +1,750 @@ +/* + * Boot a Marvell Kirkwood SoC, with Xmodem over UART0. + * + * (c) 2012 Daniel Stodden daniel.stod...@gmail.com + * + * References: marvell.com, 88F6180, 88F6190, 88F6192, and 88F6281 + * Integrated Controller: Functional Specifications December 2, + * 2008. Chapter 24.2 BootROM Firmware. + */ + +#include stdlib.h +#include stdio.h +#include string.h +#include stdarg.h +#include libgen.h +#include fcntl.h +#include errno.h +#include unistd.h +#include stdint.h +#include termios.h +#include sys/mman.h +#include sys/stat.h + +#include kwbimage.h + +#ifdef __GNUC__
Re: [U-Boot] kwboot: Boot Marvell Kirkwood SoCs over a serial link.
On Sun, 2012-04-22 at 11:46 -0700, Prafulla Wadaskar wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Daniel Stodden Sent: 22 April 2012 11:56 To: u-boot@lists.denx.de Subject: [U-Boot] kwboot: Boot Marvell Kirkwood SoCs over a serial link. Hey. I wrote a utility to boot Marvell SoCs over serial. If that sounds generally useful, would you be so kind to merge git://github.com/dns42/u-boot.git at dns/kwboot-1 If it's missing sth for that to happen, lemme know. Hi Daniel Yes, this will find very useful utility/tool. May you please post the patch for the same? I git-mailed the delta. Tweaked docs and whitespace a little since the original mail. Removing some residual stuff I thought I'd eventually support, but so far don't (like driving to debug mode etc.). That bumped up my upstream branch revision to dns/kwboot-3. Things were mostly tested with a qnap TS-219P+ board. Guess at this point it should at least be good enough to leave plugcomputer folks etc with a solid brick/unbrick perspective. Ideas + overall input certainly welcome. Cheers, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb showed wrong device count
Hi, Bob Liu lliu...@gmail.com skribis: After patch: usb: Add support for multiple-LUN mass storage devices The usb device count isn't correct. I don’t recall the details, but it worked for me on the GuruPlug. What device are you using? Thanks, Ludo’. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Sandbox question
Hello, I have a few sandbox related questions (examples run on v2012.04) 1) Memory map - What is it supposed to look like? I get DRAM: 128 MiB, and =bdi boot_params = 0x DRAM bank = 0x - start= 0x - size = 0x0800 FB base = 0x Yet I get: =md 0x100 0100:Segmentation fault 2) Sandbox does no handle EOF on stadin; this makes it impossible to use it in test scripts. For example, something like this should work: $ echo printenv | ./u-boot [As woraround I have to use ``echo 'printenv;reset' | ./u-boot''; this works, but is not really intuitive nore useful.] 3) For automatic test suites it would make a lot of sense if the return code of U-Boot was the return code of the last executed command (expecially when termination of U-Boot is the result of encountering EOF on stdin). What do you think? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There is is no reason for any individual to have a computer in their home. -- Ken Olsen (President of Digital Equipment Corporation), Convention of the World Future Society, in Boston, 1977 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [REFERENCE DON'T APPLY 1/3] dfu: Add default value for bwPollTimeout
Dear Marek, Stefan Dear Stefan Schmidt, Hello. On Fri, 2012-04-06 at 15:06, Marek Vasut wrote: On Thursday 05 April 2012 20:18:16 Marek Vasut wrote: What do you expect from me to tell you about this patch? Or do you expect someone else to comment on this? he mentioned in the summary of the series. he's run out of time, so he's dumping his WIP state in case someone else picks it up. Re: [U-Boot] [PATCH 2/4] dfu: generic backend parts this summary? I see, didn't notice it, but just read it. Stefan, thanks for your work, I hope you'll be back eventually :) Time will tell. I still think its a worthwhile feature. I just need to find some time, motivation and hardware to work on it again. Will take at leats a couple of months though before I would start anything. Just relocated to another country and still in need for a flat to rent and sort out life and work. :) Good luck on that :-) I'm working on the composite gadget (as Marek know already :-)). On top of the g_dnl USB composite download driver it is possible to lay down the DFU function. Actualy we (I mean Andrzej Pietrasiewicz and me), have managed to provide some proof-of-concept DFU code running with g_dnl driver (both DFU + THOR). Unfortunately this code is not yet finished and THOR protocol support has higher priority now. When we post DFU patches we will add you guys on the Cc. -- Best regards, Lukasz Majewski Samsung Poland RD Center Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 'run' no longer aborts on an error, can someone please verify
Hi again, On 23.04.2012 08:43, Timo Ketola wrote: ... I took a quick glance over command/main.c common/main.c, of course 1341 rc = cmd_process(flag, argc, argv, repeatable); This might fix it: - rc = cmd_process(flag, argc, argv, repeatable); + if (cmd_process(flag, argc, argv, repeatable)) + rc = -1; -- Timo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 3/8] imx: fec: Resolve speed before configuring gasket
On 20/04/2012 10:54, Timo Ketola wrote: as far as I can see, there are some inconsistencies. All boards define CONFIG_MII, but they really need CONFIG_RMII, because only with my last patch I set the gasket for MII. The driver has always set in a fixed way the gasket for RMII, independently if CONFIG_RMII or CONFIG_MII was set, and that is also wrong. Quite right, you have the second board. The ima3 board I added uses also MII instead of RMII. However, I think that something went wrong, as I understand rereading the code. Functionally this does nothing of course but I can imagine the reasoning behind that check: If I understand correctly, fec_mxc depends on MII management interface (for example miiphy_wait_aneg). Then, if CONFIG_MII is not defined, there is inconsistency because configuration says don't use MII but fec_mxc still uses it. I don't know whether this causes any confusion. It creates some confusion... Boards are compiled clean without them. Correct me if I am wrong, but it seems the correct way to do is to drop the unneeded check in the above lines and sets CONFIG_RMII for all boards except the only one (ima3-mx53), that needs really MII. Agreed regarding CONFIG_RMII. With dropping the check I'm OK either way. Furthermore, I might like to propose to change the name of the configuration variable CONFIG_MII to CONFIG_MII_MGM or something like that. That might reduce confusion (at least I have been quite confused). Support for MX28 added recently CONFIG_FEC_XCV_TYPE. To augment the confusion, CONFIG_FEC_XCV_TYPE is set to MII100 as default, and this let assume that most boards are running with MII if they do not define it. Really all MX5 boards use RMII, not MII. Not only, by setting the RCR register, there is an attempt to set reserved bits on MX5 SOCs, because MX5 defines only bits 0-5. It seems that writing to reserved bits does not produce effects, but it is quite dangerous and not compliant with SOC manual. So at the end we have multiple configuration switches (CONFIG_MII, CONFIG_RMII, and CONFIG_FEC_XCV_TYPE) to set the same thing, and this is not really good ;-(( I assume that setting CONFIG_FEC_XCV_TYPE as default to MII100 was to avoid to break building not MX28 boards, but as you can see generates other problems. I think it is really better that there is *no* default, and each board sets explicitely its own type. Instead of using CONFIG_MII or CONFIG_RMII, we can make use of CONFIG_FEC_XCV_TYPE, as it was already introduced, but making it consistent for all boards. Support for MII in FEC is in u-boot-imx/next in the last patch, and it is not yet merged. I think I am going to drop that patch from my tree, so that we start again from a clean situation (mainline). Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 3/8] imx: fec: Resolve speed before configuring gasket
On 23.04.2012 10:55, Stefano Babic wrote: Instead of using CONFIG_MII or CONFIG_RMII, we can make use of CONFIG_FEC_XCV_TYPE, as it was already introduced, but making it consistent for all boards. Second for that. -- Timo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 'run' no longer aborts on an error, can someone please verify
Dear Gray Remlin, In message 4f932cec.30...@gmail.com you wrote: U-Boot v2012.04 Marvell setenv ipaddr '192.168.1.130' Marvell setenv ifhostisup 'ping 192.168.1.100' Marvell setenv saywearehappy 'echo We are happy!' Marvell run ifhostisup saywearehappy; Using egiga0 device ping failed; host 192.168.1.100 is not alive We are happy! Marvell This is not the same behaviour as my (unfortunately customised) version based on the ancient U-Boot 2009.11 Other commands are also effected, for example 'ide dev 0' would abort a 'run' command if the device did not exist. Is this my problem (corrupted source\compilation) or a change in policy ? I cannot confirm a problem with the run' command; tested with v2012.04 in sandbox : $ echo 'setenv fail printenv foo;setenv bug echo === BUG ===;run fail bug; reset' | ./u-boot U-Boot 2012.04 (Apr 23 2012 - 10:07:18) DRAM: 128 MiB Using default environment In:serial Out: serial Err: serial =setenv fail printenv foo;setenv bug echo === BUG ===;run fail bug; reset ## Error: foo not defined $ i. e. the second command (echo === BUG ===) does not get run. Ditto on real hardware (here a MPC5200 based board): U-Boot 2012.04 (Apr 23 2012 - 10:16:22) CPU: MPC5200B v2.2, Core v1.4 at 396 MHz Bus 132 MHz, IPB 132 MHz, PCI 66 MHz ... = setenv ifhostisup 'ping 192.168.99.99' = setenv saywearehappy 'echo We are happy!' = run ifhostisup saywearehappy Using FEC device ping failed; host 192.168.99.99 is not alive = Which exact version of U-Boot and which board configuration are you testing? Are you using hush shell, or plain old command interpreter? [In both my tests the hush shell was used.] 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 A conservative is a man with two perfectly good legs who has never learned to walk. - Franklin D. Roosevelt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Sandbox cannot be built without HUSH
Dear Simon, disabling HUSH support in sandbox results in this: start.c: In function ‘sandbox_main_loop_init’: start.c:97:3: warning: implicit declaration of function ‘parse_string_outer’ [-Wimplicit-function-declaration] start.c:97:34: error: ‘FLAG_PARSE_SEMICOLON’ undeclared (first use in this function) start.c:97:34: note: each undeclared identifier is reported only once for each function it appears in start.c:98:9: error: ‘FLAG_EXIT_FROM_LOOP’ undeclared (first use in this function) make[1]: *** [start.o] Error 1 make: *** [arch/sandbox/cpu/start.o] Error 2 make: *** Waiting for unfinished jobs start.c: In function ‘sandbox_main_loop_init’: start.c:97:3: warning: implicit declaration of function ‘parse_string_outer’ [-Wimplicit-function-declaration] start.c:97:34: error: ‘FLAG_PARSE_SEMICOLON’ undeclared (first use in this function) start.c:97:34: note: each undeclared identifier is reported only once for each function it appears in start.c:98:9: error: ‘FLAG_EXIT_FROM_LOOP’ undeclared (first use in this function) 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 Everyone who comes in here wants three things: 1. They want it quick. 2. They want it good. 3. They want it cheap. I tell 'em to pick two and call me back. - sign on the back wall of a small printing company in Delaware ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 'run' no longer aborts on an error, can someone please verify
On 23.04.2012 11:20, Wolfgang Denk wrote: I cannot confirm a problem with the run' command; tested with v2012.04 in sandbox : $ echo 'setenv fail printenv foo;setenv bug echo === BUG ===;run fail bug; reset' | ./u-boot I can confirm it: EXE4026 setenv fail printenv foo;setenv bug echo === BUG ===;run fail bug ## Error: foo not defined === BUG === EXE4026 With the fix I showed earlier: EXE4026 setenv fail printenv foo;setenv bug echo === BUG ===;run fail bug ## Error: foo not defined EXE4026 Which exact version of U-Boot and which board configuration are you testing? This is u-boot-imx.git next with not yet merged board adaptation. Are you using hush shell, or plain old command interpreter? Plain old... -- Timo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 'run' no longer aborts on an error, can someone please verify
Dear Gray, In message 20120423082005.8497f200...@gemini.denx.de I wrote: I cannot confirm a problem with the run' command; tested with ... [In both my tests the hush shell was used.] I confirm the problem for the old command line interpreter. 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 think it's a new feature. Don't tell anyone it was an accident. :-) -- Larry Wall on s/foo/bar/eieio in 10...@jpl-devvax.jpl.nasa.gov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 'run' no longer aborts on an error, can someone please verify
Dear Timo, In message 4f9506aa.4000...@exertus.fi you wrote: Hi again, On 23.04.2012 08:43, Timo Ketola wrote: ... I took a quick glance over command/main.c common/main.c, of course 1341 rc = cmd_process(flag, argc, argv, repeatable); This might fix it: - rc = cmd_process(flag, argc, argv, repeatable); + if (cmd_process(flag, argc, argv, repeatable)) + rc = -1; I confirm this fixes the issue. Tested on TQM5200S. Can you please send a proper patch with SoB line etc. ? Simon, can you then please send a formal ACK to that patch? Thanks in advance. 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 Ninety-Ninety Rule of Project Schedules: The first ninety percent of the task takes ninety percent of the time, and the last ten percent takes the other ninety percent. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] EXYNOS: draw 32bpp bitmap TIZEN logo
On 23 April 2012 10:47, Donghwa Lee dh09@samsung.com wrote:
This patches support drawing 32bpp bitmap TIZEN logo in exynos fb.
asm/arch/trats_logo.h data is compressed by zip and decomressed at
the exynos fb driver.
And vl_bpix of vidinfo_t is changed proper value for u-boot.
Signed-off-by: Donghwa Lee dh09@samsung.com
Signed-off-by: Kyungmin park kyungmin.p...@samsung.com
---
arch/arm/include/asm/arch-exynos/trats_logo.h | 5070
+
board/samsung/trats/trats.c | 2 +-
drivers/video/exynos_fb.c | 40 +-
drivers/video/exynos_fimd.c | 6 +-
include/configs/trats.h | 4 +-
5 files changed, 5116 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/include/asm/arch-exynos/trats_logo.h
diff --git a/arch/arm/include/asm/arch-exynos/trats_logo.h
b/arch/arm/include/asm/arch-exynos/trats_logo.h
new file mode 100644
index 000..a595abd
--- /dev/null
+++ b/arch/arm/include/asm/arch-exynos/trats_logo.h
@@ -0,0 +1,5070 @@
+/*
+ * (C) Copyright 2012 Samsung Electronics
+ * Donghwa Lee dh09@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * aint with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+#define TRATS_LOGO_WIDTH 520
+#define TRATS_LOGO_HEIGHT 120
+#define TRATS_LOGO_BPP 32
+
+unsigned char trats_logo[]={
+};
trats logo?
I feel, it's a TIZEN logo maybe.
Also, Is it a board specific? then it should be moved to boards/samsung/trats/
diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
index f9894b1..d067bb4 100644
--- a/board/samsung/trats/trats.c
+++ b/board/samsung/trats/trats.c
@@ -467,7 +467,7 @@ void init_panel_info(vidinfo_t *vid)
vid-vl_vsp = CONFIG_SYS_LOW;
vid-vl_dp = CONFIG_SYS_LOW;
- vid-vl_bpix = 32;
+ vid-vl_bpix = 5;
vid-dual_lcd_enabled = 0;
/* s6e8ax0 Panel */
diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index 0eb7f58..c111855 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -22,6 +22,7 @@
#include config.h
#include common.h
+#include malloc.h
#include lcd.h
#include asm/io.h
#include asm/arch/cpu.h
@@ -29,6 +30,7 @@
#include asm/arch/clk.h
#include asm/arch/mipi_dsim.h
#include asm/arch/system.h
+#include asm/arch/trats_logo.h
#include exynos_fb.h
@@ -52,7 +54,7 @@ static void exynos_lcd_init_mem(void *lcdbase, vidinfo_t
*vid)
unsigned long palette_size;
unsigned int fb_size;
- fb_size = vid-vl_row * vid-vl_col * (vid-vl_bpix 3);
+ fb_size = vid-vl_row * vid-vl_col * (NBITS(vid-vl_bpix) 3);
lcd_base = lcdbase;
@@ -67,6 +69,38 @@ static void exynos_lcd_init(vidinfo_t *vid)
exynos_fimd_lcd_init(vid);
}
+static void draw_logo(void *lcdbase)
+{
+ int x, y;
+ unsigned int in_len, width, height;
+ unsigned long out_len =
+ (ARRAY_SIZE(trats_logo) * sizeof(*trats_logo)) + 1;
+ void *dst = NULL;
+
+ width = TRATS_LOGO_WIDTH;
+ height = TRATS_LOGO_HEIGHT;
NAK.
trats_logo and TRATS_* are board specific.
+ x = ((panel_width - width) 1);
+ y = ((panel_height - height) 1) - 5;
+
+ in_len = width * height * 8;
+ dst = malloc(in_len);
+ if (dst == NULL) {
+ printf(Error: malloc in gunzip failed!\n);
+ return;
+ }
need space here.
+ if (gunzip(dst, in_len, (uchar *)trats_logo, out_len) != 0) {
+ free(dst);
+ return;
+ }
need space here.
+ if (out_len == CONFIG_SYS_VIDEO_LOGO_MAX_SIZE)
need brace at this if statement.
And maybe it should be if (out_len = CONFIG_SYS_VIDEO_LOGO_MAX_SIZE) ?
+ printf(Image could be truncated
+ (increase
CONFIG_SYS_VIDEO_LOGO_MAX_SIZE)!\n);
+
+ lcd_display_bitmap((ulong)dst, x, y);
+
+ free(dst);
+}
+
static void lcd_panel_on(vidinfo_t *vid)
{
udelay(vid-init_delay);
@@ -113,6 +147,10 @@ void lcd_ctrl_init(void *lcdbase)
exynos_lcd_init_mem(lcdbase, panel_info);
+ memset(lcdbase, 0, panel_width *
Re: [U-Boot] [PATCH 2/2] EXYNOS: draw 32bpp bitmap TIZEN logo
Dear Donghwa Lee, In message 4f94b49e.5020...@samsung.com you wrote: This patches support drawing 32bpp bitmap TIZEN logo in exynos fb. asm/arch/trats_logo.h data is compressed by zip and decomressed at the exynos fb driver. And vl_bpix of vidinfo_t is changed proper value for u-boot. Signed-off-by: Donghwa Lee dh09@samsung.com Signed-off-by: Kyungmin park kyungmin.p...@samsung.com --- arch/arm/include/asm/arch-exynos/trats_logo.h | 5070 + board/samsung/trats/trats.c |2 +- drivers/video/exynos_fb.c | 40 +- drivers/video/exynos_fimd.c |6 +- include/configs/trats.h |4 +- 5 files changed, 5116 insertions(+), 6 deletions(-) create mode 100644 arch/arm/include/asm/arch-exynos/trats_logo.h diff --git a/arch/arm/include/asm/arch-exynos/trats_logo.h b/arch/arm/include/asm/arch-exynos/trats_logo.h new file mode 100644 index 000..a595abd --- /dev/null +++ b/arch/arm/include/asm/arch-exynos/trats_logo.h This is not a good location for the logo data. Either this is vendor specific, in which place it should go to the vendor directory, or it's board specific, in which case it should go into the board directory. In no case I want to have this in arch/arm/include/ thanks. 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 Remember, there's a big difference between kneeling down and bending over. - Frank Zappa ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] (no subject)
The patch for msm7630 was released to the u-boot community on 16-feb-2-2012 can this be mainlined in v2012.07 release.The Patches contain the following support * low speed uart for msm7630 * interprocessor communication * qc_mmc microcontroller * msm7630 soc * msm7630 surf board Thanks and regards, Mohamed Haneef M.A The contents of this e-mail and any attachment(s) may contain confidential or privileged information for the intended recipient(s). Unintended recipients are prohibited from taking action on the basis of information in this e-mail and using or disseminating the information, and must notify the sender and delete it from their system. LT Infotech will not accept responsibility or liability for the accuracy or completeness of, or the presence of any virus or disabling code in this e-mail ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] msm7630 mainline request
The patch for msm7630 was released to the u-boot community on 16-feb-2-2012 can this be mainlined in v2012.07 release.The Patches contain the following support * low speed uart for msm7630 * interprocessor communication * qc_mmc microcontroller * msm7630 soc * msm7630 surf board Thanks and regards, Mohamed Haneef M.A The contents of this e-mail and any attachment(s) may contain confidential or privileged information for the intended recipient(s). Unintended recipients are prohibited from taking action on the basis of information in this e-mail and using or disseminating the information, and must notify the sender and delete it from their system. LT Infotech will not accept responsibility or liability for the accuracy or completeness of, or the presence of any virus or disabling code in this e-mail ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [REFERENCE DON'T APPLY 1/3] dfu: Add default value for bwPollTimeout
Dear Lukasz Majewski, Dear Marek, Stefan Dear Stefan Schmidt, Hello. On Fri, 2012-04-06 at 15:06, Marek Vasut wrote: On Thursday 05 April 2012 20:18:16 Marek Vasut wrote: What do you expect from me to tell you about this patch? Or do you expect someone else to comment on this? he mentioned in the summary of the series. he's run out of time, so he's dumping his WIP state in case someone else picks it up. Re: [U-Boot] [PATCH 2/4] dfu: generic backend parts this summary? I see, didn't notice it, but just read it. Stefan, thanks for your work, I hope you'll be back eventually :) Time will tell. I still think its a worthwhile feature. I just need to find some time, motivation and hardware to work on it again. Will take at leats a couple of months though before I would start anything. Just relocated to another country and still in need for a flat to rent and sort out life and work. :) Good luck on that :-) I'm working on the composite gadget (as Marek know already :-)). On top of the g_dnl USB composite download driver it is possible to lay down the DFU function. Actualy we (I mean Andrzej Pietrasiewicz and me), have managed to provide some proof-of-concept DFU code running with g_dnl driver (both DFU + THOR). Unfortunately this code is not yet finished and THOR protocol support has higher priority now. When we post DFU patches we will add you guys on the Cc. I hope to review your stuff ASAP Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6qsabrelite: No need to set the direction for GPIO3_23 again
On 11/04/2012 22:22, Fabio Estevam wrote: There is a 'gpio_direction_output(87, 0);' call previously, so the GPIO direction is already established. Use gpio_set_value() for changing the GPIO output then. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX6: Add ANATOP regulator init
On 13/04/2012 10:00, Dirk Behme wrote:
Init the core regulator voltage to 1.2V. This is required for the correct
functioning of the GPU and when the ARM LDO is set to 1.225V. This is a
workaround to fix some memory clock jitter.
Note: This should be but can't be done in the DCD. The bootloader
prevents access to the ANATOP registers.
Signed-off-by: Dirk Behme dirk.be...@de.bosch.com
CC: Jason Chen b02...@freescale.com
CC: Jason Liu r64...@freescale.com
CC: Ranjani Vaidyanathan ra5...@freescale.com
CC: Stefano Babic sba...@denx.de
CC: Fabio Estevam feste...@gmail.com
---
Hi Dirk,
+static void init_anatop_reg(void)
+{
+ struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
+ int reg = readl(anatop-reg_core);
+
+ /*
+ * Increase the VDDSOC to 1.2V
+ * Mask out the REG_CORE[22:18] bits (REG2_TRIG)
+ * and set them to 1.2V (0.7V + 0x14 * 0.025V)
+ */
+ reg = (reg ~(0x1F 18)) | (0x14 18);
Everything clear, but what do you mind to add an accessor to set this
voltage ? It is straightforward, and more boards could use it.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix the behaviour of the 'run' command
If one command fails, 'run' command should terminate and not execute any remaining variables. Signed-off-by: Timo Ketola t...@exertus.fi --- This is based on u-boot-imx.git next. I hope that doesn't cause too much trouble. common/main.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/common/main.c b/common/main.c index db181d3..3b9e39a 100644 --- a/common/main.c +++ b/common/main.c @@ -1338,7 +1338,8 @@ static int builtin_run_command(const char *cmd, int flag) continue; } - rc = cmd_process(flag, argc, argv, repeatable); + if (cmd_process(flag, argc, argv, repeatable)) + rc = -1; /* Did the user stop this? */ if (had_ctrlc ()) -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix the behaviour of the 'run' command
Dear Timo Ketola, In message 1335175047-30984-1-git-send-email-t...@exertus.fi you wrote: If one command fails, 'run' command should terminate and not execute any remaining variables. Signed-off-by: Timo Ketola t...@exertus.fi --- This is based on u-boot-imx.git next. I hope that doesn't cause too much trouble. common/main.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) Tested on TQM5200S. Tested-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 To live is always desirable. -- Eleen the Capellan, Friday's Child, stardate 3498.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] EXYNOS: draw 32bpp bitmap TIZEN logo
Thank you for your comment.
On 23 April 2012 18:00, Minkyu Kang wrote:
On 23 April 2012 10:47, Donghwa Lee dh09@samsung.com wrote:
This patches support drawing 32bpp bitmap TIZEN logo in exynos fb.
asm/arch/trats_logo.h data is compressed by zip and decomressed at
the exynos fb driver.
And vl_bpix of vidinfo_t is changed proper value for u-boot.
Signed-off-by: Donghwa Lee dh09@samsung.com
Signed-off-by: Kyungmin park kyungmin.p...@samsung.com
---
arch/arm/include/asm/arch-exynos/trats_logo.h | 5070
+
board/samsung/trats/trats.c |2 +-
drivers/video/exynos_fb.c | 40 +-
drivers/video/exynos_fimd.c |6 +-
include/configs/trats.h |4 +-
5 files changed, 5116 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/include/asm/arch-exynos/trats_logo.h
diff --git a/arch/arm/include/asm/arch-exynos/trats_logo.h
b/arch/arm/include/asm/arch-exynos/trats_logo.h
new file mode 100644
index 000..a595abd
--- /dev/null
+++ b/arch/arm/include/asm/arch-exynos/trats_logo.h
@@ -0,0 +1,5070 @@
+/*
+ * (C) Copyright 2012 Samsung Electronics
+ * Donghwa Lee dh09@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * aint with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+#defineTRATS_LOGO_WIDTH520
+#defineTRATS_LOGO_HEIGHT 120
+#defineTRATS_LOGO_BPP 32
+
+unsigned char trats_logo[]={
+};
trats logo?
I feel, it's a TIZEN logo maybe.
Also, Is it a board specific? then it should be moved to boards/samsung/trats/
Ok, I will change to TIZEN logo and move it to board/samsung/trats.
diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
index f9894b1..d067bb4 100644
--- a/board/samsung/trats/trats.c
+++ b/board/samsung/trats/trats.c
@@ -467,7 +467,7 @@ void init_panel_info(vidinfo_t *vid)
vid-vl_vsp = CONFIG_SYS_LOW;
vid-vl_dp = CONFIG_SYS_LOW;
- vid-vl_bpix= 32;
+ vid-vl_bpix= 5;
vid-dual_lcd_enabled = 0;
/* s6e8ax0 Panel */
diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index 0eb7f58..c111855 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -22,6 +22,7 @@
#include config.h
#include common.h
+#include malloc.h
#include lcd.h
#include asm/io.h
#include asm/arch/cpu.h
@@ -29,6 +30,7 @@
#include asm/arch/clk.h
#include asm/arch/mipi_dsim.h
#include asm/arch/system.h
+#include asm/arch/trats_logo.h
#include exynos_fb.h
@@ -52,7 +54,7 @@ static void exynos_lcd_init_mem(void *lcdbase, vidinfo_t
*vid)
unsigned long palette_size;
unsigned int fb_size;
- fb_size = vid-vl_row * vid-vl_col * (vid-vl_bpix 3);
+ fb_size = vid-vl_row * vid-vl_col * (NBITS(vid-vl_bpix) 3);
lcd_base = lcdbase;
@@ -67,6 +69,38 @@ static void exynos_lcd_init(vidinfo_t *vid)
exynos_fimd_lcd_init(vid);
}
+static void draw_logo(void *lcdbase)
+{
+ int x, y;
+ unsigned int in_len, width, height;
+ unsigned long out_len =
+ (ARRAY_SIZE(trats_logo) * sizeof(*trats_logo)) + 1;
+ void *dst = NULL;
+
+ width = TRATS_LOGO_WIDTH;
+ height = TRATS_LOGO_HEIGHT;
NAK.
trats_logo and TRATS_* are board specific.
I will add logo size variable in the vidinfo_t structure.
+ x = ((panel_width - width) 1);
+ y = ((panel_height - height) 1) - 5;
+
+ in_len = width * height * 8;
+ dst = malloc(in_len);
+ if (dst == NULL) {
+ printf(Error: malloc in gunzip failed!\n);
+ return;
+ }
need space here.
+ if (gunzip(dst, in_len, (uchar *)trats_logo, out_len) != 0) {
+ free(dst);
+ return;
+ }
need space here.
Ok, I will fix it.
+ if (out_len == CONFIG_SYS_VIDEO_LOGO_MAX_SIZE)
need brace at this if statement.
And maybe it should be if (out_len = CONFIG_SYS_VIDEO_LOGO_MAX_SIZE) ?
+ printf(Image could be truncated
+(increase
CONFIG_SYS_VIDEO_LOGO_MAX_SIZE)!\n);
+
+ lcd_display_bitmap((ulong)dst, x, y);
+
+
Re: [U-Boot] [PATCH] i.MX6: Add ANATOP regulator init
Hi Stefano,
On 23.04.2012 11:55, Stefano Babic wrote:
On 13/04/2012 10:00, Dirk Behme wrote:
Init the core regulator voltage to 1.2V. This is required for the correct
functioning of the GPU and when the ARM LDO is set to 1.225V. This is a
workaround to fix some memory clock jitter.
Note: This should be but can't be done in the DCD. The bootloader
prevents access to the ANATOP registers.
Signed-off-by: Dirk Behme dirk.be...@de.bosch.com
CC: Jason Chen b02...@freescale.com
CC: Jason Liu r64...@freescale.com
CC: Ranjani Vaidyanathan ra5...@freescale.com
CC: Stefano Babic sba...@denx.de
CC: Fabio Estevam feste...@gmail.com
---
Hi Dirk,
+static void init_anatop_reg(void)
+{
+ struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
+ int reg = readl(anatop-reg_core);
+
+ /*
+* Increase the VDDSOC to 1.2V
+* Mask out the REG_CORE[22:18] bits (REG2_TRIG)
+* and set them to 1.2V (0.7V + 0x14 * 0.025V)
+*/
+ reg = (reg ~(0x1F 18)) | (0x14 18);
Everything clear, but what do you mind to add an accessor to set this
voltage ? It is straightforward, and more boards could use it.
Sorry, but what do you mean with add an accessor? Could you give an
example?
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX6: Add ANATOP regulator init
On 23/04/2012 11:55, Stefano Babic wrote:
+static void init_anatop_reg(void)
+{
+struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
+int reg = readl(anatop-reg_core);
+
+/*
+ * Increase the VDDSOC to 1.2V
+ * Mask out the REG_CORE[22:18] bits (REG2_TRIG)
+ * and set them to 1.2V (0.7V + 0x14 * 0.025V)
+ */
+reg = (reg ~(0x1F 18)) | (0x14 18);
Everything clear, but what do you mind to add an accessor to set this
voltage ? It is straightforward, and more boards could use it.
Well, sometimes I am quite obscure, maybe I need more coffeine before
writing my answers ;-)
What I mean is to change the function name to something like
set_vddsoc(mV), and exporting it dropping the static clause.
Stefano
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] EXYNOS: draw 32bpp bitmap TIZEN logo
On 23 April 2012 19:16, Donghwa Lee dh09@samsung.com wrote:
Thank you for your comment.
On 23 April 2012 18:00, Minkyu Kang wrote:
On 23 April 2012 10:47, Donghwa Lee dh09@samsung.com wrote:
This patches support drawing 32bpp bitmap TIZEN logo in exynos fb.
asm/arch/trats_logo.h data is compressed by zip and decomressed at
the exynos fb driver.
And vl_bpix of vidinfo_t is changed proper value for u-boot.
Signed-off-by: Donghwa Lee dh09@samsung.com
Signed-off-by: Kyungmin park kyungmin.p...@samsung.com
---
arch/arm/include/asm/arch-exynos/trats_logo.h | 5070
+
board/samsung/trats/trats.c | 2 +-
drivers/video/exynos_fb.c | 40 +-
drivers/video/exynos_fimd.c | 6 +-
include/configs/trats.h | 4 +-
5 files changed, 5116 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/include/asm/arch-exynos/trats_logo.h
static void lcd_panel_on(vidinfo_t *vid)
{
udelay(vid-init_delay);
@@ -113,6 +147,10 @@ void lcd_ctrl_init(void *lcdbase)
exynos_lcd_init_mem(lcdbase, panel_info);
+ memset(lcdbase, 0, panel_width * panel_height *
+ (NBITS(panel_info.vl_bpix) 3));
+ draw_logo(lcdbase);
Always draw the logo?
umh... How about your opinion? When board start, I think boot logo has to
turn on.
For example, some boards doesn't have logo. but want to enable the FB.
then how it work?
Maybe, you will get errors.
+
exynos_lcd_init(panel_info);
}
diff --git a/drivers/video/exynos_fimd.c b/drivers/video/exynos_fimd.c
index cd2b1b6..8f2d667 100644
--- a/drivers/video/exynos_fimd.c
+++ b/drivers/video/exynos_fimd.c
@@ -110,7 +110,7 @@ static void exynos_fimd_set_buffer_address(unsigned int
win_id)
(struct exynos4_fb *)samsung_get_base_fimd();
start_addr = (unsigned long)lcd_base_addr;
- end_addr = start_addr + ((pvid-vl_col * (pvid-vl_bpix / 8)) *
+ end_addr = start_addr + ((pvid-vl_col * (NBITS(pvid-vl_bpix) /
8)) *
Is it related change?
I think this is another bug fix.
If so, please fix them to another patch.
in u-boot mainline vl_bpix is usually used like this, so I had changed.
Before sending
this patch, exynos framebuffer didn't drawing logo. At that time I didn't
know above macro.
But if it is not used like above, drawing logo feature is not worked.
Yes it's a bug.
If you want to separate another patch, I will do that.
Yes please.
Thanks.
Minkyu Kang.
--
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2012.04 released, Merge Window is OPEN
Le 21/04/2012 22:51, Wolfgang Denk a écrit : Hello all, U-Boot v2012.04 has been released and is available from the git repository and the FTP server. The Merge Window for the next release (v2012.07) is open until Sat May 12, 2012, 23:59:59 CEST = 21 days remaining. Release v2012.07 is scheduled in 86 days — on July 16, 2012. Hi all, I have moved all u-boot-arm/next commits to u-boot-arm/master and rebased on current u-boot/master. Word of warning to other ARM tree custodians: make sure to always use current u-boot-arm/master for any pull request, as I might rebase it onto u-boot/master without notice. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 'run' no longer aborts on an error, can someone please verify
Hi Timo,
On Apr 23, 2012 5:43 PM, Timo Ketola t...@exertus.fi wrote:
Dear Gray, Jason, Heiko, Simon,
I added you, Jason, Heiko and Simon, into the CC-list because there is
your commits in the history which seems somewhere to change the
behaviour below:
On 22.04.2012 00:55, Gray Remlin wrote:
U-Boot v2012.04
Marvell setenv ipaddr '192.168.1.130'
Marvell setenv ifhostisup 'ping 192.168.1.100'
Marvell setenv saywearehappy 'echo We are happy!'
Marvell run ifhostisup saywearehappy;
Using egiga0 device
ping failed; host 192.168.1.100 is not alive
We are happy!
Marvell
This is not the same behaviour as my (unfortunately customised) version
based on the ancient U-Boot 2009.11
Other commands are also effected, for example 'ide dev 0' would abort a
'run' command if the device did not exist.
Is this my problem (corrupted source\compilation) or a change in policy
?
I took a quick glance over command/main.c. I think this is the original
behaviour (tree 9c506e 23 Aug 2011):
1374 /* OK - call function to do the command */
1375 if ((cmdtp-cmd) (cmdtp, flag, argc, argv) != 0) {
1376 rc = -1;
1377 }
run_command returns -1 on failure and
1407 if (run_command (arg, flag) == -1)
1408 return 1;
do_run exits the loop based on that.
Now (tree 762494 6 Mar 2012) builtin_run_command:
1341 rc = cmd_process(flag, argc, argv, repeatable);
returns the exit code of the command but:
1366 if (builtin_run_command(cmd, flag) == -1)
1367 return 1;
run_command now depends on it to return -1 on failure. If I followed the
code right, this is clear change in the behaviour. I hope it is not
intentional and can be fixed because I have (too?) scripts that depends
on old behaviour. For example:
run get_update_from_usb erase_flash_and_write_it
Sequence must not continue to touching flash if load from USB fails.
Thanks for the detailed information. This might be the problem Wolfgang
mentioned at the time...will take a look tomorrow.
Regards,
Simon
--
Timo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 'run' no longer aborts on an error, can someone please verify
Dear Simon, In message capnjgz2vkx3tp6wmswixeys1q3xm+6wjoiyxwc23jpfim_0...@mail.gmail.com you wrote: Thanks for the detailed information. This might be the problem Wolfgang mentioned at the time...will take a look tomorrow. Could you please try and look into this ASAP? I consider this a serious bug, and would like to fix it in mainline as soon as possible. I think I will then even issue a v12.04.1 bugfix release. 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 Virtual means never knowing where your next byte is coming from. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RESEND PATCH v6 0/4] mmc: support sdhci instead of s5p_mmc
This patchset is supported the sdhci controller for Samsung-SoC. In mmc driver, already implemented the generic sdhci. There is no reason that didn't use sdhci.c. So, use the sdhci instead of s5p_mmc. Changelog-v6: - Fix typo - Code clean for #define Changelog-v5: - Tested with goni/trats board - Fixed wrong condition checking - Increased retry time - Add the quirk_broken_r1b in s5p_sdhci.c Changelog-v4: - seperate the device driver and SoC patch. Changelog-v3: - Add the quirks for broken R1b response. - Add the timeout to prevent infinite loop. Changelog-v2: - removed the s5p_mmc.c - based-on u-boot-samsung repository. Jaehoon Chung (4): mmc: sdhci: add the quirk for broken r1b response mmc: add the quirk to use the sdhci for samsung-soc mmc: support the sdhci intead of s5p_mmc for samsung-soc ARM: SAMSUNG: support sdhci controller arch/arm/include/asm/arch-exynos/mmc.h | 93 +++--- arch/arm/include/asm/arch-s5pc1xx/mmc.h | 93 +++--- drivers/mmc/Makefile|2 +- drivers/mmc/s5p_mmc.c | 490 --- drivers/mmc/s5p_sdhci.c | 98 ++ drivers/mmc/sdhci.c | 24 ++ include/configs/origen.h|7 +- include/configs/s5p_goni.h |7 +- include/configs/s5pc210_universal.h |7 +- include/configs/smdk5250.h |3 +- include/configs/smdkv310.h |7 +- include/configs/trats.h |3 +- include/sdhci.h |7 + 13 files changed, 244 insertions(+), 597 deletions(-) delete mode 100644 drivers/mmc/s5p_mmc.c create mode 100644 drivers/mmc/s5p_sdhci.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RESEND PATCH v6 1/4] mmc: sdhci: add the quirk for broken r1b response
When response type is R1b, mask value is added the SDHCI_INT_DAT_END.
but in while(), didn't check that flag.
So sdhci controller didn't work fine.
CMD6 didn't always complete.
So add the quirks for broken r1b response
and add the timeout value to prevent the infinite loop.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Lei Wenlei...@marvell.com
---
drivers/mmc/sdhci.c | 12
include/sdhci.h |1 +
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index fc904b5..7790a1e 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -128,6 +128,7 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd,
int trans_bytes = 0, is_aligned = 1;
u32 mask, flags, mode;
unsigned int timeout, start_addr = 0;
+ unsigned int retry = 1;
/* Wait max 10 ms */
timeout = 10;
@@ -210,8 +211,19 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd
*cmd,
stat = sdhci_readl(host, SDHCI_INT_STATUS);
if (stat SDHCI_INT_ERROR)
break;
+ if (--retry == 0)
+ break;
} while ((stat mask) != mask);
+ if (retry == 0) {
+ if (host-quirks SDHCI_QUIRK_BROKEN_R1B)
+ return 0;
+ else {
+ printf(Timeout for status update!\n);
+ return TIMEOUT;
+ }
+ }
+
if ((stat (SDHCI_INT_ERROR | mask)) == mask) {
sdhci_cmd_done(host, cmd);
sdhci_writel(host, mask, SDHCI_INT_STATUS);
diff --git a/include/sdhci.h b/include/sdhci.h
index 800f9d9..a2415ba 100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -216,6 +216,7 @@
*/
#define SDHCI_QUIRK_32BIT_DMA_ADDR (1 0)
#define SDHCI_QUIRK_REG32_RW (1 1)
+#define SDHCI_QUIRK_BROKEN_R1B (1 2)
/* to make gcc happy */
struct sdhci_host;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RESEND PATCH v6 2/4] mmc: add the quirk to use the sdhci for samsung-soc
To support the Samsung-SoC, added the basically functions.
Samsung-SoC didn't used the SDHCI_CTRL_HISPD.
And added set_control_reg callback for s3c64xx.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Lei Wenlei...@marvell.com
---
drivers/mmc/sdhci.c | 12
include/sdhci.h |6 ++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 7790a1e..1709643 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -337,6 +337,9 @@ void sdhci_set_ios(struct mmc *mmc)
u32 ctrl;
struct sdhci_host *host = (struct sdhci_host *)mmc-priv;
+ if (host-set_control_reg)
+ host-set_control_reg(host);
+
if (mmc-clock != host-clock)
sdhci_set_clock(mmc, mmc-clock);
@@ -360,6 +363,9 @@ void sdhci_set_ios(struct mmc *mmc)
else
ctrl = ~SDHCI_CTRL_HISPD;
+ if (host-quirks SDHCI_QUIRK_NO_HISPD_BIT)
+ ctrl = ~SDHCI_CTRL_HISPD;
+
sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
}
@@ -443,9 +449,15 @@ int add_sdhci(struct sdhci_host *host, u32 max_clk, u32
min_clk)
mmc-voltages |= MMC_VDD_29_30 | MMC_VDD_30_31;
if (caps SDHCI_CAN_VDD_180)
mmc-voltages |= MMC_VDD_165_195;
+
+ if (host-quirks SDHCI_QUIRK_BROKEN_VOLTAGE)
+ mmc-voltages |= host-voltages;
+
mmc-host_caps = MMC_MODE_HS | MMC_MODE_HS_52MHz | MMC_MODE_4BIT;
if (caps SDHCI_CAN_DO_8BIT)
mmc-host_caps |= MMC_MODE_8BIT;
+ if (host-host_caps)
+ mmc-host_caps |= host-host_caps;
sdhci_reset(host, SDHCI_RESET_ALL);
mmc_register(mmc);
diff --git a/include/sdhci.h b/include/sdhci.h
index a2415ba..9d37183 100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -217,6 +217,8 @@
#define SDHCI_QUIRK_32BIT_DMA_ADDR (1 0)
#define SDHCI_QUIRK_REG32_RW (1 1)
#define SDHCI_QUIRK_BROKEN_R1B (1 2)
+#define SDHCI_QUIRK_NO_HISPD_BIT (1 3)
+#define SDHCI_QUIRK_BROKEN_VOLTAGE (1 4)
/* to make gcc happy */
struct sdhci_host;
@@ -241,10 +243,14 @@ struct sdhci_host {
char *name;
void *ioaddr;
unsigned int quirks;
+ unsigned int host_caps;
unsigned int version;
unsigned int clock;
struct mmc *mmc;
const struct sdhci_ops *ops;
+
+ void (*set_control_reg)(struct sdhci_host *host);
+ uintvoltages;
};
#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RESEND PATCH v6 4/4] ARM: SAMSUNG: support sdhci controller
To support sdhci controller, remove the CONFIG_S5P_MMC.. Instead, use the CONFIG_S5P_SDHCI/CONFIG_SDHCI. Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Lei Wenlei...@marvell.com Acked-by: Minkyu Kang mk7.k...@samsung.com --- include/configs/origen.h|7 --- include/configs/s5p_goni.h |7 --- include/configs/s5pc210_universal.h |7 --- include/configs/smdk5250.h |3 ++- include/configs/smdkv310.h |7 --- include/configs/trats.h |3 ++- 6 files changed, 20 insertions(+), 14 deletions(-) diff --git a/include/configs/origen.h b/include/configs/origen.h index 8ede825..367f991 100644 --- a/include/configs/origen.h +++ b/include/configs/origen.h @@ -69,9 +69,10 @@ #define EXYNOS4_DEFAULT_UART_OFFSET0x02 /* SD/MMC configuration */ -#define CONFIG_GENERIC_MMC 1 -#define CONFIG_MMC 1 -#define CONFIG_S5P_MMC 1 +#define CONFIG_GENERIC_MMC +#define CONFIG_MMC +#define CONFIG_SDHCI +#define CONFIG_S5P_SDHCI /* PWM */ #define CONFIG_PWM 1 diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h index 56b5547..e133a17 100644 --- a/include/configs/s5p_goni.h +++ b/include/configs/s5p_goni.h @@ -63,9 +63,10 @@ #define CONFIG_BAUDRATE115200 /* MMC */ -#define CONFIG_GENERIC_MMC 1 -#define CONFIG_MMC 1 -#define CONFIG_S5P_MMC 1 +#define CONFIG_GENERIC_MMC +#define CONFIG_MMC +#define CONFIG_SDHCI +#define CONFIG_S5P_SDHCI /* PWM */ #define CONFIG_PWM 1 diff --git a/include/configs/s5pc210_universal.h b/include/configs/s5pc210_universal.h index 1301275..00db374 100644 --- a/include/configs/s5pc210_universal.h +++ b/include/configs/s5pc210_universal.h @@ -66,9 +66,10 @@ #define CONFIG_BAUDRATE115200 /* MMC */ -#define CONFIG_GENERIC_MMC 1 -#define CONFIG_MMC 1 -#define CONFIG_S5P_MMC 1 +#define CONFIG_GENERIC_MMC +#define CONFIG_MMC +#define CONFIG_SDHCI +#define CONFIG_S5P_SDHCI /* PWM */ #define CONFIG_PWM 1 diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h index 9659f9e..0f63040 100644 --- a/include/configs/smdk5250.h +++ b/include/configs/smdk5250.h @@ -78,7 +78,8 @@ /* SD/MMC configuration */ #define CONFIG_GENERIC_MMC #define CONFIG_MMC -#define CONFIG_S5P_MMC +#define CONFIG_SDHCI +#define CONFIG_S5P_SDHCI #define CONFIG_BOARD_EARLY_INIT_F diff --git a/include/configs/smdkv310.h b/include/configs/smdkv310.h index 93c25da..702134b 100644 --- a/include/configs/smdkv310.h +++ b/include/configs/smdkv310.h @@ -68,9 +68,10 @@ #define EXYNOS4_DEFAULT_UART_OFFSET0x01 /* SD/MMC configuration */ -#define CONFIG_GENERIC_MMC 1 -#define CONFIG_MMC 1 -#define CONFIG_S5P_MMC 1 +#define CONFIG_GENERIC_MMC +#define CONFIG_MMC +#define CONFIG_SDHCI +#define CONFIG_S5P_SDHCI /* PWM */ #define CONFIG_PWM 1 diff --git a/include/configs/trats.h b/include/configs/trats.h index 10f11d9..71b9393 100644 --- a/include/configs/trats.h +++ b/include/configs/trats.h @@ -74,7 +74,8 @@ /* MMC */ #define CONFIG_GENERIC_MMC #define CONFIG_MMC -#define CONFIG_S5P_MMC +#define CONFIG_S5P_SDHCI +#define CONFIG_SDHCI /* PWM */ #define CONFIG_PWM ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RESEND PATCH v6 3/4] mmc: support the sdhci instead of s5p_mmc for samsung-soc
In driver mmc, generic s5p_sdhci code is implemented.
s5p_mmc file is dupulicated.
we are good that use the generic sdhci.
This patch supported the sdhci for Samsung-SoC.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Lei Wenlei...@marvell.com
Acked-by: Minkyu Kang mk7.k...@samsung.com
---
arch/arm/include/asm/arch-exynos/mmc.h | 93 +++---
arch/arm/include/asm/arch-s5pc1xx/mmc.h | 93 +++---
drivers/mmc/Makefile|2 +-
drivers/mmc/s5p_mmc.c | 490 ---
drivers/mmc/s5p_sdhci.c | 98 ++
5 files changed, 193 insertions(+), 583 deletions(-)
delete mode 100644 drivers/mmc/s5p_mmc.c
create mode 100644 drivers/mmc/s5p_sdhci.c
diff --git a/arch/arm/include/asm/arch-exynos/mmc.h
b/arch/arm/include/asm/arch-exynos/mmc.h
index 30f82b8..0f701c9 100644
--- a/arch/arm/include/asm/arch-exynos/mmc.h
+++ b/arch/arm/include/asm/arch-exynos/mmc.h
@@ -21,53 +21,54 @@
#ifndef __ASM_ARCH_MMC_H_
#define __ASM_ARCH_MMC_H_
-#ifndef __ASSEMBLY__
-struct s5p_mmc {
- unsigned intsysad;
- unsigned short blksize;
- unsigned short blkcnt;
- unsigned intargument;
- unsigned short trnmod;
- unsigned short cmdreg;
- unsigned intrspreg0;
- unsigned intrspreg1;
- unsigned intrspreg2;
- unsigned intrspreg3;
- unsigned intbdata;
- unsigned intprnsts;
- unsigned char hostctl;
- unsigned char pwrcon;
- unsigned char blkgap;
- unsigned char wakcon;
- unsigned short clkcon;
- unsigned char timeoutcon;
- unsigned char swrst;
- unsigned intnorintsts; /* errintsts */
- unsigned intnorintstsen;/* errintstsen */
- unsigned intnorintsigen;/* errintsigen */
- unsigned short acmd12errsts;
- unsigned char res1[2];
- unsigned intcapareg;
- unsigned char res2[4];
- unsigned intmaxcurr;
- unsigned char res3[0x34];
- unsigned intcontrol2;
- unsigned intcontrol3;
- unsigned char res4[4];
- unsigned intcontrol4;
- unsigned char res5[0x6e];
- unsigned short hcver;
- unsigned char res6[0xFF00];
-};
+#define SDHCI_CONTROL2 0x80
+#define SDHCI_CONTROL3 0x84
+#define SDHCI_CONTROL4 0x8C
-struct mmc_host {
- struct s5p_mmc *reg;
- unsigned int version; /* SDHCI spec. version */
- unsigned int clock; /* Current clock (MHz) */
- int dev_index;
-};
+#define SDHCI_CTRL2_ENSTAASYNCCLR (1 31)
+#define SDHCI_CTRL2_ENCMDCNFMSK(1 30)
+#define SDHCI_CTRL2_CDINVRXD3 (1 29)
+#define SDHCI_CTRL2_SLCARDOUT (1 28)
-int s5p_mmc_init(int dev_index, int bus_width);
+#define SDHCI_CTRL2_FLTCLKSEL_MASK (0xf 24)
+#define SDHCI_CTRL2_FLTCLKSEL_SHIFT(24)
+#define SDHCI_CTRL2_FLTCLKSEL(_x) ((_x) 24)
-#endif /* __ASSEMBLY__ */
+#define SDHCI_CTRL2_LVLDAT_MASK(0xff 16)
+#define SDHCI_CTRL2_LVLDAT_SHIFT (16)
+#define SDHCI_CTRL2_LVLDAT(_x) ((_x) 16)
+
+#define SDHCI_CTRL2_ENFBCLKTX (1 15)
+#define SDHCI_CTRL2_ENFBCLKRX (1 14)
+#define SDHCI_CTRL2_SDCDSEL(1 13)
+#define SDHCI_CTRL2_SDSIGPC(1 12)
+#define SDHCI_CTRL2_ENBUSYCHKTXSTART (1 11)
+
+#define SDHCI_CTRL2_DFCNT_MASK(_x) ((_x) 9)
+#define SDHCI_CTRL2_DFCNT_SHIFT(9)
+
+#define SDHCI_CTRL2_ENCLKOUTHOLD (1 8)
+#define SDHCI_CTRL2_RWAITMODE (1 7)
+#define SDHCI_CTRL2_DISBUFRD (1 6)
+#define SDHCI_CTRL2_SELBASECLK_MASK(_x)((_x) 4)
+#define SDHCI_CTRL2_SELBASECLK_SHIFT (4)
+#define SDHCI_CTRL2_PWRSYNC(1 3)
+#define SDHCI_CTRL2_ENCLKOUTMSKCON (1 1)
+#define SDHCI_CTRL2_HWINITFIN (1 0)
+
+#define SDHCI_CTRL3_FCSEL3 (1 31)
+#define SDHCI_CTRL3_FCSEL2 (1 23)
+#define SDHCI_CTRL3_FCSEL1 (1 15)
+#define SDHCI_CTRL3_FCSEL0 (1 7)
+
+#define SDHCI_CTRL4_DRIVE_MASK(_x) ((_x) 16)
+#define SDHCI_CTRL4_DRIVE_SHIFT(16)
+
+int s5p_sdhci_init(u32 regbase, u32 max_clk, u32 min_clk, u32 quirks);
+
+static inline unsigned int s5p_mmc_init(int index, int bus_width)
+{
+ unsigned int base = samsung_get_base_mmc() + (0x1 * index);
+ return s5p_sdhci_init(base, 5200, 40, index);
+}
#endif
diff --git a/arch/arm/include/asm/arch-s5pc1xx/mmc.h
b/arch/arm/include/asm/arch-s5pc1xx/mmc.h
index adef4ee..0f701c9 100644
--- a/arch/arm/include/asm/arch-s5pc1xx/mmc.h
+++ b/arch/arm/include/asm/arch-s5pc1xx/mmc.h
@@ -21,53 +21,54 @@
#ifndef __ASM_ARCH_MMC_H_
#define __ASM_ARCH_MMC_H_
-#ifndef __ASSEMBLY__
-struct s5p_mmc {
- unsigned intsysad;
- unsigned short blksize;
- unsigned short
[U-Boot] [PATCH] spi: mxs: Allow other chip selects to work
MXS SSP controller may have up to three chip selects per port: SS0, SS1 and SS2.
Currently only SS0 is supported in the mxs_spi driver.
Allow all the three chip select to work by selecting the desired one
in bits 20 and 21 of the HW_SSP_CTRL0 register.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/spi/mxs_spi.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/mxs_spi.c b/drivers/spi/mxs_spi.c
index 4e6f14e..c0bfd25 100644
--- a/drivers/spi/mxs_spi.c
+++ b/drivers/spi/mxs_spi.c
@@ -34,6 +34,8 @@
#defineMXS_SPI_MAX_TIMEOUT 100
#defineMXS_SPI_PORT_OFFSET 0x2000
+#define MXS_SSP_CHIPSELECT_MASK0x0030
+#define MXS_SSP_CHIPSELECT_SHIFT 20
struct mxs_spi_slave {
struct spi_slaveslave;
@@ -56,12 +58,19 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
{
struct mxs_spi_slave *mxs_slave;
uint32_t addr;
+ struct mx28_ssp_regs *ssp_regs;
+ int reg;
if (bus 3) {
printf(MXS SPI: Max bus number is 3\n);
return NULL;
}
+ if (cs 2) {
+ printf(MXS SPI: Invalid chip select number: %d\n, cs);
+ return NULL;
+ }
+
mxs_slave = malloc(sizeof(struct mxs_spi_slave));
if (!mxs_slave)
return NULL;
@@ -74,6 +83,14 @@ struct spi_slave *spi_setup_slave(unsigned int bus, unsigned
int cs,
mxs_slave-mode = mode;
mxs_slave-regs = (struct mx28_ssp_regs *)addr;
+ ssp_regs = mxs_slave-regs;
+
+ reg = readl(ssp_regs-hw_ssp_ctrl0);
+ reg = ~(MXS_SSP_CHIPSELECT_MASK);
+ reg |= cs MXS_SSP_CHIPSELECT_SHIFT;
+
+ writel(reg, ssp_regs-hw_ssp_ctrl0);
+
return mxs_slave-slave;
}
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spi: mxs: Allow other chip selects to work
Dear Fabio Estevam,
MXS SSP controller may have up to three chip selects per port: SS0, SS1 and
SS2.
Currently only SS0 is supported in the mxs_spi driver.
Allow all the three chip select to work by selecting the desired one
in bits 20 and 21 of the HW_SSP_CTRL0 register.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/spi/mxs_spi.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/mxs_spi.c b/drivers/spi/mxs_spi.c
index 4e6f14e..c0bfd25 100644
--- a/drivers/spi/mxs_spi.c
+++ b/drivers/spi/mxs_spi.c
@@ -34,6 +34,8 @@
#define MXS_SPI_MAX_TIMEOUT 100
#define MXS_SPI_PORT_OFFSET 0x2000
+#define MXS_SSP_CHIPSELECT_MASK 0x0030
+#define MXS_SSP_CHIPSELECT_SHIFT 20
struct mxs_spi_slave {
struct spi_slaveslave;
@@ -56,12 +58,19 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs, {
struct mxs_spi_slave *mxs_slave;
uint32_t addr;
+ struct mx28_ssp_regs *ssp_regs;
+ int reg;
if (bus 3) {
printf(MXS SPI: Max bus number is 3\n);
return NULL;
}
+ if (cs 2) {
+ printf(MXS SPI: Invalid chip select number: %d\n, cs);
+ return NULL;
+ }
+
mxs_slave = malloc(sizeof(struct mxs_spi_slave));
if (!mxs_slave)
return NULL;
@@ -74,6 +83,14 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs, mxs_slave-mode = mode;
mxs_slave-regs = (struct mx28_ssp_regs *)addr;
+ ssp_regs = mxs_slave-regs;
+
+ reg = readl(ssp_regs-hw_ssp_ctrl0);
+ reg = ~(MXS_SSP_CHIPSELECT_MASK);
+ reg |= cs MXS_SSP_CHIPSELECT_SHIFT;
+
+ writel(reg, ssp_regs-hw_ssp_ctrl0);
+
return mxs_slave-slave;
}
Acked-by: Marek Vasut ma...@denx.de
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Preventing overriding of serverip when set in environment by user
-Original Message- From: Stefano Babic [mailto:sba...@denx.de] Sent: Thursday, April 19, 2012 4:14 AM To: Peter Barada Cc: u-boot@lists.denx.de; Maupin, Chase Subject: Re: [U-Boot] [RFC] Preventing overriding of serverip when set in environment by user On 18/04/2012 17:46, Peter Barada wrote: On 04/18/2012 11:28 AM, Wolfgang Denk wrote: Is this the proper way to fix this issue and the right location to make the change? The overall goal was to make sure that if I specified a particular serverip that I wanted to use, then the DHCP server should not be changing that. No, this is not an acceptable patch. What exactly _are_ you trying to fix? What is wrong with using the DHCP server supplied address? If it is incorrect, you should fix your DHCP server configuration. I have the same type of problem. In my case our company controls the DHCP server that hands out addresses for the network, but I want to use a *local* TFTP server (the one on my development machine). I can't modify the DHCP server so if I use dhcp to get and address u-boot also overwrites serverip. At home my FiOS router has a DHCP server (that I can't modify since its closed and is needed to provide addresses to my TV set top box) that provides addresses for my network, and has the same problem... Would an option to dhcp (i.e. one that tells it to *only* modify ipaddr) suffice? Or would it be better to provide an entirely a new command that optionally updates the variables in the environment be better? Then users have the option of using dhcp as is, or for environments like mine (and apparently Chase) can just get an IP address and go from there... There is already such as option. You can pass the tftp server in the tftpcommand, see code: tftp [loadAddress] [[hostIPaddr:]bootfilename] for example, something like tftp 0x80008000 192.168.1.1:uImage Is it not enough ? I think it will be. This can be worked around and I had a misunderstanding of how the DHCP response was being used. Thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Add support for MINI2440 (s3c2440). Documentation about the product can be found on: http://www.friendlyarm.net/products/mini2440
Dear Marek Vasut, Would you please explain, why do you want to initialize the sdram has been in C code. If for provide this feature should be written assembly code. And it would sometimes even harder than the initialization code sdram? 2012/4/21 Marek Vasut ma...@denx.de Dear Ilya Averyanov, 2012/4/21 Vasily Khoruzhick anars...@gmail.com 2012/4/21 Ilya Averyanov averyanovin+ub...@gmail.com: No have problem. Available only if you boot from NOR flash. If you boot from the NAND 4kb of SRAM (steppingstone) not available. For NAND boot it's mapped at 0x0 For NOR boot it's mapped at 0x4000 NAND controller uses it for booting purpose, but anyway for SPL we should fit code into 4k (hardware limitation), so I think using assembly here for SDRAM init is OK. And how will you use the internal SRAM when you boot from NAND, if the SoC writes in the SDRAM read data from NAND, and your data will be overwritten. Why? You'll load SPL into SRAM, then in SPL you'll copy the rest of uboot from NAND to - then already inited - SDRAM and execute it. We even have ready-to-use NAND SPL. Regards Vasily Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Add support for MINI2440 (s3c2440). Documentation about the product can be found on: http://www.friendlyarm.net/products/mini2440
Dear Ilya Averyanov, Dear Marek Vasut, Would you please explain, why do you want to initialize the sdram has been in C code. Ok, no problem: - You'll be able to call get_ram_size() to scan for ram size as any other board - SDRAM driver will fit properly into the driver model once it's in place (WIP, wanna volunteer for review process?) - It's much cleaner If for provide this feature should be written assembly code. And it would sometimes even harder than the initialization code sdram? What do you mean? Ah yes, just a remark, please don't top-post. Notice how other people don't do it -- I know gmail does it out-of-the-box, but that doesn't mean it's correct. 2012/4/21 Marek Vasut ma...@denx.de Dear Ilya Averyanov, 2012/4/21 Vasily Khoruzhick anars...@gmail.com 2012/4/21 Ilya Averyanov averyanovin+ub...@gmail.com: No have problem. Available only if you boot from NOR flash. If you boot from the NAND 4kb of SRAM (steppingstone) not available. For NAND boot it's mapped at 0x0 For NOR boot it's mapped at 0x4000 NAND controller uses it for booting purpose, but anyway for SPL we should fit code into 4k (hardware limitation), so I think using assembly here for SDRAM init is OK. And how will you use the internal SRAM when you boot from NAND, if the SoC writes in the SDRAM read data from NAND, and your data will be overwritten. Why? You'll load SPL into SRAM, then in SPL you'll copy the rest of uboot from NAND to - then already inited - SDRAM and execute it. We even have ready-to-use NAND SPL. Regards Vasily Best regards, Marek Vasut Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Booting a dt zImage kernel
Hi, I am able to successfully boot a zImage kernel with latest 2012.04 U-boot on mx28evk. Now I want to boot a dt zImage version. These are the steps I am doing: make menuconfig and select [*] Support MXS platforms from device tree make imx28-evk.dtb make cat arch/arm/boot/imx28-evk.dtb arch/arm/boot/zImage arch/arm/boot/zImage_dtb cp arch/arm/boot/zImage_dtb /tftpboot/zImage Then I get the following result: U-Boot 2012.04-1-ga1f2367-dirty (Apr 23 2012 - 10:01:52) Freescale i.MX28 family at 454 MHz DRAM: 128 MiB MMC: MXS MMC: 0 In:serial Out: serial Err: serial Net: FEC0, FEC1 Hit any key to stop autoboot: 0 BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 10.29.244.54 Using FEC0 device TFTP from server 10.29.240.143; our IP address is 10.29.244.54 Filename 'zImage'. Load address: 0x4200 Loading: ## Warning: gatewayip needed but not set # # # # # # ## done Bytes transferred = 2250927 (2258af hex) Bad Linux ARM zImage magic! Any idea of why this is failing? Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting a dt zImage kernel
Dear Fabio Estevam, Hi, I am able to successfully boot a zImage kernel with latest 2012.04 U-boot on mx28evk. Oh I'm so dead :-( Now I want to boot a dt zImage version. These are the steps I am doing: make menuconfig and select [*] Support MXS platforms from device tree make imx28-evk.dtb make cat arch/arm/boot/imx28-evk.dtb arch/arm/boot/zImage arch/arm/boot/zImage_dtb cp arch/arm/boot/zImage_dtb /tftpboot/zImage Then I get the following result: U-Boot 2012.04-1-ga1f2367-dirty (Apr 23 2012 - 10:01:52) Freescale i.MX28 family at 454 MHz DRAM: 128 MiB MMC: MXS MMC: 0 In:serial Out: serial Err: serial Net: FEC0, FEC1 Hit any key to stop autoboot: 0 BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 10.29.244.54 Using FEC0 device TFTP from server 10.29.240.143; our IP address is 10.29.244.54 Filename 'zImage'. Load address: 0x4200 Loading: ## Warning: gatewayip needed but not set # # # # # # ## done Bytes transferred = 2250927 (2258af hex) Bad Linux ARM zImage magic! Any idea of why this is failing? Dunno, maybe you need further patch? Thanks, Fabio Estevam Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Add support for MINI2440 (s3c2440). Documentation about the product can be found on: http://www.friendlyarm.net/products/mini2440
2012/4/23 Marek Vasut ma...@denx.de Dear Ilya Averyanov, Dear Marek Vasut, Would you please explain, why do you want to initialize the sdram has been in C code. Ok, no problem: - You'll be able to call get_ram_size() to scan for ram size as any other board - SDRAM driver will fit properly into the driver model once it's in place (WIP, wanna volunteer for review process?) - It's much cleaner If for provide this feature should be written assembly code. And it would sometimes even harder than the initialization code sdram? What do you mean? If we use 4kb of SRAM (steppingstone), then at least need to edit u-boot/arch/arm/cpu/arm920t/start.S, to add a test from there was a boot (NAND or NOR). Edit the address stack. etc ... Use the MMU cache for the stack, even a little better, but it is more difficult. Ah yes, just a remark, please don't top-post. Notice how other people don't do it -- I know gmail does it out-of-the-box, but that doesn't mean it's correct. Ok. 2012/4/21 Marek Vasut ma...@denx.de Dear Ilya Averyanov, 2012/4/21 Vasily Khoruzhick anars...@gmail.com 2012/4/21 Ilya Averyanov averyanovin+ub...@gmail.com: No have problem. Available only if you boot from NOR flash. If you boot from the NAND 4kb of SRAM (steppingstone) not available. For NAND boot it's mapped at 0x0 For NOR boot it's mapped at 0x4000 NAND controller uses it for booting purpose, but anyway for SPL we should fit code into 4k (hardware limitation), so I think using assembly here for SDRAM init is OK. And how will you use the internal SRAM when you boot from NAND, if the SoC writes in the SDRAM read data from NAND, and your data will be overwritten. Why? You'll load SPL into SRAM, then in SPL you'll copy the rest of uboot from NAND to - then already inited - SDRAM and execute it. We even have ready-to-use NAND SPL. Regards Vasily Best regards, Marek Vasut Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting a dt zImage kernel
On 23 April 2012 22:13, Fabio Estevam feste...@gmail.com wrote: Hi, I am able to successfully boot a zImage kernel with latest 2012.04 U-boot on mx28evk. Now I want to boot a dt zImage version. Why do you need to do that at all? Turn on CONFIG_OF_LIBFDT, and you will be able to boot an DT kernel (without dtb append) in the following command. tftpboot 4200 uImage; tftpboot 4280 imx28-evk.dtb; bootm 0x4200 - 0x4280 Regards, Shawn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cm-t35: add I2C multi-bus support
On 04/21/2012 11:09 PM, Igor Grinberg wrote: Hi Tom, On 04/20/12 20:27, Tom Rini wrote: On Mon, Apr 2, 2012 at 5:29 AM, Igor Grinberggrinb...@compulab.co.il wrote: From: Nikita Kiryanovnik...@compulab.co.il Enable I2C multi-bus support and config I2C muxes for I2C2 and I2C3. Signed-off-by: Nikita Kiryanovnik...@compulab.co.il Signed-off-by: Igor Grinberggrinb...@compulab.co.il Applied to u-boot-ti/next (and this missed the PR I just sent, sorry). Hmmm... Will you send another pull request in some time during the merge window, so it will still reach the v2012.07? Absolutely. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Yaffs] yaffs2 u-boot patching support
On 04/22/2012 01:23 PM, Charles Manning wrote: On Friday 20 April 2012 09:40:50 Tom Rini wrote: On Mon, Apr 16, 2012 at 04:32:07PM +1200, Charles Manning wrote: Hello ubooters and yaffsers I was commissioned to refresh yaffs2 in u-boot and add a mechanism to support dynamic yaffs partition set up (way simpler than screwing around with mtd part) and manual configuration. Rather than do this as a once off, I set this scripting up so that this can be done at any time (painlessly I hope) to bring in the fresh code (as per Linux patching). Just to put this out there, if you're not submitting patches to get the code into git, should the current support in-tree be removed? I think it is worth having yaffs in the main code base, but not the old stuff. The primary reason to have a patch-in script is to allow people to refresh the yaffs they are using in a pretty painless way. OK, but why not just update mainline? When you posted the original message, the next branch of master was open. Today master is open. I'm pretty sure that a pull request from the yaffs2 maintainers to update the codebase would be accepted if it's self contained to fs/yaffs2 and reviewed if it touches stuff outside. This isn't the old days... Thanks! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting a dt zImage kernel
On 23/04/2012 16:13, Fabio Estevam wrote: Hi, Hi Fabio, I am able to successfully boot a zImage kernel with latest 2012.04 U-boot on mx28evk. Now I want to boot a dt zImage version. These are the steps I am doing: make menuconfig and select [*] Support MXS platforms from device tree make imx28-evk.dtb make cat arch/arm/boot/imx28-evk.dtb arch/arm/boot/zImage arch/arm/boot/zImage_dtb Is it possible ? Do you not set CONFIG_ARM_APPENDED_DTB in kernel and let kbuild doing the rest of the job ? Is there some reason doing this ? I mean, the easy and tested way is to produce an uImage, and start the kernel from U-Boot with bootm address - dtb in ram. Of course, CONFIG_OF_LIBFDT must be enabled, it is currently not set in mainline for mx28. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Add support for MINI2440 (s3c2440). Documentation about the product can be found on: http://www.friendlyarm.net/products/mini2440
Dear Ilya Averyanov, 2012/4/23 Marek Vasut ma...@denx.de Dear Ilya Averyanov, Dear Marek Vasut, Would you please explain, why do you want to initialize the sdram has been in C code. Ok, no problem: - You'll be able to call get_ram_size() to scan for ram size as any other board - SDRAM driver will fit properly into the driver model once it's in place (WIP, wanna volunteer for review process?) - It's much cleaner If for provide this feature should be written assembly code. And it would sometimes even harder than the initialization code sdram? What do you mean? If we use 4kb of SRAM (steppingstone), then at least need to edit u-boot/arch/arm/cpu/arm920t/start.S, to add a test from there was a boot (NAND or NOR). Edit the address stack. etc ... Use the MMU cache for the stack, even a little better, but it is more difficult. Just check where you have SRAM and adjust SP accordingly, it's easy :-) Ah yes, just a remark, please don't top-post. Notice how other people don't do it -- I know gmail does it out-of-the-box, but that doesn't mean it's correct. Ok. 2012/4/21 Marek Vasut ma...@denx.de Dear Ilya Averyanov, 2012/4/21 Vasily Khoruzhick anars...@gmail.com 2012/4/21 Ilya Averyanov averyanovin+ub...@gmail.com: No have problem. Available only if you boot from NOR flash. If you boot from the NAND 4kb of SRAM (steppingstone) not available. For NAND boot it's mapped at 0x0 For NOR boot it's mapped at 0x4000 NAND controller uses it for booting purpose, but anyway for SPL we should fit code into 4k (hardware limitation), so I think using assembly here for SDRAM init is OK. And how will you use the internal SRAM when you boot from NAND, if the SoC writes in the SDRAM read data from NAND, and your data will be overwritten. Why? You'll load SPL into SRAM, then in SPL you'll copy the rest of uboot from NAND to - then already inited - SDRAM and execute it. We even have ready-to-use NAND SPL. Regards Vasily Best regards, Marek Vasut Best regards, Marek Vasut Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting a dt zImage kernel
On Mon, Apr 23, 2012 at 11:50 AM, Shawn Guo shawn@linaro.org wrote: Why do you need to do that at all? Turn on CONFIG_OF_LIBFDT, and you will be able to boot an DT kernel (without dtb append) in the following command. tftpboot 4200 uImage; tftpboot 4280 imx28-evk.dtb; bootm 0x4200 - 0x4280 Ok, turned CONFIG_OF_LIBFDT and set: bootcmd_net=run netargs; dhcp 0x4200 uImage; dhcp 0x4280 imx28-evk.dtb; bootm 0x4200 - 0x4280 U-Boot 2012.04-2-ge8c5d3d-dirty (Apr 23 2012 - 12:19:15) Freescale i.MX28 family at 454 MHz DRAM: 128 MiB MMC: MXS MMC: 0 In:serial Out: serial Err: serial Net: FEC0, FEC1 Hit any key to stop autoboot: 0 BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 10.29.244.54 Using FEC0 device TFTP from server 10.29.240.143; our IP address is 10.29.244.54 Filename 'uImage'. Load address: 0x4200 Loading: ## Warning: gatewayip needed but not set # # # # # # done Bytes transferred = 2237480 (222428 hex) BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 10.29.244.54 Using FEC0 device TFTP from server 10.29.240.143; our IP address is 10.29.244.54 Filename 'imx28-evk.dtb'. Load address: 0x4280 Loading: ## Warning: gatewayip needed but not set ## done Bytes transferred = 5367 (14f7 hex) ## Booting kernel from Legacy Image at 4200 ... Image Name: Linux-3.4.0-rc3-next-20120419 Created: 2012-04-23 15:02:08 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2237416 Bytes = 2.1 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4280 Booting using the fdt blob at 0x4280 Loading Kernel Image ... OK OK Loading Device Tree to 47b7e000, end 47b824f6 ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. ,no console output after that. Any suggestions? Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Sandbox question
On Monday 23 April 2012 02:41:08 Wolfgang Denk wrote: =md 0x100 0100:Segmentation fault yes, this is because the code to make this work was reverted because of ppc oddity. i haven't reviewed that yet to see why, but it seems to me that the ppc code is not quite right. 2) Sandbox does no handle EOF on stadin; this makes it impossible to use it in test scripts. For example, something like this should work: $ echo printenv | ./u-boot currently as designed -- this is how the hardware works after all. it keeps polling stdin forever and there is no concept of EOF in a serial port. the reads are also non-blocking, so i'm not sure it's possible to tell when you've got EOF vs read too fast. might be able to contingent on stdin being a TTY though. 3) For automatic test suites it would make a lot of sense if the return code of U-Boot was the return code of the last executed command (expecially when termination of U-Boot is the result of encountering EOF on stdin). i'm not sure how hard that is to pass on. Simon might know since he's been grubbing around the shell internals lately. we could have reset take an argument in the sandbox path so it's easy to pass back arbitrary values in the middle of a script. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting a dt zImage kernel
On 04/23/2012 09:29 AM, Fabio Estevam wrote: On Mon, Apr 23, 2012 at 11:50 AM, Shawn Guo shawn@linaro.org wrote: Why do you need to do that at all? Turn on CONFIG_OF_LIBFDT, and you will be able to boot an DT kernel (without dtb append) in the following command. tftpboot 4200 uImage; tftpboot 4280 imx28-evk.dtb; bootm 0x4200 - 0x4280 Ok, turned CONFIG_OF_LIBFDT and set: bootcmd_net=run netargs; dhcp 0x4200 uImage; dhcp 0x4280 imx28-evk.dtb; bootm 0x4200 - 0x4280 ... Starting kernel ... Uncompressing Linux... done, booting the kernel. ,no console output after that. Any suggestions? There could well be many additional reasons, but it's probably due to http://lists.denx.de/pipermail/u-boot/2012-April/122781.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2012.04 released, Merge Window is OPEN
On 04/21/2012 02:51 PM, Wolfgang Denk wrote: Hello all, U-Boot v2012.04 has been released and is available from the git repository and the FTP server. The following didn't get merged: http://lists.denx.de/pipermail/u-boot/2012-April/122781.html which means nobody can pass a device tree to the bootm command on ARM (and I think bootz too). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting a dt zImage kernel
Hi Stephen, On Mon, Apr 23, 2012 at 12:41 PM, Stephen Warren swar...@wwwdotorg.org wrote: There could well be many additional reasons, but it's probably due to http://lists.denx.de/pipermail/u-boot/2012-April/122781.html Yes, that fixes the boot :-) I saw your patch earlier, but I thought it would be included in 2012.04. Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mx28evk: Allow to booting a dt kernel
Allow to booting a dt kernel. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- The following patch is required to get dt booting to work: http://lists.denx.de/pipermail/u-boot/2012-April/122781.html include/configs/mx28evk.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h index 02f3366..cb4ff37 100644 --- a/include/configs/mx28evk.h +++ b/include/configs/mx28evk.h @@ -225,6 +225,7 @@ #define CONFIG_BOOTCOMMAND run bootcmd_net #define CONFIG_LOADADDR0x4200 #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR +#define CONFIG_OF_LIBFDT /* * Extra Environments -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] m28evk: Allow to booting a dt kernel
Allow to booting a dt kernel. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/m28evk.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h index 012381a..39d6a07 100644 --- a/include/configs/m28evk.h +++ b/include/configs/m28evk.h @@ -279,6 +279,7 @@ #defineCONFIG_BOOTCOMMAND run bootcmd_net #defineCONFIG_LOADADDR 0x4200 #defineCONFIG_SYS_LOAD_ADDRCONFIG_LOADADDR +#defineCONFIG_OF_LIBFDT /* * Extra Environments -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Tegra2: Add a useful default boot env
Stephen, On Fri, Apr 20, 2012 at 2:40 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 04/20/2012 01:50 PM, Tom Warren wrote: This set of boot cmds from Stephen Warren provides a simple default for booting a linux kernel and DT from mmc (eMMC or SD-Card, in that order). Tested on Seaboard w/an SD card. ... diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h ... #define CONFIG_EXTRA_ENV_SETTINGS \ ... + script=/boot.scr.uimg\0 \ It might be best to make that just /boot.scr. The reason being that I looked at the Ubuntu Precise images for OMAP, and they don't have .uimg in the filename, even though they're uImage files. It's probably best to be consistent with the Ubuntu images given the only other precedent is what I do locally, which can easily be adjusted. I'll change it to /boot.scr, but do we have any stats on other/more distros and what they use? As to using fat instead of ext2, this is just an example, and would be (should be) customized for each vendor/distro. I could also add a USB boot example. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] mx28evk: Allow booting a zImage kernel
Allow booting a zImage kernel. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx28evk.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h index cb4ff37..31dc718 100644 --- a/include/configs/mx28evk.h +++ b/include/configs/mx28evk.h @@ -67,6 +67,7 @@ #define CONFIG_CMD_SF #define CONFIG_CMD_SPI #define CONFIG_CMD_USB +#define CONFIG_CMD_BOOTZ /* * Memory configurations -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] mx6qsabrelite: Allow booting a zImage kernel
Allow booting a zImage kernel. Cc: Jason Liu r64...@freescale.com Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx6qsabrelite.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h index 3f7e51d..492c618 100644 --- a/include/configs/mx6qsabrelite.h +++ b/include/configs/mx6qsabrelite.h @@ -211,6 +211,7 @@ #endif #define CONFIG_OF_LIBFDT +#define CONFIG_CMD_BOOTZ #define CONFIG_SYS_DCACHE_OFF -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] mx6qarm2: Allow booting a zImage kernel
Allow booting a zImage kernel. Cc: Jason Liu r64...@freescale.com Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx6qarm2.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/mx6qarm2.h b/include/configs/mx6qarm2.h index e83aec6..90652c6 100644 --- a/include/configs/mx6qarm2.h +++ b/include/configs/mx6qarm2.h @@ -168,6 +168,7 @@ #define CONFIG_SYS_MMC_ENV_DEV 1 #define CONFIG_OF_LIBFDT +#define CONFIG_CMD_BOOTZ #define CONFIG_SYS_DCACHE_OFF -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] mx31pdk: Allow booting a zImage kernel
Allow booting a zImage kernel. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx31pdk.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/mx31pdk.h b/include/configs/mx31pdk.h index 49d440b..6ce97bc 100644 --- a/include/configs/mx31pdk.h +++ b/include/configs/mx31pdk.h @@ -99,6 +99,7 @@ #define CONFIG_CMD_SPI #define CONFIG_CMD_DATE #define CONFIG_CMD_NAND +#define CONFIG_CMD_BOOTZ /* * Disabled due to compilation errors in cmd_bootm.c (IMLS seems to require -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Tegra2: Add a useful default boot env
On 04/23/2012 10:22 AM, Tom Warren wrote: Stephen, On Fri, Apr 20, 2012 at 2:40 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 04/20/2012 01:50 PM, Tom Warren wrote: This set of boot cmds from Stephen Warren provides a simple default for booting a linux kernel and DT from mmc (eMMC or SD-Card, in that order). Tested on Seaboard w/an SD card. ... diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h ... #define CONFIG_EXTRA_ENV_SETTINGS \ ... + script=/boot.scr.uimg\0 \ It might be best to make that just /boot.scr. The reason being that I looked at the Ubuntu Precise images for OMAP, and they don't have .uimg in the filename, even though they're uImage files. It's probably best to be consistent with the Ubuntu images given the only other precedent is what I do locally, which can easily be adjusted. I'll change it to /boot.scr, but do we have any stats on other/more distros and what they use? I don't believe any other distros are creating packages/images for Tegra yet. As to using fat instead of ext2, this is just an example, and would be (should be) customized for each vendor/distro. I could also add a USB boot example. Really, we should be defining the boot architecture for Tegra, and distros following suite. So, I think we should just say: * Partition 1 of the media is /boot. * Partition 1 should be ext2 or compatible. * boot.scr should exist there and be a uImage script file. Distros certainly can't customize the U-Boot environment for themselves, since there's no generally applicable way of doing so. That's exactly why I pushed to load a boot.scr rather than having U-Boot load the kernel directly (and define the command-line), to give distros the ability to customize boot.scr; generating files in a filesystem is much easier for distros. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] arm: Tegra2: Add a useful default boot env
This set of boot cmds from Stephen Warren provides a simple
default for booting a linux kernel and DT from mmc (eMMC or
SD-Card, in that order). Tested on Seaboard w/an SD card.
Signed-off-by: Tom Warren twar...@nvidia.com
---
V2: Use /boot.scr instead of boot.scr.uimg
include/configs/tegra2-common.h | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h
index 068ce88..a7f06d2 100644
--- a/include/configs/tegra2-common.h
+++ b/include/configs/tegra2-common.h
@@ -140,9 +140,15 @@
stderr=serial\0
#define CONFIG_EXTRA_ENV_SETTINGS \
- console=ttyS0,115200n8\0 \
- mem= TEGRA2_SYSMEM \0 \
- smpflag=smp\0 \
+ bootdelay=2\0 \
+ bootcmd=run mmc1_boot ; run mmc0_boot\0 \
+ mmc0_boot=setenv devnum 0; run mmc_boot;\0 \
+ mmc1_boot=setenv devnum 1; run mmc_boot;\0 \
+ mmc_boot=setenv devtype mmc;mmc dev ${devnum};run scr_boot;\0 \
+ scriptaddr=0x40\0 \
+ script=/boot.scr\0 \
+ scr_boot=ext2load ${devtype} ${devnum}:1 ${scriptaddr} ${script}; \
+ source ${scriptaddr};\0 \
TEGRA2_DEVICE_SETTINGS
#define CONFIG_LOADADDR0x408000/* def. location for
kernel */
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Tegra2: Add a useful default boot env
On Mon, Apr 23, 2012 at 09:22:22AM -0700, Tom Warren wrote: Stephen, On Fri, Apr 20, 2012 at 2:40 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 04/20/2012 01:50 PM, Tom Warren wrote: This set of boot cmds from Stephen Warren provides a simple default for booting a linux kernel and DT from mmc (eMMC or SD-Card, in that order). Tested on Seaboard w/an SD card. ... diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h ... ?#define CONFIG_EXTRA_ENV_SETTINGS \ ... + ? ? script=/boot.scr.uimg\0 \ It might be best to make that just /boot.scr. The reason being that I looked at the Ubuntu Precise images for OMAP, and they don't have .uimg in the filename, even though they're uImage files. It's probably best to be consistent with the Ubuntu images given the only other precedent is what I do locally, which can easily be adjusted. I'll change it to /boot.scr, but do we have any stats on other/more distros and what they use? Can I suggest that instead of using boot.scr files we just use a text file that can be imported to the environment and a command run? The omap3_beagle example (uEnv.txt + uenvcmd) is something I plan to propogate to more TI boards and I think it'd be good if we picked it up on other SoCs. Or came up with a better plan for everyone :) The main benefit of uEnv.txt over boot.scr is that it's now plain text, rather than text that needs to be mkimage'd at each change. -- 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] arm: Tegra2: Add a useful default boot env
On Mon, Apr 23, 2012 at 10:36:37AM -0600, Stephen Warren wrote: On 04/23/2012 10:22 AM, Tom Warren wrote: [snip] Distros certainly can't customize the U-Boot environment for themselves, since there's no generally applicable way of doing so. That's exactly That is (very recently) no longer true! We've had for a while now the ability to append to the environment from a file and much more recently the ability for the whole environment to be a plain text file read from FAT (and written back to). And to repeat what I just now said in another email, I'd really like it if we can come up with something that's common across multiple SoCs. -- 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] Please pull u-boot-ti/master
Hello, The following changes since commit 5697158fd27c9cc938eb3e3308e3c1483a2a1ef8: Tom Rini (1): include/configs: Remove CONFIG_SYS_64BIT_STRTOUL are available in the git repository at: git://git.denx.de/u-boot-ti master Nikita Kiryanov (1): cm-t35: add I2C multi-bus support Nobuhiro Iwamatsu (2): arm: cam_enc_4xx: Change macro from BOARD_LATE_INIT to CONFIG_BOARD_LATE_INIT arm: ea20: Change macro from BOARD_LATE_INIT to CONFIG_BOARD_LATE_INIT board/cm_t35/cm_t35.c |6 ++ board/davinci/ea20/ea20.c |4 ++-- include/configs/cam_enc_4xx.h |2 +- include/configs/cm_t35.h |1 + include/configs/ea20.h|2 +- 5 files changed, 11 insertions(+), 4 deletions(-) -- 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] Add support s3c2440 NAND controller
Dear Ilya Averyanov,
please always Cc the mainline list. Also, I'm now s3c2440 person, I have no
relationship with this chip at all ...
arch/arm/include/asm/arch-s3c24x0/s3c2410.h |4 +-
arch/arm/include/asm/arch-s3c24x0/s3c2440.h |4 +-
arch/arm/include/asm/arch-s3c24x0/s3c24x0.h | 13 +-
drivers/mtd/nand/Makefile |3 +-
drivers/mtd/nand/s3c2410_nand.c | 189 ---
drivers/mtd/nand/s3c24x0_nand.c | 268
+++
6 files changed, 283 insertions(+), 198 deletions(-)
delete mode 100644 drivers/mtd/nand/s3c2410_nand.c
create mode 100644 drivers/mtd/nand/s3c24x0_nand.c
diff --git a/arch/arm/include/asm/arch-s3c24x0/s3c2410.h
b/arch/arm/include/asm/arch-s3c24x0/s3c2410.h
index 4fbdf20..71eb33e 100644
--- a/arch/arm/include/asm/arch-s3c24x0/s3c2410.h
+++ b/arch/arm/include/asm/arch-s3c24x0/s3c2410.h
@@ -99,9 +99,9 @@ static inline struct s3c24x0_lcd
*s3c24x0_get_base_lcd(void)
return (struct s3c24x0_lcd *)S3C24X0_LCD_BASE;
}
-static inline struct s3c2410_nand *s3c2410_get_base_nand(void)
+static inline struct s3c24x0_nand *s3c24x0_get_base_nand(void)
{
-return (struct s3c2410_nand *)S3C2410_NAND_BASE;
+return (struct s3c24x0_nand *)S3C2410_NAND_BASE;
}
static inline struct s3c24x0_uart
diff --git a/arch/arm/include/asm/arch-s3c24x0/s3c2440.h
b/arch/arm/include/asm/arch-s3c24x0/s3c2440.h
index 8c606e3..8b9a5b0 100644
--- a/arch/arm/include/asm/arch-s3c24x0/s3c2440.h
+++ b/arch/arm/include/asm/arch-s3c24x0/s3c2440.h
@@ -97,9 +97,9 @@ static inline struct s3c24x0_lcd
*s3c24x0_get_base_lcd(void)
return (struct s3c24x0_lcd *)S3C24X0_LCD_BASE;
}
-static inline struct s3c2440_nand *s3c2440_get_base_nand(void)
+static inline struct s3c24x0_nand *s3c24x0_get_base_nand(void)
get_nand_base might be better? And what if this returned the value by checking
what CPU this runs on at runtime?
{
-return (struct s3c2440_nand *)S3C2440_NAND_BASE;
+return (struct s3c24x0_nand *)S3C2440_NAND_BASE;
}
static inline struct s3c24x0_uart
diff --git a/arch/arm/include/asm/arch-s3c24x0/s3c24x0.h
b/arch/arm/include/asm/arch-s3c24x0/s3c24x0.h
index ca978c9..d82251d 100644
--- a/arch/arm/include/asm/arch-s3c24x0/s3c24x0.h
+++ b/arch/arm/include/asm/arch-s3c24x0/s3c24x0.h
@@ -151,20 +151,19 @@ struct s3c24x0_lcd {
};
+
+struct s3c24x0_nand {
#ifdef CONFIG_S3C2410
Please don't put ifdefs into the structure ... also, this is weird, don't
create
structure like that. What is the difference between the chips so the structure
can't be shared in one form?
/* NAND FLASH (see S3C2410 manual chapter 6) */
-struct s3c2410_nand {
u32nfconf;
u32nfcmd;
u32nfaddr;
u32nfdata;
u32nfstat;
u32nfecc;
-};
#endif
#ifdef CONFIG_S3C2440
/* NAND FLASH (see S3C2440 manual chapter 6) */
-struct s3c2440_nand {
u32nfconf;
u32nfcont;
u32nfcmd;
@@ -176,8 +175,14 @@ struct s3c2440_nand {
u32nfstat;
u32nfstat0;
u32nfstat1;
-};
+u32 nfmecc0;
+ u32 nfmecc1;
+ u32 nfsecc;
+u32 nfsblk;
+u32 nfeblk;
#endif
+};
+
/* UART (see manual chapter 11) */
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 1d1b628..b080cf7 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -58,7 +58,8 @@ COBJS-$(CONFIG_NAND_MXC) += mxc_nand.o
COBJS-$(CONFIG_NAND_MXS) += mxs_nand.o
COBJS-$(CONFIG_NAND_NDFC) += ndfc.o
COBJS-$(CONFIG_NAND_NOMADIK) += nomadik.o
-COBJS-$(CONFIG_NAND_S3C2410) += s3c2410_nand.o
+COBJS-$(CONFIG_NAND_S3C2410) += s3c24x0_nand.o
+COBJS-$(CONFIG_NAND_S3C2440) += s3c24x0_nand.o
COBJS-$(CONFIG_NAND_S3C64XX) += s3c64xx.o
COBJS-$(CONFIG_NAND_SPEAR) += spr_nand.o
COBJS-$(CONFIG_NAND_OMAP_GPMC) += omap_gpmc.o
diff --git a/drivers/mtd/nand/s3c2410_nand.c
b/drivers/mtd/nand/s3c2410_nand.c
deleted file mode 100644
index e1a459b..000
--- a/drivers/mtd/nand/s3c2410_nand.c
+++ /dev/null
@@ -1,189 +0,0 @@
-/*
- * (C) Copyright 2006 OpenMoko, Inc.
- * Author: Harald Welte lafo...@openmoko.org
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-#include common.h
Re: [U-Boot] Sandbox question
Am 23.04.2012 17:41, schrieb Mike Frysinger: On Monday 23 April 2012 02:41:08 Wolfgang Denk wrote: =md 0x100 0100:Segmentation fault yes, this is because the code to make this work was reverted because of ppc oddity. i haven't reviewed that yet to see why, but it seems to me that the ppc code is not quite right. I suggested another solution: http://patchwork.ozlabs.org/patch/123074/ This has the disadvantage, as discussed in the thread, that the address passed to mmap is not guaranteed to be returned. This could be caught by an assert. The base address in the patch (0x2000) was choosen with respect to the typical process address layout on x86 and x86_64 linux to avoid any conflict. Even when ASLR causes this the u-boot binary could still be started using setarch with ASLR disabled. -- Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Tegra2: Add a useful default boot env
On 04/23/2012 11:14 AM, Tom Rini wrote: On Mon, Apr 23, 2012 at 09:22:22AM -0700, Tom Warren wrote: Stephen, On Fri, Apr 20, 2012 at 2:40 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 04/20/2012 01:50 PM, Tom Warren wrote: This set of boot cmds from Stephen Warren provides a simple default for booting a linux kernel and DT from mmc (eMMC or SD-Card, in that order). Tested on Seaboard w/an SD card. ... diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h ... ?#define CONFIG_EXTRA_ENV_SETTINGS \ ... + ? ? script=/boot.scr.uimg\0 \ It might be best to make that just /boot.scr. The reason being that I looked at the Ubuntu Precise images for OMAP, and they don't have .uimg in the filename, even though they're uImage files. It's probably best to be consistent with the Ubuntu images given the only other precedent is what I do locally, which can easily be adjusted. I'll change it to /boot.scr, but do we have any stats on other/more distros and what they use? Can I suggest that instead of using boot.scr files we just use a text file that can be imported to the environment and a command run? That sounds like a great idea; it avoids a mkimage call and generally simplifies things. Looking at the code, it's just a list of name=value, one per line. TomW, I'd suggest looking at ./include/configs/omap3_beagle.h. In particular: a) The load from MMC is only attempted if mmc rescan succeeds, rather than just blasting through the script with lots of failures. The hush shell might be needed for this; is it enabled on Tegra? b) See the macros loadbootenv/importbootenv which are the replacement for boot.scr. TomR, is there a reason OMAP3 uses FAT for /boot rather than ext2? Perhaps it's due to the need to load intermediate boot loaders from the filesystem, and that code needs FAT? On Tegra, we jump straight to U-Boot from the boot ROM without the need for intermediate filesystem access, and could make /boot ext2 - do you see any reason not to do this? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Sandbox question
Dear Matthias Weisser, In message 4f959235.1070...@arcor.de you wrote: On Monday 23 April 2012 02:41:08 Wolfgang Denk wrote: =md 0x100 0100:Segmentation fault yes, this is because the code to make this work was reverted because of ppc oddity. i haven't reviewed that yet to see why, but it seems to me that the ppc code is not quite right. The PPC code just accesses physical memory, as is. I suggested another solution: http://patchwork.ozlabs.org/patch/123074/ This has the disadvantage, as discussed in the thread, that the address passed to mmap is not guaranteed to be returned. I don't see why this would be needed. I think you got things backwards. Please note that I do NOT complain that md 0x100 or md 0 segfaults in general; it is IMO perfectoy OK to do this if there is no memory. But the bdinfo command reported that memory starts at 0, and then both these commands are supposed to work. I am not asking for any specific mapping - I just ask for _consistent_ information provided to the user. 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 ignorance is bliss, why aren't there more happy people? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spi: mxs: Allow other chip selects to work
On Monday 23 April 2012 08:43:12 Fabio Estevam wrote:
--- a/drivers/spi/mxs_spi.c
+++ b/drivers/spi/mxs_spi.c
@@ -56,12 +58,19 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
if (bus 3) {
printf(MXS SPI: Max bus number is 3\n);
return NULL;
}
+ if (cs 2) {
+ printf(MXS SPI: Invalid chip select number: %d\n, cs);
+ return NULL;
+ }
this stuff really belongs in spi_cs_is_valid(), sans the printf's.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Tegra2: Add a useful default boot env
On Mon, Apr 23, 2012 at 11:39:30AM -0600, Stephen Warren wrote: [snip] TomR, is there a reason OMAP3 uses FAT for /boot rather than ext2? Perhaps it's due to the need to load intermediate boot loaders from the filesystem, and that code needs FAT? On Tegra, we jump straight to U-Boot from the boot ROM without the need for intermediate filesystem access, and could make /boot ext2 - do you see any reason not to do this? Correct. Our ROMs will read FAT looking for 'MLO' (which is u-boot-spl these days) and that loads U-Boot. It can also raw read the card. The other reason for having the first partition be FAT by default is ease of replacement since everything can read/write FAT but ext2/3/4 is limited (largely/easily...) to Linux. Distro do change this behavior and Angstrom for example changes to ext2load (or ext4load) from /boot. And I don't think omap3_beagle is perfect just yet. I really want to switch to the whole env being a file on the SD card, but I can't easily do that until we can tell at run time if we're on beagleboard classic or xM (which we can now) and then change where the environment is (we can't do that yet, but perhaps soon). -- 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] Sandbox question
Am 23.04.2012 19:39, schrieb Wolfgang Denk: I suggested another solution: http://patchwork.ozlabs.org/patch/123074/ This has the disadvantage, as discussed in the thread, that the address passed to mmap is not guaranteed to be returned. I don't see why this would be needed. Because you will have the same address for physical memory in all instances of sandbox u-boot. This could simplify test scripts a bit. Imagine testing tftp downloads to memory where DRAM bank- start is different for every program run. This was a PITA for me while testing the tap ethernet simulation for sandbox. And that is why I came up with the patch. Or is there something like $(ramstart) in u-boot? -- Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Sandbox question
Hi Wolfgang, On Tue, Apr 24, 2012 at 3:41 AM, Mike Frysinger vap...@gentoo.org wrote: On Monday 23 April 2012 02:41:08 Wolfgang Denk wrote: =md 0x100 0100:Segmentation fault yes, this is because the code to make this work was reverted because of ppc oddity. i haven't reviewed that yet to see why, but it seems to me that the ppc code is not quite right. The commit which made this work was this one: 355a835 sandbox: Change md command to use map_physmem and was reverted by: 94c50f1 Revert sandbox: Change md command to use map_physmem The commit message from the revert is The original commit broke long standing assumption that md commands work on effective addresses. This normally isn't an issue for most systems that map 1:1, however on systems with a 36-bit address map it breaks. I did try to start a discussion on the list about how to deal with this. One idea was to add a translation function in the md command (and potentially then in other code) that converts an effective address as seen by U-Boot into one that can be used by the architecture. The down side is that all architectures except sandbox would have this as a no-op. I am pretty keen for sandbox memory to start at 0 if possible, since it makes test code easier to write if we can make that assumption. Also I don't like the idea of different people writing test code with different assumptions about the memory map, such that we can't run all the tests with the same sandbox config. 2) Sandbox does no handle EOF on stadin; this makes it impossible to use it in test scripts. For example, something like this should work: $ echo printenv | ./u-boot currently as designed -- this is how the hardware works after all. it keeps polling stdin forever and there is no concept of EOF in a serial port. the reads are also non-blocking, so i'm not sure it's possible to tell when you've got EOF vs read too fast. might be able to contingent on stdin being a TTY though. Yes I think this captures the current situation. We could perhaps add some sort of hack to make this work, perhaps with a new CONFIG option which accepts EOF on input and somehow passes it up the stack, or keeps the info in sandbox's state. Another option would be to create a special sandbox input device. In any case, it would be nice to implement EOF in the console layer for this. Could be related to serial cleanup also. 3) For automatic test suites it would make a lot of sense if the return code of U-Boot was the return code of the last executed command (expecially when termination of U-Boot is the result of encountering EOF on stdin). i'm not sure how hard that is to pass on. Simon might know since he's been grubbing around the shell internals lately. we could have reset take an argument in the sandbox path so it's easy to pass back arbitrary values in the middle of a script. I'm pretty sure I had this working, at least for one shell. It was part of the motivation for the command cleanup. It would be worth sorting out these three things. Once we have a bit of agreement on which way to go, I'm happy to come up with some patches for any that don't have volunteers. -mike Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Sandbox cannot be built without HUSH
Hi Wolfgang, On Mon, Apr 23, 2012 at 8:28 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon, disabling HUSH support in sandbox results in this: start.c: In function ‘sandbox_main_loop_init’: start.c:97:3: warning: implicit declaration of function ‘parse_string_outer’ [-Wimplicit-function-declaration] start.c:97:34: error: ‘FLAG_PARSE_SEMICOLON’ undeclared (first use in this function) start.c:97:34: note: each undeclared identifier is reported only once for each function it appears in start.c:98:9: error: ‘FLAG_EXIT_FROM_LOOP’ undeclared (first use in this function) make[1]: *** [start.o] Error 1 make: *** [arch/sandbox/cpu/start.o] Error 2 make: *** Waiting for unfinished jobs start.c: In function ‘sandbox_main_loop_init’: start.c:97:3: warning: implicit declaration of function ‘parse_string_outer’ [-Wimplicit-function-declaration] start.c:97:34: error: ‘FLAG_PARSE_SEMICOLON’ undeclared (first use in this function) start.c:97:34: note: each undeclared identifier is reported only once for each function it appears in start.c:98:9: error: ‘FLAG_EXIT_FROM_LOOP’ undeclared (first use in this function) Yes, that was fixed by one of the patches in the run_command_list series. This one: http://patchwork.ozlabs.org/patch/149810/ Regards, Simon 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 Everyone who comes in here wants three things: 1. They want it quick. 2. They want it good. 3. They want it cheap. I tell 'em to pick two and call me back. - sign on the back wall of a small printing company in Delaware ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Sandbox question
Dear Matthias, In message 4f959612.7040...@arcor.de you wrote: Because you will have the same address for physical memory in all instances of sandbox u-boot. This could simplify test scripts a bit. Imagine testing tftp downloads to memory where DRAM bank- start is different for every program run. This was a PITA for me while testing the tap ethernet simulation for sandbox. And that is why I came up with the patch. Agreed - though I would expect the mapping at least to be consistent through all runs of the same binary image. Or is there something like $(ramstart) in u-boot? Not yet - but it would be trivial to add. 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 Everyting looks interesting until you do it. Then you find it's just another job. - Terry Pratchett, _Moving Pictures_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] spi: mxs: Allow other chip selects to work
MXS SSP controller may have up to three chip selects per port: SS0, SS1 and SS2.
Currently only SS0 is supported in the mxs_spi driver.
Allow all the three chip select to work by selecting the desired one
in bits 20 and 21 of the HW_SSP_CTRL0 register.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v1:
- Check vor valid cs inside spi_cs_is_valid() (patch 1/2)
drivers/spi/mxs_spi.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/mxs_spi.c b/drivers/spi/mxs_spi.c
index e7237e7..7859536 100644
--- a/drivers/spi/mxs_spi.c
+++ b/drivers/spi/mxs_spi.c
@@ -34,6 +34,8 @@
#defineMXS_SPI_MAX_TIMEOUT 100
#defineMXS_SPI_PORT_OFFSET 0x2000
+#define MXS_SSP_CHIPSELECT_MASK0x0030
+#define MXS_SSP_CHIPSELECT_SHIFT 20
struct mxs_spi_slave {
struct spi_slaveslave;
@@ -65,6 +67,8 @@ struct spi_slave *spi_setup_slave(unsigned int bus, unsigned
int cs,
{
struct mxs_spi_slave *mxs_slave;
uint32_t addr;
+ struct mx28_ssp_regs *ssp_regs;
+ int reg;
if (!spi_cs_is_valid(bus, cs)) {
printf(mxs_spi: invalid bus %d / chip select %d\n, bus, cs);
@@ -82,7 +86,13 @@ struct spi_slave *spi_setup_slave(unsigned int bus, unsigned
int cs,
mxs_slave-max_khz = max_hz / 1000;
mxs_slave-mode = mode;
mxs_slave-regs = (struct mx28_ssp_regs *)addr;
+ ssp_regs = mxs_slave-regs;
+ reg = readl(ssp_regs-hw_ssp_ctrl0);
+ reg = ~(MXS_SSP_CHIPSELECT_MASK);
+ reg |= cs MXS_SSP_CHIPSELECT_SHIFT;
+
+ writel(reg, ssp_regs-hw_ssp_ctrl0);
return mxs_slave-slave;
}
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] spi: mxs: Introduce spi_cs_is_valid()
Introduce spi_cs_is_valid() for validating spi bus and chip select numbers.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v1:
- Newly introduced in v2
drivers/spi/mxs_spi.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/mxs_spi.c b/drivers/spi/mxs_spi.c
index 4e6f14e..e7237e7 100644
--- a/drivers/spi/mxs_spi.c
+++ b/drivers/spi/mxs_spi.c
@@ -51,14 +51,23 @@ void spi_init(void)
{
}
+int spi_cs_is_valid(unsigned int bus, unsigned int cs)
+{
+ /* MXS SPI: 4 ports and 3 chip selects maximum */
+ if (bus 3 || cs 2)
+ return 0;
+ else
+ return 1;
+}
+
struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
unsigned int max_hz, unsigned int mode)
{
struct mxs_spi_slave *mxs_slave;
uint32_t addr;
- if (bus 3) {
- printf(MXS SPI: Max bus number is 3\n);
+ if (!spi_cs_is_valid(bus, cs)) {
+ printf(mxs_spi: invalid bus %d / chip select %d\n, bus, cs);
return NULL;
}
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Sandbox question
Dear Simon, In message capnjgz1av723lzf1vnmoarix6dnxfho-962y8wqij5-g462...@mail.gmail.com you wrote: I did try to start a discussion on the list about how to deal with this. One idea was to add a translation function in the md command (and potentially then in other code) that converts an effective address as seen by U-Boot into one that can be used by the architecture. The down side is that all architectures except sandbox would have this as a no-op. I don't see why such a function would be needed. Other architectures don't need it either. Yes, some architectures use a common, fixed mapping (like PPC, where physical RAM almost always starts at address 0x0) - but others don't have such a common map- for example on ARM, there is a wild mix where RAM starts, and basicly every SoC defines his own mapping. I am pretty keen for sandbox memory to start at 0 if possible, since it makes test code easier to write if we can make that assumption. On ARM you don't have this either. Also I don't like the idea of different people writing test code with different assumptions about the memory map, such that we can't run all the tests with the same sandbox config. Eventually introducing two variables like ramstart and ramend would solve 90% of the potential issues. In any case, information returned by commands like bdinfo must be correct. currently as designed -- this is how the hardware works after all. it keeps polling stdin forever and there is no concept of EOF in a serial port. the reads are also non-blocking, so i'm not sure it's possible to tell when you've got EOF vs read too fast. might be able to contingent on stdin being a TTY though. Yes I think this captures the current situation. We could perhaps add some sort of hack to make this work, perhaps with a new CONFIG option I don't see why we cannot simply read from stdin (or rathr from file descriptor 0) as usual? You can use standard methods like select() or poll() to wait for input, which will also inform you about events like EOF. which accepts EOF on input and somehow passes it up the stack, or keeps the info in sandbox's state. Another option would be to create a special sandbox input device. In any case, it would be nice to implement EOF in the console layer for this. Could be related to serial cleanup also. Good point. Marek, can you please add this to the DM planning? It would be worth sorting out these three things. Once we have a bit of agreement on which way to go, I'm happy to come up with some patches for any that don't have volunteers. Thanks! 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 Of course there's no reason for it, it's just our policy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2012.04 released, Merge Window is OPEN
On 23.04.2012 17:45, Stephen Warren wrote: On 04/21/2012 02:51 PM, Wolfgang Denk wrote: Hello all, U-Boot v2012.04 has been released and is available from the git repository and the FTP server. The following didn't get merged: http://lists.denx.de/pipermail/u-boot/2012-April/122781.html which means nobody can pass a device tree to the bootm command on ARM (and I think bootz too). Today, I saw a an issue which looks identical to http://lists.denx.de/pipermail/u-boot/2012-April/122974.html I will test this tomorrow. Sounds like an additional reason for a v12.04.1, then. Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Sandbox question
On Monday 23 April 2012 14:39:59 Wolfgang Denk wrote: Simon wrote: I did try to start a discussion on the list about how to deal with this. One idea was to add a translation function in the md command (and potentially then in other code) that converts an effective address as seen by U-Boot into one that can be used by the architecture. The down side is that all architectures except sandbox would have this as a no-op. I don't see why such a function would be needed. Other architectures don't need it either. Yes, some architectures use a common, fixed mapping (like PPC, where physical RAM almost always starts at address 0x0) - but others don't have such a common map- for example on ARM, there is a wild mix where RAM starts, and basicly every SoC defines his own mapping. because, as you said, you want things to be deterministic. when the sandbox starts up, it does mmap() and there's no guarantee that the address you get back is always going to be the same. you cannot compare this to an SoC where the memory layout is always exactly the same for u-boot across runs. thus we need the map call to adjust what the user sees (memory always starts at 0) vs what sandbox got back from the kernel (almost literally, any address). Also I don't like the idea of different people writing test code with different assumptions about the memory map, such that we can't run all the tests with the same sandbox config. Eventually introducing two variables like ramstart and ramend would solve 90% of the potential issues. In any case, information returned by commands like bdinfo must be correct. it was correct. and then the change that made it correct was reverted. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Sandbox question
On Monday 23 April 2012 14:39:59 Wolfgang Denk wrote: Simon wrote: currently as designed -- this is how the hardware works after all. it keeps polling stdin forever and there is no concept of EOF in a serial port. the reads are also non-blocking, so i'm not sure it's possible to tell when you've got EOF vs read too fast. might be able to contingent on stdin being a TTY though. Yes I think this captures the current situation. We could perhaps add some sort of hack to make this work, perhaps with a new CONFIG option I don't see why we cannot simply read from stdin (or rathr from file descriptor 0) as usual? the usual method of reading from stdin involves the tty doing buffering and the application only seeing fully flushed lines. thus it would not operate the same as the hardware (where u-boot gets every char as you type) and you wouldn't be able to handle things like tab completion. You can use standard methods like select() or poll() to wait for input, which will also inform you about events like EOF. because that isn't how u-boot on the hardware works. u-boot itself calls tstc() to see if there's any data and does so in a continuous loop. when there is data, it calls getc(). tstc() should not block, and getc() isn't call unless u-boot knows there's data. it is also problematic (currently) to get access to errno from the C library because u-boot itself has a variable called errno. so we cannot call the C library's read() and check errno to see why it failed. would be possible to solve by having u-boot internally rename the storage from errno to something else, and then having u-boot's errno.h header define errno to the rename value. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 'run' no longer aborts on an error, can someone please verify
Hi Wolfgang, On Mon, Apr 23, 2012 at 11:16 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon, In message capnjgz2vkx3tp6wmswixeys1q3xm+6wjoiyxwc23jpfim_0...@mail.gmail.com you wrote: Thanks for the detailed information. This might be the problem Wolfgang mentioned at the time...will take a look tomorrow. Could you please try and look into this ASAP? I consider this a serious bug, and would like to fix it in mainline as soon as possible. I think I will then even issue a v12.04.1 bugfix release. Sorry for the delay - I am travelling this week. Yes I am looking at it now. It would be nice to add a test. Regards, Simon 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 Virtual means never knowing where your next byte is coming from. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Sandbox question
Dear Mike Frysinger, In message 201204231503.08835.vap...@gentoo.org you wrote: I don't see why we cannot simply read from stdin (or rathr from file descriptor 0) as usual? the usual method of reading from stdin involves the tty doing buffering and the application only seeing fully flushed lines. thus it would not operate the That's why I wrote or rather from fd 0. same as the hardware (where u-boot gets every char as you type) and you wouldn't be able to handle things like tab completion. C'me on. That's a standard issue. We know how to handle this, right? You can use standard methods like select() or poll() to wait for input, which will also inform you about events like EOF. because that isn't how u-boot on the hardware works. u-boot itself calls tstc() to see if there's any data and does so in a continuous loop. when there is data, it calls getc(). tstc() should not block, and getc() isn't call unless u-boot knows there's data. That's why I suggested to use select() or poll() to poll for available characters, just like the hardware does. Only we do NOT want to tun this in a tight loop. We will most likely want to add a sufficiently large delay to keep CPU load in reasonable bounds. it is also problematic (currently) to get access to errno from the C library because u-boot itself has a variable called errno. so we cannot call the C Why invent new methods when we can encapsulate this in the input interface? We do not even have to pass EOF on to higher layers in U-Boot - we could exit directly in the tty interface code. 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 As usual, this being a 1.3.x release, I haven't even compiled this kernel yet. So if it works, you should be doubly impressed. - Linus Torvalds in 199506181536.saa10...@keos.cs.helsinki.fi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix the behaviour of the 'run' command
Hi Timo, On Mon, Apr 23, 2012 at 9:57 PM, Timo Ketola t...@exertus.fi wrote: If one command fails, 'run' command should terminate and not execute any remaining variables. Signed-off-by: Timo Ketola t...@exertus.fi Tested on sandbox after a bit of investigation. Tested-by: Simon Glass s...@chromium.org Acked-by: Simon Glass s...@chromium.org This is a clear bug, since cmd_process() returns 1 on failure, but we need builtin_run_command() to return -1. I suspect this might be the problem that Wolfgang found some months ago, although perhaps in a more subtle form. We really need some tests for this sort of thing - I did create a few for the new run_command_list(), but will make time to add some tests for standard run_command() also. Thanks for finding and fixing this. Regards, Simon --- This is based on u-boot-imx.git next. I hope that doesn't cause too much trouble. common/main.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/common/main.c b/common/main.c index db181d3..3b9e39a 100644 --- a/common/main.c +++ b/common/main.c @@ -1338,7 +1338,8 @@ static int builtin_run_command(const char *cmd, int flag) continue; } - rc = cmd_process(flag, argc, argv, repeatable); + if (cmd_process(flag, argc, argv, repeatable)) + rc = -1; /* Did the user stop this? */ if (had_ctrlc ()) -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix the behaviour of the 'run' command
Dear Timo Ketola, In message 1335175047-30984-1-git-send-email-t...@exertus.fi you wrote: If one command fails, 'run' command should terminate and not execute any remaining variables. Signed-off-by: Timo Ketola t...@exertus.fi --- This is based on u-boot-imx.git next. I hope that doesn't cause too much trouble. common/main.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) Applied, thanks. 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 Is not that the nature of men and women -- that the pleasure is in the learning of each other? -- Natira, the High Priestess of Yonada, For the World is Hollow and I Have Touched the Sky, stardate 5476.3. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2012.04 released, Merge Window is OPEN
Dear Stephen Warren, In message 4f957907.4070...@wwwdotorg.org you wrote: U-Boot v2012.04 has been released and is available from the git repository and the FTP server. The following didn't get merged: http://lists.denx.de/pipermail/u-boot/2012-April/122781.html which means nobody can pass a device tree to the bootm command on ARM (and I think bootz too). Argh. And why did _nobody_ complain during the -rc cycle? 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 As of 1992, they're called European Economic Community fries. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] arm: fix bootm with device tree
Dear Stephen Warren, In message 1334871241-11932-1-git-send-email-swar...@wwwdotorg.org you wrote: From: Stephen Warren swar...@nvidia.com Commit 0a672d4 arm: Add Prep subcommand support to bootm re-organized do_bootm_linux() for ARM. During the re-organization, the code to pass the device tree to the kernel was removed. Add it back. This restores the ability to boot a kernel using device tree. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Tom Rini tr...@ti.com --- v2: Fix a build warning --- arch/arm/lib/bootm.c | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) Applied, thanks. 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 Keep your head and your heart going in the right direction and you will not have to worry about your feet. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 'run' no longer aborts on an error, can someone please verify
Hi Wolfgang, On Mon, Apr 23, 2012 at 11:16 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon, In message capnjgz2vkx3tp6wmswixeys1q3xm+6wjoiyxwc23jpfim_0...@mail.gmail.com you wrote: Thanks for the detailed information. This might be the problem Wolfgang mentioned at the time...will take a look tomorrow. Could you please try and look into this ASAP? I consider this a serious bug, and would like to fix it in mainline as soon as possible. I think I will then even issue a v12.04.1 bugfix release. Yes, I have acked it. If you do a bugfix release, and have a bit of extra time, it would be good to pull in the sandbox fix: http://patchwork.ozlabs.org/patch/149810/ Sorry for the trouble, I hope to get some tests created for this behaviour. Regards, Simon 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 Virtual means never knowing where your next byte is coming from. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2012.04 released, Merge Window is OPEN
On 04/23/2012 02:08 PM, Wolfgang Denk wrote: Dear Stephen Warren, In message 4f957907.4070...@wwwdotorg.org you wrote: U-Boot v2012.04 has been released and is available from the git repository and the FTP server. The following didn't get merged: http://lists.denx.de/pipermail/u-boot/2012-April/122781.html which means nobody can pass a device tree to the bootm command on ARM (and I think bootz too). Argh. And why did _nobody_ complain during the -rc cycle? Um, what was: http://lists.denx.de/pipermail/u-boot/2012-April/122339.html And of course the patch I sent to solve it, admittedly late in the release cycle, but still before it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [STATUS] v2012.04.1 bug fix release
Hi all, it seems that at least two critical commits have not been included in the v2012.04 release. To fix the serious bugs caused by this I want to push out a v2012.04.1 maintenance release as soon as possible. For now I have included the following commits: commit 9e02a6b8e514a3256471a820cdb567668098fa22 Author: Stephen Warren swar...@nvidia.com Date: Thu Apr 19 11:09:49 2012 + arm: restore fdt_fixup_ethernet call to do_bootm_linux commit 1723997610ace497252d6f9a44ec76c06951ae43 Author: Stephen Warren swar...@nvidia.com Date: Thu Apr 19 11:34:00 2012 + arm: fix bootm with device tree commit 030fca5228a2a1e946ac13ff8fae9ccb8c516d7b Author: Timo Ketola t...@exertus.fi Date: Sun Apr 22 23:57:27 2012 + Fix the behaviour of the 'run' command Are there any other patches that should be included? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You know, after a woman's raised a family and so on, she wants to start living her own life. Whose life she's _been_ living, then? - Terry Pratchett, _Witches Abroad_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2012.04 released, Merge Window is OPEN
On Mon, Apr 23, 2012 at 10:08:35PM +0200, Wolfgang Denk wrote: Dear Stephen Warren, In message 4f957907.4070...@wwwdotorg.org you wrote: U-Boot v2012.04 has been released and is available from the git repository and the FTP server. The following didn't get merged: http://lists.denx.de/pipermail/u-boot/2012-April/122781.html which means nobody can pass a device tree to the bootm command on ARM (and I think bootz too). Argh. And why did _nobody_ complain during the -rc cycle? To try and say what Stephan said, differently, what do we need to do in the future to make sure complains aren't missed? You were on the to: line for at least part of the thread of patches. Do we need to make sure it's assigned to you in patchwork? Poke you on irc? What? :) -- 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 v3] Add support for MINI2440 (s3c2440). Documentation about the product can be found on: http://www.friendlyarm.net/products/mini2440
Dear Ilya Averyanov, In message CABi8O6aBPyYFPbzJETJFyx4fL4y1EHYpWJx8Ew4Ki-AHpLA=m...@mail.gmail.com you wrote: Why do you insist on sdram initialization code in C? If you simply do as done in the other boards on this architecture? We want to simplify code by usiing the same approach everywhere. And this means that we first set up a system that can run C code, and then use this to insitialize the RAM. This includes using get_ram_size() to auto-detect (and verify) the actual RAM size. And get_ram_size() is a C function as well. The other boards are still old-style and should not be used as examples. 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 How many QA engineers does it take to screw in a lightbulb? 3: 1 to screw it in and 2 to say I told you so when it doesn't work. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Add support for MINI2440 (s3c2440). Documentation about the product can be found on: http://www.friendlyarm.net/products/mini2440
Dear Vasily Khoruzhick, In message CA+E=qVdyJB3R8vwwFmZsU-0Yh1ah+ZyherrHnN3jx=xTY=t...@mail.gmail.com you wrote: Btw, using cache for stack looks like awful hack to me. No, why? Cache is pretty fast RAM, so why not use it as such? Hey, there are people who boot the whole Linux system (kernel + RAM disk) in cache (actully already on the die, before the chip even has seen a casing, far from thinking about a board... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de One planet is all you get. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Add support for MINI2440 (s3c2440). Documentation about the product can be found on: http://www.friendlyarm.net/products/mini2440
Dear Vasily Khoruzhick, In message CA+E=qvexe0wutn4nb6k-zah7uqvf4j0umd33+gxkqb3ypvt...@mail.gmail.com you wrote: Doing SDRAM init very early (even in assembly code) is obvious and simple. Just few simple writes into RAM controller registers. This is a misconception. Experience on this very mailing list has shown that an extremely high number of issues is cause by incomplete and/or incorrect memory initialization. This is why U-Boot (be design!) makes sure we have a full C environment when doing this taks, where we can use printf() and friends for useful output etc. It's not as simple as previous solution, isn't it? And looks No, it's not so simple, but far more convenient. And over time, much more time-saving. overengineered to me. I prefer to keep such low-level things simple. We respect your personal preferences. But in this case we ask you to stick with the U-Boot design andimplement as requested. Thanks. 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 1 1 was a race-horse, 2 2 was 1 2. When 1 1 1 1 race, 2 2 1 1 2. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v4] Add support for MINI2440 (s3c2440).
Dear Gabriel Huau,
In message 1335083622-8284-3-git-send-email-cont...@huau-gabriel.fr you wrote:
---
Please add some explanations what MINI2440 is, where to find
documentation, etc.
board/friendlyarm/mini2440/Makefile | 44 +++
board/friendlyarm/mini2440/mini2440.c | 121 +++
boards.cfg|1 +
include/configs/mini2440.h| 212
+
4 files changed, 378 insertions(+)
create mode 100644 board/friendlyarm/mini2440/Makefile
create mode 100644 board/friendlyarm/mini2440/mini2440.c
create mode 100644 include/configs/mini2440.h
Entry to MAINTAINERS missing.
...
+int dram_init(void)
+{
+ /*
+ * Configuring bus width and timing for bank 0 only
+ * Initialize clocks for each bank 0..5
+ * Bank 3 and 4 are used for DM9000
+ */
+ __raw_writel(0x221dd120, S3C24X0_MEMCTL_BASE);
+ __raw_writel(0x700, S3C24X0_MEMCTL_BASE+0x4); /* Bank0 register */
+ __raw_writel(0x700, S3C24X0_MEMCTL_BASE+0x8); /* Bank1 register */
+ __raw_writel(0x700, S3C24X0_MEMCTL_BASE+0xc); /* Bank2 register */
+ __raw_writel(0x1f70, S3C24X0_MEMCTL_BASE+0x10); /* Bank3 register */
+ __raw_writel(0x1f70, S3C24X0_MEMCTL_BASE+0x14); /* Bank4 register */
+ __raw_writel(0x700, S3C24X0_MEMCTL_BASE+0x18); /* Bank5 register */
We do not allow base address plus offset notation. Please use a
proper C struct instead.
+ gd-ram_size = PHYS_SDRAM_1_SIZE;
Please use get_ram_size() to auto-detect / verify the actual RAM size.
+/*
+ * High Level Configuration Options
+ */
+#define CONFIG_ARM920T 1 /* This is an ARM920T Core
*/
+#define CONFIG_S3C24X0 1 /* in a SAMSUNG S3C2440 SoC */
+#define CONFIG_S3C2440 1 /* in a SAMSUNG S3C2440 SoC */
+#define CONFIG_MINI2440 1 /* on a MIN2440 Board */
Please do not use values in feature-defines. Please fix globally.
+/* size in bytes reserved for initial data */
+#define CONFIG_GBL_DATA_SIZE 128
NAK. This gets auto-computed.
+/* everything, incl board info, in Hz */
+#undef CONFIG_CLKS_IN_HZ
Please do not undefine what is not defined anyway. Please fix
globally.
+/*
+ * When booting from NAND, it is impossible to access the lowest addresses
+ * due to the SteppingStone being in the way. Luckily the NOR doesn't really
+ * care about the highest 16 bits of address, so we set the controlers
+ * registers to go and poke over there, instead.
+ */
+#define PHYS_FLASH_1 0x0
+#define CONFIG_SYS_FLASH_BASE0x0
Urghh... this sounds very much like a serious design issue?
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
backups: always in season, never out of style.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/4] sandbox: Use the new run_command()
Dear Simon Glass, In message 1333179058-19598-3-git-send-email-...@chromium.org you wrote: Now that run_command() handles both parsers, clean up sandbox to use it. This fixes a build error. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: - Add new patch to clean up sandbox's run_command() usage arch/sandbox/cpu/start.c |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) Applied, thanks. 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 the facts don't fit the theory, change the facts. -- Albert Einstein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Sandbox question
On Monday 23 April 2012 15:33:42 Wolfgang Denk wrote: Mike Frysinger wrote: I don't see why we cannot simply read from stdin (or rathr from file descriptor 0) as usual? the usual method of reading from stdin involves the tty doing buffering and the application only seeing fully flushed lines. thus it would not operate the That's why I wrote or rather from fd 0. reading directly from fd 0 makes no difference. stdin is stdin. if stdin is backed by a tty, you need to behave differently than if it's backed by a pipe. same as the hardware (where u-boot gets every char as you type) and you wouldn't be able to handle things like tab completion. C'me on. That's a standard issue. We know how to handle this, right? and it's being handled already in the code because i submitted a patch to do so. my point was that sandbox can't read from stdin as usual. You can use standard methods like select() or poll() to wait for input, which will also inform you about events like EOF. because that isn't how u-boot on the hardware works. u-boot itself calls tstc() to see if there's any data and does so in a continuous loop. when there is data, it calls getc(). tstc() should not block, and getc() isn't call unless u-boot knows there's data. That's why I suggested to use select() or poll() to poll for available characters, just like the hardware does. Only we do NOT want to tun this in a tight loop. We will most likely want to add a sufficiently large delay to keep CPU load in reasonable bounds. where exactly do you propose adding this delay ? tstc() is called in many places (not just the main console loop), many of which are done simply to handle the unlikely CTRL+C interrupt. thus we don't want tstc() delaying at all or it'll slow down random CPU-bound operations. also, what you're proposing is changing the behavior of u-boot when it's in the sandbox so that it acts less like the hardware. when you run u-boot on the hardware and it's sitting at the prompt, u-boot is running the cpu at 100%. it is also problematic (currently) to get access to errno from the C library because u-boot itself has a variable called errno. so we cannot call the C Why invent new methods when we can encapsulate this in the input interface? i'm not inventing new methods. i'm telling you that the sandbox OS layer today cannot access the C library's errno because u-boot's own implementation of errno is overriding it. so any call sandbox makes to the OS (like read() or select() or poll()) that results in an error, sandbox has no way of knowing the underlying reason. We do not even have to pass EOF on to higher layers in U-Boot - we could exit directly in the tty interface code. yes, we can special case the sandbox-specific serial driver and have it call the sandbox-specific exit function when EOF is reached. if it's a pipe, we can do it in the tstc() func by waiting until POLLIN is cleared and POLLHUP is set. if it's a tty, the eof key (CTRL+D by default) will emit an EOT byte (0x04) which we will read in getc(). that is, if we want to actually support this. after all, doing CTRL+D on a serial port won't cause the board to reset, so i'm not sure the sandbox shell should exit either. plus, this would get in the way of code reading arbitrary data. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 05/10] tegra: Add keyboard support to funcmux
On 04/17/2012 01:01 PM, Simon Glass wrote: Add funcmux support for the default keyboard mapping. Signed-off-by: Simon Glass s...@chromium.org Acked-by: Stephen Warren swar...@wwwdotorg.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] kwboot: Boot Marvell Kirkwood SoCs over a serial link.
Dear Daniel Stodden, In message 1335075976.10449.13.camel@ramone you wrote: I wrote a utility to boot Marvell SoCs over serial. If that sounds generally useful, would you be so kind to merge Please see http://www.denx.de/wiki/U-Boot/Patches and post proper patch(es). Thanks. 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 Winners never talk about glorious victories. That's because they're the ones who see what the battlefield looks like afterwards. It's only the losers who have glorious victories. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 06/10] tegra: fdt: Add keyboard controller definition
On 04/17/2012 01:01 PM, Simon Glass wrote: From: Anton Staff robot...@chromium.org The Tegra keyboard controller provides a simple interface to a matrix keyboard. Signed-off-by: Simon Glass s...@chromium.org Acked-by: Stephen Warren swar...@wwwdotorg.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
