Re: [U-Boot] [PATCH] common, hush [BUG]: exit not work in hush shell
Dear Heiko, In message 505561a0.3060...@denx.de you wrote: Do you still have this test somewhere? Not really. It was during the development of an install upgrade script, and step by step I removed all constructs that the hush shell would stumble upon. Sorry. Hmm... Okay, so I have two options: - fix exit with arguments - update to a recent version of hush (where is the current code from?) Hush is part of Busybox, see http://www.busybox.net/source.html But I have the gut feeling, that the problem is not in the original code, but in the u-boot adaptions, as the code in hush.c has a lot of #ifndef __U_BOOT__ ... There are also bugs in the old original code, many of them long fixed since. I once started looking into updating hush, and I have to admit that I don't understand the need for all of the #ifndef __U_BOOT__ removals. When hush support was added, and additional 60 kB of code was a very heavy thing on most systems, so the primary intention then was to make the code as lightwight as possible. Today, a much larger percentage of users is both able to accept such code sizes and looking for the features offered. Many would even accept somewhat bigger code if they could get, for example, support for shell functions etc. Not to mention command substitution... 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 Thought for the day: What if there were no hypothetical situations? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
Hi, On Sun, Sep 16, 2012 at 5:36 PM, Marek Vasut ma...@denx.de wrote: Dear José Miguel Gonçalves, On 09/16/2012 11:06 AM, Marek Vasut wrote: Dear José Miguel Gonçalves, On 09/15/2012 07:03 PM, Marek Vasut wrote: Dear José Miguel Gonçalves, Jumping to board_init_r is not performed due to a bug on address computation. Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards. Maybe because you are not using it to build an SPL? I do ... and I use CONFIG_SPL_TEXT_BASE properly . Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs. Please wait and please first explain what is the issue. The issue is what I've explained in the patch comments. Jumping to board_init_r is not performed due to a bug on address computation. Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway .. Same for me - I have no idea what you are trying to fix here. In my SPL configuration, _TEXT_BASE and _start point to the same location, so please explain why they are different on your board. Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set. I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL or something like that. Marek, going into board_init_r is fine for SPL, for example the davinci SPL does some hw initialization in board_init_f and then loads u-boot in board_init_r. Regards, Christian What do you boot the rest from ? If the bug is not from here please suggest me what I need to change in the configuration in order to correctly boot my board. Relocation offsets are not needed when building SPL. Do they cause any trouble? No! Just not needed. Signed-off-by: José Miguel Gonçalves jose.goncal...@inov.pt --- Changes for v2: - None --- arch/arm/cpu/arm926ejs/start.S |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -325,7 +325,7 @@ _nand_boot_ofs: .word nand_boot #else ldr r0, _board_init_r_ofs -ldr r1, _TEXT_BASE +adr r1, _start add lr, r0, r1 add lr, lr, r9 /* setup parameters for board_init_r */ @@ -338,12 +338,14 @@ _board_init_r_ofs: .word board_init_r - _start #endif +#ifndef CONFIG_SPL_BUILD _rel_dyn_start_ofs: .word __rel_dyn_start - _start _rel_dyn_end_ofs: .word __rel_dyn_end - _start _dynsym_start_ofs: .word __dynsym_start - _start +#endif /* ** *** Best regards, Marek Vasut Best regards, José Gonçalves Best regards, Marek Vasut Best regards, José Gonçalves ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
Hi,
On Sun, Sep 16, 2012 at 11:27 AM, José Miguel Gonçalves
jose.goncal...@inov.pt wrote:
On 09/14/2012 08:08 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel Gon??alves wrote:
Samsung's S3C24XX SoCs need this in order to generate a binary image
with the SPL and U-Boot concatenated.
Signed-off-by: Jos?? Miguel Gon??alves jose.goncal...@inov.pt
---
Changes for v2:
- None
---
Makefile |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 058fb53..595b5f6 100644
--- a/Makefile
+++ b/Makefile
@@ -442,13 +442,14 @@ $(obj)u-boot.sha1:$(obj)u-boot.bin
$(obj)u-boot.dis: $(obj)u-boot
$(OBJDUMP) -d $ $@
-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
+$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
$(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary
$(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin
$(obj)u-boot-ubl.bin
+ rm $(obj)spl/u-boot-spl-pad.bin
+
+$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin
$(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \
-e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin
$(obj)u-boot.ubl
- rm $(obj)u-boot-ubl.bin
- rm $(obj)spl/u-boot-spl-pad.bin
$(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
$(obj)tools/mkimage -s -n $(if
$(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),/dev/null) \
This diff is hard to read, but what exactly are you changing? The
u-boot-ubl target is also used on TI platforms. It looks like you're
making it such that u-boot-ubl.bin produces the old binary and
u-boot-ubl adds a new target which is the mkimage header on top of the
same bits as before, but without possibly padding the output image. I
suspect in your case you could just set PAD_TO to 8192 in
board/../config.mk and use the existing target.
In the S3C2416 I don't need the mkimage stuff. I only need the raw SPL image
padded at 8KB concatenated with the standard U-Boot. What I've done was to
split the existing u-boot-ubl target in two; u-boot-ubl.bin, that I use to
program the Flash, and u-boot-ubl that remains with the same functionality
as before, just now it depends on u-boot-ubl.bin.
I think you should drop the UBL names from your padding target
(u-boot-ubl.bin) since this is TI specific, use something more
generic.
Regards, Christian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 41/71] serial: arm: Implement CONFIG_SERIAL_MULTI into atmel serial driver
Dear Marek Vasut,
I have to admit that when reading this patch I got attention of your
UDM-serial.txt for the first time. However when reading this patch some
questions come to my mind.
On 17.09.12 01:21, Marek Vasut wrote:
Implement support for CONFIG_SERIAL_MULTI into atmel serial driver.
This driver was so far only usable directly, but this patch also adds
support for the multi method. This allows using more than one serial
driver alongside the atmel driver. Also, add a weak implementation
of default_serial_console() returning this driver.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Marek Vasut marek.va...@gmail.com
Cc: Tom Rini tr...@ti.com
Cc: Xu, Hong hong...@atmel.com
---
common/serial.c |2 ++
drivers/serial/atmel_usart.c | 67
++
2 files changed, 63 insertions(+), 6 deletions(-)
diff --git a/common/serial.c b/common/serial.c
index e6566da..b880303 100644
--- a/common/serial.c
+++ b/common/serial.c
@@ -71,6 +71,7 @@ serial_initfunc(sconsole_serial_initialize);
serial_initfunc(p3mx_serial_initialize);
serial_initfunc(altera_jtag_serial_initialize);
serial_initfunc(altera_serial_initialize);
+serial_initfunc(atmel_serial_initialize);
void serial_register(struct serial_device *dev)
{
@@ -120,6 +121,7 @@ void serial_initialize(void)
p3mx_serial_initialize();
altera_jtag_serial_initialize();
altera_serial_initialize();
+ atmel_serial_initialize();
serial_assign(default_serial_console()-name);
}
diff --git a/drivers/serial/atmel_usart.c b/drivers/serial/atmel_usart.c
index 943ef70..d49d5d4 100644
--- a/drivers/serial/atmel_usart.c
+++ b/drivers/serial/atmel_usart.c
@@ -20,6 +20,8 @@
*/
#include common.h
#include watchdog.h
+#include serial.h
+#include linux/compiler.h
#include asm/io.h
#include asm/arch/clk.h
@@ -29,7 +31,7 @@
DECLARE_GLOBAL_DATA_PTR;
-void serial_setbrg(void)
+static void atmel_serial_setbrg(void)
{
atmel_usart3_t *usart = (atmel_usart3_t *)CONFIG_USART_BASE;
shouldn't this USART_BASE be carried by the driver struct in some way? I
wonder how one should implement multiple interfaces later on with this
atmel_serial_xx(void) interface.
unsigned long divisor;
@@ -45,7 +47,7 @@ void serial_setbrg(void)
writel(USART3_BF(CD, divisor), usart-brgr);
}
-int serial_init(void)
+static int atmel_serial_init(void)
{
atmel_usart3_t *usart = (atmel_usart3_t *)CONFIG_USART_BASE;
@@ -73,7 +75,7 @@ int serial_init(void)
return 0;
}
-void serial_putc(char c)
+static void atmel_serial_putc(char c)
{
atmel_usart3_t *usart = (atmel_usart3_t *)CONFIG_USART_BASE;
@@ -84,13 +86,13 @@ void serial_putc(char c)
writel(c, usart-thr);
}
-void serial_puts(const char *s)
+static void atmel_serial_puts(const char *s)
{
while (*s)
serial_putc(*s++);
}
I have seen this one in a lot of drivers ... shouldn't we build a
generic one?
-int serial_getc(void)
+static int atmel_serial_getc(void)
{
atmel_usart3_t *usart = (atmel_usart3_t *)CONFIG_USART_BASE;
@@ -99,8 +101,61 @@ int serial_getc(void)
return readl(usart-rhr);
}
-int serial_tstc(void)
+static int atmel_serial_tstc(void)
{
atmel_usart3_t *usart = (atmel_usart3_t *)CONFIG_USART_BASE;
return (readl(usart-csr) USART3_BIT(RXRDY)) != 0;
}
+
+#ifdef CONFIG_SERIAL_MULTI
+static struct serial_device atmel_serial_drv = {
+ .name = atmel_serial,
even though here is just one instance shouldn't the name reflect the
multiplicity of this driver (e.g. 'atmel_serial0')?
+ .start = atmel_serial_init,
+ .stop = NULL,
+ .setbrg = atmel_serial_setbrg,
+ .putc = atmel_serial_putc,
+ .puts = atmel_serial_puts,
+ .getc = atmel_serial_getc,
+ .tstc = atmel_serial_tstc,
As I understand this struct we need a start/stop/setbgr/... for each
instance we build.
Shouldn't we carry some void* private in this struct instead (I have
none seen in '[PATCH 01/71] serial: Coding style cleanup of struct
serial_device') to be able to reuse the interface with multiple
instances of the same driver class?
I think this is my main objection to this structure. I wonder how
existing SERIAL_MULTI implementations handle the need of private driver
information bound to an instance.
Best regards
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] phy: Add support for Marvell 88E1118R
On 09/14/2012 06:17 PM, Joe Hershberger wrote: Hi Michal, On Fri, Sep 14, 2012 at 8:15 AM, Michal Simek mon...@monstr.eu wrote: Hi Tom and Joe, On 08/07/2012 02:23 PM, Michal Simek wrote: Marvell 88E1118R has different uid then 88E1118. Signed-off-by: Michal Simek mon...@monstr.eu CC: Andy Fleming aflem...@freescale.com CC: Zang Roy-R61911 tie-fei.z...@freescale.com CC: Kumar Gala ga...@kernel.crashing.org --- drivers/net/phy/marvell.c | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) can you please handle this patch? Or if you like I will add to my custodian tree. I'll apply it when I get to my backlog. Ok. Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
On 09/17/2012 07:47 AM, Christian Riesch wrote:
Hi,
On Sun, Sep 16, 2012 at 11:27 AM, José Miguel Gonçalves
jose.goncal...@inov.pt wrote:
On 09/14/2012 08:08 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel Gon??alves wrote:
Samsung's S3C24XX SoCs need this in order to generate a binary image
with the SPL and U-Boot concatenated.
Signed-off-by: Jos?? Miguel Gon??alves jose.goncal...@inov.pt
---
Changes for v2:
- None
---
Makefile |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 058fb53..595b5f6 100644
--- a/Makefile
+++ b/Makefile
@@ -442,13 +442,14 @@ $(obj)u-boot.sha1:$(obj)u-boot.bin
$(obj)u-boot.dis: $(obj)u-boot
$(OBJDUMP) -d $ $@
-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
+$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
$(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary
$(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin
$(obj)u-boot-ubl.bin
+ rm $(obj)spl/u-boot-spl-pad.bin
+
+$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin
$(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \
-e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin
$(obj)u-boot.ubl
- rm $(obj)u-boot-ubl.bin
- rm $(obj)spl/u-boot-spl-pad.bin
$(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
$(obj)tools/mkimage -s -n $(if
$(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),/dev/null) \
This diff is hard to read, but what exactly are you changing? The
u-boot-ubl target is also used on TI platforms. It looks like you're
making it such that u-boot-ubl.bin produces the old binary and
u-boot-ubl adds a new target which is the mkimage header on top of the
same bits as before, but without possibly padding the output image. I
suspect in your case you could just set PAD_TO to 8192 in
board/../config.mk and use the existing target.
In the S3C2416 I don't need the mkimage stuff. I only need the raw SPL image
padded at 8KB concatenated with the standard U-Boot. What I've done was to
split the existing u-boot-ubl target in two; u-boot-ubl.bin, that I use to
program the Flash, and u-boot-ubl that remains with the same functionality
as before, just now it depends on u-boot-ubl.bin.
I think you should drop the UBL names from your padding target
(u-boot-ubl.bin) since this is TI specific, use something more
generic.
I only reused a temporary filename used for the u-boot-ubl target and
make it a new target.
If you think this is not an adequate name, can you suggest a new one?
Best regards,
José Gonçalves
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
On 09/17/2012 07:28 AM, Christian Riesch wrote: Hi, On Sun, Sep 16, 2012 at 5:36 PM, Marek Vasut ma...@denx.de wrote: Dear José Miguel Gonçalves, On 09/16/2012 11:06 AM, Marek Vasut wrote: Dear José Miguel Gonçalves, On 09/15/2012 07:03 PM, Marek Vasut wrote: Dear José Miguel Gonçalves, Jumping to board_init_r is not performed due to a bug on address computation. Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards. Maybe because you are not using it to build an SPL? I do ... and I use CONFIG_SPL_TEXT_BASE properly . Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs. Please wait and please first explain what is the issue. The issue is what I've explained in the patch comments. Jumping to board_init_r is not performed due to a bug on address computation. Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway .. Same for me - I have no idea what you are trying to fix here. In my SPL configuration, _TEXT_BASE and _start point to the same location, so please explain why they are different on your board. They are different because of how start.S is implemented in arm926ejs. In my SPL map file I see: .text 0x 0xc24 arch/arm/cpu/arm926ejs/start.o(.text) .text 0x 0x120 arch/arm/cpu/arm926ejs/start.o 0x_start 0x0040_TEXT_BASE 0x0044_bss_start_ofs 0x0048_bss_end_ofs 0x004c_end_ofs 0x0050IRQ_STACK_START_IN 0x0074relocate_code Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set. I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL or something like that. Marek, going into board_init_r is fine for SPL, for example the davinci SPL does some hw initialization in board_init_f and then loads u-boot in board_init_r. Regards, Christian What do you boot the rest from ? If the bug is not from here please suggest me what I need to change in the configuration in order to correctly boot my board. Relocation offsets are not needed when building SPL. Do they cause any trouble? No! Just not needed. Signed-off-by: José Miguel Gonçalves jose.goncal...@inov.pt --- Changes for v2: - None --- arch/arm/cpu/arm926ejs/start.S |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -325,7 +325,7 @@ _nand_boot_ofs: .word nand_boot #else ldr r0, _board_init_r_ofs -ldr r1, _TEXT_BASE +adr r1, _start add lr, r0, r1 add lr, lr, r9 /* setup parameters for board_init_r */ @@ -338,12 +338,14 @@ _board_init_r_ofs: .word board_init_r - _start #endif +#ifndef CONFIG_SPL_BUILD _rel_dyn_start_ofs: .word __rel_dyn_start - _start _rel_dyn_end_ofs: .word __rel_dyn_end - _start _dynsym_start_ofs: .word __dynsym_start - _start +#endif /* ** *** Best regards, Marek Vasut Best regards, José Gonçalves Best regards, Marek Vasut Best regards, José Gonçalves Best regards, José Gonçalves ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AR8031 Ethernet on mx6
On 15.09.2012 05:06, Fabio Estevam wrote:
Hi Jason,
I don't have a mx6qarm2 and would like to ask you if you could please
confirm that Ethernet is functional on mx6qarm2 running the latest
U-boot.
I am trying to get Ethernet working on mx6qsabresd, which also uses
the same AR8031 PHY, but it is not working yet.
AR8031 is supposed to output a 125MHz clock to mx6q, but I see a 25MHz
clock instead.
I do the same PHY init as in mx6qarm2.
Any ideas/suggestions are appreciated.
Trying the recent mainline U-Boot (a6f0c4faa4c65a7b7048b) on an ARM2
board we get [1] after manually setting an ethaddr and the IP addresses.
Sometimes U-Boot seems to hang after 'MMC: FSL_SDHC: 0, FSL_SDHC: 1'
but this might be an other issue.
Best regards
Dirk
[1]
U-Boot 2012.07-00490-ga6f0c4f (Sep 17 2012 - 10:01:46)
CPU: Freescale i.MX6Q rev1.0 at 792 MHz
Reset cause: POR
Board: MX6Q-Armadillo2
DRAM: 2 GiB
WARNING: Caches not enabled
MMC: FSL_SDHC: 0, FSL_SDHC: 1
In:serial
Out: serial
Err: serial
Net: FEC
Hit any key to stop autoboot: 0
MX6QARM2 U-Boot printenv
baudrate=115200
bootargs=console=ttymxc3,115200 root=/dev/nfs ip=dhcp nfsroot=:,v3,tcp
bootcmd=mmc dev ${mmcdev};if mmc rescan ${mmcdev}; then if run
loadbootscript; then run bootscript; else if run loi
bootdelay=3
bootscript=echo Running bootscript from mmc ...; source
console=ttymxc3
ethact=FEC
ethaddr=00:19:B8:00:E5:4E
fdt_high=0x
initrd_high=0x
ipaddr=172.17.0.1
loadaddr=0x1080
loadbootscript=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};
loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}
mmcargs=setenv bootargs console=${console},${baudrate} root=${mmcroot}
mmcboot=echo Booting from mmc ...; run mmcargs; bootm
mmcdev=1
mmcpart=2
mmcroot=/dev/mmcblk0p3 rootwait rw
netargs=setenv bootargs console=${console},${baudrate} root=/dev/nfs
ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp
netboot=echo Booting from net ...; run netargs; dhcp ${uimage}; bootm
script=boot.scr
serverip=172.17.0.6
stderr=serial
stdin=serial
stdout=serial
uimage=uImage
Environment size: 1125/8188 bytes
MX6QARM2 U-Boot tftpboot ${loadaddr} uImage
Using FEC device
TFTP from server 172.17.0.6; our IP address is 172.17.0.1
Filename 'uImage'.
Load address: 0x1080
Loading:
#
#
#
#
done
Bytes transferred = 3756664 (395278 hex)
MX6QARM2 U-Boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
Hi, On Mon, Sep 17, 2012 at 10:34 AM, José Miguel Gonçalves jose.goncal...@inov.pt wrote: On 09/17/2012 07:28 AM, Christian Riesch wrote: Hi, On Sun, Sep 16, 2012 at 5:36 PM, Marek Vasut ma...@denx.de wrote: Dear José Miguel Gonçalves, On 09/16/2012 11:06 AM, Marek Vasut wrote: Dear José Miguel Gonçalves, On 09/15/2012 07:03 PM, Marek Vasut wrote: Dear José Miguel Gonçalves, Jumping to board_init_r is not performed due to a bug on address computation. Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards. Maybe because you are not using it to build an SPL? I do ... and I use CONFIG_SPL_TEXT_BASE properly . Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs. Please wait and please first explain what is the issue. The issue is what I've explained in the patch comments. Jumping to board_init_r is not performed due to a bug on address computation. Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway .. Same for me - I have no idea what you are trying to fix here. In my SPL configuration, _TEXT_BASE and _start point to the same location, so please explain why they are different on your board. They are different because of how start.S is implemented in arm926ejs. In my SPL map file I see: .text 0x 0xc24 arch/arm/cpu/arm926ejs/start.o(.text) .text 0x 0x120 arch/arm/cpu/arm926ejs/start.o 0x_start 0x0040_TEXT_BASE 0x0044_bss_start_ofs 0x0048_bss_end_ofs 0x004c_end_ofs 0x0050IRQ_STACK_START_IN 0x0074relocate_code So _start is 0x, and in your config/include/include/configs/mini2416.h you have #define CONFIG_SPL_TEXT_BASE 0x and in arch/arm/cpu/arm926ejs/start.S we have .globl _TEXT_BASE _TEXT_BASE: #ifdef CONFIG_NAND_SPL /* deprecated, use instead CONFIG_SPL_BUILD */ .word CONFIG_SYS_TEXT_BASE #else #ifdef CONFIG_SPL_BUILD .word CONFIG_SPL_TEXT_BASE #else .word CONFIG_SYS_TEXT_BASE #endif #endif So ldr r1, _TEXT_BASE should be the same as adr r1, _start However, if you do not load your SPL to 0x but to another address and execute it from there, it will be different, since adr uses relative adressing, right? Are you sure you are loading it to 0x? Regards, Christian Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set. I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL or something like that. Marek, going into board_init_r is fine for SPL, for example the davinci SPL does some hw initialization in board_init_f and then loads u-boot in board_init_r. Regards, Christian What do you boot the rest from ? If the bug is not from here please suggest me what I need to change in the configuration in order to correctly boot my board. Relocation offsets are not needed when building SPL. Do they cause any trouble? No! Just not needed. Signed-off-by: José Miguel Gonçalves jose.goncal...@inov.pt --- Changes for v2: - None --- arch/arm/cpu/arm926ejs/start.S |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -325,7 +325,7 @@ _nand_boot_ofs: .word nand_boot #else ldr r0, _board_init_r_ofs -ldr r1, _TEXT_BASE +adr r1, _start add lr, r0, r1 add lr, lr, r9 /* setup parameters for board_init_r */ @@ -338,12 +338,14 @@ _board_init_r_ofs: .word board_init_r - _start #endif +#ifndef CONFIG_SPL_BUILD _rel_dyn_start_ofs: .word __rel_dyn_start - _start _rel_dyn_end_ofs: .word __rel_dyn_end - _start _dynsym_start_ofs: .word __dynsym_start - _start +#endif /* ** *** Best regards, Marek Vasut Best regards, José Gonçalves Best regards, Marek Vasut Best regards, José Gonçalves Best regards, José Gonçalves ___ U-Boot mailing list
Re: [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
Hi Christian, On 09/17/2012 10:03 AM, Christian Riesch wrote: Hi, On Mon, Sep 17, 2012 at 10:34 AM, José Miguel Gonçalves jose.goncal...@inov.pt wrote: On 09/17/2012 07:28 AM, Christian Riesch wrote: Hi, On Sun, Sep 16, 2012 at 5:36 PM, Marek Vasut ma...@denx.de wrote: Dear José Miguel Gonçalves, On 09/16/2012 11:06 AM, Marek Vasut wrote: Dear José Miguel Gonçalves, On 09/15/2012 07:03 PM, Marek Vasut wrote: Dear José Miguel Gonçalves, Jumping to board_init_r is not performed due to a bug on address computation. Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards. Maybe because you are not using it to build an SPL? I do ... and I use CONFIG_SPL_TEXT_BASE properly . Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs. Please wait and please first explain what is the issue. The issue is what I've explained in the patch comments. Jumping to board_init_r is not performed due to a bug on address computation. Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway .. Same for me - I have no idea what you are trying to fix here. In my SPL configuration, _TEXT_BASE and _start point to the same location, so please explain why they are different on your board. They are different because of how start.S is implemented in arm926ejs. In my SPL map file I see: .text 0x 0xc24 arch/arm/cpu/arm926ejs/start.o(.text) .text 0x 0x120 arch/arm/cpu/arm926ejs/start.o 0x_start 0x0040_TEXT_BASE 0x0044_bss_start_ofs 0x0048_bss_end_ofs 0x004c_end_ofs 0x0050IRQ_STACK_START_IN 0x0074relocate_code So _start is 0x, and in your config/include/include/configs/mini2416.h you have #define CONFIG_SPL_TEXT_BASE 0x and in arch/arm/cpu/arm926ejs/start.S we have .globl _TEXT_BASE _TEXT_BASE: #ifdef CONFIG_NAND_SPL /* deprecated, use instead CONFIG_SPL_BUILD */ .word CONFIG_SYS_TEXT_BASE #else #ifdef CONFIG_SPL_BUILD .word CONFIG_SPL_TEXT_BASE #else .word CONFIG_SYS_TEXT_BASE #endif #endif So ldr r1, _TEXT_BASE should be the same as adr r1, _start However, if you do not load your SPL to 0x but to another address and execute it from there, it will be different, since adr uses relative adressing, right? Are you sure you are loading it to 0x? Not an expert on ARM assembly, so cannot give any feedback on the differences between adr and ldr mnemonics. What I know for a fact is that the S3C2416, when booting from it's internal ROM, makes a copy of the first 8KB of the NAND flash to an internal RAM (named SteppingStone), maps it at address 0 and the jumps to the start of it. This mapping is not clear in Samsung's user manual but I retrieved that information from here: http://barebox.org/documentation/barebox-2011.05.0/dev_s3c24xx_arch.html Regards, Christian Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set. I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL or something like that. Marek, going into board_init_r is fine for SPL, for example the davinci SPL does some hw initialization in board_init_f and then loads u-boot in board_init_r. Regards, Christian What do you boot the rest from ? If the bug is not from here please suggest me what I need to change in the configuration in order to correctly boot my board. Relocation offsets are not needed when building SPL. Do they cause any trouble? No! Just not needed. Signed-off-by: José Miguel Gonçalves jose.goncal...@inov.pt --- Changes for v2: - None --- arch/arm/cpu/arm926ejs/start.S |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -325,7 +325,7 @@ _nand_boot_ofs: .word nand_boot #else ldr r0, _board_init_r_ofs -ldr r1, _TEXT_BASE +adr r1, _start add lr, r0, r1 add lr, lr, r9 /* setup parameters for board_init_r */ @@ -338,12 +338,14 @@ _board_init_r_ofs: .word board_init_r - _start #endif +#ifndef CONFIG_SPL_BUILD
Re: [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
On 09/17/2012 10:10 AM, Christian Riesch wrote:
On Mon, Sep 17, 2012 at 10:30 AM, José Miguel Gonçalves
jose.goncal...@inov.pt wrote:
On 09/17/2012 07:47 AM, Christian Riesch wrote:
Hi,
On Sun, Sep 16, 2012 at 11:27 AM, José Miguel Gonçalves
jose.goncal...@inov.pt wrote:
On 09/14/2012 08:08 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel Gon??alves wrote:
Samsung's S3C24XX SoCs need this in order to generate a binary image
with the SPL and U-Boot concatenated.
Signed-off-by: Jos?? Miguel Gon??alves jose.goncal...@inov.pt
---
Changes for v2:
- None
---
Makefile |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 058fb53..595b5f6 100644
--- a/Makefile
+++ b/Makefile
@@ -442,13 +442,14 @@ $(obj)u-boot.sha1:$(obj)u-boot.bin
$(obj)u-boot.dis: $(obj)u-boot
$(OBJDUMP) -d $ $@
-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
+$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
$(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary
$(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin
$(obj)u-boot-ubl.bin
+ rm $(obj)spl/u-boot-spl-pad.bin
+
+$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin
$(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \
-e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin
$(obj)u-boot.ubl
- rm $(obj)u-boot-ubl.bin
- rm $(obj)spl/u-boot-spl-pad.bin
$(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
$(obj)tools/mkimage -s -n $(if
$(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),/dev/null) \
This diff is hard to read, but what exactly are you changing? The
u-boot-ubl target is also used on TI platforms. It looks like you're
making it such that u-boot-ubl.bin produces the old binary and
u-boot-ubl adds a new target which is the mkimage header on top of the
same bits as before, but without possibly padding the output image. I
suspect in your case you could just set PAD_TO to 8192 in
board/../config.mk and use the existing target.
In the S3C2416 I don't need the mkimage stuff. I only need the raw SPL
image
padded at 8KB concatenated with the standard U-Boot. What I've done was
to
split the existing u-boot-ubl target in two; u-boot-ubl.bin, that I use
to
program the Flash, and u-boot-ubl that remains with the same
functionality
as before, just now it depends on u-boot-ubl.bin.
I think you should drop the UBL names from your padding target
(u-boot-ubl.bin) since this is TI specific, use something more
generic.
I only reused a temporary filename used for the u-boot-ubl target and make
it a new target.
If you think this is not an adequate name, can you suggest a new one?
u-boot.pad? u-boot-pad.bin?
If no one else has anything against, I will change the name of the new
target to u-boot-pad.bin
Best regards,
José Gonçalves
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/16] pmic:i2c: Add I2C byte order to PMIC framework
On 14/09/2012 17:40, Lukasz Majewski wrote:
Since the pmic_reg_read is the u32 value, the order in which bytes
are placed to form u32 value is important.
This commit adds the reverse (which is default) and normal byte order.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Hi,
drivers/misc/pmic_i2c.c | 31 ---
include/pmic.h |3 +++
2 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/misc/pmic_i2c.c b/drivers/misc/pmic_i2c.c
index e74c372..1aa5b7b 100644
--- a/drivers/misc/pmic_i2c.c
+++ b/drivers/misc/pmic_i2c.c
@@ -40,13 +40,24 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
switch (pmic_i2c_tx_num) {
case 3:
- buf[0] = (val 16) 0xff;
- buf[1] = (val 8) 0xff;
- buf[2] = val 0xff;
+ if (pmic_i2c_byte_order == PMIC_BYTE_ORDER_NORMAL) {
+ buf[2] = (val 16) 0xff;
+ buf[1] = (val 8) 0xff;
+ buf[0] = val 0xff;
+ } else {
+ buf[0] = (val 16) 0xff;
+ buf[1] = (val 8) 0xff;
+ buf[2] = val 0xff;
+ }
break;
case 2:
- buf[0] = (val 8) 0xff;
- buf[1] = val 0xff;
+ if (pmic_i2c_byte_order == PMIC_BYTE_ORDER_NORMAL) {
+ buf[1] = (val 8) 0xff;
+ buf[0] = val 0xff;
+ } else {
+ buf[0] = (val 8) 0xff;
+ buf[1] = val 0xff;
+ }
break;
case 1:
buf[0] = val 0xff;
@@ -75,10 +86,16 @@ int pmic_reg_read(struct pmic *p, u32 reg, u32 *val)
switch (pmic_i2c_tx_num) {
case 3:
- ret_val = buf[0] 16 | buf[1] 8 | buf[2];
+ if (pmic_i2c_byte_order == PMIC_BYTE_ORDER_NORMAL)
+ ret_val = buf[2] 16 | buf[1] 8 | buf[0];
+ else
+ ret_val = buf[0] 16 | buf[1] 8 | buf[2];
break;
case 2:
- ret_val = buf[0] 8 | buf[1];
+ if (pmic_i2c_byte_order == PMIC_BYTE_ORDER_NORMAL)
+ ret_val = buf[1] 8 | buf[0];
+ else
+ ret_val = buf[0] 8 | buf[1];
break;
case 1:
ret_val = buf[0];
diff --git a/include/pmic.h b/include/pmic.h
index 6a05b40..2166f73 100644
--- a/include/pmic.h
+++ b/include/pmic.h
@@ -27,11 +27,13 @@
enum { PMIC_I2C, PMIC_SPI, };
enum { I2C_PMIC, I2C_NUM, };
enum { PMIC_READ, PMIC_WRITE, };
+enum { PMIC_BYTE_ORDER_REVERSED, PMIC_BYTE_ORDER_NORMAL, };
struct p_i2c {
unsigned char addr;
unsigned char *buf;
unsigned char tx_num;
+ unsigned char byte_order;
I can imagine we could have the same issue with SPI and not only with
I2C. The byte order is not strictly related to the interface type, and I
think this should add to the struct pmic instead of the struct p_i2c.
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 03/16] pmic:max8997: Switch the MAX8997 PMIC to be used with multibus I2C
On 14/09/2012 17:40, Lukasz Majewski wrote:
PMIC MAX8997 is now ready to work with single and multibus soft I2C
implementation.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/misc/pmic_max8997.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/misc/pmic_max8997.c b/drivers/misc/pmic_max8997.c
index 62dbc05..4943f66 100644
--- a/drivers/misc/pmic_max8997.c
+++ b/drivers/misc/pmic_max8997.c
@@ -24,6 +24,7 @@
#include common.h
#include pmic.h
#include max8997_pmic.h
+#include i2c.h
int pmic_init(void)
{
@@ -37,7 +38,7 @@ int pmic_init(void)
p-number_of_regs = PMIC_NUM_OF_REGS;
p-hw.i2c.addr = MAX8997_I2C_ADDR;
p-hw.i2c.tx_num = 1;
- p-bus = I2C_PMIC;
+ p-bus = I2C_0;
I do not see so useful to add an enum for each instance of the I2C bus.
And we have to add it if the number of i2c busses grows. IMHO it is
better to use directly the constant, so later in another patch
pmic_init(5) instead of pmic(I2C_5).
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 08/16] pmic:muic: Support for MUIC built into MAX8997 device
On 14/09/2012 17:40, Lukasz Majewski wrote: Support for MUIC (Micro USB Integrated Circuit) built into the MAX8997 power management device. The MUIC device will work with redesigned PMIC framework. Signed-off-by: Lukasz Majewski l.majew...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Stefano Babic sba...@denx.de --- Hi Lukasz, drivers/misc/Makefile|1 + drivers/misc/muic_max8997.c | 80 ++ include/power/max8997_muic.h | 61 include/power/power_chrg.h |1 + 4 files changed, 143 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/muic_max8997.c create mode 100644 include/power/max8997_muic.h I see now with this patch, but we have a mix between drivers/misc and drivers/power. I think this was done because the power directory was introduced later, but really all pmics under drivers/misc should be moved into drivers/power. Maybe belong this one also to drivers/power ? You added several add-ons for MAX8997. Maybe it is clearer if everything goes into a separate directory, such as power/max8997/ diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 271463c..f08a800 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -41,6 +41,7 @@ COBJS-$(CONFIG_PMIC_I2C) += pmic_i2c.o COBJS-$(CONFIG_PMIC_SPI) += pmic_spi.o COBJS-$(CONFIG_PMIC_MAX8998) += pmic_max8998.o COBJS-$(CONFIG_PMIC_MAX8997) += pmic_max8997.o +COBJS-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o COBJS:= $(COBJS-y) SRCS := $(COBJS:.o=.c) diff --git a/drivers/misc/muic_max8997.c b/drivers/misc/muic_max8997.c new file mode 100644 index 000..d332c09 --- /dev/null +++ b/drivers/misc/muic_max8997.c @@ -0,0 +1,80 @@ +/* + * Copyright (C) 2012 Samsung Electronics + * Lukasz Majewski l.majew...@samsung.com + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include common.h +#include power/pmic.h +#include power/power_chrg.h +#include power/max8997_muic.h +#include i2c.h + +int power_muic_init(unsigned int bus) You add a different function to initialize it, but this is a version opf pmic_init(). Why cannot we consider this one as all other pmics, avoiding to introduce new and undocumented functions ? If I do not misunderstand, you use the different functions to select the pmic. In other words, calling power_update_battery() in the trats code selects automatically the fulel-gauge, because this code implements this function. But this is against the goal of your patches, that is to add multi instances of the pmics (and maybe a second instance of fuel_gauge..). I think this should be solved moving this function to the general API and calling it via pointer. For example, something like: p = pmic_get(MAX_8997); p-read(...); p = pmic_get(MAX17042_FG); p-power_update_battery(..); What do you think ? 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 v5 4/5] OMAP: networking support for SPL
Hi Joe, On Thu, Aug 30, 2012 at 1:25 AM, Joe Hershberger joe.hershber...@gmail.comwrote: diff --git a/arch/arm/cpu/armv7/omap-common/Makefile b/arch/arm/cpu/armv7/omap-common/Makefile index d37b22d..f042078 100644 --- a/arch/arm/cpu/armv7/omap-common/Makefile +++ b/arch/arm/cpu/armv7/omap-common/Makefile @@ -53,6 +53,9 @@ endif ifdef CONFIG_SPL_YMODEM_SUPPORT COBJS += spl_ymodem.o endif +ifdef CONFIG_SPL_NET_SUPPORT +COBJS += spl_net.o +endif Why not use common pattern of... COBJS-$(CONFIG_SPL_NET_SUPPORT) += spl_net.o COBJS := $(sort $(COBJS-y)) In fact, I'm just following the existing style here... But I can change it as you requested. +#include common.h +#include net.h +#include asm/omap_common.h What in here needs this header? Looks like it's unneeded. Thanks, I'll remove it. diff --git a/common/command.c b/common/command.c index aa0fb0a..9827c70 100644 --- a/common/command.c +++ b/common/command.c @@ -526,7 +526,7 @@ enum command_ret_t cmd_process(int flag, int argc, char * const argv[], if (argc cmdtp-maxargs) rc = CMD_RET_USAGE; -#if defined(CONFIG_CMD_BOOTD) +#ifdef CONFIG_CMD_BOOTD Unrelated style change. Yep, it came from earlier version. Will fix. -#ifdef CONFIG_BOOTP_VCI_STRING +#if defined(CONFIG_BOOTP_VCI_STRING) || \ + (defined(CONFIG_SPL_BUILD) defined(CONFIG_SPL_NET_VCI_STRING)) +#ifndef CONFIG_SPL_BUILD Don't use negative logic for no reason. Ok, Will fix. put_vci(e, CONFIG_VCI_STRING); +#else + put_vci(e, CONFIG_SPL_NET_VCI_STRING); +#endif #endif #if defined(CONFIG_BOOTP_SUBNETMASK) diff --git a/net/net.c b/net/net.c index e8ff066..bbd1a6d 100644 --- a/net/net.c +++ b/net/net.c @@ -81,6 +81,19 @@ #include common.h +#ifdef CONFIG_SPL_BUILD +/* SPL needs only BOOTP + TFTP so undefine other stuff to save space */ +#undef CONFIG_CMD_DHCP +#undef CONFIG_CMD_CDP +#undef CONFIG_CMD_DNS +#undef CONFIG_CMD_LINK_LOCAL +#undef CONFIG_CMD_NFS +#undef CONFIG_CMD_PING +#undef CONFIG_CMD_RARP +#undef CONFIG_CMD_SNTP +#undef CONFIG_CMD_TFTPPUT +#undef CONFIG_CMD_TFTPSRV +#endif Is this the best place to do this? Seems it would be clearer to modify config_cmd_default.h or add a config_cmd_spl.h that will undefine them, and include that. I agree it's not the best place... config_cmd_spl.h sounds a little bit crazy as we don't have any commands at all in SPL... Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [i2c] Pull request
Hello Tom, The following changes since commit a6f0c4faa4c65a7b7048b12c9d180d7e1aad1721: Merge branch 'master' of git://git.denx.de/u-boot-avr32 (2012-09-04 09:17:27 +0200) are available in the git repository at: git://git.denx.de/u-boot-i2c.git master Koen Kooi (1): omap4 i2c: add support for i2c bus 4 Łukasz Majewski (2): i2c:soft:multi: Support for multiple soft I2C buses at Samsung boards i2c:soft:multi: Enable soft I2C multibus at Trats development board arch/arm/include/asm/arch-omap4/cpu.h |1 + arch/arm/include/asm/arch-omap4/i2c.h |2 +- board/samsung/common/Makefile | 43 ++ board/samsung/common/multi_i2c.c | 65 + board/samsung/trats/trats.c | 15 drivers/i2c/omap24xx_i2c.c|8 include/configs/trats.h | 24 + include/i2c.h | 12 ++ 8 files changed, 162 insertions(+), 8 deletions(-) create mode 100644 board/samsung/common/Makefile create mode 100644 board/samsung/common/multi_i2c.c bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 41/71] serial: arm: Implement CONFIG_SERIAL_MULTI into atmel serial driver
Dear Andreas Bießmann,
Dear Marek Vasut,
I have to admit that when reading this patch I got attention of your
UDM-serial.txt for the first time. However when reading this patch some
questions come to my mind.
[...]
-void serial_setbrg(void)
+static void atmel_serial_setbrg(void)
{
atmel_usart3_t *usart = (atmel_usart3_t *)CONFIG_USART_BASE;
shouldn't this USART_BASE be carried by the driver struct in some way? I
wonder how one should implement multiple interfaces later on with this
atmel_serial_xx(void) interface.
We can't rework the whole stdio/serial subsystem right away. All such calls
(serial_setbrg, serial_putc etc) will be augmented by one more parameter to
push
such information through at runtime. This will be done in subsequent patch,
stage 1 in only a preparation stage.
unsigned long divisor;
@@ -45,7 +47,7 @@ void serial_setbrg(void)
writel(USART3_BF(CD, divisor), usart-brgr);
}
-int serial_init(void)
+static int atmel_serial_init(void)
{
atmel_usart3_t *usart = (atmel_usart3_t *)CONFIG_USART_BASE;
@@ -73,7 +75,7 @@ int serial_init(void)
return 0;
}
-void serial_putc(char c)
+static void atmel_serial_putc(char c)
{
atmel_usart3_t *usart = (atmel_usart3_t *)CONFIG_USART_BASE;
@@ -84,13 +86,13 @@ void serial_putc(char c)
writel(c, usart-thr);
}
-void serial_puts(const char *s)
+static void atmel_serial_puts(const char *s)
{
while (*s)
serial_putc(*s++);
}
I have seen this one in a lot of drivers ... shouldn't we build a
generic one?
Indeed, but only in stage 2 or somewhere later ... I have that in mind, but the
serial subsystem needs a bit of a patching for that.
-int serial_getc(void)
+static int atmel_serial_getc(void)
{
atmel_usart3_t *usart = (atmel_usart3_t *)CONFIG_USART_BASE;
@@ -99,8 +101,61 @@ int serial_getc(void)
return readl(usart-rhr);
}
-int serial_tstc(void)
+static int atmel_serial_tstc(void)
{
atmel_usart3_t *usart = (atmel_usart3_t *)CONFIG_USART_BASE;
return (readl(usart-csr) USART3_BIT(RXRDY)) != 0;
}
+
+#ifdef CONFIG_SERIAL_MULTI
+static struct serial_device atmel_serial_drv = {
+ .name = atmel_serial,
even though here is just one instance shouldn't the name reflect the
multiplicity of this driver (e.g. 'atmel_serial0')?
This is the name of the driver, not the name of the instance of the driver. I'd
like to add .id field later on.
+ .start = atmel_serial_init,
+ .stop = NULL,
+ .setbrg = atmel_serial_setbrg,
+ .putc = atmel_serial_putc,
+ .puts = atmel_serial_puts,
+ .getc = atmel_serial_getc,
+ .tstc = atmel_serial_tstc,
As I understand this struct we need a start/stop/setbgr/... for each
instance we build.
No, this isn't instance. This are driver ops combined with it's name. I can not
split it yet.
Shouldn't we carry some void* private in this struct instead (I have
none seen in '[PATCH 01/71] serial: Coding style cleanup of struct
serial_device') to be able to reuse the interface with multiple
instances of the same driver class?
Yes, but not now, not yet. I'm trying to keep this changes incremental as much
as possible.
I think this is my main objection to this structure. I wonder how
existing SERIAL_MULTI implementations handle the need of private driver
information bound to an instance.
They have multiple drivers so far and a default_serial_console call. That is
indeed stupid, but fixing this is not part of this patchset, but a subsequent
one. This one is only a preparation, trying not to break anything and unify the
drivers under the serial_multi api, so the further stages can easily continue
reworking it.
Best regards
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 41/71] serial: arm: Implement CONFIG_SERIAL_MULTI into atmel serial driver
Dear Marek Vasut,
On 17.09.2012 12:00, Marek Vasut wrote:
Dear Andreas Bießmann,
Dear Marek Vasut,
I have to admit that when reading this patch I got attention of your
UDM-serial.txt for the first time. However when reading this patch some
questions come to my mind.
[...]
-void serial_setbrg(void)
+static void atmel_serial_setbrg(void)
{
atmel_usart3_t *usart = (atmel_usart3_t *)CONFIG_USART_BASE;
shouldn't this USART_BASE be carried by the driver struct in some way? I
wonder how one should implement multiple interfaces later on with this
atmel_serial_xx(void) interface.
We can't rework the whole stdio/serial subsystem right away. All such calls
(serial_setbrg, serial_putc etc) will be augmented by one more parameter to
push
such information through at runtime. This will be done in subsequent patch,
stage 1 in only a preparation stage.
Ok.
snip
-void serial_puts(const char *s)
+static void atmel_serial_puts(const char *s)
{
while (*s)
serial_putc(*s++);
}
I have seen this one in a lot of drivers ... shouldn't we build a
generic one?
Indeed, but only in stage 2 or somewhere later ... I have that in mind, but
the
serial subsystem needs a bit of a patching for that.
Ok.
snip
+
+#ifdef CONFIG_SERIAL_MULTI
+static struct serial_device atmel_serial_drv = {
+ .name = atmel_serial,
even though here is just one instance shouldn't the name reflect the
multiplicity of this driver (e.g. 'atmel_serial0')?
This is the name of the driver, not the name of the instance of the driver.
I'd
like to add .id field later on.
Ah, ok. Sounds good.
+ .start = atmel_serial_init,
+ .stop = NULL,
+ .setbrg = atmel_serial_setbrg,
+ .putc = atmel_serial_putc,
+ .puts = atmel_serial_puts,
+ .getc = atmel_serial_getc,
+ .tstc = atmel_serial_tstc,
As I understand this struct we need a start/stop/setbgr/... for each
instance we build.
No, this isn't instance. This are driver ops combined with it's name. I can
not
split it yet.
Shouldn't we carry some void* private in this struct instead (I have
none seen in '[PATCH 01/71] serial: Coding style cleanup of struct
serial_device') to be able to reuse the interface with multiple
instances of the same driver class?
Yes, but not now, not yet. I'm trying to keep this changes incremental as
much
as possible.
I think this is my main objection to this structure. I wonder how
existing SERIAL_MULTI implementations handle the need of private driver
information bound to an instance.
They have multiple drivers so far and a default_serial_console call. That is
indeed stupid, but fixing this is not part of this patchset, but a subsequent
one. This one is only a preparation, trying not to break anything and unify
the
drivers under the serial_multi api, so the further stages can easily continue
reworking it.
Understood, I'm fine with it. I will run a test on avr32/some at91 board
these days and send my ACK then.
Best regards
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 41/71] serial: arm: Implement CONFIG_SERIAL_MULTI into atmel serial driver
Dear Andreas Bießmann, [...] They have multiple drivers so far and a default_serial_console call. That is indeed stupid, but fixing this is not part of this patchset, but a subsequent one. This one is only a preparation, trying not to break anything and unify the drivers under the serial_multi api, so the further stages can easily continue reworking it. Understood, I'm fine with it. I will run a test on avr32/some at91 board these days and send my ACK then. Thank you! Please note, I have the subsequent stages planned and some already being worked on, but please let's wait with them until this gets into -next. Best regards Andreas Bießmann 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] mx28evk: extend default environment
On 15/09/2012 20:26, Otavio Salvador wrote:
The environment has been based on mx53loco and m28evk but keeping the
possibility to easy change the default console device as Freescale and
mainline kernels differ on the device name.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
include/configs/mx28evk.h | 82
-
1 file changed, 74 insertions(+), 8 deletions(-)
diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index 43b4002..dffb744 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -239,7 +239,6 @@
#define CONFIG_SETUP_MEMORY_TAGS
#define CONFIG_BOOTDELAY 3
#define CONFIG_BOOTFILE uImage
-#define CONFIG_BOOTCOMMAND run bootcmd_net
#define CONFIG_LOADADDR 0x4200
#define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR
#define CONFIG_OF_LIBFDT
@@ -248,13 +247,80 @@
* Extra Environments
*/
#define CONFIG_EXTRA_ENV_SETTINGS \
- console_fsl=console=ttyAM0 \
- console_mainline=console=ttyAMA0 \
- netargs=setenv bootargs console=${console_mainline} \
+ update_nand_full_filename=u-boot.nand\0 \
+ update_nand_firmware_filename=u-boot.sb\0 \
+ update_sd_firmware_filename=u-boot.sd\0 \
+ update_nand_firmware_maxsz=0x10\0 \
+ update_nand_stride=0x40\0 /* MX28 datasheet ch. 12.12 */ \
+ update_nand_count=0x4\0 /* MX28 datasheet ch. 12.12 */ \
+ update_nand_get_fcb_size= /* Get size of FCB blocks */ \
+ nand device 0 ; \
+ nand info ; \
+ setexpr fcb_sz ${update_nand_stride} * ${update_nand_count}; \
+ setexpr update_nand_fcb ${fcb_sz} * ${nand_writesize}\0 \
+ update_nand_full= /* Update FCB, DBBT and FW */ \
+ if tftp ${update_nand_full_filename} ; then \
+ run update_nand_get_fcb_size ; \
+ nand scrub -y 0x0 ${filesize} ; \
+ nand write.raw ${loadaddr} 0x0 ${update_nand_fcb} ; \
+ setexpr update_off ${loadaddr} + ${update_nand_fcb} ; \
+ setexpr update_sz ${filesize} - ${update_nand_fcb} ; \
+ nand write ${update_off} ${update_nand_fcb} ${update_sz} ; \
+ fi\0 \
+ update_nand_firmware= /* Update only firmware */ \
+ if tftp ${update_nand_firmware_filename} ; then \
+ run update_nand_get_fcb_size ; \
+ setexpr fcb_sz ${update_nand_fcb} * 2 ; /* FCB + DBBT */ \
+ setexpr fw_sz ${update_nand_firmware_maxsz} * 2 ; \
+ setexpr fw_off ${fcb_sz} + ${update_nand_firmware_maxsz}; \
+ nand erase ${fcb_sz} ${fw_sz} ; \
+ nand write ${loadaddr} ${fcb_sz} ${filesize} ; \
+ nand write ${loadaddr} ${fw_off} ${filesize} ; \
+ fi\0 \
+ update_sd_firmware= /* Update the SD firmware partition */ \
+ if mmc rescan ; then \
+ if tftp ${update_sd_firmware_filename} ; then \
+ setexpr fw_sz ${filesize} / 0x200 ; /* SD block size */ \
+ setexpr fw_sz ${fw_sz} + 1 ; \
+ mmc write ${loadaddr} 0x800 ${fw_sz} ; \
+ fi ; \
+ fi\0 \
+ script=boot.scr\0 \
+ uimage=uImage\0 \
+ console_fsl=ttyAM0\0 \
+ console_mainline=ttyAMA0\0 \
+ mmcdev=0\0 \
+ mmcpart=2\0 \
+ mmcroot=/dev/mmcblk0p3 rw\0 \
+ mmcrootfstype=ext3 rootwait\0 \
+ mmcargs=setenv bootargs console=${console_mainline},${baudrate} \
+ root=${mmcroot} \
+ rootfstype=${mmcrootfstype}\0 \
+ loadbootscript= \
+ fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0 \
+ bootscript=echo Running bootscript from mmc ...; \
+ source\0 \
+ loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0 \
+ mmcboot=echo Booting from mmc ...; \
+ run mmcargs; \
+ bootm\0 \
+ netargs=setenv bootargs console=${console_mainline},${baudrate} \
root=/dev/nfs \
- ip=dhcp nfsroot=${serverip}:${nfsroot}\0 \
- bootcmd_net=echo Booting from net ...; \
- run netargs; \
- dhcp ${uimage}; bootm\0 \
+ ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0 \
+ netboot=echo Booting from net ...; \
+ run netargs; \
+ dhcp ${uimage}; bootm\0
+
+#define CONFIG_BOOTCOMMAND \
+ if mmc rescan ${mmcdev}; then \
+ if run loadbootscript; then \
+ run bootscript; \
+ else \
+ if run loaduimage; then \
+ run mmcboot; \
+ else run netboot; \
+ fi; \
+ fi; \
+ else run netboot; fi
#endif /* __MX28EVK_CONFIG_H__ */
Any issue why I should not merge
Re: [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
Hi Marek,
On 14-09-2012 19:21, Marek Vasut wrote:
Dear José Miguel Gonçalves,
NAND Flash driver with HW ECC for the S3C24XX SoCs.
Currently it only supports SLC NAND chips.
Signed-off-by: José Miguel Gonçalves jose.goncal...@inov.pt
[...]
+#include common.h
+#include nand.h
+#include asm/io.h
+#include asm/arch/s3c24xx_cpu.h
+#include asm/errno.h
+
+#define MAX_CHIPS 2
+static int nand_cs[MAX_CHIPS] = { 0, 1 };
+
+#ifdef CONFIG_SPL_BUILD
+#define printf(arg...) do {} while (0)
This doesn't seem quite right ...
1) this should be in CPU directory
2) should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
3) should be inline function, not a macro
I'm having difficulties in following this suggestion. No problem if I migrate the
printf as a macro to a header in the CPU directory. The problem is when I try to
put it as an inline function. In this case if I define it like this;
#ifdef CONFIG_SPL_BUILD
static inline int printf(const char *fmt, ...)
{
return 0;
}
#endif
I will get an static declaration of `printf' follows non-static declaration
error due to the printf() declaration in common.h.
If I put this inline printf function (without the static) in a .c file in the CPU
directory, it will compile but, as I expected, it will not be inlined, but it will
be compiled as a normal function.
Can you detail on how to do this?
Best regards,
José Gonçalves
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx35pdk: README: Remove NAND references
On 15/09/2012 00:14, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com Booting from NAND is currently not supported, so remove its references. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Applied to u-boot-imx, thanks to drop the confusion ! 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 v2 1/2] mx6q: Factor out common DDR3 init code
On 13/09/2012 15:18, Fabio Estevam wrote: Factor out common DDR3 initialization code, allowing easier maintainance of such scripts. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Applied to u-boot-imx, next branch. 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 6/6] arm: exynos4: universal_C210: add display support
Dear Minkyu,
-Original Message-
From: Minkyu Kang [mailto:proms...@gmail.com]
Sent: Saturday, September 15, 2012 10:46 AM
To: Piotr Wilczek; Donghwa Lee
Cc: u-boot@lists.denx.de; Kyungmin Park
Subject: Re: [U-Boot] [PATCH 6/6] arm: exynos4: universal_C210: add
display support
Dear Piotr,
On 13 September 2012 16:45, Piotr Wilczek p.wilc...@samsung.com
wrote:
This patch add support for display on Universal C210 board.
Width of displayed logo must be not bigger than 480 pixel and is
limited by width of the screen.
Tizen logo size is 520x120 pixels should be reseized to be displayed
corectly on Universal C210.
Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Minkyu Kang mk7.k...@samsung.com
---
board/samsung/universal_c210/universal.c | 225
+++---
include/configs/s5pc210_universal.h | 13 ++
2 files changed, 220 insertions(+), 18 deletions(-)
diff --git a/board/samsung/universal_c210/universal.c
b/board/samsung/universal_c210/universal.c
index 772ade5..da28f7a 100644
--- a/board/samsung/universal_c210/universal.c
+++ b/board/samsung/universal_c210/universal.c
+static void init_pmic_lcd(void)
+{
+ unsigned char val;
+ int ret = 0;
+
+ struct pmic *p = get_pmic();
+
+ if (pmic_probe(p))
+ return;
+
+ /* LDO7 1.8V */
+ val = 0x02; /* (1800 - 1600) / 100; */
+ ret |= pmic_reg_write(p, MAX8998_REG_LDO7, val);
+
+ /* LDO17 3.0V */
+ val = 0xe; /* (3000 - 1600) / 100; */
+ ret |= pmic_reg_write(p, MAX8998_REG_LDO17, val);
+
+ /* Disable unneeded regulators */
+ /*
+* ONOFF1
+* Buck1 ON, Buck2 OFF, Buck3 ON, Buck4 ON
+* LDO2 ON, LDO3 OFF, LDO4 OFF, LDO5 ON
+*/
+ val = 0xB9;
+ ret |= pmic_reg_write(p, MAX8998_REG_ONOFF1, val);
+
+ /* ONOFF2
+* LDO6 OFF, LDO7 ON, LDO8 OFF, LDO9 ON,
+* LDO10 OFF, LDO11 OFF, LDO12 OFF, LDO13 OFF
+*/
+ val = 0x50;
+ ret |= pmic_reg_write(p, MAX8998_REG_ONOFF2, val);
+
+ /* ONOFF3
+* LDO14 OFF, LDO15 OFF, LGO16 OFF, LDO17 OFF
+* EPWRHOLD OFF, EBATTMON OFF, ELBCNFG2 OFF, ELBCNFG1 OFF
+*/
+ val = 0x00;
+ ret |= pmic_reg_write(p, MAX8998_REG_ONOFF3, val);
+
+ if (ret)
+ puts(LCD pmic initialisation error!\n); }
+
+static void fimd_clk_set(void)
+{
+ unsigned int cfg = 0;
+
+ /* LCD0_BLK FIFO S/W reset */
+ cfg = readl(EXYNOS4_DISPLAY_CONTROL);
+ cfg |= EXYNOS_DISPLAYCONTROL_FIFORST_LBLK0;
+ writel(cfg, EXYNOS4_DISPLAY_CONTROL);
+
+ cfg = 0;
+
+ /* FIMD of LBLK0 Bypass Selection */
+ cfg = readl(EXYNOS4_DISPLAY_CONTROL);
+ cfg = ~EXYNOS_DISPLAYCONTROL_FIFORST_LBLK0;
+ cfg |= EXYNOS_DISPLAYCONTROL_FIMDBYPASS_LBLK0;
+ writel(cfg, EXYNOS4_DISPLAY_CONTROL);
No..
We don't allow direct access.
And this function looks same with exynos4_set_system_display.
Ok, I will fix it.
+}
+
+static void lcd_cfg_gpio(void)
+{
+ unsigned int i, f3_end = 4;
+
+ for (i = 0; i 8; i++) {
+ /* set GPF0,1,2[0:7] for RGB Interface and Data lines
(32bit) */
+ s5p_gpio_cfg_pin(gpio1-f0, i, GPIO_FUNC(2));
+ s5p_gpio_cfg_pin(gpio1-f1, i, GPIO_FUNC(2));
+ s5p_gpio_cfg_pin(gpio1-f2, i, GPIO_FUNC(2));
+ /* pull-up/down disable */
+ s5p_gpio_set_pull(gpio1-f0, i, GPIO_PULL_NONE);
+ s5p_gpio_set_pull(gpio1-f1, i, GPIO_PULL_NONE);
+ s5p_gpio_set_pull(gpio1-f2, i, GPIO_PULL_NONE);
+
+ /* drive strength to max (24bit) */
+ s5p_gpio_set_drv(gpio1-f0, i, GPIO_DRV_4X);
+ s5p_gpio_set_rate(gpio1-f0, i, GPIO_DRV_SLOW);
+ s5p_gpio_set_drv(gpio1-f1, i, GPIO_DRV_4X);
+ s5p_gpio_set_rate(gpio1-f1, i, GPIO_DRV_SLOW);
+ s5p_gpio_set_drv(gpio1-f2, i, GPIO_DRV_4X);
+ s5p_gpio_set_rate(gpio1-f0, i, GPIO_DRV_SLOW);
+ }
+
+ for (i = 0; i f3_end; i++) {
+ /* set GPF3[0:3] for RGB Interface and Data lines
(32bit) */
+ s5p_gpio_cfg_pin(gpio1-f3, i, GPIO_FUNC(2));
+ /* pull-up/down disable */
+ s5p_gpio_set_pull(gpio1-f3, i, GPIO_PULL_NONE);
+ /* drive strength to max (24bit) */
+ s5p_gpio_set_drv(gpio1-f3, i, GPIO_DRV_4X);
+ s5p_gpio_set_rate(gpio1-f3, i, GPIO_DRV_SLOW);
+ }
+
+ /* gpio pad configuration for LCD reset. */
+ s5p_gpio_cfg_pin(gpio2-y4, 5, GPIO_OUTPUT);
+
+ spi_init();
+
+ return;
Please remove this return.
Ok.
Re: [U-Boot] AR8031 Ethernet on mx6
Hi Dirk, On Mon, Sep 17, 2012 at 5:44 AM, Dirk Behme dirk.be...@de.bosch.com wrote: Trying the recent mainline U-Boot (a6f0c4faa4c65a7b7048b) on an ARM2 board we get [1] after manually setting an ethaddr and the IP addresses. Thanks for confirming that Ethernet works on mx6qarm2. I will debug more on mx6qsabresd then. Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm:exynos4:universal_c210: implement software SPI
Dear Minkyu,
-Original Message-
From: Minkyu Kang [mailto:proms...@gmail.com]
Sent: Saturday, September 15, 2012 11:06 AM
To: Piotr Wilczek
Cc: u-boot@lists.denx.de; Kyungmin Park
Subject: Re: [U-Boot] [PATCH] arm:exynos4:universal_c210: implement
software SPI
Dear Piotr,
On 29 August 2012 17:15, Piotr Wilczek p.wilc...@samsung.com wrote:
This patch implements software SPI for the universal C210 board.
Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Minkyu Kang mk7.k...@samsung.com
CC: Wolfgang Denk w...@denx.de
CC: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
board/samsung/universal_c210/universal.c | 36
++
drivers/spi/soft_spi.c |7 +-
include/configs/s5pc210_universal.h | 19 +++
3 files changed, 61 insertions(+), 1 deletions(-)
diff --git a/board/samsung/universal_c210/universal.c
b/board/samsung/universal_c210/universal.c
index 8a114e6..772ade5 100644
--- a/board/samsung/universal_c210/universal.c
+++ b/board/samsung/universal_c210/universal.c
@@ -24,6 +24,7 @@
#include common.h
#include asm/io.h
+#include spi.h
#include asm/arch/adc.h
#include asm/arch/gpio.h
#include asm/arch/mmc.h
@@ -34,6 +35,10 @@
#include max8998_pmic.h
#include asm/arch/watchdog.h
+#if defined(CONFIG_SOFT_SPI)
+# include asm/gpio.h
remove space between # and include.
Ok.
+#endif
+
DECLARE_GLOBAL_DATA_PTR;
struct exynos4_gpio_part1 *gpio1;
@@ -288,3 +293,34 @@ int board_early_init_f(void)
return 0;
}
+
+void soft_spi_init()
+{
+ gpio_direction_output(CONFIG_SOFT_SPI_GPIO_SCLK,
+ CONFIG_SOFT_SPI_MODE SPI_CPOL);
+ gpio_direction_output(CONFIG_SOFT_SPI_GPIO_MOSI, 1);
+ gpio_direction_input(CONFIG_SOFT_SPI_GPIO_MISO);
+ gpio_direction_output(CONFIG_SOFT_SPI_GPIO_CS,
+ !(CONFIG_SOFT_SPI_MODE SPI_CS_HIGH)); }
+
+void spi_cs_activate(struct spi_slave *slave) {
+ gpio_set_value(CONFIG_SOFT_SPI_GPIO_CS,
+ !(CONFIG_SOFT_SPI_MODE SPI_CS_HIGH));
+ SPI_SCL(1);
+ gpio_set_value(CONFIG_SOFT_SPI_GPIO_CS,
+ CONFIG_SOFT_SPI_MODE SPI_CS_HIGH); }
+
+void spi_cs_deactivate(struct spi_slave *slave) {
+ gpio_set_value(CONFIG_SOFT_SPI_GPIO_CS,
+ !(CONFIG_SOFT_SPI_MODE SPI_CS_HIGH)); }
+
+int spi_cs_is_valid(unsigned int bus, unsigned int cs) {
+ return 1;
always return 1?
I can change that it would return 1 only if bus==0 and cs==0.
+}
+
diff --git a/drivers/spi/soft_spi.c b/drivers/spi/soft_spi.c index
13df8cb..a0a3012 100644
--- a/drivers/spi/soft_spi.c
+++ b/drivers/spi/soft_spi.c
@@ -29,6 +29,10 @@
#include malloc.h
+#if defined(CONFIG_SOFT_SPI)
+# include asm/gpio.h
+#endif
+
/*--
-
* Definitions
*/
@@ -59,8 +63,9 @@ static inline struct soft_spi_slave
*to_soft_spi(struct spi_slave *slave) void spi_init (void) {
#ifdef
SPI_INIT
+#ifdef CONFIG_SYS_IMMR
volatile immap_t *immr = (immap_t *)CONFIG_SYS_IMMR;
-
+#endif
Is it related change with this patch?
Yes, it is necessary to successfully compile.
SPI_INIT;
#endif
}
diff --git a/include/configs/s5pc210_universal.h
b/include/configs/s5pc210_universal.h
index 7978317..a338840 100644
--- a/include/configs/s5pc210_universal.h
+++ b/include/configs/s5pc210_universal.h
@@ -266,4 +266,23 @@
#define CONFIG_USB_GADGET_S3C_UDC_OTG #define
CONFIG_USB_GADGET_DUALSPEED
+/*
+ * SPI Settings
+ */
+#define CONFIG_SOFT_SPI
+#define CONFIG_SOFT_SPI_MODE SPI_MODE_3 #define
+CONFIG_SOFT_SPI_GPIO_SCLK exynos4_gpio_part2_get_nr(y3, 1) #define
+CONFIG_SOFT_SPI_GPIO_MOSI exynos4_gpio_part2_get_nr(y3, 3) #define
+CONFIG_SOFT_SPI_GPIO_MISO exynos4_gpio_part2_get_nr(y3, 0) #define
+CONFIG_SOFT_SPI_GPIO_CS exynos4_gpio_part2_get_nr(y4, 3)
+
+#define SPI_DELAY udelay(1)
+#define SPI_INIT soft_spi_init()
+#define SPI_SCL(bit) gpio_set_value(CONFIG_SOFT_SPI_GPIO_SCLK, bit)
+#define SPI_SDA(bit) gpio_set_value(CONFIG_SOFT_SPI_GPIO_MOSI, bit)
+#define SPI_READ gpio_get_value(CONFIG_SOFT_SPI_GPIO_MISO)
+#ifndef__ASSEMBLY__
+void soft_spi_init(void);
+#endif
+
#endif /* __CONFIG_H */
--
1.7.5.4
Thanks.
Minkyu Kang.
--
from. prom.
www.promsoft.net
Best regards,
Piotr Wilczek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] Pull request: u-boot-imx
Hi Albert,
please pull from u-boot-imx, thanks.
The following changes since commit a9f1a4893364ddbb8b7942cded91d4c17c4f5948:
lsxl: support power switch (2012-09-03 17:48:51 +0530)
are available in the git repository at:
git://www.denx.de/git/u-boot-imx.git master
for you to fetch changes up to 1d9b033269263a69f7402f508c17b242fc7fea43:
mx35pdk: README: Remove NAND references (2012-09-17 13:17:17 +0200)
Ashok Kumar Reddy (2):
ima3-mx53:Rename CONFIG_PRIME = CONFIG_ETHPRME, remove
mx6qsabrelite:Use IMX_GPIO_NR Macro
Benoît Thébaudeau (8):
mx35: Fix decode_pll
mx35: Add definitions for clock gate values
mx35: Fix clock dividers
mx25: Define default SoC input clock frequencies
mx35: Define default SoC input clock frequencies
mx35 timer: Switch to 32-kHz source
Fix mx31_decode_pll
mx31: Define default SoC input clock frequencies
Fabio Estevam (3):
mx28evk: Convert to mxs_adjust_memory_params()
mx28evk: Add USB Ethernet support
mx35pdk: README: Remove NAND references
Marek Vasut (7):
M28: Fix the use of gpmi-nand in mtdparts
MX28: Cleanup mxsboot within make mrproper
MX28: Fixup the ad-hoc use of DIGCTL_MICROSECONDS
SCSPS1: Enable caches
MX28: SPI: Fix the DMA DCache race condition
MX28: SPI: Fix the DMA chaining
MX28: MMC: Avoid DMA DCache race condition
Matt Sealey (1):
efikamx: refine USB support
Otavio Salvador (3):
MX28: mx28evk: Align SSP clock speed
MX28: mx28evk: Enable SPI DMA
mx28evk: extend default environment
Stefano Babic (3):
MX: set a common place to share code for Freescale i.MX
MX35: mx35pdk: add support for MMC
MX6: drop binary constants from iomux header
Makefile |8 +-
arch/arm/cpu/arm1136/mx31/generic.c| 12 +-
arch/arm/cpu/arm1136/mx31/timer.c | 16 +--
arch/arm/cpu/arm1136/mx35/generic.c| 90 ++
arch/arm/cpu/arm1136/mx35/timer.c | 46 +---
arch/arm/cpu/arm926ejs/mx25/generic.c |2 +-
arch/arm/cpu/arm926ejs/mx25/timer.c| 16 +--
arch/arm/cpu/arm926ejs/mxs/spl_boot.c |8 +-
arch/arm/{cpu/armv7 = }/imx-common/Makefile |4 +-
arch/arm/{cpu/armv7 = }/imx-common/cmd_bmode.c|0
arch/arm/{cpu/armv7 = }/imx-common/cpu.c |0
.../imx-common/i2c.c = imx-common/i2c-mxv7.c} |0
arch/arm/{cpu/armv7 = }/imx-common/iomux-v3.c |0
arch/arm/{cpu/armv7 = }/imx-common/speed.c|0
arch/arm/{cpu/armv7 = }/imx-common/timer.c|0
arch/arm/include/asm/arch-mx25/clock.h | 14 +++
arch/arm/include/asm/arch-mx31/clock.h | 14 +++
arch/arm/include/asm/arch-mx35/clock.h | 14 +++
arch/arm/include/asm/arch-mx35/crm_regs.h | 48 +++-
arch/arm/include/asm/arch-mx6/iomux.h | 124
++--
board/freescale/mx28evk/iomux.c|2 +-
board/freescale/mx28evk/mx28evk.c |4 +-
board/freescale/mx35pdk/README | 78 +---
board/freescale/mx35pdk/mx35pdk.c | 25
board/freescale/mx6qsabrelite/mx6qsabrelite.c | 24 ++--
board/genesi/mx51_efikamx/Makefile |6 +-
board/genesi/mx51_efikamx/efikamx-usb.c| 12 ++
board/genesi/mx51_efikamx/efikamx.c|3 -
drivers/mmc/mxsmmc.c |4 +
drivers/spi/mxs_spi.c | 58 +
include/configs/flea3.h|1 -
include/configs/ima3-mx53.h|3 +-
include/configs/imx31_litekit.h|1 -
include/configs/imx31_phycore.h|1 -
include/configs/m28evk.h |4 +-
include/configs/mx25pdk.h |1 -
include/configs/mx28evk.h | 86 --
include/configs/mx31ads.h |2 -
include/configs/mx31pdk.h |2 -
include/configs/mx35pdk.h | 18 ++-
include/configs/qong.h |2 -
include/configs/sc_sps_1.h |2 -
include/configs/tt01.h |2 -
include/configs/zmx25.h|1 -
44 files changed, 409 insertions(+), 349 deletions(-)
rename arch/arm/{cpu/armv7 = }/imx-common/Makefile (94%)
rename arch/arm/{cpu/armv7 = }/imx-common/cmd_bmode.c (100%)
rename arch/arm/{cpu/armv7 = }/imx-common/cpu.c (100%)
rename arch/arm/{cpu/armv7/imx-common/i2c.c = imx-common/i2c-mxv7.c}
(100%)
rename arch/arm/{cpu/armv7 = }/imx-common/iomux-v3.c (100%)
rename
Re: [U-Boot] [PATCH 50/71] serial: arm: Implement CONFIG_SERIAL_MULTI into imx serial driver
On 17/09/2012 01:21, Marek Vasut wrote: Implement support for CONFIG_SERIAL_MULTI into imx serial driver. This driver was so far only usable directly, but this patch also adds support for the multi method. This allows using more than one serial driver alongside the imx driver. Also, add a weak implementation of default_serial_console() returning this driver. Signed-off-by: Marek Vasut ma...@denx.de Cc: Marek Vasut marek.va...@gmail.com Cc: Tom Rini tr...@ti.com Cc: Stefano Babic sba...@denx.de --- Hi Marek, I have later realized that you pushed this series for u-boot-dm and not u-boot. Anyway, is there some reason to prohibit to merge them directly into mainline ? I do not see any special DM code here. Regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 50/71] serial: arm: Implement CONFIG_SERIAL_MULTI into imx serial driver
Dear Stefano Babic, On 17/09/2012 01:21, Marek Vasut wrote: Implement support for CONFIG_SERIAL_MULTI into imx serial driver. This driver was so far only usable directly, but this patch also adds support for the multi method. This allows using more than one serial driver alongside the imx driver. Also, add a weak implementation of default_serial_console() returning this driver. Signed-off-by: Marek Vasut ma...@denx.de Cc: Marek Vasut marek.va...@gmail.com Cc: Tom Rini tr...@ti.com Cc: Stefano Babic sba...@denx.de --- Hi Marek, I have later realized that you pushed this series for u-boot-dm and not u-boot. This is for U-Boot, I only CCed the cover letter for DM to give'em heads up ;-) Anyway, is there some reason to prohibit to merge them directly into mainline ? I do not see any special DM code here. Nope, this stage 1 is really only support patchset for later stages which will converge this whole subsystem towards easy deployment of DM. Regards, Stefano Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Weekly status
Hey all, I had intended to send this last thing Friday but it slipped my mind. But with my intention to do -rc1 this Friday, this works too. That said... Here's where I'm at so far: - Locally, I believe I have all outstanding pull requets queued up and MAKEALL'd when there's an ELDK toolchain. - Working out the access issues with Detlev. - I've given the first two pages of patchwork a read and assign pass. If you're a custodian I've probably assigned a few patches to you that look like your area. I've also done my best to spot superseded patches and things which have been accepted but I'm sure I missed a few. - If you have assigned me items in patchwork and sent me an email, I have read it and will act on it shortly if I haven't already (just don't want the queue of I have applied this messages locally to get too large). I expect to be able to snap -rc1 on my previously announced schedule. Once I do the usual rules about next will open and I would encourage custodians to open up a next branch as well. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/11] S3C24XX: Add support to MINI2416 board
On Sun, Sep 16, 2012 at 10:11:07AM +0100, Jos? Miguel Gon?alves wrote: On 09/14/2012 07:58 PM, Tom Rini wrote: On Fri, Sep 14, 2012 at 06:29:02PM +0100, Jos?? Miguel Gon??alves wrote: The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM, 256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC. This U-Boot port was implemented and tested on a unit bought to Boardcon (http://www.armdesigner.com/) but there are some other chinese providers that can supply it with a selectable NAND chip from 128MB to 1GB. [snip] Can you please try this on top of my SPL framework series? Thanks! I thought I was using the latest SPL framework! Can you please detail on what I should do different? Please see http://www.mail-archive.com/u-boot@lists.denx.de/msg92156.html -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
On Mon, Sep 17, 2012 at 10:24:34AM +0100, Jos?? Miguel Gon??alves wrote:
On 09/17/2012 10:10 AM, Christian Riesch wrote:
On Mon, Sep 17, 2012 at 10:30 AM, Jos?? Miguel Gon??alves
jose.goncal...@inov.pt wrote:
On 09/17/2012 07:47 AM, Christian Riesch wrote:
Hi,
On Sun, Sep 16, 2012 at 11:27 AM, Jos?? Miguel Gon??alves
jose.goncal...@inov.pt wrote:
On 09/14/2012 08:08 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel Gon??alves wrote:
Samsung's S3C24XX SoCs need this in order to generate a binary image
with the SPL and U-Boot concatenated.
Signed-off-by: Jos?? Miguel Gon??alves jose.goncal...@inov.pt
---
Changes for v2:
- None
---
Makefile |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 058fb53..595b5f6 100644
--- a/Makefile
+++ b/Makefile
@@ -442,13 +442,14 @@ $(obj)u-boot.sha1:$(obj)u-boot.bin
$(obj)u-boot.dis: $(obj)u-boot
$(OBJDUMP) -d $ $@
-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
+$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
$(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary
$(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin
$(obj)u-boot-ubl.bin
+ rm $(obj)spl/u-boot-spl-pad.bin
+
+$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin
$(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \
-e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin
$(obj)u-boot.ubl
- rm $(obj)u-boot-ubl.bin
- rm $(obj)spl/u-boot-spl-pad.bin
$(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
$(obj)tools/mkimage -s -n $(if
$(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),/dev/null) \
This diff is hard to read, but what exactly are you changing? The
u-boot-ubl target is also used on TI platforms. It looks like you're
making it such that u-boot-ubl.bin produces the old binary and
u-boot-ubl adds a new target which is the mkimage header on top of the
same bits as before, but without possibly padding the output image. I
suspect in your case you could just set PAD_TO to 8192 in
board/../config.mk and use the existing target.
In the S3C2416 I don't need the mkimage stuff. I only need the raw SPL
image
padded at 8KB concatenated with the standard U-Boot. What I've done was
to
split the existing u-boot-ubl target in two; u-boot-ubl.bin, that I use
to
program the Flash, and u-boot-ubl that remains with the same
functionality
as before, just now it depends on u-boot-ubl.bin.
I think you should drop the UBL names from your padding target
(u-boot-ubl.bin) since this is TI specific, use something more
generic.
I only reused a temporary filename used for the u-boot-ubl target and make
it a new target.
If you think this is not an adequate name, can you suggest a new one?
u-boot.pad? u-boot-pad.bin?
If no one else has anything against, I will change the name of the
new target to u-boot-pad.bin
I think I'm OK with that.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/11] S3C24XX: Add support to MINI2416 board
On 17-09-2012 15:39, Tom Rini wrote: On Sun, Sep 16, 2012 at 10:11:07AM +0100, Jos? Miguel Gon?alves wrote: On 09/14/2012 07:58 PM, Tom Rini wrote: On Fri, Sep 14, 2012 at 06:29:02PM +0100, Jos?? Miguel Gon??alves wrote: The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM, 256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC. This U-Boot port was implemented and tested on a unit bought to Boardcon (http://www.armdesigner.com/) but there are some other chinese providers that can supply it with a selectable NAND chip from 128MB to 1GB. [snip] Can you please try this on top of my SPL framework series? Thanks! I thought I was using the latest SPL framework! Can you please detail on what I should do different? Please see http://www.mail-archive.com/u-boot@lists.denx.de/msg92156.html As this is still not merged, I reckon you only want to check if this new SPL framework works fine with my board. I'm not expected to resubmit my patch to be according with the new framework, correct? Best regards, José Gonçalves ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/11] S3C24XX: Add support to MINI2416 board
On Mon, Sep 17, 2012 at 03:47:46PM +0100, Jos? Miguel Gon?alves wrote: On 17-09-2012 15:39, Tom Rini wrote: On Sun, Sep 16, 2012 at 10:11:07AM +0100, Jos? Miguel Gon?alves wrote: On 09/14/2012 07:58 PM, Tom Rini wrote: On Fri, Sep 14, 2012 at 06:29:02PM +0100, Jos?? Miguel Gon??alves wrote: The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM, 256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC. This U-Boot port was implemented and tested on a unit bought to Boardcon (http://www.armdesigner.com/) but there are some other chinese providers that can supply it with a selectable NAND chip from 128MB to 1GB. [snip] Can you please try this on top of my SPL framework series? Thanks! I thought I was using the latest SPL framework! Can you please detail on what I should do different? Please see http://www.mail-archive.com/u-boot@lists.denx.de/msg92156.html As this is still not merged, I reckon you only want to check if this new SPL framework works fine with my board. I'm not expected to resubmit my patch to be according with the new framework, correct? v1 of your patches was posted well after the merge window for v2012.10 closed. My SPL series will be merged to mainline shortly (taking care of everyone elses merge requests first). So yes, to get into v2013.01 you will need to update. If you check the archives you can see how the altera soc support changed to adapt to this framework. And if there's a shortcoming in the framework, I really do want to know. Thanks! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] tegra: enable lp0 on paz00
Marc, -Original Message- From: Marc Dietrich [mailto:marvi...@gmx.de] Sent: Sunday, September 16, 2012 9:17 AM To: Tom Warren Cc: Stephen Warren; u-boot@lists.denx.de Subject: Re: [PATCH 2/2] tegra: enable lp0 on paz00 Tom, On Monday 10 September 2012 12:32:00 Tom Warren wrote: -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Monday, September 10, 2012 12:08 PM To: Marc Dietrich Cc: u-boot@lists.denx.de; Tom Warren Subject: Re: [PATCH 2/2] tegra: enable lp0 on paz00 On 09/10/2012 12:51 PM, Marc Dietrich wrote: This enables LP0 to support suspend / resume on PAZ00. Ooh. Did you test this out with the AC100 kernel, and have it work? That'd be pretty cool... diff --git a/board/compal/paz00/Makefile b/board/compal/paz00/Makefile -COBJS := $(BOARD).o -COBJS += ../../nvidia/common/board.o +COBJS-y:= $(BOARD).o +COBJS-y+= ../../nvidia/common/board.o +COBJS-$(CONFIG_TEGRA_CLOCK_SCALING) += ../../nvidia/common/emc.o Hmmm. That's odd. I'd expect that to be part of the core Tegra code, rather than something boards have to pull in manually. I checked this again. The Makefile in nvidia/common is never executed on non nvidia boards (it is included from the topdir Makefile ($vendor/common/Makefile). Therefore the explicit COBJS += ../../nvidia/common/board.o in the paz00 Makefile is needed. So either we have to add ../../nvidia/common/foo.o to all non nvidia boards or we source the whole Makefile somehow else. Marc Feel free to submit a patch that does one or the other (patches all non-nvidia Makefiles or sources the whole Makefile). I think I'd prefer the first approach, though it's ugly having ../.. 'reach arounds' in the Makefiles. Once you have a fix, we can discuss its merits and move forward. Thanks, Tom Stephen's right - this is already done in ../cpu/tegra20-common/Makefile when CONFIG_TEGRA_CLOCK_SCALING is defined. So no need to change the PAZ00 Makefile. diff --git a/include/configs/paz00.h b/include/configs/paz00.h +/* LP0 suspend / resume */ +#define CONFIG_TEGRA20_LP0 That's been renamed CONFIG_TEGRA_LP0 in u-boot-tegra/next. As part of the pre-work for Tegra30 changes, I've changed generic Tegra defines, labels, etc. to be more non-specific, unless it does really refer to a Tegra20 feature, file, etc. As Stephen says, see u-boot-tegra/next's top commit. Tom -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
On 09/17/2012 04:24:34 AM, José Miguel Gonçalves wrote:
On 09/17/2012 10:10 AM, Christian Riesch wrote:
On Mon, Sep 17, 2012 at 10:30 AM, José Miguel Gonçalves
jose.goncal...@inov.pt wrote:
On 09/17/2012 07:47 AM, Christian Riesch wrote:
Hi,
On Sun, Sep 16, 2012 at 11:27 AM, José Miguel Gonçalves
jose.goncal...@inov.pt wrote:
On 09/14/2012 08:08 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel
Gon??alves wrote:
Samsung's S3C24XX SoCs need this in order to generate a binary
image
with the SPL and U-Boot concatenated.
Signed-off-by: Jos?? Miguel Gon??alves jose.goncal...@inov.pt
---
Changes for v2:
- None
---
Makefile |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 058fb53..595b5f6 100644
--- a/Makefile
+++ b/Makefile
@@ -442,13 +442,14 @@ $(obj)u-boot.sha1:$(obj)u-boot.bin
$(obj)u-boot.dis: $(obj)u-boot
$(OBJDUMP) -d $ $@
-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin
$(obj)u-boot.bin
+$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin
$(obj)u-boot.bin
$(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O
binary
$(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
cat $(obj)spl/u-boot-spl-pad.bin
$(obj)u-boot.bin
$(obj)u-boot-ubl.bin
+ rm $(obj)spl/u-boot-spl-pad.bin
+
+$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin
$(obj)tools/mkimage -n $(UBL_CONFIG) -T
ublimage \
-e $(CONFIG_SYS_TEXT_BASE) -d
$(obj)u-boot-ubl.bin
$(obj)u-boot.ubl
- rm $(obj)u-boot-ubl.bin
- rm $(obj)spl/u-boot-spl-pad.bin
$(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin
$(obj)u-boot.bin
$(obj)tools/mkimage -s -n $(if
$(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),/dev/null)
\
This diff is hard to read, but what exactly are you changing?
The
u-boot-ubl target is also used on TI platforms. It looks like
you're
making it such that u-boot-ubl.bin produces the old binary and
u-boot-ubl adds a new target which is the mkimage header on top
of the
same bits as before, but without possibly padding the output
image. I
suspect in your case you could just set PAD_TO to 8192 in
board/../config.mk and use the existing target.
In the S3C2416 I don't need the mkimage stuff. I only need the
raw SPL
image
padded at 8KB concatenated with the standard U-Boot. What I've
done was
to
split the existing u-boot-ubl target in two; u-boot-ubl.bin, that
I use
to
program the Flash, and u-boot-ubl that remains with the same
functionality
as before, just now it depends on u-boot-ubl.bin.
I think you should drop the UBL names from your padding target
(u-boot-ubl.bin) since this is TI specific, use something more
generic.
I only reused a temporary filename used for the u-boot-ubl target
and make
it a new target.
If you think this is not an adequate name, can you suggest a new
one?
u-boot.pad? u-boot-pad.bin?
If no one else has anything against, I will change the name of the
new target to u-boot-pad.bin
What exactly is u-boot-pad.bin supposed to be? I hope that's not being
proposed as the final output file the user sees.
With old nand_spl we had u-boot-nand.bin for the final concatenated
binary, but that's not appropriate for a generic spl. I think it would
be better for the user to see u-boot.bin as the actual image to put
on the boot device, regardless of implementation details like spl, if
there's no requirement of a specific file format. The second stage
could become u-boot-main.bin or similar on builds where spl is used.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
Dear Tom Rini, [...] If no one else has anything against, I will change the name of the new target to u-boot-pad.bin I think I'm OK with that. What about having CPU-overridable targets ? So omap can have it's own .ubl result and commands leading to it ... and so can s3c24xx. Such targets would have to be shifted into CPU-specific dirs, is that possible? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
On 09/17/12 09:29, Marek Vasut wrote: Dear Tom Rini, [...] If no one else has anything against, I will change the name of the new target to u-boot-pad.bin I think I'm OK with that. What about having CPU-overridable targets ? So omap can have it's own .ubl result and commands leading to it ... and so can s3c24xx. Such targets would have to be shifted into CPU-specific dirs, is that possible? The problem I see first is that UBL doesn't seem to mean anything in the context of s3c24xx, it just happens to be doing some of what the system wants. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6: Remove lowlevel_init.S
lowlevel_init.S is not used on mx6, so remove the file and the associated calls. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- arch/arm/cpu/armv7/mx6/Makefile|1 - arch/arm/cpu/armv7/mx6/lowlevel_init.S | 25 - arch/arm/cpu/armv7/start.S | 24 3 files changed, 50 deletions(-) delete mode 100644 arch/arm/cpu/armv7/mx6/lowlevel_init.S diff --git a/arch/arm/cpu/armv7/mx6/Makefile b/arch/arm/cpu/armv7/mx6/Makefile index cbce411..4f9ca68 100644 --- a/arch/arm/cpu/armv7/mx6/Makefile +++ b/arch/arm/cpu/armv7/mx6/Makefile @@ -28,7 +28,6 @@ include $(TOPDIR)/config.mk LIB= $(obj)lib$(SOC).o COBJS = soc.o clock.o -SOBJS = lowlevel_init.o SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) diff --git a/arch/arm/cpu/armv7/mx6/lowlevel_init.S b/arch/arm/cpu/armv7/mx6/lowlevel_init.S deleted file mode 100644 index acadef2..000 --- a/arch/arm/cpu/armv7/mx6/lowlevel_init.S +++ /dev/null @@ -1,25 +0,0 @@ -/* - * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation; either version 2 of - * the License, or (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, - * MA 02111-1307 USA - */ -.section .text.init, x - -#include linux/linkage.h - -ENTRY(lowlevel_init) - mov pc, lr -ENDPROC(lowlevel_init) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 32658eb..4c7c385 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -152,7 +152,6 @@ reset: /* the mask ROM code should have PLL and others stable */ #ifndef CONFIG_SKIP_LOWLEVEL_INIT bl cpu_init_cp15 - bl cpu_init_crit #endif /* Set stackpointer in internal RAM to call board_init_f */ @@ -353,29 +352,6 @@ ENTRY(cpu_init_cp15) mov pc, lr @ back to my caller ENDPROC(cpu_init_cp15) -#ifndef CONFIG_SKIP_LOWLEVEL_INIT -/* - * - * CPU_init_critical registers - * - * setup important registers - * setup memory timing - * - */ -ENTRY(cpu_init_crit) - /* -* Jump to board specific initialization... -* The Mask ROM will have already initialized -* basic memory. Go here to bump up clock rate and handle -* wake up conditions. -*/ - mov ip, lr @ persevere link reg across call - bl lowlevel_init @ go setup pll,mux,memory - mov lr, ip @ restore link - mov pc, lr @ back to my caller -ENDPROC(cpu_init_crit) -#endif - #ifndef CONFIG_SPL_BUILD /* * -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
On 09/17/12 09:27, Scott Wood wrote: On 09/17/2012 04:24:34 AM, José Miguel Gonçalves wrote: [snip] If no one else has anything against, I will change the name of the new target to u-boot-pad.bin What exactly is u-boot-pad.bin supposed to be? I hope that's not being proposed as the final output file the user sees. With old nand_spl we had u-boot-nand.bin for the final concatenated binary, but that's not appropriate for a generic spl. I think it would be better for the user to see u-boot.bin as the actual image to put on the boot device, regardless of implementation details like spl, if there's no requirement of a specific file format. The second stage could become u-boot-main.bin or similar on builds where spl is used. We need some name that means U-Boot SPL with U-Boot tacked on at the end. This can optionally be padded to a defined size to make writing to hardware easier. We also have the problem that u-boot.bin already means something so it needs to be clear. I further fear that even if we made an out directory if we put u-boot.bin in there and it's not the same as the objcopy -O binary u-boot u-boot.bin as before we've violated the rule of least surprise and the end user problems from people that read the document (that happened to be out of date) will be our problem. In short, at least a few people have said something along the lines of We need generic output nameo $mediums and targets but there's two hard problems, one of which is that every SoC _needs_ things tweaked just so (no header? no boot!), sometimes wants things tweaked further (pad the final image out to be easier to write to $medium) and sometimes needs multiple files (the whole of 'SPL' will be read so it must fit into $SMALL_MEMORY). The other is naming. I don't want to block this series on this problem. I do want to say it needs to use my updated SPL framework or show that it's inadequate (and I owe another reply to part of this thread still) for this platform. Call it u-boot.s3c or .s3c24xx and lets continue talking about how to solve the general problem. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves wrote:
On 09/14/2012 08:01 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel Gon?alves wrote:
On 14-09-2012 19:21, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
NAND Flash driver with HW ECC for the S3C24XX SoCs.
Currently it only supports SLC NAND chips.
Signed-off-by: Jos? Miguel Gon?alves jose.goncal...@inov.pt
[...]
+#include common.h
+#include nand.h
+#include asm/io.h
+#include asm/arch/s3c24xx_cpu.h
+#include asm/errno.h
+
+#define MAX_CHIPS2
+static int nand_cs[MAX_CHIPS] = { 0, 1 };
+
+#ifdef CONFIG_SPL_BUILD
+#define printf(arg...) do {} while (0)
This doesn't seem quite right ...
1) this should be in CPU directory
2) should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
3) should be inline function, not a macro
1) and 3) OK.
Don't quite understand 2). I want to remove the printfs in the SPL
build, as it would blown up the internal SoC RAM space available.
So why add a condition with CONFIG_SPL_SERIAL_SUPPORT?
You've got 8KB, based on the final patch in the series. At least in my
SPL series that's still enough to get you printf/puts (I believe 4kb was
the cutoff where that had to be dropped).
Barely:
$ size u-boot-spl
text databssdechexfilename
3337 8588 3933f5du-boot-spl
$ size u-boot-spl-printf
text databssdechexfilename
7968 8604 8580 2184 u-boot-spl-printf
The printf is not so important that justifies exhausting the IRAM
space available and preventing any future SPL expansion...
There's two parts to this:
- What else can you do in a single binary, in theory? Is there boot
medium detection and you would want to have, for example, NAND and SD
support in the same binary? I would say memory is meant for using,
but this is a board maintainer decision and that's you :)
- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that toggles
printf or no printf. If we really need to say yes to
LIBCOMMON_SUPPORT and no to printf, we need finer grained config
options and then a do-nothing printf is used for SPL. Doing the
opt-out driver by driver just punts this problem down the road to the
next developer and that's not very nice (and adding
CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few
Makefiles, update a bunch of config files, add
common/spl/dummy_funcs.c and a __weak printf).
--
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 1/3] spi: add atmel at25df321 serial flash support
Dear Bo Shen, On 16.08.2012 06:44, Bo Shen wrote: Add atmel at25df321 serial flash support Signed-off-by: Bo Shen voice.s...@atmel.com --- since this patch did not appear to be merged by Mike as mentioned earlier ([1], [2], [3]) I did apply it to u-boot-atmel/master, thanks! Best regards Andreas Bießmann [1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/138226/focus=138332 [2] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/137983/focus=139926 [3] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/140642/focus=140774 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] spiflash: at25: using common spi flash operation
Dear Bo Shen, On 20.08.2012 08:32, Bo Shen wrote: Using common spi flash operation function to replace private operation funtion This patch is based on http://patchwork.ozlabs.org/patch/177896/ which has been merged by Mike frysinger Signed-off-by: Bo Shen voice.s...@atmel.com --- applied to u-boot-atmel/master, thanks! Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
On 09/17/2012 11:57:57 AM, Tom Rini wrote:
On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves wrote:
On 09/14/2012 08:01 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel Gon?alves
wrote:
On 14-09-2012 19:21, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
NAND Flash driver with HW ECC for the S3C24XX SoCs.
Currently it only supports SLC NAND chips.
Signed-off-by: Jos? Miguel Gon?alves jose.goncal...@inov.pt
[...]
+#include common.h
+#include nand.h
+#include asm/io.h
+#include asm/arch/s3c24xx_cpu.h
+#include asm/errno.h
+
+#define MAX_CHIPS 2
+static int nand_cs[MAX_CHIPS] = { 0, 1 };
+
+#ifdef CONFIG_SPL_BUILD
+#define printf(arg...) do {} while (0)
This doesn't seem quite right ...
1) this should be in CPU directory
2) should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
3) should be inline function, not a macro
1) and 3) OK.
Don't quite understand 2). I want to remove the printfs in the SPL
build, as it would blown up the internal SoC RAM space available.
So why add a condition with CONFIG_SPL_SERIAL_SUPPORT?
You've got 8KB, based on the final patch in the series. At least
in my
SPL series that's still enough to get you printf/puts (I believe
4kb was
the cutoff where that had to be dropped).
Barely:
$ size u-boot-spl
text databssdechexfilename
3337 8588 3933f5du-boot-spl
$ size u-boot-spl-printf
text databssdechexfilename
7968 8604 8580 2184
u-boot-spl-printf
The printf is not so important that justifies exhausting the IRAM
space available and preventing any future SPL expansion...
There's two parts to this:
- What else can you do in a single binary, in theory? Is there boot
medium detection and you would want to have, for example, NAND and
SD
support in the same binary? I would say memory is meant for using,
but this is a board maintainer decision and that's you :)
- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that toggles
printf or no printf. If we really need to say yes to
LIBCOMMON_SUPPORT and no to printf, we need finer grained config
options and then a do-nothing printf is used for SPL. Doing the
opt-out driver by driver just punts this problem down the road to
the
next developer and that's not very nice (and adding
CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few
Makefiles, update a bunch of config files, add
common/spl/dummy_funcs.c and a __weak printf).
Weak symbols are not OK for configuring printf out of the SPL, as
you'll still have all the format strings and caller code in the
binary. It should be a macro (or an inline function that replaces the
standard printf declaration), but it should be in a system header (not
the CPU directory -- not sure what Marek meant there) and be based on
an appropriate CONFIG symbol.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Atmel: sam9g10/9m10/9x5: Add support to boot DT kernel
Dear Bo Shen, On 05.09.2012 11:22, Bo Shen wrote: The mainline linux kernel is moving to flatten device tree support Add the CONFIG_OF_LIBFDT option to support booting DT linux kernel Signed-off-by: Bo Shen voice.s...@atmel.com --- applied to u-boot-atmel/master, thanks! Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 4/5] OMAP: networking support for SPL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/17/12 02:55, Ilya Yanok wrote: Hi Joe, On Thu, Aug 30, 2012 at 1:25 AM, Joe Hershberger joe.hershber...@gmail.com mailto:joe.hershber...@gmail.com wrote: [snip] diff --git a/net/net.c b/net/net.c index e8ff066..bbd1a6d 100644 --- a/net/net.c +++ b/net/net.c @@ -81,6 +81,19 @@ #include common.h +#ifdef CONFIG_SPL_BUILD +/* SPL needs only BOOTP + TFTP so undefine other stuff to save space */ +#undef CONFIG_CMD_DHCP +#undef CONFIG_CMD_CDP +#undef CONFIG_CMD_DNS +#undef CONFIG_CMD_LINK_LOCAL +#undef CONFIG_CMD_NFS +#undef CONFIG_CMD_PING +#undef CONFIG_CMD_RARP +#undef CONFIG_CMD_SNTP +#undef CONFIG_CMD_TFTPPUT +#undef CONFIG_CMD_TFTPSRV +#endif Is this the best place to do this? Seems it would be clearer to modify config_cmd_default.h or add a config_cmd_spl.h that will undefine them, and include that. I agree it's not the best place... config_cmd_spl.h sounds a little bit crazy as we don't have any commands at all in SPL... How about config_uncmd_spl.h then and a nice big comment up top explaining what we're doing. Or can we take another stab at seeing why some stuff isn't being garbage collected? If garbage_collected_func_a calls never_seen_while_linking_func, we still succeed since we garbage collect the first func. There's just the gcc issue I've noted before about strings. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQV1goAAoJENk4IS6UOR1WmCIQAKmnvVA5ZiYmWNqTvXPtjCz3 DRBfE8iLLpDzMgzjgEyy/3e3at7zE4+svN5ncYvkxPRBqiBol9InXYnUBdgZXiMk 7/HahZdJpsX1KwFGQxUTuRErABQXT14IQn0Nz/7xKbpHcFlrJSxPaKb3RblwBylj nZiRYhNfCFVzsMvmLPRk/IiHh9EMqwGDmKW1sAsF7qGw1CFzOTkLW9KKIqW6anUH JXOy0fVeVOyBK6erK2R0kFYbYSvpYUJPG88pymu/hiSHvwI2vOZdJ0g6Q9O3RKP3 rXz5Xnei5ujnQ5Kb8T5gES5Y1My/m1LXCqSY2Aq0cuyDnUEDItZLYycPKkrXZ3yf W73ydbMrT1BpFasWB/Crce/J54zIpLMnQiFpJ0vgv4sSD+yzrD4o02TsYeXgvekJ KpJRhsdRp1r190s2wdyeJTTSsP2yQCbPWGL/vDQr9hb1tdLK+EIxLsG++9uZxHQ5 TgtaPyvlScaz/WC0TxE3NRNOGFRqvTGa+MgD3JHoUOMfc1FhsZXIjoW5K239GvkL lIEFKYaTsFvo1lygPFUTZPEls4ElbeJ6OJjJy9xUs33avlpvTbkEqgkb2L39+uQM cK5LoGKqwyrEa8CMxyCkzD6GTywkf+LYiUmKY6Ped2svN0WRgakISOuDRXdAdsB0 W2Gx6XbRea/1iE+wHEUC =7bJ2 -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL} please pull u-boot-atmel/master into u-boot-arm/master
Dear Albert Aribaud, as mentioned before there are some fixes left for this upcoming release, here they are. The following changes since commit 057df193b40d31799d41d43bc832a972f658bfe4: Merge remote-tracking branch 'u-boot-ti/master' into m (2012-09-05 20:20:04 +0200) are available in the git repository at: git://git.denx.de/u-boot-atmel.git master for you to fetch changes up to dc3e30bab7c5ef87bd24ebcbb7cdfc3fb2b44555: Atmel: sam9g10/9m10/9x5: Add support to boot DT kernel (2012-09-17 19:02:44 +0200) Bo Shen (3): spi: add atmel at25df321 serial flash support spiflash: at25: using common spi flash operation Atmel: sam9g10/9m10/9x5: Add support to boot DT kernel Wu, Josh (2): at91sam9x5: set default EBI I/O drive configuration. atmel_nand: fix the U-Boot output information about nand flash with PMECC enable. board/atmel/at91sam9x5ek/at91sam9x5ek.c |4 drivers/mtd/nand/atmel_nand.c |5 +++-- drivers/mtd/spi/atmel.c | 17 - include/configs/at91sam9261ek.h |2 ++ include/configs/at91sam9m10g45ek.h |2 ++ include/configs/at91sam9x5ek.h |2 ++ 6 files changed, 29 insertions(+), 3 deletions(-) Best regards Andreas Bie??mann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
On 17-09-2012 17:57, Tom Rini wrote:
On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves wrote:
On 09/14/2012 08:01 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel Gon?alves wrote:
On 14-09-2012 19:21, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
NAND Flash driver with HW ECC for the S3C24XX SoCs.
Currently it only supports SLC NAND chips.
Signed-off-by: Jos? Miguel Gon?alves jose.goncal...@inov.pt
[...]
+#include common.h
+#include nand.h
+#include asm/io.h
+#include asm/arch/s3c24xx_cpu.h
+#include asm/errno.h
+
+#define MAX_CHIPS 2
+static int nand_cs[MAX_CHIPS] = { 0, 1 };
+
+#ifdef CONFIG_SPL_BUILD
+#define printf(arg...) do {} while (0)
This doesn't seem quite right ...
1) this should be in CPU directory
2) should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
3) should be inline function, not a macro
1) and 3) OK.
Don't quite understand 2). I want to remove the printfs in the SPL
build, as it would blown up the internal SoC RAM space available.
So why add a condition with CONFIG_SPL_SERIAL_SUPPORT?
You've got 8KB, based on the final patch in the series. At least in my
SPL series that's still enough to get you printf/puts (I believe 4kb was
the cutoff where that had to be dropped).
Barely:
$ size u-boot-spl
text databssdechexfilename
3337 8588 3933f5du-boot-spl
$ size u-boot-spl-printf
text databssdechexfilename
7968 8604 8580 2184 u-boot-spl-printf
The printf is not so important that justifies exhausting the IRAM
space available and preventing any future SPL expansion...
There's two parts to this:
- What else can you do in a single binary, in theory? Is there boot
medium detection and you would want to have, for example, NAND and SD
support in the same binary? I would say memory is meant for using,
but this is a board maintainer decision and that's you :)
That's exactly what I've got in mind when I talked about a future expansion! Being
able to boot also from an SD card.
With only 8KB for .text and .data, I can not use printfs in the SPL for this
platform (at least with the present printf support for SPL).
- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that toggles
printf or no printf. If we really need to say yes to
LIBCOMMON_SUPPORT and no to printf, we need finer grained config
options and then a do-nothing printf is used for SPL. Doing the
opt-out driver by driver just punts this problem down the road to the
next developer and that's not very nice (and adding
CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few
Makefiles, update a bunch of config files, add
common/spl/dummy_funcs.c and a __weak printf).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
On 09/17/12 10:03, Scott Wood wrote:
On 09/17/2012 11:57:57 AM, Tom Rini wrote:
On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves wrote:
On 09/14/2012 08:01 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel Gon?alves wrote:
On 14-09-2012 19:21, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
NAND Flash driver with HW ECC for the S3C24XX SoCs.
Currently it only supports SLC NAND chips.
Signed-off-by: Jos? Miguel Gon?alves jose.goncal...@inov.pt
[...]
+#include common.h
+#include nand.h
+#include asm/io.h
+#include asm/arch/s3c24xx_cpu.h
+#include asm/errno.h
+
+#define MAX_CHIPS2
+static int nand_cs[MAX_CHIPS] = { 0, 1 };
+
+#ifdef CONFIG_SPL_BUILD
+#define printf(arg...) do {} while (0)
This doesn't seem quite right ...
1) this should be in CPU directory
2) should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
3) should be inline function, not a macro
1) and 3) OK.
Don't quite understand 2). I want to remove the printfs in the SPL
build, as it would blown up the internal SoC RAM space available.
So why add a condition with CONFIG_SPL_SERIAL_SUPPORT?
You've got 8KB, based on the final patch in the series. At least
in my
SPL series that's still enough to get you printf/puts (I believe
4kb was
the cutoff where that had to be dropped).
Barely:
$ size u-boot-spl
text databssdechexfilename
3337 8588 3933f5du-boot-spl
$ size u-boot-spl-printf
text databssdechexfilename
7968 8604 8580 2184 u-boot-spl-printf
The printf is not so important that justifies exhausting the IRAM
space available and preventing any future SPL expansion...
There's two parts to this:
- What else can you do in a single binary, in theory? Is there boot
medium detection and you would want to have, for example, NAND and SD
support in the same binary? I would say memory is meant for using,
but this is a board maintainer decision and that's you :)
- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that toggles
printf or no printf. If we really need to say yes to
LIBCOMMON_SUPPORT and no to printf, we need finer grained config
options and then a do-nothing printf is used for SPL. Doing the
opt-out driver by driver just punts this problem down the road to the
next developer and that's not very nice (and adding
CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few
Makefiles, update a bunch of config files, add
common/spl/dummy_funcs.c and a __weak printf).
Weak symbols are not OK for configuring printf out of the SPL, as you'll
still have all the format strings and caller code in the binary. It
should be a macro (or an inline function that replaces the standard
printf declaration), but it should be in a system header (not the CPU
directory -- not sure what Marek meant there) and be based on an
appropriate CONFIG symbol.
I'm a little leery of adding #if ... into common.h around printf. I'd
like to not worry about the branch/return bytes until we really really
have to again but yes, the strings are more of a concern since they
won't be collected out. Just top of my head thinking above.
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
On 09/17/2012 12:08:17 PM, Tom Rini wrote: On 09/17/12 10:03, Scott Wood wrote: Weak symbols are not OK for configuring printf out of the SPL, as you'll still have all the format strings and caller code in the binary. It should be a macro (or an inline function that replaces the standard printf declaration), but it should be in a system header (not the CPU directory -- not sure what Marek meant there) and be based on an appropriate CONFIG symbol. I'm a little leery of adding #if ... into common.h around printf. I'd like to not worry about the branch/return bytes until we really really have to again but yes, the strings are more of a concern since they won't be collected out. Just top of my head thinking above. Caller code won't be collected either. It's not just branch/return bytes but argument preparation -- possibly significant chunks of code to calculate values to be displayed, that might otherwise be optimized out. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, On 09/16/2012 11:06 AM, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, On 09/15/2012 07:03 PM, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, Jumping to board_init_r is not performed due to a bug on address computation. Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards. Maybe because you are not using it to build an SPL? I do ... and I use CONFIG_SPL_TEXT_BASE properly . Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs. Please wait and please first explain what is the issue. The issue is what I've explained in the patch comments. Jumping to board_init_r is not performed due to a bug on address computation. Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway .. Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set. I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL Here's a good point for me to jump in, I think. There's two things to understand: - In the current in-tree SPL implementations the code flow is board_init_f calls relocate_code() to clear the BSS _and_ get our jump to board_init_r. It does not actually relocate the running U-Boot, just clears the BSS. board_init_r is what calls the things to load and boot the next stage (U-Boot or Linux). - In my series this has been changed slightly to be board_init_f calls memset and then board_init_r directly. So this patch should not be needed once rebased on that series. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
On 09/17/2012 12:18:31 PM, Tom Rini wrote: On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, On 09/16/2012 11:06 AM, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, On 09/15/2012 07:03 PM, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, Jumping to board_init_r is not performed due to a bug on address computation. Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards. Maybe because you are not using it to build an SPL? I do ... and I use CONFIG_SPL_TEXT_BASE properly . Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs. Please wait and please first explain what is the issue. The issue is what I've explained in the patch comments. Jumping to board_init_r is not performed due to a bug on address computation. Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway .. Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set. I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL Here's a good point for me to jump in, I think. There's two things to understand: - In the current in-tree SPL implementations the code flow is board_init_f calls relocate_code() to clear the BSS _and_ get our jump to board_init_r. It does not actually relocate the running U-Boot, just clears the BSS. board_init_r is what calls the things to load and boot the next stage (U-Boot or Linux). - In my series this has been changed slightly to be board_init_f calls memset and then board_init_r directly. So this patch should not be needed once rebased on that series. So you've removed the ability to relocate at all? What about hardware where you boot from an I/O buffer, that you need to get out of in order to load more pages? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot's stack space on a Sequoia board
On 09/15/2012 01:27 AM, Wolfgang Denk wrote: Dear Corey Ashford, In message 5053ccb5.3070...@linux.vnet.ibm.com you wrote: The board I am using is a Sequoia, powerpc 440EPx board running U-boot 1.2.0-gc0c292b2 (Jun 5 2007 - 07:16:12). Frankly: we don't really care any longer about 5 years old code. The Sequoia board is well supported in mainline U-Boot, so please update and use current code instead. So I have a couple of questions: Please update, then try again. Best regards, Wolfgang Denk Dear Wolfgang Denk, OK, and thank you for your quick reply. I don't have physical access to this board, but I'll ask around to find if this is something we can do. Regards, - Corey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
Dear Tom Rini, On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, On 09/16/2012 11:06 AM, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, On 09/15/2012 07:03 PM, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, Jumping to board_init_r is not performed due to a bug on address computation. Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards. Maybe because you are not using it to build an SPL? I do ... and I use CONFIG_SPL_TEXT_BASE properly . Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs. Please wait and please first explain what is the issue. The issue is what I've explained in the patch comments. Jumping to board_init_r is not performed due to a bug on address computation. Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway .. Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set. I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL Here's a good point for me to jump in, I think. There's two things to understand: - In the current in-tree SPL implementations the code flow is board_init_f calls relocate_code() to clear the BSS _and_ get our jump to board_init_r. It does not actually relocate the running U-Boot, just clears the BSS. board_init_r is what calls the things to load and boot the next stage (U-Boot or Linux). - In my series this has been changed slightly to be board_init_f calls memset and then board_init_r directly. So this patch should not be needed once rebased on that series. Do we need to do all the relocation in assembler code btw? Can it not be moved into C code and made generic across all platforms (module the stack adjustment and a few minor things) ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
On 17-09-2012 18:18, Tom Rini wrote: On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, On 09/16/2012 11:06 AM, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, On 09/15/2012 07:03 PM, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, Jumping to board_init_r is not performed due to a bug on address computation. Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards. Maybe because you are not using it to build an SPL? I do ... and I use CONFIG_SPL_TEXT_BASE properly . Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs. Please wait and please first explain what is the issue. The issue is what I've explained in the patch comments. Jumping to board_init_r is not performed due to a bug on address computation. Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway .. Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set. I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL Here's a good point for me to jump in, I think. There's two things to understand: - In the current in-tree SPL implementations the code flow is board_init_f calls relocate_code() to clear the BSS _and_ get our jump to board_init_r. It does not actually relocate the running U-Boot, just clears the BSS. board_init_r is what calls the things to load and boot the next stage (U-Boot or Linux). - In my series this has been changed slightly to be board_init_f calls memset and then board_init_r directly. So this patch should not be needed once rebased on that series. OK Tom. I will start working on rebasing the MINI2416 board support on the new SPL framework. If I have any doubts I will get in touch with you... Best regards, José Gonçalves ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
On Mon, Sep 17, 2012 at 12:23:53PM -0500, Scott Wood wrote: On 09/17/2012 12:18:31 PM, Tom Rini wrote: On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, On 09/16/2012 11:06 AM, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, On 09/15/2012 07:03 PM, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, Jumping to board_init_r is not performed due to a bug on address computation. Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards. Maybe because you are not using it to build an SPL? I do ... and I use CONFIG_SPL_TEXT_BASE properly . Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs. Please wait and please first explain what is the issue. The issue is what I've explained in the patch comments. Jumping to board_init_r is not performed due to a bug on address computation. Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway .. Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set. I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL Here's a good point for me to jump in, I think. There's two things to understand: - In the current in-tree SPL implementations the code flow is board_init_f calls relocate_code() to clear the BSS _and_ get our jump to board_init_r. It does not actually relocate the running U-Boot, just clears the BSS. board_init_r is what calls the things to load and boot the next stage (U-Boot or Linux). - In my series this has been changed slightly to be board_init_f calls memset and then board_init_r directly. So this patch should not be needed once rebased on that series. So you've removed the ability to relocate at all? What about hardware where you boot from an I/O buffer, that you need to get out of in order to load more pages? Then you do that instead. Getting from board_init_f to _r is setup at the arch level, weakly, and with what it must perform documented. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
On 09/17/2012 11:51:52 AM, Tom Rini wrote: On 09/17/12 09:27, Scott Wood wrote: On 09/17/2012 04:24:34 AM, José Miguel Gonçalves wrote: [snip] If no one else has anything against, I will change the name of the new target to u-boot-pad.bin What exactly is u-boot-pad.bin supposed to be? I hope that's not being proposed as the final output file the user sees. With old nand_spl we had u-boot-nand.bin for the final concatenated binary, but that's not appropriate for a generic spl. I think it would be better for the user to see u-boot.bin as the actual image to put on the boot device, regardless of implementation details like spl, if there's no requirement of a specific file format. The second stage could become u-boot-main.bin or similar on builds where spl is used. We need some name that means U-Boot SPL with U-Boot tacked on at the end. This can optionally be padded to a defined size to make writing to hardware easier. We also have the problem that u-boot.bin already means something so it needs to be clear. u-boot.bin has traditionally (except for nand_spl and derivatives) meant the final image ready to put into flash, after any platform-specific layout issues are taken care of (e.g. on mpc83xx it will have a reset control word embedded, on mpc85xx it will be padded to 512K with a reset vector at the end, etc.). That we did the tweaking in the linker script rather than after linking seems like an inconsequential implementation detail. I further fear that even if we made an out directory if we put u-boot.bin in there and it's not the same as the objcopy -O binary u-boot u-boot.bin as before we've violated the rule of least surprise and the end user problems from people that read the document (that happened to be out of date) will be our problem. In this case I think you can't meet one user's expectations without violating another's. I think it's more important to make it clear to the user what file they're supposed to put into flash. Users of platforms that are currently supported by nand_spl would probably like to continue seeing u-boot-nand.bin -- it's a tradeoff of historical stability versus current consistency. In short, at least a few people have said something along the lines of We need generic output nameo $mediums and targets but there's two hard problems, one of which is that every SoC _needs_ things tweaked just so (no header? no boot!), sometimes wants things tweaked further (pad the final image out to be easier to write to $medium) and sometimes needs multiple files (the whole of 'SPL' will be read so it must fit into $SMALL_MEMORY). The other is naming. A simple concatenation of a padded SPL plus the main U-Boot was good enough for all the nand_spl boards AFAIK, so it's not quite every SoC that needs something special here. For those that do require a special format (or multiple files) with a file extension that is familiar to people working with that platform, using that extension makes sense. pad does not, and a proliferation of SoC-specific suffixes isn't much better. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
On Mon, Sep 17, 2012 at 07:26:06PM +0200, Marek Vasut wrote: Dear Tom Rini, On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, On 09/16/2012 11:06 AM, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, On 09/15/2012 07:03 PM, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, Jumping to board_init_r is not performed due to a bug on address computation. Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards. Maybe because you are not using it to build an SPL? I do ... and I use CONFIG_SPL_TEXT_BASE properly . Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs. Please wait and please first explain what is the issue. The issue is what I've explained in the patch comments. Jumping to board_init_r is not performed due to a bug on address computation. Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway .. Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set. I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL Here's a good point for me to jump in, I think. There's two things to understand: - In the current in-tree SPL implementations the code flow is board_init_f calls relocate_code() to clear the BSS _and_ get our jump to board_init_r. It does not actually relocate the running U-Boot, just clears the BSS. board_init_r is what calls the things to load and boot the next stage (U-Boot or Linux). - In my series this has been changed slightly to be board_init_f calls memset and then board_init_r directly. So this patch should not be needed once rebased on that series. Do we need to do all the relocation in assembler code btw? Can it not be moved into C code and made generic across all platforms (module the stack adjustment and a few minor things) ? I think people have posted patches for this before and yes, once CONFIG_NEEDS_MANUAL_RELOC dies it should be all possible to do in C, so long as it doesn't grow in size or doesn't grow in size that would be problematic (remember the 4kb people). -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
Dear Tom Rini, On Mon, Sep 17, 2012 at 07:26:06PM +0200, Marek Vasut wrote: Dear Tom Rini, On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, On 09/16/2012 11:06 AM, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, On 09/15/2012 07:03 PM, Marek Vasut wrote: Dear Jos? Miguel Gon?alves, Jumping to board_init_r is not performed due to a bug on address computation. Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards. Maybe because you are not using it to build an SPL? I do ... and I use CONFIG_SPL_TEXT_BASE properly . Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs. Please wait and please first explain what is the issue. The issue is what I've explained in the patch comments. Jumping to board_init_r is not performed due to a bug on address computation. Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway .. Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set. I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL Here's a good point for me to jump in, I think. There's two things to understand: - In the current in-tree SPL implementations the code flow is board_init_f calls relocate_code() to clear the BSS _and_ get our jump to board_init_r. It does not actually relocate the running U-Boot, just clears the BSS. board_init_r is what calls the things to load and boot the next stage (U-Boot or Linux). - In my series this has been changed slightly to be board_init_f calls memset and then board_init_r directly. So this patch should not be needed once rebased on that series. Do we need to do all the relocation in assembler code btw? Can it not be moved into C code and made generic across all platforms (module the stack adjustment and a few minor things) ? I think people have posted patches for this before and yes, once CONFIG_NEEDS_MANUAL_RELOC dies it should be all possible to do in C, so long as it doesn't grow in size or doesn't grow in size that would be problematic (remember the 4kb people). How does MANUAL_RELOC interfere with that? Eg. on ARM, it can already be shifted to C. Then if we made it generic enough, those MANUAL_RELOC platforms could simply adopt the C code. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weekly status
Dear Tom Rini, Hey all, I had intended to send this last thing Friday but it slipped my mind. But with my intention to do -rc1 this Friday, this works too. That said... Here's where I'm at so far: - Locally, I believe I have all outstanding pull requets queued up and MAKEALL'd when there's an ELDK toolchain. You're getting them MAKEALL's around 6 hours after you push it to master for PPC and ARM with ELDK4.2 and 5.2 ;-) - Working out the access issues with Detlev. - I've given the first two pages of patchwork a read and assign pass. If you're a custodian I've probably assigned a few patches to you that look like your area. I've also done my best to spot superseded patches and things which have been accepted but I'm sure I missed a few. - If you have assigned me items in patchwork and sent me an email, I have read it and will act on it shortly if I haven't already (just don't want the queue of I have applied this messages locally to get too large). I think I have a few more USB patches holed up in my usb tree, I'll send you a pullRQ now. I expect to be able to snap -rc1 on my previously announced schedule. Once I do the usual rules about next will open and I would encourage custodians to open up a next branch as well. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-usb/master
I'm not sure if we want them in current release or next, I'll leave that to you to decide. I don't see much danger for current though. The following changes since commit a6f0c4faa4c65a7b7048b12c9d180d7e1aad1721: Merge branch 'master' of git://git.denx.de/u-boot-avr32 (2012-09-04 09:17:27 +0200) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 8187c2dcbd3e47ecfef406468c8eee1fe746b8e7: usb: do explicit unaligned accesses (2012-09-06 08:02:08 +0200) Lucas Stach (5): usb: lowlevel interface change to support multiple controllers usb: ehci: rework to take advantage of new lowlevel interface usb: add support for multiple usb controllers tegra20: port to new ehci interface usb: do explicit unaligned accesses Łukasz Majewski (2): dfu:usb: Support for ext4 dfu:usb:fix: Read the filesize environment variable only when file read arch/arm/cpu/arm920t/s3c24x0/usb_ohci.c |4 +-- arch/arm/cpu/armv7/tegra20/usb.c | 15 +++-- arch/arm/include/asm/arch-tegra20/usb.h |4 +-- arch/arm/include/asm/ehci-omap.h | 10 +- arch/mips/cpu/mips32/au1x00/au1x00_usb_ohci.c |4 +-- arch/powerpc/cpu/mpc5xxx/usb_ohci.c |4 +-- arch/powerpc/cpu/ppc4xx/usb_ohci.c|4 +-- arch/sparc/cpu/leon3/usb_uhci.c |4 +-- arch/sparc/lib/bootm.c|2 +- board/htkw/mcx/mcx.c |6 ++-- board/mpl/common/usb_uhci.c |4 +-- board/technexion/twister/twister.c|6 ++-- board/teejet/mt_ventoux/mt_ventoux.c |6 ++-- board/ti/beagle/beagle.c |6 ++-- board/ti/panda/panda.c|6 ++-- common/cmd_usb.c | 16 ++--- common/usb.c | 108 + common/usb_hub.c | 16 + common/usb_storage.c |2 +- drivers/dfu/dfu_mmc.c | 34 +++ drivers/usb/eth/usb_ether.c |2 +- drivers/usb/host/ehci-armada100.c | 15 - drivers/usb/host/ehci-atmel.c | 11 +++ drivers/usb/host/ehci-core.h | 29 - drivers/usb/host/ehci-exynos.c| 15 - drivers/usb/host/ehci-fsl.c | 11 +++ drivers/usb/host/ehci-hcd.c | 131 +- drivers/usb/host/ehci-ixp4xx.c| 15 - drivers/usb/host/ehci-marvell.c | 15 - drivers/usb/host/ehci-mpc512x.c | 25 ++ drivers/usb/host/ehci-mx5.c | 11 +++ drivers/usb/host/ehci-mx6.c | 11 +++ drivers/usb/host/ehci-mxc.c | 11 +++ drivers/usb/host/ehci-mxs.c | 28 +--- drivers/usb/host/ehci-omap.c | 10 +++--- drivers/usb/host/ehci-pci.c | 15 - drivers/usb/host/ehci-ppc4xx.c| 11 +++ drivers/usb/host/ehci-tegra.c | 14 drivers/usb/host/ehci-vct.c |9 +++--- drivers/usb/host/ehci.h |4 +-- drivers/usb/host/isp116x-hcd.c|4 +-- drivers/usb/host/ohci-hcd.c |4 +-- drivers/usb/host/r8a66597-hcd.c |4 +-- drivers/usb/host/sl811-hcd.c |4 +-- drivers/usb/musb/musb_hcd.c |4 +-- include/usb.h | 10 -- include/usb/mv_udc.h |2 +- 47 files changed, 352 insertions(+), 334 deletions(-) delete mode 100644 drivers/usb/host/ehci-core.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
On 09/17/12 10:32, Scott Wood wrote: On 09/17/2012 11:51:52 AM, Tom Rini wrote: On 09/17/12 09:27, Scott Wood wrote: On 09/17/2012 04:24:34 AM, José Miguel Gonçalves wrote: [snip] If no one else has anything against, I will change the name of the new target to u-boot-pad.bin What exactly is u-boot-pad.bin supposed to be? I hope that's not being proposed as the final output file the user sees. With old nand_spl we had u-boot-nand.bin for the final concatenated binary, but that's not appropriate for a generic spl. I think it would be better for the user to see u-boot.bin as the actual image to put on the boot device, regardless of implementation details like spl, if there's no requirement of a specific file format. The second stage could become u-boot-main.bin or similar on builds where spl is used. We need some name that means U-Boot SPL with U-Boot tacked on at the end. This can optionally be padded to a defined size to make writing to hardware easier. We also have the problem that u-boot.bin already means something so it needs to be clear. u-boot.bin has traditionally (except for nand_spl and derivatives) meant the final image ready to put into flash, after any platform-specific layout issues are taken care of (e.g. on mpc83xx it will have a reset control word embedded, on mpc85xx it will be padded to 512K with a reset vector at the end, etc.). That we did the tweaking in the linker script rather than after linking seems like an inconsequential implementation detail. Right, but it's also just objcopy (with OBJCFLAGS) -O binary of, and this is the biggie to me, just U-Boot. I further fear that even if we made an out directory if we put u-boot.bin in there and it's not the same as the objcopy -O binary u-boot u-boot.bin as before we've violated the rule of least surprise and the end user problems from people that read the document (that happened to be out of date) will be our problem. In this case I think you can't meet one user's expectations without violating another's. I think it's more important to make it clear to the user what file they're supposed to put into flash. Users of platforms that are currently supported by nand_spl would probably like to continue seeing u-boot-nand.bin -- it's a tradeoff of historical stability versus current consistency. Right. So I'm saying we need to set new expectations for everyone and some human helper symlinks to help. A new top-level out or images or something, with symlinks inside. In short, at least a few people have said something along the lines of We need generic output nameo $mediums and targets but there's two hard problems, one of which is that every SoC _needs_ things tweaked just so (no header? no boot!), sometimes wants things tweaked further (pad the final image out to be easier to write to $medium) and sometimes needs multiple files (the whole of 'SPL' will be read so it must fit into $SMALL_MEMORY). The other is naming. A simple concatenation of a padded SPL plus the main U-Boot was good enough for all the nand_spl boards AFAIK, so it's not quite every SoC that needs something special here. For those that do require a special format (or multiple files) with a file extension that is familiar to people working with that platform, using that extension makes sense. pad does not, and a proliferation of SoC-specific suffixes isn't much better. I think we're running into PowerPC vs ARM fun. We've got 7 or so different whack the image for this SoC for this medium type things already. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 4/5] OMAP: networking support for SPL
Hi Tom, On Mon, Sep 17, 2012 at 9:04 PM, Tom Rini tr...@ti.com wrote: I agree it's not the best place... config_cmd_spl.h sounds a little bit crazy as we don't have any commands at all in SPL... How about config_uncmd_spl.h then and a nice big comment up top Well, it will be at least less confusing... explaining what we're doing. Or can we take another stab at seeing why some stuff isn't being garbage collected? If garbage_collected_func_a calls never_seen_while_linking_func, we still succeed since we garbage collect the first func. There's just the gcc issue I've noted before about strings. That's not really about garbage collection in this case (net-spl). I want to disable some functionality of generic net code not some stuff used only by commands implementation. The confusion comes from the fact that this code is protected by CONFIG_CMD_* defines. Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/17/12 10:08, José Miguel Gonçalves wrote:
On 17-09-2012 17:57, Tom Rini wrote:
On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves
wrote:
On 09/14/2012 08:01 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel
Gon?alves wrote:
On 14-09-2012 19:21, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
NAND Flash driver with HW ECC for the S3C24XX SoCs.
Currently it only supports SLC NAND chips.
Signed-off-by: Jos? Miguel Gon?alves
jose.goncal...@inov.pt
[...]
+#include common.h +#include nand.h +#include
asm/io.h +#include asm/arch/s3c24xx_cpu.h +#include
asm/errno.h + +#define MAX_CHIPS2 +static int
nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef
CONFIG_SPL_BUILD +#define printf(arg...) do {} while
(0)
This doesn't seem quite right ...
1) this should be in CPU directory 2) should be enabled
only if CONFIG_SPL_SERIAL_SUPPORT is not set 3) should be
inline function, not a macro
1) and 3) OK. Don't quite understand 2). I want to remove
the printfs in the SPL build, as it would blown up the
internal SoC RAM space available. So why add a condition
with CONFIG_SPL_SERIAL_SUPPORT?
You've got 8KB, based on the final patch in the series. At
least in my SPL series that's still enough to get you
printf/puts (I believe 4kb was the cutoff where that had to
be dropped).
Barely:
$ size u-boot-spl text databssdec
hexfilename 3337 8588 3933
f5du-boot-spl
$ size u-boot-spl-printf text databssdec
hexfilename 7968 8604 8580
2184 u-boot-spl-printf
The printf is not so important that justifies exhausting the
IRAM space available and preventing any future SPL
expansion...
There's two parts to this: - What else can you do in a single
binary, in theory? Is there boot medium detection and you would
want to have, for example, NAND and SD support in the same
binary? I would say memory is meant for using, but this is a
board maintainer decision and that's you :)
That's exactly what I've got in mind when I talked about a future
expansion! Being able to boot also from an SD card. With only 8KB
for .text and .data, I can not use printfs in the SPL for this
platform (at least with the present printf support for SPL).
- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that
toggles printf or no printf. If we really need to say yes to
LIBCOMMON_SUPPORT and no to printf, we need finer grained config
options and then a do-nothing printf is used for SPL. Doing the
opt-out driver by driver just punts this problem down the road to
the next developer and that's not very nice (and adding
CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few
Makefiles, update a bunch of config files, add
common/spl/dummy_funcs.c and a __weak printf).
OK, so please take a stab at option two, on top of my SPL series,
keeping in mind what Scott has said (which makes sense) because
otherwise you'll be changing a lot of MMC files too to drop out printf :)
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQV2Q+AAoJENk4IS6UOR1W0VMP/1ToNzW5XmNApUGYIZi1d779
hJ6MieZoiTHOCnrHiRMMMAfOnPNnt+63TozmXWkhNhlPVRCs1Irx8nCpzMabjevr
ZENjnewtKsvgBsICak5rSQLbfyQBUG8tL3iBMPnYwyNhDf8CgED6rNCnxhV8Lr7j
o0gELaNHPRD7bJwglXo3TN0BxNtTrww3uSArSYh4WMVaOP908Mk7p7y8qEVSvNeh
BrdbVZK1oPmhlke9EUXfCQYqn/JdJ7mtdW1q5PdST7GFtnLZmqpj+FuOEwN3OioA
DE6J461Aqr95mGVUnUr7PxglytL6zLKJcE8YpIhu9nL6r9QRg0wm4HIKr3uTKLl5
WBs4ziJsLtm5IAZ7xg2FOsPrCkrAiL3bVQg0+7xVc1cVzKIGmtMR6oGVS+nI38Q6
lzmz0AQSuobeLkiP4+tL8C7kFkwMcj9I5LByN968ZMvbTftecIsdgYSkluOdGU5w
dwKPjplU4t8yy6d1TXbh0Xdw7q8cBZ3bjqbAKi3uo9BpEHgCDOwHp7oOTuJTDB/7
C6WxXHdQFHh7m0hxf1zkawOeh+oqd5MHAxjlckQ/zmg5UsmNWDA6RmmYgWrOBw9m
jCvN/lhe1soBnxaz2byUKwEkPIDwmBl+JgtSL7DMZ7bLfS59daXiaMNac2JPstG3
j0lBvj7SCVnQrE6SJxxa
=71I1
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/7] gpt:doc: GPT (GUID Partition Table) documentation
On 09/13/2012 02:10 AM, Lukasz Majewski wrote:
Documentation of the GPT format.
diff --git a/doc/README.gpt b/doc/README.gpt
+Example usage:
+==
+
+To restore GUID partition table one needs to:
+1. at ./include/configs/{board}.h
+ - define partitions= environment variable with format:
+ name=u-boot,size=60M;name=kernel,size=60M;name=platform,size=1G;
+ - define GPT_PARTS_NUM with actual number of partitions (as defined above)
That seems unfortunate; the partitions variable and GPT_PARTS_NUM define
could easily become out-of-sync (what if the user edited the variable in
order to create an alternative disk layout, or what if a developer
simply forgot to update GPT_PARTS_NUM when editing the hard-coded value?).
Instead, can't GPT_PARTS_NUM be removed, and the code simply count the
number of entries in the partitions variable?
+ - #define CONFIG_EFI_PARTITION and #define CONFIG_CMD_GPT
+
+2. From u-boot prompt type:
+ gpt mmc 0 uuid_disk=ec2cddf2-fbf5-11e1-af3a-001fd09285c0, \
+ uuid1=ed09c4b0-fbf5-11e1-9a95-001fd09285c0, \
+ uuid2=edd6d93c-fbf5-11e1-875a-001fd09285c0, \
+ uuid3=f0485114-fbf5-11e1-a3ae-001fd09285c0 ...
+
+ UUIDs shall be defined up to GPT_PARTS_NUM. Smaller number is acceptable.
+ When UUIDs are NOT provided, internal (rather weak) GUID generator will be
+ used instead
Hmmm. It's a little unfortunate to provide the partitions list through
one mechanism (environment variable with a hard-coded name), and the
UUIDs through a different mechanism (command-line). Surely these two
mechanisms can be combined; rather than the command reading an
environment variable, you could at least require the user to pass the
appropriate data on the command-line, and optionally have them pass the
environment variable if they want to use the pre-defined layout, e.g.:
pre-defined:
gpt mmc 0 ${partitions}
manual/custom layout:
gpt mmc 0 name=u-boot,size=60M;name=kernel,size=60M;...
Then, I wonder if you couldn't define the partitions environment
variable as:
partitions=\
name=u-boot,size=60M,uuid=${uuid_gpt_u_boot};\
name=kernel,size=60M,uuid=${uuid_gpt_kernel};...
and have the environment variables expanded as in:
setenv uuid_gpt_u_boot=ed09c4b0-fbf5-11e1-9a95-001fd09285c0
setenv uuid_gpt_kernel=...
gpt mmc 0 ${partitions}
That way, the gpt command would read everything from the command-line,
yet the partition layout and UUID names could be specified separately,
so as to allow the user to define them at different times or places.
The implementation of gpt would have to scan all the variables it
extracted from the command-line, and expand any environment variable
references in them for this to work, since I assume the shell doesn't do
recursive variable expansions like make does.
Oh, and don't you want the gpt command to take a sub-command like
create, so that gpt could do different things in the future, e.g.
take an existing GPT layout, and edit, say, one partition's name:
gpt create mmc 0 ${partitions}
gpt set-name mmc 0 ${partition-id} ${new-name}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/17/12 10:48, Marek Vasut wrote:
Dear Tom Rini,
On Mon, Sep 17, 2012 at 07:26:06PM +0200, Marek Vasut wrote:
Dear Tom Rini,
On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
On 09/16/2012 11:06 AM, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
On 09/15/2012 07:03 PM, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
Jumping to board_init_r is not performed due to a
bug on address computation.
Is your CONFIG_SYS_TEXT_BASE configured correctly?
I don't detect any misbehavior on my arm926
boards.
Maybe because you are not using it to build an SPL?
I do ... and I use CONFIG_SPL_TEXT_BASE properly .
Please check the same chunk of code in other start.S
for arm1176 and armv7. They have the same code that I
put for arm926ejs.
Please wait and please first explain what is the
issue.
The issue is what I've explained in the patch comments.
Jumping to board_init_r is not performed due to a bug on
address computation.
Ok, I don't know how to replicate the bug from this comment
or what effects it causes or ... well, anything. So please,
try to be more elaborate in your patch description next
time. Anyway ..
Without this change the code never reaches board_init_r
in the SPL and I think I have all the configurations
correctly set.
I wonder why you'd ever want to reach board_init_r in the
SPL. SPL is there only to load the real U-Boot from
whatever media, so you usually use either NAND SPL
Here's a good point for me to jump in, I think. There's two
things to understand: - In the current in-tree SPL
implementations the code flow is
board_init_f calls relocate_code() to clear the BSS _and_ get
our jump to board_init_r. It does not actually relocate the
running U-Boot, just clears the BSS. board_init_r is what
calls the things to load and boot the next stage (U-Boot or
Linux).
- In my series this has been changed slightly to be
board_init_f calls
memset and then board_init_r directly. So this patch should
not be needed once rebased on that series.
Do we need to do all the relocation in assembler code btw? Can
it not be moved into C code and made generic across all
platforms (module the stack adjustment and a few minor things)
?
I think people have posted patches for this before and yes, once
CONFIG_NEEDS_MANUAL_RELOC dies it should be all possible to do in
C, so long as it doesn't grow in size or doesn't grow in size
that would be problematic (remember the 4kb people).
How does MANUAL_RELOC interfere with that? Eg. on ARM, it can
already be shifted to C. Then if we made it generic enough, those
MANUAL_RELOC platforms could simply adopt the C code.
Yes, one of the platforms that already has C code for ELF relocation
(x86, iirc) could be made more generic and I think someone (Graeme?)
already started this a long time ago as part of making a generic set
of functions for board_init_{f,r}. Just can't make it for all
platforms until everyone has ELF is the point I was poorly making.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQV2VKAAoJENk4IS6UOR1W3McP/1htBzFzXXPULGOO+1zanoaO
T2tmJZ9f4gHNIY6gnCdU7SlW4mhZPEFlwHD+JwPmIS7ZhGcPxVn9Vgl+r0fpEZHW
VBY1bGeSGmaLhziiT+9MmaUqKUx6IFN5nZX0ypYcHS1ZTo1JztvLSUrSdOnOYHWx
DXXPwNIreUctwIpyjNrhu93e39ep1AYb1ZW+o57Sj4+uGqt8+G9FpEjdxMQrjKqh
r88j7XRgfWNPiqLwuGy+7HHEXnQGDum3Aml/ojO3WSzpZYXZQ4zC4MTND+TwzSi6
h3+nB3OfYktPgFWRDYQt8VyWPl9beVHzhac3o6sF5SiclQyya0liCCNsSbDSKf/G
Zjpjg5cOAmPMMUs1ZXq2Ve5wMxb0alArzxZuMZ/ZA1gRDjazFErvYCUzAQFkDAZz
zB6YMNc1+iCaYyaeNOqvJdMOZXAIoGLx5bbv9dzsnYc45jeU1ScDywcOQC2jTYFf
jnzmqzh/6EJW2gfWW33XdxbHsDOZeEfCzJFmK7/vEbVW0TrkiCMJjHzf/jdguABQ
jhusLwYYJr5yNlwq16RmiPxIaUhBrCFLY5cxLiSTd4v0DdbqyaTC7MEadjKQLpBW
/LA5ImhXr/ORhfNTrVQjDSRhAGdmi2L0GVTurHJ2I6SCIVesu/ioMCGY3sy+aizK
H3jl0yobGtRNFamgK+Ld
=ncZ8
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
On 17-09-2012 18:56, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/17/12 10:08, José Miguel Gonçalves wrote:
On 17-09-2012 17:57, Tom Rini wrote:
On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves
wrote:
On 09/14/2012 08:01 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel
Gon?alves wrote:
On 14-09-2012 19:21, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
NAND Flash driver with HW ECC for the S3C24XX SoCs.
Currently it only supports SLC NAND chips.
Signed-off-by: Jos? Miguel Gon?alves
jose.goncal...@inov.pt
[...]
+#include common.h +#include nand.h +#include
asm/io.h +#include asm/arch/s3c24xx_cpu.h +#include
asm/errno.h + +#define MAX_CHIPS2 +static int
nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef
CONFIG_SPL_BUILD +#define printf(arg...) do {} while
(0)
This doesn't seem quite right ...
1) this should be in CPU directory 2) should be enabled
only if CONFIG_SPL_SERIAL_SUPPORT is not set 3) should be
inline function, not a macro
1) and 3) OK. Don't quite understand 2). I want to remove
the printfs in the SPL build, as it would blown up the
internal SoC RAM space available. So why add a condition
with CONFIG_SPL_SERIAL_SUPPORT?
You've got 8KB, based on the final patch in the series. At
least in my SPL series that's still enough to get you
printf/puts (I believe 4kb was the cutoff where that had to
be dropped).
Barely:
$ size u-boot-spl text databssdec
hexfilename 3337 8588 3933
f5du-boot-spl
$ size u-boot-spl-printf text databssdec
hexfilename 7968 8604 8580
2184 u-boot-spl-printf
The printf is not so important that justifies exhausting the
IRAM space available and preventing any future SPL
expansion...
There's two parts to this: - What else can you do in a single
binary, in theory? Is there boot medium detection and you would
want to have, for example, NAND and SD support in the same
binary? I would say memory is meant for using, but this is a
board maintainer decision and that's you :)
That's exactly what I've got in mind when I talked about a future
expansion! Being able to boot also from an SD card. With only 8KB
for .text and .data, I can not use printfs in the SPL for this
platform (at least with the present printf support for SPL).
- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that
toggles printf or no printf. If we really need to say yes to
LIBCOMMON_SUPPORT and no to printf, we need finer grained config
options and then a do-nothing printf is used for SPL. Doing the
opt-out driver by driver just punts this problem down the road to
the next developer and that's not very nice (and adding
CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few
Makefiles, update a bunch of config files, add
common/spl/dummy_funcs.c and a __weak printf).
OK, so please take a stab at option two, on top of my SPL series,
keeping in mind what Scott has said (which makes sense) because
otherwise you'll be changing a lot of MMC files too to drop out printf :)
The solution that I sorted out on the current SPL framework was to add this:
#ifdef CONFIG_SPL_BUILD
#define printf(arg...) do {} while (0)
#ifdef CONFIG_SPL_SERIAL_SUPPORT
#define puts(arg) serial_puts(arg)
#endif
#endif
on a CPU specific header. Marek told me to not use macros, but to use inline
functions instead, but has I told earlier on this thread, I am unable to do that.
Suggestions for doing this in a better way are welcome...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 4/5] OMAP: networking support for SPL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/17/12 10:54, Ilya Yanok wrote:
Hi Tom,
On Mon, Sep 17, 2012 at 9:04 PM, Tom Rini tr...@ti.com
mailto:tr...@ti.com wrote:
I agree it's not the best place... config_cmd_spl.h sounds a
little bit crazy as we don't have any commands at all in SPL...
How about config_uncmd_spl.h then and a nice big comment up top
Well, it will be at least less confusing...
explaining what we're doing. Or can we take another stab at
seeing why some stuff isn't being garbage collected? If
garbage_collected_func_a calls never_seen_while_linking_func, we
still succeed since we garbage collect the first func. There's
just the gcc issue I've noted before about strings.
That's not really about garbage collection in this case (net-spl).
I want to disable some functionality of generic net code not some
stuff used only by commands implementation. The confusion comes
from the fact that this code is protected by CONFIG_CMD_* defines.
So I guess the code construct is roughly:
function_we_need(...) {
#ifdef CONFIG_CMD_A
... stuff_spl_does_not_need();
#endif
...
}
? Otherwise we would end up building files we don't use, but then all
of the un-used code gets garbage collected.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIbBAEBAgAGBQJQV2bQAAoJENk4IS6UOR1WXNAP+MLdJeSu0x5xpbKEyURT6ISc
hKwYFO9esQRTnssp+0efz+RlYgAV1fet5pxhtn+RqMvA5XfWT413yZoEOg7XzsBE
TYcVs63TRuTDI5o0qgOryAQifY6GTFj1hw4BecAvODErJl7D6dtyGJjg4QWVUP4M
C1AFb0132ILlj5MSXCAC3d0ZYVNDqkIGl0BNGUSwOmZ8OT7IHi/x1tOUaKibOin6
wytrPXFwNxjvNeDVXe1Ot89Kx/t+kbNh6LDJLoIPK8SasuKdrtDxiQLCMMGGxT7R
vAS7//AqupWuzyWPdcQvM+YJetDKk/iYCy1FpYeo0yY1nKBHgh85lr6yBqjRnwKV
Tbh9ny41J1xd4AhIbRvEXirReZ/Zu3vEr01Qe+ddqgY+2mol0wucyhY2dgWlAn5G
jRCARRpEd8tIgzWBN5lxosHq+v7iltAOXZT/hHZpv19zzZ2KK3xG4CiqaZZvRS2B
DHWj2dOZW7CJGhCpYapLtCmxhh+M4X6YGflNCkiuQV9NGZjE3PhGh0N9QRQXBQjU
CzmY/cqWXG7QZ6NIlKyEG9nZMuFggSW2miHINGmk4G68rH6QfCpGilucOkN2LDjt
sE60qAIxRmkW2emn12V9dBU5CTyhgVetr0nYBD0PGO366Z+Xoq9sODG2aiQYdNTF
250WBWG235mtco6BNUw=
=v55G
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] gpt: Support for GPT (GUID Partition Table) restoration
On 09/13/2012 02:10 AM, Lukasz Majewski wrote: The restoration of GPT table (both primary and secondary) is now possible. Simple GUID generation is supported. diff --git a/include/part.h b/include/part.h +int set_gpt_table(block_dev_desc_t *dev_desc, + gpt_header *gpt_h, gpt_entry *gpt_e); The API here isn't very generic; it requires the caller to have formatted the GPT entirely by itself, which means having complete knowledge of how to lay out a GPT header and partition table entry. Right now, all that knowledge is contained inside the implementation of the gpt command - what if some other unrelated code wanted to write a GPT; it'd have to duplicate everything. I was thinking of a much more generic interface, where each partition is described using abstract structs, and the creation of the actual on-disk layout is handling inside the set_gpt_table() function. That would presumably allow the same abstract structs to be passed to e.g. set_mbr_partition_table() and a generic ptable create command to be created. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 4/5] OMAP: networking support for SPL
On Mon, Sep 17, 2012 at 10:07 PM, Tom Rini tr...@ti.com wrote:
That's not really about garbage collection in this case (net-spl).
I want to disable some functionality of generic net code not some
stuff used only by commands implementation. The confusion comes
from the fact that this code is protected by CONFIG_CMD_* defines.
So I guess the code construct is roughly:
function_we_need(...) {
#ifdef CONFIG_CMD_A
... stuff_spl_does_not_need();
#endif
...
}
? Otherwise we would end up building files we don't use, but then all
of the un-used code gets garbage collected.
Exactly.
Regards, Ilya.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 4/5] OMAP: networking support for SPL
BTW, I'm going to repost this serie soon. Shouldn't I rebase it on top of your SPL rework patches? Where can I find the tree? Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
On 09/17/2012 12:53:41 PM, Tom Rini wrote: On 09/17/12 10:32, Scott Wood wrote: On 09/17/2012 11:51:52 AM, Tom Rini wrote: On 09/17/12 09:27, Scott Wood wrote: On 09/17/2012 04:24:34 AM, José Miguel Gonçalves wrote: [snip] If no one else has anything against, I will change the name of the new target to u-boot-pad.bin What exactly is u-boot-pad.bin supposed to be? I hope that's not being proposed as the final output file the user sees. With old nand_spl we had u-boot-nand.bin for the final concatenated binary, but that's not appropriate for a generic spl. I think it would be better for the user to see u-boot.bin as the actual image to put on the boot device, regardless of implementation details like spl, if there's no requirement of a specific file format. The second stage could become u-boot-main.bin or similar on builds where spl is used. We need some name that means U-Boot SPL with U-Boot tacked on at the end. This can optionally be padded to a defined size to make writing to hardware easier. We also have the problem that u-boot.bin already means something so it needs to be clear. u-boot.bin has traditionally (except for nand_spl and derivatives) meant the final image ready to put into flash, after any platform-specific layout issues are taken care of (e.g. on mpc83xx it will have a reset control word embedded, on mpc85xx it will be padded to 512K with a reset vector at the end, etc.). That we did the tweaking in the linker script rather than after linking seems like an inconsequential implementation detail. Right, but it's also just objcopy (with OBJCFLAGS) -O binary of, and this is the biggie to me, just U-Boot. I further fear that even if we made an out directory if we put u-boot.bin in there and it's not the same as the objcopy -O binary u-boot u-boot.bin as before we've violated the rule of least surprise and the end user problems from people that read the document (that happened to be out of date) will be our problem. In this case I think you can't meet one user's expectations without violating another's. I think it's more important to make it clear to the user what file they're supposed to put into flash. Users of platforms that are currently supported by nand_spl would probably like to continue seeing u-boot-nand.bin -- it's a tradeoff of historical stability versus current consistency. Right. So I'm saying we need to set new expectations for everyone and some human helper symlinks to help. A new top-level out or images or something, with symlinks inside. How about something like u-boot-final.bin[1], u-boot-all.bin, u-boot-image.bin, etc. as the end-user output, with .bin changed to something else if it's a well known file type? At least for the boards that only require one output file. -Scott [1] Though then LDFLAGS_FINAL becomes confusing... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 4/5] OMAP: networking support for SPL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/17/12 11:10, Ilya Yanok wrote:
On Mon, Sep 17, 2012 at 10:07 PM, Tom Rini tr...@ti.com
mailto:tr...@ti.com wrote:
That's not really about garbage collection in this case
(net-spl). I want to disable some functionality of generic net
code not some stuff used only by commands implementation. The
confusion comes from the fact that this code is protected by
CONFIG_CMD_* defines.
So I guess the code construct is roughly: function_we_need(...) {
#ifdef CONFIG_CMD_A ... stuff_spl_does_not_need(); #endif ... }
? Otherwise we would end up building files we don't use, but then
all of the un-used code gets garbage collected.
Exactly.
OK, config_uncmd_spl.h, nice big comment and v6, thanks :)
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQV2m7AAoJENk4IS6UOR1WxuEP/RFkI74bRCQeKKjTTEjIhRJo
d1GQdX0GPJ0eFoMZ8ZX4Q1vo/j1VobTPABPu6DT0t/40biKrZvQu1EAf+i7Kct8c
P/90xoWI60L6gYo9/mKdxu5TDULbyg306RUr8D2KoXhmMm1w57Ug4LK/MXH3WcLk
rVMNJT6WXNDuAaHy8fM7ZxLIdDyuVlo4rqf6CgjKA4iE1LEyNf3RHE9PQn9780QJ
Eun4/sLN3ulBc94s6+I+OAY4HeBwXCxOlVjxu5ta/NnmY5OEMfMbwVl7ka2sLspt
R58ZxOJ3oSZbVL/joQ6zk6JnmWCX6Dku8M/V7eiryXMwx+F8rdYX+mcL3/0Jk337
2AzScXTzKMVQnv1IFuG+SlHMH0jEcsPsd/sa9C+mDQIfcwNby86uFs0Khj2kNAwq
0GWPdOvP+KKmdiaKpgth2vcvmJcln10p9YyB8K8MVwByDP9Mw+mlS4cxvr/yGf5V
3kDntGP9mpn6L1qp8MceKyz27gE9HkbTYGVk5r4TEwwwdahHiQ500UswivLDtO4V
IH1hzZsachaYyGlptiAvxw3ZpRQwQ2j7P/2s6G2uW1b4VoSYcDiT0uzYYYVqKi1u
u3jmpgH3Qse62rcZPg3gSqrwPFFhYV/6Ol+evcI6dk1I3o2a8wbMRJnSBZyqe0UV
/05A2dMTsdnNwpUe9f54
=QB8w
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem Booting RTEMS with u-boot on Phycore LPC3250
Dear Wolfgang, Where exactly did you get the U-Boot source code from? Various sources in fact: http://bitshrine.org/gpp/u-boot-1.3.3-lpc32xx.patch http://git.lpclinux.com/?p=uboot-2009.03-lpc32xx.git;a=summary http://git.lpclinux.com/?p=uboot-2011.12-lpc32xx.git;a=summary https://github.com/sobczyk/u-boot I think the problem might be related to the big size of .Work section. (About 63 MB while board's SRAM is 64 MB!) Is it possible that clearing .Work, collapses U-Boot which is stored in SRAM at 0x83fc? BTW, it is a little weird that U-Boot loads .start @ 0x8000 and then clears .vector at the same address: Loading .start @ 0x8000 (1120 bytes) Clearing .vector @ 0x8000 (5952 bytes) Might the problem be related to the wrong structure of my ELF file? Thanks, SAeeD On Mon, Sep 17, 2012 at 9:47 AM, Wolfgang Denk w...@denx.de wrote: Dear SAeeD, In message CAEdVrmO=+ abwhnxtog9rkwspnpqq8uzqtqot+_mtleu3-hr...@mail.gmail.com you wrote: I have built an RTEMS 4.10.2 elf image for Phycore LPC3250. I am using ... I have tried both u-boot 1.3.3 and u-boot 2009.03 and have not found any improvements. These are two very old versions. Forthermore, it appears that the Phycore LPC3250 is not supported in mainline U-Boot (mr what would the exact board name be?). Where exactly did you get the U-Boot source code from? 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 A equals success, then the formula is A = X + Y + Z. X is work. Y is play. Z is keep your mouth shut. - Albert Einstein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
On Mon, Sep 17, 2012 at 07:05:48PM +0100, Jos? Miguel Gon?alves wrote:
On 17-09-2012 18:56, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/17/12 10:08, Jos? Miguel Gon?alves wrote:
On 17-09-2012 17:57, Tom Rini wrote:
On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves
wrote:
On 09/14/2012 08:01 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel
Gon?alves wrote:
On 14-09-2012 19:21, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
NAND Flash driver with HW ECC for the S3C24XX SoCs.
Currently it only supports SLC NAND chips.
Signed-off-by: Jos? Miguel Gon?alves
jose.goncal...@inov.pt
[...]
+#include common.h +#include nand.h +#include
asm/io.h +#include asm/arch/s3c24xx_cpu.h +#include
asm/errno.h + +#define MAX_CHIPS2 +static int
nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef
CONFIG_SPL_BUILD +#define printf(arg...) do {} while
(0)
This doesn't seem quite right ...
1) this should be in CPU directory 2) should be enabled
only if CONFIG_SPL_SERIAL_SUPPORT is not set 3) should be
inline function, not a macro
1) and 3) OK. Don't quite understand 2). I want to remove
the printfs in the SPL build, as it would blown up the
internal SoC RAM space available. So why add a condition
with CONFIG_SPL_SERIAL_SUPPORT?
You've got 8KB, based on the final patch in the series. At
least in my SPL series that's still enough to get you
printf/puts (I believe 4kb was the cutoff where that had to
be dropped).
Barely:
$ size u-boot-spl text databssdec
hexfilename 3337 8588 3933
f5du-boot-spl
$ size u-boot-spl-printf text databssdec
hexfilename 7968 8604 8580
2184 u-boot-spl-printf
The printf is not so important that justifies exhausting the
IRAM space available and preventing any future SPL
expansion...
There's two parts to this: - What else can you do in a single
binary, in theory? Is there boot medium detection and you would
want to have, for example, NAND and SD support in the same
binary? I would say memory is meant for using, but this is a
board maintainer decision and that's you :)
That's exactly what I've got in mind when I talked about a future
expansion! Being able to boot also from an SD card. With only 8KB
for .text and .data, I can not use printfs in the SPL for this
platform (at least with the present printf support for SPL).
- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that
toggles printf or no printf. If we really need to say yes to
LIBCOMMON_SUPPORT and no to printf, we need finer grained config
options and then a do-nothing printf is used for SPL. Doing the
opt-out driver by driver just punts this problem down the road to
the next developer and that's not very nice (and adding
CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few
Makefiles, update a bunch of config files, add
common/spl/dummy_funcs.c and a __weak printf).
OK, so please take a stab at option two, on top of my SPL series,
keeping in mind what Scott has said (which makes sense) because
otherwise you'll be changing a lot of MMC files too to drop out printf :)
The solution that I sorted out on the current SPL framework was to add this:
#ifdef CONFIG_SPL_BUILD
#define printf(arg...) do {} while (0)
#ifdef CONFIG_SPL_SERIAL_SUPPORT
#define puts(arg) serial_puts(arg)
#endif
#endif
on a CPU specific header. Marek told me to not use macros, but to
use inline functions instead, but has I told earlier on this thread,
I am unable to do that. Suggestions for doing this in a better way
are welcome...
It's gotta go in common.h, and something like
/* Big comment what / why */
#if !defined(CONFIG_SPL_BUILD) || \
(CONFIG_SPL_BUILD CONFIG_SPL_PRINTF_SUPPORT)
void putc(...);
void puts(...);
int printf();
#else
#define putc(c) serial_putc(c)
#define puts(s) serial_puts(s)
#define printf(arg...) do {} while (0)
#endif
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
On 17-09-2012 19:27, Tom Rini wrote:
On Mon, Sep 17, 2012 at 07:05:48PM +0100, Jos? Miguel Gon?alves wrote:
On 17-09-2012 18:56, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/17/12 10:08, Jos? Miguel Gon?alves wrote:
On 17-09-2012 17:57, Tom Rini wrote:
On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves
wrote:
On 09/14/2012 08:01 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel
Gon?alves wrote:
On 14-09-2012 19:21, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
NAND Flash driver with HW ECC for the S3C24XX SoCs.
Currently it only supports SLC NAND chips.
Signed-off-by: Jos? Miguel Gon?alves
jose.goncal...@inov.pt
[...]
+#include common.h +#include nand.h +#include
asm/io.h +#include asm/arch/s3c24xx_cpu.h +#include
asm/errno.h + +#define MAX_CHIPS2 +static int
nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef
CONFIG_SPL_BUILD +#define printf(arg...) do {} while
(0)
This doesn't seem quite right ...
1) this should be in CPU directory 2) should be enabled
only if CONFIG_SPL_SERIAL_SUPPORT is not set 3) should be
inline function, not a macro
1) and 3) OK. Don't quite understand 2). I want to remove
the printfs in the SPL build, as it would blown up the
internal SoC RAM space available. So why add a condition
with CONFIG_SPL_SERIAL_SUPPORT?
You've got 8KB, based on the final patch in the series. At
least in my SPL series that's still enough to get you
printf/puts (I believe 4kb was the cutoff where that had to
be dropped).
Barely:
$ size u-boot-spl text databssdec
hexfilename 3337 8588 3933
f5du-boot-spl
$ size u-boot-spl-printf text databssdec
hexfilename 7968 8604 8580
2184 u-boot-spl-printf
The printf is not so important that justifies exhausting the
IRAM space available and preventing any future SPL
expansion...
There's two parts to this: - What else can you do in a single
binary, in theory? Is there boot medium detection and you would
want to have, for example, NAND and SD support in the same
binary? I would say memory is meant for using, but this is a
board maintainer decision and that's you :)
That's exactly what I've got in mind when I talked about a future
expansion! Being able to boot also from an SD card. With only 8KB
for .text and .data, I can not use printfs in the SPL for this
platform (at least with the present printf support for SPL).
- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that
toggles printf or no printf. If we really need to say yes to
LIBCOMMON_SUPPORT and no to printf, we need finer grained config
options and then a do-nothing printf is used for SPL. Doing the
opt-out driver by driver just punts this problem down the road to
the next developer and that's not very nice (and adding
CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few
Makefiles, update a bunch of config files, add
common/spl/dummy_funcs.c and a __weak printf).
OK, so please take a stab at option two, on top of my SPL series,
keeping in mind what Scott has said (which makes sense) because
otherwise you'll be changing a lot of MMC files too to drop out printf :)
The solution that I sorted out on the current SPL framework was to add this:
#ifdef CONFIG_SPL_BUILD
#define printf(arg...) do {} while (0)
#ifdef CONFIG_SPL_SERIAL_SUPPORT
#define puts(arg) serial_puts(arg)
#endif
#endif
on a CPU specific header. Marek told me to not use macros, but to
use inline functions instead, but has I told earlier on this thread,
I am unable to do that. Suggestions for doing this in a better way
are welcome...
It's gotta go in common.h, and something like
/* Big comment what / why */
#if !defined(CONFIG_SPL_BUILD) || \
(CONFIG_SPL_BUILD CONFIG_SPL_PRINTF_SUPPORT)
void putc(...);
void puts(...);
int printf();
#else
#define putc(c) serial_putc(c)
#define puts(s) serial_puts(s)
#define printf(arg...) do {} while (0)
#endif
Are macros OK to remove printf() and to replace putc()/puts() by
serial_putc()/serial_puts() in the SPL?
Shouldn’t we be using inline functions instead?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 4/5] OMAP: networking support for SPL
On Mon, Sep 17, 2012 at 1:55 PM, Ilya Yanok ilya.ya...@cogentembedded.comwrote: +#include common.h +#include net.h +#include asm/omap_common.h What in here needs this header? Looks like it's unneeded. Thanks, I'll remove it. Nope, it's needed for spl_parse_image_header. Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot's stack space on a Sequoia board
Dear Corey Ashford, In message 50575cb3.20...@linux.vnet.ibm.com you wrote: Please update, then try again. OK, and thank you for your quick reply. I don't have physical access to this board, but I'll ask around to find if this is something we can do. No physical access is needed for such an update (unless you botch it and need to access the BDI3000, or to switch the jumpers to boot the backup version from NAND - if you were clever enough to install one there first). 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 Be careful what you wish for. You never know who will be listening. - Terry Pratchett, _Soul Music_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/17/12 10:52, Marek Vasut wrote: I'm not sure if we want them in current release or next, I'll leave that to you to decide. I don't see much danger for current though. I believe all of this made it by the merge window and looks good. But in the future please only pull request code you believe to be ready for mainline. If you aren't sure, test it more, review it more and be sure. I'm relying on all of the custodians and their judgement of what is, and is not, ready to go. Thanks! - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQV2/qAAoJENk4IS6UOR1WlDcP+QExUWs63LzKcahlUrOsFftZ 1kx06ZquDPYPt2suR54VxV81bo7Iuf3i/XO6NU/jOQpBBPsuixB8ij1oRGB/glpd H05QckOhh8FYJYvoXpVEctHN2z/Tm3PcWR1gWfcVC8RmtDASpn8pxzLBC9x3iiSe qD0z8JBvSBghC5F/u7LW8twDXyDitL7VZEE59sbzKrSvpHW/nH+1rMbvQzXX57QQ abogaI+XNNJWUskm7BRXqfE5tPwE2pABXkVXv7pFEqMAXl53iJVWBEvskFyHsBwv UdzCxMHMs3ktbBpAX1vtBxsCPIW0Egc1pLdq9CZxisTHsaQ0C6fUcxYIJFHlSiaB dhCZfMhp+v90HdDm8p5ZhDJPEwUosYVGUqiSqgVQLcgFT3xfsq7uP1JsAIay6jDG DtlKMKkFOkiQgM1lt7RP6DnG9CyHojqOFUQ5Rlv7dP7e3o2utf5F51pyPGvrOR3S HOIVS/MH9AIPNrNeVywYmROPCBtOmESCsHogDpY/iil/qRgL0+YFUumWc2vadRvT MoL81OwLBmMDOfC6X6krz4XYswHIAhHGWyoOrMo+KZQIFrQxZOYoqNGGvsh5lklc dDwAaOl0HCEOGuv53oi/UrdR/gcNlt3L+obhPzngJjRUwavns2i6M2MPqPsakTE0 13vCk0tMCfQ7yARkiT/6 =Dnsj -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/17/12 11:34, José Miguel Gonçalves wrote:
On 17-09-2012 19:27, Tom Rini wrote:
On Mon, Sep 17, 2012 at 07:05:48PM +0100, Jos? Miguel Gon?alves
wrote:
On 17-09-2012 18:56, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
On 09/17/12 10:08, Jos? Miguel Gon?alves wrote:
On 17-09-2012 17:57, Tom Rini wrote:
On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel
Gon?alves wrote:
On 09/14/2012 08:01 PM, Tom Rini wrote:
On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos?
Miguel Gon?alves wrote:
On 14-09-2012 19:21, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
NAND Flash driver with HW ECC for the S3C24XX
SoCs. Currently it only supports SLC NAND
chips.
Signed-off-by: Jos? Miguel Gon?alves
jose.goncal...@inov.pt
[...]
+#include common.h +#include nand.h
+#include asm/io.h +#include
asm/arch/s3c24xx_cpu.h +#include
asm/errno.h + +#define MAX_CHIPS2 +static
int nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef
CONFIG_SPL_BUILD +#define printf(arg...) do {}
while (0)
This doesn't seem quite right ...
1) this should be in CPU directory 2) should be
enabled only if CONFIG_SPL_SERIAL_SUPPORT is not
set 3) should be inline function, not a macro
1) and 3) OK. Don't quite understand 2). I want to
remove the printfs in the SPL build, as it would
blown up the internal SoC RAM space available. So
why add a condition with
CONFIG_SPL_SERIAL_SUPPORT?
You've got 8KB, based on the final patch in the
series. At least in my SPL series that's still
enough to get you printf/puts (I believe 4kb was the
cutoff where that had to be dropped).
Barely:
$ size u-boot-spl text databss
dec hexfilename 3337 8588
3933 f5du-boot-spl
$ size u-boot-spl-printf text databss
dec hexfilename 7968 8604
8580 2184 u-boot-spl-printf
The printf is not so important that justifies
exhausting the IRAM space available and preventing any
future SPL expansion...
There's two parts to this: - What else can you do in a
single binary, in theory? Is there boot medium detection
and you would want to have, for example, NAND and SD
support in the same binary? I would say memory is meant
for using, but this is a board maintainer decision and
that's you :)
That's exactly what I've got in mind when I talked about a
future expansion! Being able to boot also from an SD card.
With only 8KB for .text and .data, I can not use printfs in
the SPL for this platform (at least with the present printf
support for SPL).
- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT)
that toggles printf or no printf. If we really need to
say yes to LIBCOMMON_SUPPORT and no to printf, we need
finer grained config options and then a do-nothing printf
is used for SPL. Doing the opt-out driver by driver just
punts this problem down the road to the next developer
and that's not very nice (and adding
CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch,
modify a few Makefiles, update a bunch of config files,
add common/spl/dummy_funcs.c and a __weak printf).
OK, so please take a stab at option two, on top of my SPL
series, keeping in mind what Scott has said (which makes
sense) because otherwise you'll be changing a lot of MMC
files too to drop out printf :)
The solution that I sorted out on the current SPL framework was
to add this:
#ifdef CONFIG_SPL_BUILD #define printf(arg...) do {} while (0)
#ifdef CONFIG_SPL_SERIAL_SUPPORT #define puts(arg)
serial_puts(arg) #endif #endif
on a CPU specific header. Marek told me to not use macros, but
to use inline functions instead, but has I told earlier on this
thread, I am unable to do that. Suggestions for doing this in a
better way are welcome...
It's gotta go in common.h, and something like /* Big comment
what / why */ #if !defined(CONFIG_SPL_BUILD) || \
(CONFIG_SPL_BUILD CONFIG_SPL_PRINTF_SUPPORT) void putc(...);
void puts(...); int printf(); #else #define putc(c)
serial_putc(c) #define puts(s) serial_puts(s) #define
printf(arg...) do {} while (0) #endif
Are macros OK to remove printf() and to replace putc()/puts() by
serial_putc()/serial_puts() in the SPL? Shouldn’t we be using
inline functions instead?
As Scott pointed out, inline won't remove the string constants from
the binary so it will still be possibly too large, depending on all of
the code in question. And note the above isn't 100% right, we need a
test for SERIAL_SUPPORT in there too.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQV3JcAAoJENk4IS6UOR1WMe0P/RlvfaE4J6ZxdIAIy77XmqGt
KKTEnJV+dTu8/a9jrMZFmZ/lGNPNrujLlphNUgGZr2W1+lriHuCgAZx1ObsMXhx9
XGRn05gshUuUtTWRCpOy3Nzo9jPF/LYrWttBiwDfOPWZ6+6G3zGPIXV3T9HHEFMM
ti0c0zCBMu1ci5RoQg4Zb6CJqJR/giBrBzegQZlL4x8t9p/GR03MSxdVPHx+NoQ7
[U-Boot] [PATCH] mx51evk: Add CONFIG_REVISION_TAG
FSL 2.6.35 kernel assumes that the bootloader passes the CONFIG_REVISION_TAG
information.
If this data is not present, the kernel misconfigures the TZIC, which results in
the timer interrupt handler never being called, so the kernel deadlocks while
calibrating its delay.
Suggested-by: Greg Topmiller greg.topmil...@jdsu.com
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
Cc: Stefano Babic sba...@denx.de
Cc: Fabio Estevam feste...@gmail.com
---
.../board/freescale/mx51evk/mx51evk.c |5 +
.../include/configs/mx51evk.h |1 +
2 files changed, 6 insertions(+)
diff --git u-boot-imx-1d9b033.orig/board/freescale/mx51evk/mx51evk.c
u-boot-imx-1d9b033/board/freescale/mx51evk/mx51evk.c
index 7a0682a..2e877c1 100644
--- u-boot-imx-1d9b033.orig/board/freescale/mx51evk/mx51evk.c
+++ u-boot-imx-1d9b033/board/freescale/mx51evk/mx51evk.c
@@ -60,6 +60,11 @@ int dram_init(void)
return 0;
}
+u32 get_board_rev(void)
+{
+ return get_cpu_rev();
+}
+
static void setup_iomux_uart(void)
{
unsigned int pad = PAD_CTL_HYS_ENABLE | PAD_CTL_PKE_ENABLE |
diff --git u-boot-imx-1d9b033.orig/include/configs/mx51evk.h
u-boot-imx-1d9b033/include/configs/mx51evk.h
index ba4a4a6..7b027b4 100644
--- u-boot-imx-1d9b033.orig/include/configs/mx51evk.h
+++ u-boot-imx-1d9b033/include/configs/mx51evk.h
@@ -44,6 +44,7 @@
#define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */
#define CONFIG_SETUP_MEMORY_TAGS
#define CONFIG_INITRD_TAG
+#define CONFIG_REVISION_TAG
#define CONFIG_OF_LIBFDT
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix checkpatch warnings about externs in *.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/16/12 05:59, Pavel Herrmann wrote: On Sunday 16 September 2012 14:37:16 Marek Vasut wrote: Dear Pavel Herrmann, ... Won't include/sata.h work just fine ? I feel include/sata.h is a consumer-facing header, and implementation details such as the array used for all data-retention for command and drivers should not be there. But it needs to be in sync with common/cmd_sata.c which is where both that and sata_curr_device are defined. So please use sata.h. I will also state this doesn't seem to be ideal but it's how our sata subsystem is setup currently. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQV3RiAAoJENk4IS6UOR1WszYP/jK3Llu0R1H4a57Me1k56Afu qniSbmI9pNr8eA6Bf5NxC7clvnK6HOBHWMegX6V42P4Dxy2/Bhod0K24RppsWaFs Wj604F+3gWWy/fhCojw6kVyzjV2WBlBse51XBHEMjNa5Ftf33lOKxr2mHNG5XrSD IL9uxRTwlwhKhs/WJ8HwH3C4Eo/zBG2AoIXbqmoyvqr/7gqGcERdo7NWtHPUrLwB smgJkL6t91MULlZc/RMwGTtX7CoKv0YbM+swWqY3rBQ7jQrP31vH8e6R9CfDr9nV ynZarYwTC4gy+qC7z7dLbutJHPdHcVv7SPJXh1fKUlpgOssbRKB7bxG/Gw9k52Pf ZtvnOP91pIKckAZ6EpgFrpYDf7B6fujjg4Z8hbCORBx3l45tmYxAbCnaAeO0Gn/r fbW78jElfOewr0QDpbTor1yorK9Qidf8Y2lujs9VtR7Gek2jIYIedtL/hPcG7Awa 7yI0qfLXPe/wo6eoQphoARtFf/oM2URlPAzyB1smJB85ytn8AR8J98O1JnzPbY+E 2foQ9g/wcKCeWRZohCjOyVK7cJ2kX618GJOukLXKzQVIxRQBkf2fdDocE2FbD9LW uAbSL0k6HT7TKugBh8FNolhNfOggyFONK/A4UQ+rQmsgTZ2dWvvDnr53Lyv5KagS 1OJ5YAkwIxUJpiaCQNLl =0CLe -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
Dear Tom Rini, On 09/17/12 10:52, Marek Vasut wrote: I'm not sure if we want them in current release or next, I'll leave that to you to decide. I don't see much danger for current though. I believe all of this made it by the merge window and looks good. It's been stuck in there for a while, yes. But in the future please only pull request code you believe to be ready for mainline. If you aren't sure, test it more, review it more and be sure. I'm relying on all of the custodians and their judgement of what is, and is not, ready to go. Thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
Dear Tom Rini, In message 505763a5.1030...@ti.com you wrote: Right. So I'm saying we need to set new expectations for everyone and some human helper symlinks to help. A new top-level out or images or something, with symlinks inside. Why would we need that? For the end user, any name is good enough, as long as it's clearly documented which file to use, and what exactly to do with it. There are so many different boot formatrequirements, that we canot expect to come up with good names for all of these in any way that matches all people's expectations because everything is completely self-explanatory. Make it simple, and handle it in the documentation. I think we're running into PowerPC vs ARM fun. We've got 7 or so different whack the image for this SoC for this medium type things already. I don't think it's an PPC versus ARM issue It's more an good old times versus brave new world thing. Actually Shakespeare's verses apply fully to many of teh recent SoC designs - be these PPC or ARM or whatever based: O wonder! How many goodly creatures are there here! How beauteous mankind is! O brave new world, That has such people in't. —William Shakespeare, The Tempest, Act V, Scene I, ll. 203—6 Thinking about features, boot image formats, boot device selection and other boot requirements of the ROM boot loaders of any recent SoC indeed makes me wonder How many goodly creatures are there here! PS: The good in this reference is to be understood in the same sense as the best in the name of the MPC5200 BestComm DMA controller. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In the long run, every program becomes rococo, and then rubble. - Alan Perlis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
On Mon, Sep 17, 2012 at 07:52:26PM +0200, Marek Vasut wrote: I'm not sure if we want them in current release or next, I'll leave that to you to decide. I don't see much danger for current though. The following changes since commit a6f0c4faa4c65a7b7048b12c9d180d7e1aad1721: Merge branch 'master' of git://git.denx.de/u-boot-avr32 (2012-09-04 09:17:27 +0200) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 8187c2dcbd3e47ecfef406468c8eee1fe746b8e7: usb: do explicit unaligned accesses (2012-09-06 08:02:08 +0200) Lucas Stach (5): usb: lowlevel interface change to support multiple controllers usb: ehci: rework to take advantage of new lowlevel interface usb: add support for multiple usb controllers tegra20: port to new ehci interface usb: do explicit unaligned accesses ??ukasz Majewski (2): dfu:usb: Support for ext4 dfu:usb:fix: Read the filesize environment variable only when file read arch/arm/cpu/arm920t/s3c24x0/usb_ohci.c |4 +-- arch/arm/cpu/armv7/tegra20/usb.c | 15 +++-- arch/arm/include/asm/arch-tegra20/usb.h |4 +-- arch/arm/include/asm/ehci-omap.h | 10 +- arch/mips/cpu/mips32/au1x00/au1x00_usb_ohci.c |4 +-- arch/powerpc/cpu/mpc5xxx/usb_ohci.c |4 +-- arch/powerpc/cpu/ppc4xx/usb_ohci.c|4 +-- arch/sparc/cpu/leon3/usb_uhci.c |4 +-- arch/sparc/lib/bootm.c|2 +- board/htkw/mcx/mcx.c |6 ++-- board/mpl/common/usb_uhci.c |4 +-- board/technexion/twister/twister.c|6 ++-- board/teejet/mt_ventoux/mt_ventoux.c |6 ++-- board/ti/beagle/beagle.c |6 ++-- board/ti/panda/panda.c|6 ++-- common/cmd_usb.c | 16 ++--- common/usb.c | 108 + common/usb_hub.c | 16 + common/usb_storage.c |2 +- drivers/dfu/dfu_mmc.c | 34 +++ drivers/usb/eth/usb_ether.c |2 +- drivers/usb/host/ehci-armada100.c | 15 - drivers/usb/host/ehci-atmel.c | 11 +++ drivers/usb/host/ehci-core.h | 29 - drivers/usb/host/ehci-exynos.c| 15 - drivers/usb/host/ehci-fsl.c | 11 +++ drivers/usb/host/ehci-hcd.c | 131 +- drivers/usb/host/ehci-ixp4xx.c| 15 - drivers/usb/host/ehci-marvell.c | 15 - drivers/usb/host/ehci-mpc512x.c | 25 ++ drivers/usb/host/ehci-mx5.c | 11 +++ drivers/usb/host/ehci-mx6.c | 11 +++ drivers/usb/host/ehci-mxc.c | 11 +++ drivers/usb/host/ehci-mxs.c | 28 +--- drivers/usb/host/ehci-omap.c | 10 +++--- drivers/usb/host/ehci-pci.c | 15 - drivers/usb/host/ehci-ppc4xx.c| 11 +++ drivers/usb/host/ehci-tegra.c | 14 drivers/usb/host/ehci-vct.c |9 +++--- drivers/usb/host/ehci.h |4 +-- drivers/usb/host/isp116x-hcd.c|4 +-- drivers/usb/host/ohci-hcd.c |4 +-- drivers/usb/host/r8a66597-hcd.c |4 +-- drivers/usb/host/sl811-hcd.c |4 +-- drivers/usb/musb/musb_hcd.c |4 +-- include/usb.h | 10 -- include/usb/mv_udc.h |2 +- 47 files changed, 352 insertions(+), 334 deletions(-) delete mode 100644 drivers/usb/host/ehci-core.h This breaks at least: ARM: m28evk apx4devkit sc_sps_1 mx28evk PowerPC: Everything that uses ehci-fsl.c, the first of which I saw was P2020RDB_36BIT but there's approx 141 boards total broken with MAKEALL -a powerpc. Rejected, please re-work. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 2/4] OMAP: spl: call timer_init() from SPL
We need to initialize timer properly, otherwise all delays inside SPL will be wrong. Signed-off-by: Ilya Yanok ilya.ya...@cogentembedded.com --- Changes in v6: - fix typo in patch name arch/arm/cpu/armv7/omap-common/spl.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/cpu/armv7/omap-common/spl.c b/arch/arm/cpu/armv7/omap-common/spl.c index 4d1ac85..f0d766c 100644 --- a/arch/arm/cpu/armv7/omap-common/spl.c +++ b/arch/arm/cpu/armv7/omap-common/spl.c @@ -152,6 +152,8 @@ void board_init_r(gd_t *id, ulong dummy) mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START, CONFIG_SYS_SPL_MALLOC_SIZE); + timer_init(); + #ifdef CONFIG_SPL_BOARD_INIT spl_board_init(); #endif -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 0/4] OMAP: SPL networking support
These series provides support for networking in SPL. In this version some effort is done to minimize the resulting SPL size and now Net-only SPL is 50KB in size. So theoretically it can be used on boards with enough SRAM space like AM3517. But real testing was done only on AM335x. Changes in v3: - use BOOTP in SPL regardless of CONFIG_CMD_DHCP - add support for setting different VCI in SPL - set Vendor Class Identifier for SPL Changes in v4: - used strlen instead of sizeof - moved vci_strlen var inside macro - fix compilation of SPL's libcommon with CONFIG_HUSH_PARSER and CONFIG_BOOTD defined - rename spl_eth.c to spl_net.c - set ethact variable if device name is passed - SPL_BOARD_INIT is not needed anymore Changes in v5: - set up guards in cmd_nvedit.c more carefully - now we don't need command.c and only need main.c for show_boot_progress() so defined it to be noop and remove both files from SPL sources - SPL guards in command.c and main.c are no longer needed - add some guards in env_common.c - qsort.c is no longer needed - add guard to hashtable.c to save some space - undefine unneeded CONFIG_CMD_* while building SPL to save space Changes in v6: - fix typo in patch name - remove some unneeded changes introduced by earlier versions - switch clauses and use ifdef instead of ifndef - create new header config_uncmd_spl.h which undefines CONFIG_CMD_* options unneeded in SPL and include it last from config.h - remove explicit undefs from net/net.c and net/bootp.c Ilya Yanok (4): net/bootp: add VCI support for BOOTP also OMAP: spl: call timer_init() from SPL OMAP: networking support for SPL am335x_evm: enable networking in SPL arch/arm/cpu/armv7/omap-common/Makefile |3 ++ arch/arm/cpu/armv7/omap-common/spl.c | 11 +++ arch/arm/cpu/armv7/omap-common/spl_net.c | 52 ++ arch/arm/include/asm/omap_common.h |4 +++ common/Makefile |4 +++ common/cmd_nvedit.c |8 + common/env_common.c |7 ++-- include/bootstage.h |6 +++- include/config_uncmd_spl.h | 24 ++ include/configs/am335x_evm.h |5 ++- lib/Makefile |9 -- lib/hashtable.c |2 ++ lib/vsprintf.c |2 +- mkconfig |1 + net/bootp.c | 27 net/tftp.c |4 +++ spl/Makefile |3 ++ 17 files changed, 159 insertions(+), 13 deletions(-) create mode 100644 arch/arm/cpu/armv7/omap-common/spl_net.c create mode 100644 include/config_uncmd_spl.h -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 4/4] am335x_evm: enable networking in SPL
This patch adds support for networking in SPL on TI AM335x based boards. Vendor Class Identifier used by SPL during BOOTP is AM335x U-Boot SPL. Signed-off-by: Ilya Yanok ilya.ya...@cogentembedded.com --- Changes in v3: - set Vendor Class Identifier for SPL Changes in v4: - SPL_BOARD_INIT is not needed anymore include/configs/am335x_evm.h |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index a3752bc..1d69125 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -194,7 +194,7 @@ /* Defines for SPL */ #define CONFIG_SPL #define CONFIG_SPL_TEXT_BASE 0x402F0400 -#define CONFIG_SPL_MAX_SIZE(46 * 1024) +#define CONFIG_SPL_MAX_SIZE(101 * 1024) #define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR #define CONFIG_SPL_BSS_START_ADDR 0x8000 @@ -214,6 +214,9 @@ #define CONFIG_SPL_SERIAL_SUPPORT #define CONFIG_SPL_GPIO_SUPPORT #define CONFIG_SPL_YMODEM_SUPPORT +#define CONFIG_SPL_NET_SUPPORT +#define CONFIG_SPL_NET_VCI_STRING AM335x U-Boot SPL +#define CONFIG_SPL_ETH_SUPPORT #define CONFIG_SPL_LDSCRIPT$(CPUDIR)/omap-common/u-boot-spl.lds /* -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 3/4] OMAP: networking support for SPL
This patch adds support for networking in SPL. Some devices are
capable of loading SPL via network so it makes sense to load the
main U-Boot binary via network too. This patch tries to use
existing network code as much as possible. Unfortunately, it depends
on environment which in turn depends on other code so SPL size
is increased significantly. No effort was done to decouple network
code and environment so far.
Signed-off-by: Ilya Yanok ilya.ya...@cogentembedded.com
---
Changes in v3:
- use BOOTP in SPL regardless of CONFIG_CMD_DHCP
- add support for setting different VCI in SPL
Changes in v4:
- fix compilation of SPL's libcommon with CONFIG_HUSH_PARSER
and CONFIG_BOOTD defined
- rename spl_eth.c to spl_net.c
- set ethact variable if device name is passed
Changes in v5:
- set up guards in cmd_nvedit.c more carefully
- now we don't need command.c and only need main.c for
show_boot_progress() so defined it to be noop and remove
both files from SPL sources
- SPL guards in command.c and main.c are no longer needed
- add some guards in env_common.c
- qsort.c is no longer needed
- add guard to hashtable.c to save some space
- undefine unneeded CONFIG_CMD_* while building SPL to save space
Changes in v6:
- remove some unneeded changes introduced by earlier versions
- switch clauses and use ifdef instead of ifndef
- create new header config_uncmd_spl.h which undefines CONFIG_CMD_*
options unneeded in SPL and include it last from config.h
- remove explicit undefs from net/net.c and net/bootp.c
arch/arm/cpu/armv7/omap-common/Makefile |3 ++
arch/arm/cpu/armv7/omap-common/spl.c |9 ++
arch/arm/cpu/armv7/omap-common/spl_net.c | 52 ++
arch/arm/include/asm/omap_common.h |4 +++
common/Makefile |4 +++
common/cmd_nvedit.c |8 +
common/env_common.c |7 ++--
include/bootstage.h |6 +++-
include/config_uncmd_spl.h | 24 ++
lib/Makefile |9 --
lib/hashtable.c |2 ++
lib/vsprintf.c |2 +-
mkconfig |1 +
net/bootp.c |7 +++-
net/tftp.c |4 +++
spl/Makefile |3 ++
16 files changed, 138 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/cpu/armv7/omap-common/spl_net.c
create mode 100644 include/config_uncmd_spl.h
diff --git a/arch/arm/cpu/armv7/omap-common/Makefile
b/arch/arm/cpu/armv7/omap-common/Makefile
index d37b22d..f042078 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -53,6 +53,9 @@ endif
ifdef CONFIG_SPL_YMODEM_SUPPORT
COBJS += spl_ymodem.o
endif
+ifdef CONFIG_SPL_NET_SUPPORT
+COBJS += spl_net.o
+endif
endif
ifndef CONFIG_SPL_BUILD
diff --git a/arch/arm/cpu/armv7/omap-common/spl.c
b/arch/arm/cpu/armv7/omap-common/spl.c
index f0d766c..53b9261 100644
--- a/arch/arm/cpu/armv7/omap-common/spl.c
+++ b/arch/arm/cpu/armv7/omap-common/spl.c
@@ -178,6 +178,15 @@ void board_init_r(gd_t *id, ulong dummy)
spl_ymodem_load_image();
break;
#endif
+#ifdef CONFIG_SPL_ETH_SUPPORT
+ case BOOT_DEVICE_CPGMAC:
+#ifdef CONFIG_SPL_ETH_DEVICE
+ spl_net_load_image(CONFIG_SPL_ETH_DEVICE);
+#else
+ spl_net_load_image(NULL);
+#endif
+ break;
+#endif
default:
printf(SPL: Un-supported Boot Device - %d!!!\n, boot_device);
hang();
diff --git a/arch/arm/cpu/armv7/omap-common/spl_net.c
b/arch/arm/cpu/armv7/omap-common/spl_net.c
new file mode 100644
index 000..cbb3087
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap-common/spl_net.c
@@ -0,0 +1,52 @@
+/*
+ * (C) Copyright 2000-2004
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * (C) Copyright 2012
+ * Ilya Yanok ilya.ya...@gmail.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc.
+ */
+#include common.h
+#include net.h
+#include asm/omap_common.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+void spl_net_load_image(const char *device)
+{
+ int rv;
+
+
[U-Boot] [PATCH v6 1/4] net/bootp: add VCI support for BOOTP also
Vendor Class Identifier option is common to BOOTP and DHCP and
can be useful without PXE. So send VCI in both BOOTP and DHCP
requests if CONFIG_BOOTP_VCI_STRING is defined.
Signed-off-by: Ilya Yanok ilya.ya...@cogentembedded.com
---
Changes in v4:
- used strlen instead of sizeof
- moved vci_strlen var inside macro
net/bootp.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/net/bootp.c b/net/bootp.c
index c9b8349..35b2e77 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -341,6 +341,15 @@ BootpTimeout(void)
}
}
+#define put_vci(e, str)\
+ do {\
+ size_t vci_strlen = strlen(str);\
+ *e++ = 60; /* Vendor Class Identifier */ \
+ *e++ = vci_strlen; \
+ memcpy(e, str, vci_strlen); \
+ e += vci_strlen;\
+ } while (0)
+
/*
* Initialize BOOTP extension fields in the request.
*/
@@ -352,7 +361,6 @@ static int DhcpExtended(u8 *e, int message_type, IPaddr_t
ServerID,
u8 *cnt;
#if defined(CONFIG_BOOTP_PXE)
char *uuid;
- size_t vci_strlen;
u16 clientarch;
#endif
@@ -437,12 +445,10 @@ static int DhcpExtended(u8 *e, int message_type, IPaddr_t
ServerID,
printf(Invalid pxeuuid: %s\n, uuid);
}
}
+#endif
- *e++ = 60; /* Vendor Class Identifier */
- vci_strlen = strlen(CONFIG_BOOTP_VCI_STRING);
- *e++ = vci_strlen;
- memcpy(e, CONFIG_BOOTP_VCI_STRING, vci_strlen);
- e += vci_strlen;
+#ifdef CONFIG_BOOTP_VCI_STRING
+ put_vci(e, CONFIG_VCI_STRING);
#endif
#if defined(CONFIG_BOOTP_VENDOREX)
@@ -529,6 +535,10 @@ static int BootpExtended(u8 *e)
*e++ = (576 - 312 + OPT_FIELD_SIZE) 0xff;
#endif
+#ifdef CONFIG_BOOTP_VCI_STRING
+ put_vci(e, CONFIG_VCI_STRING);
+#endif
+
#if defined(CONFIG_BOOTP_SUBNETMASK)
*e++ = 1; /* Subnet mask request */
*e++ = 4;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] i.MX6: mx6qsabrelite: Add splash screen support
Series includes one patch to fix a register name in imx6/crm_regs.h and a second that's a re-base of Fabio's patch from 5/31. http://patchwork.ozlabs.org/patch/162206/ Note that I'm not sure whether this should have been based on u-boot-video because it's video-related or u-boot imx because the bulk of the patch set is board-specific. arch/arm/include/asm/arch-mx6/crm_regs.h |6 ++- board/freescale/mx6qsabrelite/mx6qsabrelite.c | 90 + include/configs/mx6qsabrelite.h | 14 - 3 files changed, 108 insertions(+), 2 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] i.MX6: change register name for CCM_CHSCCDR to match ref. manual
Register CCM_CHSCCDR (offset 0x34 in CCM) is named CCM_CHSCCDR in
reference manual, but was named chscdr in struct mxc_ccm_reg.
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
arch/arm/include/asm/arch-mx6/crm_regs.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h
b/arch/arm/include/asm/arch-mx6/crm_regs.h
index 0e605c2..8388e38 100644
--- a/arch/arm/include/asm/arch-mx6/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
@@ -34,7 +34,7 @@ struct mxc_ccm_reg {
u32 cs1cdr;
u32 cs2cdr;
u32 cdcdr; /* 0x0030 */
- u32 chscdr;
+ u32 chsccdr;
u32 cscdr2;
u32 cscdr3;
u32 cscdr4; /* 0x0040 */
--
1.7.9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] i.MX6: mx6qsabrelite: Add splash screen support
Adds support for the Hannstar 1024 x 768 LVDS panel (Freescale part
number MCIMX-LVDS1) to SABRE-Lite board.
This commit is a rebase Fabio Estevan's patch from 5/31 to
u-boot-video/master:
http://patchwork.ozlabs.org/patch/162206/
Modifications include:
removal of i2c setup (unneeded)
cleanup of lcd_iomux to use struct mxc_ccm_reg and anatop_regs
and associated constants
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
arch/arm/include/asm/arch-mx6/crm_regs.h |4 +
board/freescale/mx6qsabrelite/mx6qsabrelite.c | 90 +
include/configs/mx6qsabrelite.h | 14 -
3 files changed, 107 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h
b/arch/arm/include/asm/arch-mx6/crm_regs.h
index 8388e38..cffc0a1 100644
--- a/arch/arm/include/asm/arch-mx6/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
@@ -294,6 +294,10 @@ struct mxc_ccm_reg {
#define MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_MASK (0x7)
#define MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_OFFSET0
+#define CHSCCDR_CLK_SEL_LDB_DI03
+#define CHSCCDR_PODF_DIVIDE_BY_3 2
+#define CHSCCDR_IPU_PRE_CLK_540M_PFD 5
+
/* Define the bits in register CSCDR2 */
#define MXC_CCM_CSCDR2_ECSPI_CLK_PODF_MASK (0x3F 19)
#define MXC_CCM_CSCDR2_ECSPI_CLK_PODF_OFFSET 19
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index 909ccca..22943b1 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -36,6 +36,9 @@
#include micrel.h
#include miiphy.h
#include netdev.h
+#include linux/fb.h
+#include ipu_pixfmt.h
+#include asm/arch/crm_regs.h
DECLARE_GLOBAL_DATA_PTR;
#define UART_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \
@@ -195,6 +198,10 @@ static iomux_v3_cfg_t button_pads[] = {
MX6Q_PAD_GPIO_18__GPIO_7_13 | MUX_PAD_CTRL(BUTTON_PAD_CTRL),
};
+iomux_v3_cfg_t lcd_gpio[] = {
+ MX6Q_PAD_SD1_CMD__GPIO_1_18 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
static void setup_iomux_enet(void)
{
gpio_direction_output(87, 0); /* GPIO 3-23 */
@@ -372,10 +379,84 @@ int setup_sata(void)
}
#endif
+static struct fb_videomode lvds_xga = {
+ .name = Hannstar-XGA,
+ .refresh= 60,
+ .xres = 1024,
+ .yres = 768,
+ .pixclock = 15385,
+ .left_margin= 220,
+ .right_margin = 40,
+ .upper_margin = 21,
+ .lower_margin = 7,
+ .hsync_len = 60,
+ .vsync_len = 10,
+ .sync = FB_SYNC_EXT,
+ .vmode = FB_VMODE_NONINTERLACED
+};
+
+void lcd_iomux(void)
+{
+ struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+ struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
+
+ int reg;
+ /* Turn on GPIO backlight */
+ imx_iomux_v3_setup_multiple_pads(lcd_gpio, ARRAY_SIZE(lcd_gpio));
+ gpio_direction_output(18, 1);
+
+ /* Turn on LDB0,IPU,IPU DI0 clocks */
+ reg = __raw_readl(mxc_ccm-CCGR3);
+ reg |= 0x300F;
+ writel(reg, mxc_ccm-CCGR3);
+
+ /* set PFD3_FRAC to 0x13 == 455 MHz (480*18)/0x13 */
+ writel(0x3F00, anatop-pfd_480_clr);
+ writel(0x1300, anatop-pfd_480_set);
+
+ /* set LDB0, LDB1 clk select to 011/011 */
+ reg = readl(mxc_ccm-cs2cdr);
+ reg = ~(MXC_CCM_CS2CDR_LDB_DI0_CLK_SEL_MASK
+|MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_MASK);
+ reg |= (3MXC_CCM_CS2CDR_LDB_DI0_CLK_SEL_OFFSET)
+ |(3MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_OFFSET);
+ writel(reg, mxc_ccm-cs2cdr);
+
+ reg = readl(mxc_ccm-cscmr2);
+ reg |= MXC_CCM_CSCMR2_LDB_DI0_IPU_DIV;
+ writel(reg, mxc_ccm-cscmr2);
+
+ reg = readl(mxc_ccm-chsccdr);
+ reg = ~(MXC_CCM_CHSCCDR_IPU1_DI0_PRE_CLK_SEL_MASK
+ |MXC_CCM_CHSCCDR_IPU1_DI0_PODF_MASK
+ |MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_MASK);
+ /* derive clock from LDB_DI0 */
+ /* divide by 3 */
+ /* derive clock from 540M PFD */
+ reg |= (CHSCCDR_CLK_SEL_LDB_DI0
+ MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_OFFSET)
+ |(CHSCCDR_PODF_DIVIDE_BY_3
+ MXC_CCM_CHSCCDR_IPU1_DI0_PODF_OFFSET)
+ |(CHSCCDR_IPU_PRE_CLK_540M_PFD
+ MXC_CCM_CHSCCDR_IPU1_DI0_PRE_CLK_SEL_OFFSET);
+ writel(reg, mxc_ccm-chsccdr);
+
+ writel(0x201, IOMUXC_BASE_ADDR + 0x8); /* 16 bpp */
+}
+
+void lcd_enable(void)
+{
+
+ int ret = ipuv3_fb_init(lvds_xga, 0, IPU_PIX_FMT_RGB666);
+ if (ret)
+ printf(LCD cannot be configured: %d\n, ret);
+}
+
int board_early_init_f(void)
{
setup_iomux_uart();
setup_buttons();
+ lcd_iomux();
return 0;
}
@@ -396,9 +477,18 @@ int
Re: [U-Boot] [PATCH 2/2] i.MX6: mx6qsabrelite: Add splash screen support
Hi Eric,
On Mon, Sep 17, 2012 at 5:20 PM, Eric Nelson
eric.nel...@boundarydevices.com wrote:
+int board_late_init(void)
+{
+ setenv(stdout, serial);
+ return 0;
+}
I was told not to do this way.
Please follow this approach instead:
commit 3e0773708dd4e502c127a589be5779708eb7ba69
Author: Stefano Babic sba...@denx.de
Date: Sun Aug 5 00:18:53 2012 +
MX5: mx53loco: do not overwrite the console
On this board, the console is always set to the serial line.
Do not allow to overwrite it when video is enabled.
Signed-off-by: Stefano Babic sba...@denx.de
CC: Fabio Estevam fabio.este...@freescale.com
Tested-by: Fabio Estevam fabio.este...@freescale.com
Regards,
Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] i.MX6: mx6qsabrelite: Add splash screen support
Hi Eric, On Mon, 17 Sep 2012 13:20:49 -0700 Eric Nelson eric.nel...@boundarydevices.com wrote: Series includes one patch to fix a register name in imx6/crm_regs.h and a second that's a re-base of Fabio's patch from 5/31. http://patchwork.ozlabs.org/patch/162206/ Note that I'm not sure whether this should have been based on u-boot-video because it's video-related or u-boot imx because the bulk of the patch set is board-specific. It should be based on u-boot-imx since it touches board files. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] video/powerpc: don't touch DIU registers that we don't need
Several DIU registers were being initialized either unnecessarily or to
wrong values.
1) All interrupts were enabled even though there's no interrupt handler.
Interrupts were left enabled when booting Linux.
2) Don't configure a dummy area descriptor, since we don't support ADs
in U-Boot.
3) Don't configure any write-back buffer registers, since we don't use
that mode.
4) The default values for the THRESHOLDS, SYN_POL, and PLUT registers
should be used, so don't touch those registers either.
Signed-off-by: Timur Tabi ti...@freescale.com
---
drivers/video/fsl_diu_fb.c | 21 ++---
1 files changed, 2 insertions(+), 19 deletions(-)
diff --git a/drivers/video/fsl_diu_fb.c b/drivers/video/fsl_diu_fb.c
index 648ffa3..a98cb67 100644
--- a/drivers/video/fsl_diu_fb.c
+++ b/drivers/video/fsl_diu_fb.c
@@ -271,7 +271,6 @@ int fsl_diu_init(u16 xres, u16 yres, u32 pixel_format, int
gamma_fix)
struct diu *hw = (struct diu *)CONFIG_SYS_DIU_ADDR;
u8 *gamma_table_base;
unsigned int i, j;
- struct diu_ad *dummy_ad;
struct diu_addr gamma;
struct diu_addr cursor;
@@ -302,14 +301,6 @@ int fsl_diu_init(u16 xres, u16 yres, u32 pixel_format, int
gamma_fix)
return -1;
}
- /* The AD struct for the dummy framebuffer and the FB itself */
- dummy_ad = allocate_fb(2, 4, 4, NULL);
- if (!dummy_ad) {
- printf(DIU: Out of memory\n);
- return -1;
- }
- dummy_ad-pix_fmt = 0x3316;
-
/* read mode info */
info.var.xres = fsl_diu_mode_db-xres;
info.var.yres = fsl_diu_mode_db-yres;
@@ -376,10 +367,7 @@ int fsl_diu_init(u16 xres, u16 yres, u32 pixel_format, int
gamma_fix)
out_be32(hw-gamma, gamma.paddr);
out_be32(hw-cursor, cursor.paddr);
out_be32(hw-bgnd, 0x007F7F7F);
- out_be32(hw-bgnd_wb, 0);
out_be32(hw-disp_size, info.var.yres 16 | info.var.xres);
- out_be32(hw-wb_size, 0);
- out_be32(hw-wb_mem_addr, 0);
out_be32(hw-hsyn_para, info.var.left_margin 22 |
info.var.hsync_len 11 |
info.var.right_margin);
@@ -388,18 +376,13 @@ int fsl_diu_init(u16 xres, u16 yres, u32 pixel_format,
int gamma_fix)
info.var.vsync_len 11 |
info.var.lower_margin);
- out_be32(hw-syn_pol, 0);
- out_be32(hw-thresholds, 0x00037800);
- out_be32(hw-int_status, 0);
- out_be32(hw-int_mask, 0);
- out_be32(hw-plut, 0x01F5F666);
/* Pixel Clock configuration */
diu_set_pixel_clock(info.var.pixclock);
/* Set the frame buffers */
out_be32(hw-desc[0], virt_to_phys(ad));
- out_be32(hw-desc[1], virt_to_phys(dummy_ad));
- out_be32(hw-desc[2], virt_to_phys(dummy_ad));
+ out_be32(hw-desc[1], 0);
+ out_be32(hw-desc[2], 0);
/* Enable the DIU, set display to all three planes */
out_be32(hw-diu_mode, 1);
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 15/16] arm:trats:pmic: Support for charging battery at Samsung's TRATS board
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/17/12 13:55, Lukasz Majewski wrote: Hi Tom , If I read this right we'll pause in the middle of start up to charge the battery for possibly a long time right? And this could be a while loop even, yes? If so to the first one, this really should be under some sort of CONFIG option. This is one of the options. Other option is to extend the pmic/power command to: pmic charger on/off to recharge battery when needed. I think, that above is a better solution. I know the value of showing proof of concept type examples in development boards but that should still be an opt-in thing I would think. Yes, indeed this shall be regarded as a proof-of-concept to show that battery is automatically charged when needed. Instead, I think, that it would be a good idea to write a warning on the u-boot starting (when PMIC driver is initialized): e.g. WARNING: Battery needs charging (voltage: 3.5V capacity: 8%) And then user can on its own decide if he/she will charge the battery or not. Yes, sounds good, thanks! - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQV5XMAAoJENk4IS6UOR1WnXYP/iZdtirR6Rflcp/YZSna/ld0 SsW0cW8fGT+Hy44T2pOsd4m0ne/WnTq6EUPJqQ1xs+ZIjj55Uh2ngLdc3/PpMC10 mi+vzm3E1wi8Wm83205r+7DAWnD20JXE413WimaBnP+EbVJzBjtZDFyFwtpvKnFd G2SyVyUsyBATsMFpfz7yFwNPYB9JoG/XgsLK64nP3wCVt/gSB6hE+ZBrRQgKvvsn AvQV3JhZbPMSWIj9Qq1qY8ReA2fC5SXBft/mcOt6cee7dTlaTzXkK3dxDQkmzOF8 l1Lhm3h/QMQ6/+mlghk9tZmfR7kXH54Ak0tZWLXQiT86namTymvgQ/SyOE8B0Rf8 p0+rD6X9WcuirhyeoKOmQS/cx6S1evNuPXJiRRGN3Y52nwWEnYlsDyDWEOqqLa70 466hdJhLm14HguJCsRbjs2l+rJ4pRj0WaKio7dq3uk0ojwueZRqSZyI6UEBQLMQU NBZExliUI+6TNBFVdmpaRe9cKVaDIbmtFWH8yl6xNAsU0MgOH15OsZOdQUO3bTgb sZPKHWKhiZbS16kMGGdvcb18up1qA/oXZJcnPD/rmyCQ4Tq/Z6eOt9CRwZyLss9p cUVb2PXJ6X4r6eTaK9HMAAk9zYZkk0pcmZcczsdcNhVv3MJlxwmNEfYY6RXfRdaI Dh3242syeDsez5ZQ3Uou =v4oy -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] using initrd with U-boot on the imx28evk
Dear Bill, I'm CCing Fabio ... he might have some idea for you. Marek, Yes, I checked the kernel and it is enabled for ramdisk support in Linux, gzip compression, and loop back block driver. I did find some other posts where some folks added the address of the ram drive. So I changed the kernel arguments from: setenv bootargs console=ttyAM0,115200n8 debug root=/dev/ram rw ip=dhcp fec_mac= TO: setenv bootargs console=ttyAM0,115200n8 debug root=/dev/ram rw initrd=0x4300,40K ip=dhcp fec_mac= And now the kernel output generates a additional error line from RAMDISK: ... ... ... RAMDISK: Couldn't find valid RAM disk image starting at 0. This line now appears on the console List of all partitions: b300 3872256 mmcblk0 driver: mmcblk b3011024 mmcblk0p1 0800 503808 sda driver: sd 0801 503792 sda1 No filesystem could mount root, tried: ext3 ext2 vfat msdos iso9660 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) ... ... ... Is it something with the RAM disk format or the uboot tool mkimage parameters? Thanks, Bill On 9/12/2012 6:44 PM, Marek Vasut wrote: Dear Bill, I'm using U-boot version: U-Boot 2012.07 Through googling, I've come across several variations of using a ramdisk. So I selected some things that looked good. So basically, I am building a rootfs as a ramdisk by: dd if=/dev/zero of=./myinitrd.img bs=1M count=35 mke2fs -m 1 ./myinitrd.img mkdir ./myinitrd mount -t ext2 ./myinitrd.img ./myinitrd -o loop cp -r rootfs/* ./myinitrd/. umount ./myinitrd/ gzip ./myinitrd.img rm -rf myinitrd Then I use the u-boot tool to prepare it for use with u-boot by: u-boot-imx/tools/mkimage -n 'MyRamDisk' -A arm -O linux -T ramdisk -C none -d ./myinitrd.img.gz rootfs-initrd I place both both my uImage and rootfs-initrd on a USB stick and insert it into the imx28evk and enter u-boot command line. I then do: usb start fatload usb 0 0x4200 uimage fatload usb 0 0x4300 rootfs-initrd setenv bootargs console=ttyAM0,115200n8 debug root=/dev/ram rw ip=dhcp fec_mac= bootm 0x4200 0x4300 u-boot then starts booting with: ## Booting kernel from Legacy Image at 4200 ... Image Name: Linux-2.6.35.3-571-gcca29a0-g45b Created: 2012-09-08 22:31:46 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2582304 Bytes = 2.5 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 4300 ... Image Name: MyRamDisk Created: 2012-09-12 20:51:35 UTC Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size:37774 Bytes = 36.9 KiB Load Address: Entry Point: Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Linux version 2.6.35.3-571-gcca29a0-g45b53d0-dirty (blsousan@ubuntu) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #13 PREEMPT Sat Sep 8 14:06:34 PDT 2012 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 CPU: VIVT data cache, VIVT instruction cache Machine: Freescale MX28EVK board The kernel starts to boot, I get all the kernel output, and at the end it does not find the rootfs. I get: ... ... ... List of all partitions: b300 3872256 mmcblk0 driver: mmcblk b3011024 mmcblk0p1 0800 503808 sda driver: sd 0801 503792 sda1 No filesystem could mount root, tried: ext3 ext2 vfat msdos iso9660 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Backtrace: I not sure how the kernel knows where the ramdisk lives in memory ( 0x4300) where the the uboot put it ? Thanks, Bill On 9/12/2012 5:29 PM, Marek Vasut wrote: Dear Bill, Has anyone used U-boot on the imx28evk with initrd to setup a small rootfs in RAM? I need the ability to do have a small temp rootfs to assist in mounting a full rootfs from a USB for field upgrade purposes. Yes, it's a linux thingie though. What's the problem? What version of uboot do you use? Some ancient kernel you have ... did you enable ramdisk support in Linux? And gzip compression for it ? And loop back block driver ? Thanks, Bill 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] Cache alignment warnings on Tegra (ARM)
Hi Thierry, On Sat, Sep 15, 2012 at 11:49 PM, Thierry Reding thierry.red...@avionic-design.de wrote: On Sat, Sep 15, 2012 at 07:45:30PM -0700, Simon Glass wrote: Hi, On Sat, Sep 15, 2012 at 1:41 PM, Thierry Reding thierry.red...@avionic-design.de wrote: On Sat, Sep 15, 2012 at 10:11:54PM +0200, Marek Vasut wrote: Dear Thierry Reding, On Fri, Sep 14, 2012 at 08:53:32AM -0700, Simon Glass wrote: Hi, On Wed, Sep 12, 2012 at 4:42 PM, Marek Vasut ma...@denx.de wrote: Dear Stephen Warren, On 09/12/2012 04:38 PM, Marek Vasut wrote: Dear Stephen Warren, On 09/12/2012 10:19 AM, Tom Warren wrote: Folks, Stephen Warren has posted an internal bug regarding the cache alignment 'warnings' seen on Tegra20 boards when accessing MMC. Here's the gist: Executing mmc dev 0 still yields cache warnings: Tegra20 (Harmony) # mmc dev 0 ERROR: v7_dcache_inval_range- stop address is not aligned- 0x3fb69908 mmc0 is current device ... There have been patches in the past (IIRC) that have tried to ensure all callers (FS, MMC driver, USB driver, etc.) force their buffers to the appropriate alignment, but I don't know that we can ever correct every instance, now or in the future. Can we start a discussion about what we can do about this warning? Adding an appropriate #ifdef (CONFIG_SYS_NO_CACHE_ALIGNMENT_WARNINGS, etc.) where Stephen put his #if 0's would be one approach, or changing the printf() to a debug(), perhaps. As far as I can tell, these alignment 'errors' don't seem to produce bad data in the transfer. I don't think simply turning off the warning is the correct approach; I believe they represent real problems that can in fact cause data corruption. I don't believe we have any choice other than to fully solve the root-cause. Yes I agree, and I think it is pretty close - certainly much better than it used to be. The good thing about them being annoying is that they will likely get fixed :-) I think I traced this to the copying of CSD a while back. The problem is that the transferred buffer is 8 bytes, so there's no way to make it aligned properly. Unfortunately the entailing discussion did not yield a solution at the time. And how exactly does the MMC bounce buffer not help here? The problem solved by the bounce buffer is that it is properly cache- line aligned. However the issue here is not that the buffer is not properly aligned but rather that the transfer is too small. When the MMC core transfers the SCR, it requests 8 bytes. The buffer used to store these 8 bytes is properly allocated. However, those 8 bytes eventually end up as the size of the range that is to be invalidated. This is the reason for the warning. Address x of the buffer is cache-line aligned, but x + 8 is never properly aligned and therefore the code complains. Would it be too dreadful to define a minimum MMC transfer size, and set that to the cache line size? I did try setting the data size to the cache line size back then, but that resulted in an error. After that I gave up. I think what we really need to do is separate the invalidation size from the transfer size in order to properly handle these situations. Or alternatively pass an additional buffer size so the code knows how much needs to be invalidated. AFAICT this is the only location where this actually happens. All other transfers are typically block sized so they'll be a multiple of the cache line anyway. I suppose the requirement is that the buffer size is large enough, and is aligned. Even if fewer bytes are transferred than the size of the buffer, that still solves the problem. As you say, if we had a way of saying 'here is a 64-byte buffer but only 16 bytes need to be transferred' then we would be good. If this is really just an MMC problem then perhaps the fix can be localised there. Regards, Simon Thierry ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] using initrd with U-boot on the imx28evk
Bill, On Mon, Sep 17, 2012 at 6:31 PM, Marek Vasut ma...@denx.de wrote: Dear Bill, I'm CCing Fabio ... he might have some idea for you. What about starting a thread in linux-arm-kernel for this? Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
