Re: [U-Boot] [PATCH v3] mx6: Read silicon revision from register
-Original Message-
From: Fabio Estevam [mailto:feste...@gmail.com]
Sent: Wednesday, March 14, 2012 10:57 AM
To: u-boot@lists.denx.de
Cc: sba...@denx.de; eric.nel...@boundarydevices.com;
dirk.be...@de.bosch.com; Liu Hui-R64343; Estevam Fabio-R49496
Subject: [PATCH v3] mx6: Read silicon revision from register
Instead of hardcoding the mx6 silicon revision, read it in run-time.
Also, besides the silicon version also print the mx6 variant type: quad,
dual/solo or solo-lite.
Tested on a mx6qsabrelite, where it shows:
CPU: Freescale i.MX6Q rev1.0 at 792 MHz
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v2:
- Read both chip variant and chip silicon version from anatop
- Create a struct for accessing the anatop registers Changes since v1:
- Fix typo on Subject
arch/arm/cpu/armv7/imx-common/cpu.c | 19 +--
arch/arm/cpu/armv7/mx6/soc.c |8 +++-
arch/arm/include/asm/arch-mx6/imx-regs.h |5 +
3 files changed, 29 insertions(+), 3 deletions(-)
[...]
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 5ba5f39..9644807 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -294,5 +294,10 @@ struct aipstz_regs {
u32 opacr4;
};
+struct anatop_regs {
+ u8 rsvd[0x260]; /* To be completed as needed */
+ u32 siliconid;
+};
I'm afraid whether this is correct to add it here since some registers of
anatop was included into the ccm_reg.
ANATOP is a collection of analog and anadig. So, ANATOP register mostly is
consist of 4 parts:
ANADIG in CCM: for example: PLL/PFD,
ANAREG in power: internal analog regulator, power tree.
ANAUSB in usb: for usb vbus dection, charge, etc.
ANAMISC: misc feature, only one register now for the Chip Silicon Version
So the siliconid is in the last register.
Jason Liu
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] EXYNOS: Detect cpuid based on Exynos product codes
Exynos based SoC's have two different naming conventions.
One is S5PC_ and other is EXXX_. This patch adds
generic code to handle EXXX_ connvention.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
arch/arm/include/asm/arch-exynos/cpu.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/cpu.h
b/arch/arm/include/asm/arch-exynos/cpu.h
index 89f2c2e..da89ccf 100644
--- a/arch/arm/include/asm/arch-exynos/cpu.h
+++ b/arch/arm/include/asm/arch-exynos/cpu.h
@@ -105,10 +105,13 @@ static inline void s5p_set_cpu_id(void)
}
}
+#define EXYNOS_ID ((readl(EXYNOS4_PRO_ID) (0xF 24)) 24)
#define IS_SAMSUNG_TYPE(type, id) \
static inline int cpu_is_##type(void) \
{ \
- return s5p_cpu_id == id ? 1 : 0;\
+ return ((s5p_cpu_id == id) \
+ || (EXYNOS_ID == (#type[sizeof(#type) - 2] - '0'))) \
+ ? 1 : 0;\
}
IS_SAMSUNG_TYPE(exynos4, 0xc210)
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPI flash writing
On 03/14/2012 03:16 AM, Mike Frysinger wrote: On Tuesday 13 March 2012 17:31:02 Falauto, Gerlando wrote: From: Mike Frysinger [mailto:vap...@gentoo.org] On Tuesday 13 March 2012 16:17:52 Jason Cooper wrote: On Tue, Mar 13, 2012 at 04:11:29PM -0400, Mike Frysinger wrote: On Tuesday 13 March 2012 14:25:07 Gerlando Falauto wrote: 2) an out-of-boundary-check againts the flash size so at least a warning is issued when you use too big a size value i'm not sure about this. if you want to do size checking, then enable the hush shell and do it in a script. Is there a programatic way to get the size of the flash at runtime from the hush script? no. question is, do you really need that ? sounds like you know ahead of time how big the space is for u-boot, so the size of the flash doesn't matter. Can't the same command also be used for burning something *other than* u-boot (e.g. a kernel, config section, or something like that)? So the size of the flash *does matter*, doesn't it? you have to show how it actually does matter. when you deploy a board and programming the flash directly, you don't let the regions grow arbitrarily. you know how big the space for u-boot, or the kernel, or dedicated config space, or anything else is going to be. if you want to arbitrarily append things, then you're going to use a filesystem. -mike You're right, but I failed to stress enough one point. The thing is, if you issue e write (or erase) and accidentally cross the flash size boundary, you get a wraparound (or aliasing, or whatever you want to call it) so that you end up overwriting (e.g. zeroing out bits) the initial sectors of the flash. Which is where u-boot normally lies. [At least, that's the way I understand things are working right now.] I hope you'd agree that this is *a bad thing (TM)*. My concern is not about the fully aware u-boot developer, who normally has some other way to restore a dead board (JTAG, rom monitor, etc...). My conncern is about mistakes made by the absent-minded user who reads an upgrade procedure somewhere, puts an extra zero, and ends up bricking their board, whereas it could have been easily avoided. Thanks, Gerlando ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPI flash writing
On 03/14/2012 03:18 AM, Simon Glass wrote:
Hi Gerlando,
On Tue, Mar 13, 2012 at 11:25 AM, Gerlando Falauto
gerlando.fala...@keymile.com wrote:
Hi everyone,
[I took the liberty to Cc: Mike and Simon as they have provided patches in
the area]
I struggled for a while trying to update a Kirkwood-based board to the
latest u-boot (with Keymile's patches).
As it turned out, our update procedure:
sf probe 0;sf erase 0 5;sf write ${load_addr_r} 0 ${filesize}
mistakenly expects a maximum size of 0x5 (327680) bytes for
u-boot.kwb. Sadly, the latest u-boot trunk results in a binary size for that
board which is dangerously close to that limit. Hence, after adding some
innocent lines of code, the update procedure could brick the board (for no
evident reason and with no error message whatsoever) if the binary size
crosses that boundary.
It turns out somebody else also picked up this magic number:
http://lacie-nas.org/doku.php?id=uboot#update_u-boot_mainline
And others have bricked their board, most likely for the same reason:
http://www.trimslice.com/forum/viewtopic.php?f=16t=462
Also, something bad could happen if you make a mistake in the opposite
direction (use too big a number for the write size):
http://sequanux.org/pipermail/lacie-nas/2012-March/000378.html
From what I can understand, writing into a sector which has not been erased
first is an acceptable behaviour of the flash interface, it will just set to
zero whatever bits are not zero already, without reporting any error
whatsoever.
Even though any change we introduce now would only apply to upgrades FROM
future versions, I think it might be worth fixing this somehow.
I believe several things could be easily done here:
1) a + syntax to the sf update command so it can be used with
${filesize} as a parameter, and/or some read,replace,erase,overwrite block
mechanism for the last (incomplete) block
Sounds reasonable, although I wonder if it is worth worrying about
preserved the rest of the contents of the last block.
Probably unimportant, as everything you'd ever want to write would be
block aligned. But I think it still makes sense to make the semantics of
the update command (which could be also thought of as a way of patching
regions of arbitrary alignment and length) consistent with linux's
/dev/mtd, which sort of allows you to do any such things (hiding from
the user any notion of sector/block).
But please correct me if I'm talking nonsense.
2) an out-of-boundary-check againts the flash size so at least a warning is
issued when you use too big a size value
Should be easy enough.
3) a command line option (sf write -v and/or to sf update -v), or an
entirely new command (like sf writeverify, sf updateverify) to read back
after writing so to double-check what really ended up being written to the
flash before it's too late.
I'd like a -V (instead of -v which could perhaps be used for verbose).
But as Mike mentions I wonder if we could/should do this generally for
all flash?
I agree it would totally make sense.
Also, why do you get verify failures? 'sf update' will auto-erase when
it needs to.
True. The option would probably make more sense with the write command.
Do you really have a chip which reports success but then
fails? Or is it just a problem with the size being too large?
Uhm, there's actually two different problems.
One, forgetting to erase enough blocks. This is where -V might come
useful, but with write only.
Two, accidentally writing/updating past the flash size. Here -V would
not help much (unless you wrap around the whole flash and past the
starting address again!), but size checking should at least warn you.
Best,
Gerlando
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] kirkwood: add support for Cloud Engines Pogoplug E02
[PATCH v2] add support for Cloud Engines Pogoplug E02 This patch adds support for Cloud Engines Pogoplug E02. Signed-off-by: David Purdy david.c.pu...@gmail.com Cc: prafu...@marvell.com Cc: albert.u.b...@aribaud.net --- Changes for v2: - added MAINTAINERS info for pogoplug_e02 - fixed format to ensure capture of all files in path MAINTAINERS|4 + board/cloudengines/pogoplug_e02/Makefile | 49 +++ board/cloudengines/pogoplug_e02/kwbimage.cfg | 165 board/cloudengines/pogoplug_e02/pogoplug_e02.c | 148 + board/cloudengines/pogoplug_e02/pogoplug_e02.h | 46 +++ boards.cfg |1 + include/configs/pogoplug_e02.h | 123 ++ 7 files changed, 536 insertions(+), 0 deletions(-) create mode 100644 board/cloudengines/pogoplug_e02/Makefile create mode 100644 board/cloudengines/pogoplug_e02/kwbimage.cfg create mode 100644 board/cloudengines/pogoplug_e02/pogoplug_e02.c create mode 100644 board/cloudengines/pogoplug_e02/pogoplug_e02.h create mode 100644 include/configs/pogoplug_e02.h diff --git a/MAINTAINERS b/MAINTAINERS index 46f63a0..ae65ff3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -793,6 +793,10 @@ Stelian Pop stel...@popies.net at91sam9263ek ARM926EJS (AT91SAM9263 SoC) at91sam9rlekARM926EJS (AT91SAM9RL SoC) +Dave Purdy david.c.pu...@gmail.com + + pogoplug_e02ARM926EJS (Kirkwood SoC) + Thierry Reding thierry.red...@avionic-design.de plutux Tegra2 (ARM7 A9 Dual Core) diff --git a/board/cloudengines/pogoplug_e02/Makefile b/board/cloudengines/pogoplug_e02/Makefile new file mode 100644 index 000..fe92238 --- /dev/null +++ b/board/cloudengines/pogoplug_e02/Makefile @@ -0,0 +1,49 @@ +# +# Copyright (C) 2012 +# David Purdy david.c.pu...@gmail.com +# +# Based on Kirkwood support: +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Written-by: Prafulla Wadaskar prafu...@marvell.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., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS := pogoplug_e02.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(call cmd_link_o_target, $(OBJS) $(SOBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/cloudengines/pogoplug_e02/kwbimage.cfg b/board/cloudengines/pogoplug_e02/kwbimage.cfg new file mode 100644 index 000..e482f16 --- /dev/null +++ b/board/cloudengines/pogoplug_e02/kwbimage.cfg @@ -0,0 +1,165 @@ +# +# Copyright (C) 2012 +# David Purdy david.c.pu...@gmail.com +# +# Based on Kirkwood support: +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Written-by: Prafulla Wadaskar prafulla at marvell.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., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# +# Refer docs/README.kwimage for more details about how-to configure +# and create kirkwood boot image +# + +# Boot Media configurations +BOOT_FROM nand +NAND_ECC_MODE default +NAND_PAGE_SIZE 0x0800 + +# SOC registers configuration using bootrom header extension +# Maximum KWBIMAGE_MAX_CONFIG configurations
Re: [U-Boot] [PATCH 1/4] doc: Add documentation for mpc85xx debugger support
Hi Wolfgang, On Tuesday 13 March 2012 12:44 PM, Prabhakar Kushwaha wrote: Hi Wolfgang, On Wednesday 07 March 2012 06:00 PM, Wolfgang Denk wrote: Dear Prabhakar Kushwaha, In message4f572159.9020...@freescale.com you wrote: Also, what's the V1_V2 ? Are there also other systems (say, e500 v3 cores), and are this not affected? We already have CONFIG_E500 and CONFIG_E500MC so CONFIG_E500_V1_V2 appears to belong to this group, but if I understand your intentions it does something completely unrelated. V1_V2 is used because it applied to e500v1 and e500v2 not e500mc processor. So CONFIG_E500MC cant be used. Also I cant use CONFIG_E500 as it refer the entire e500 family which includes e500mc. Hm... I am not sure if CONFIG_E500 was supposed to include CONFIG_E500MC; it's nowhere documented. Let's assume it is. What happens if you enable this code on a E500MC system? Debug restrictions are not valid for e500mc system. At first sight it should not hurt e500mc execution (other than some seemingly unnecessary steps). However i will check this point. We tried by enabling CONFIG_E500_V2_V2 for E500MC with u-boot patches. It boots fine and debugging can be done. So, we can use CONFIG_E500 #define instead of CONFIG_E500_V2_V2 i.e. debugging will always be enabled. One have to define CONFIG_DEBUGGER_TEMP_TLB for debugging in AS1 ( Part of patch powerpc/85xx:Update NOR code base to support debugger ) CONFIG_DEBUGGER_TEMP_TLB can also be used for placing code which can only be required during debugging (specially code of temporary TLB creation) Please suggest. Regards, Prabhakar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building uboot image for panda board
Hi Charles, I have encountered similar problems before. The error might happen while compiling MLO for OMAP platforms. Check the Makefile under u-boot/spl/board/ or other spl-related Makefiles. There might be some unnecessary .o files outside the #ifndef CONFIG_SPL_BUILD obj-(CONFIG_BLABLABLA...) += something.o obj-(CONFIG_BLABLABLA...) += something.o .. #endif put the .o files which necessary for u-boot.img but not for MLO inside. charlesKAO wrote: Hi i am charles. I am building the panda uboot image, but something wrong. make[1]: Leaving directory `/home/charles/Work_100G/PandaBoard/U_boot/u-boot/arch/arm/cpu/armv7' make -C tools all make[1]: Entering directory `/home/charles/Work_100G/PandaBoard/U_boot/u-boot/tools' make[1]: Leaving directory `/home/charles/Work_100G/PandaBoard/U_boot/u-boot/tools' make -C spl/board/ti/panda all make[1]: Entering directory `/home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/board/ti/panda' /home/charles/Work_100G/PandaBoard/ICS4.0/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-gcc -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x80e8 -I/home/charles/Work_100G/PandaBoard/U_boot/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /home/charles/Work_100G/PandaBoard/ICS4.0/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../lib/gcc/arm-eabi/4.4.3/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -march=armv5 -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -DCONFIG_PRELOADER -Os -ffixed-r8 -ffunction-sections -fdata-sections -march=armv7-a -mthumb -c -o spl-omap.o spl-omap.c cd /home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/board/ti/panda /home/charles/Work_100G/PandaBoard/ICS4.0/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-ld -Bstatic -T /home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/u-boot-spl-generated.lds --gc-sections start.o reset.o lowlevel_init.o serial.o ns16550.o string.o vsprintf.o console.o stdio.o ctype.o eabi_compat.o div64.o omap_hsmmc.o omap24xx_i2c.o mmc.o time.o part.o part_dos.o fat.o syslib.o utils.o timer.o spl-omap.o board.o clocks.o emif.o sdram_elpida.o \ -L /home/charles/Work_100G/PandaBoard/ICS4.0/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../lib/gcc/arm-eabi/4.4.3/thumb -lgcc \ -Map /home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/u-boot-spl.map \ -o /home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/u-boot-spl clocks.o: In function `prcm_init': clocks.c:(.text.prcm_init+0x8a): undefined reference to `omap_set_gpio_direction' clocks.c:(.text.prcm_init+0x92): undefined reference to `omap_set_gpio_dataout' make[1]: *** [/home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/u-boot-spl] Error 1 make[1]: Leaving directory `/home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/board/ti/panda' make: *** [SPL] Error 2 Does anyone know what's wrong? Thanks~ -- View this message in context: http://old.nabble.com/Building-uboot-image-for-panda-board-tp33464297p33500685.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] mx6: Read silicon revision from register
On Wed, Mar 14, 2012 at 3:09 AM, Liu Hui-R64343 r64...@freescale.com wrote: I'm afraid whether this is correct to add it here since some registers of anatop was included into the ccm_reg. ANATOP is a collection of analog and anadig. So, ANATOP register mostly is consist of 4 parts: ANADIG in CCM: for example: PLL/PFD, ANAREG in power: internal analog regulator, power tree. ANAUSB in usb: for usb vbus dection, charge, etc. ANAMISC: misc feature, only one register now for the Chip Silicon Version So the siliconid is in the last register. In the mx6 reference manual version I have I cannot find all the fields you mentioned. Can you send me offline the anatop register layout so that I can complete this structure? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot -Users]- Hush shell
Hi.. I defined CFG_HUSH_PARSER and CFG_PROMPT_HUSH_PS2 for Command Interpreter. I am facing a problem that i able to see only one line at the screen (last printf) and overwrites the previouly printed lines. I am trying to display like welcome to u-boot and in the next line u-boot version number-.but i am able to see only u-boot version number. because the last line overwrites previous line. i given \n at printf. any idea to solve my problem? Thanks in advace... -- *Thanks Regards** * *periyasamy.R* ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] mx6: Read silicon revision from register
Hi Fabio, On 03/14/2012 11:24 AM, Fabio Estevam wrote: On Wed, Mar 14, 2012 at 3:09 AM, Liu Hui-R64343 r64...@freescale.com wrote: I'm afraid whether this is correct to add it here since some registers of anatop was included into the ccm_reg. ANATOP is a collection of analog and anadig. So, ANATOP register mostly is consist of 4 parts: ANADIG in CCM: for example: PLL/PFD, ANAREG in power: internal analog regulator, power tree. ANAUSB in usb: for usb vbus dection, charge, etc. ANAMISC: misc feature, only one register now for the Chip Silicon Version So the siliconid is in the last register. In the mx6 reference manual version I have I cannot find all the fields you mentioned. Can you send me offline the anatop register layout so that I can complete this structure? I think arch/arm/mach-mx6/regs-anadig.h from Freescale's 2.6.38 kernel tree does define the register layout. Do you have that file? Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] EXYNOS: Rename exynos5_tzpc structure to s5p_tzpc
TZPC IP is common across S5P and Exynos based SoC'c. Renaming exynos5_tzpc
in arch/arm/include/asm/arch-exynos/tzpc.h to s5p_tzpc will allow generic
usase of tzpc.
Also modify board/samsung/smdk5250/tzpc_init.c to use s5p_tzpc.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
arch/arm/include/asm/arch-exynos/tzpc.h |2 +-
board/samsung/smdk5250/tzpc_init.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/tzpc.h
b/arch/arm/include/asm/arch-exynos/tzpc.h
index 2c9a07b..63736ae 100644
--- a/arch/arm/include/asm/arch-exynos/tzpc.h
+++ b/arch/arm/include/asm/arch-exynos/tzpc.h
@@ -22,7 +22,7 @@
#define __TZPC_H_
#ifndef __ASSEMBLY__
-struct exynos5_tzpc {
+struct s5p_tzpc {
unsigned int r0size;
char res1[0x7FC];
unsigned int decprot0stat;
diff --git a/board/samsung/smdk5250/tzpc_init.c
b/board/samsung/smdk5250/tzpc_init.c
index c2ccef3..03e46bb 100644
--- a/board/samsung/smdk5250/tzpc_init.c
+++ b/board/samsung/smdk5250/tzpc_init.c
@@ -28,7 +28,7 @@
/* Setting TZPC[TrustZone Protection Controller] */
void tzpc_init(void)
{
- struct exynos5_tzpc *tzpc;
+ struct s5p_tzpc *tzpc;
unsigned int addr;
for (addr = TZPC0_BASE; addr = TZPC9_BASE; addr += TZPC_BASE_OFFSET) {
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] EXYNOS: Rename exynos5_tzpc structure to s5p_tzpc
Hi Chander,
On Wed, Mar 14, 2012 at 10:14 PM, Chander Kashyap
chander.kash...@linaro.org wrote:
TZPC IP is common across S5P and Exynos based SoC'c. Renaming exynos5_tzpc
in arch/arm/include/asm/arch-exynos/tzpc.h to s5p_tzpc will allow generic
usase of tzpc.
Also modify board/samsung/smdk5250/tzpc_init.c to use s5p_tzpc.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
arch/arm/include/asm/arch-exynos/tzpc.h | 2 +-
board/samsung/smdk5250/tzpc_init.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/tzpc.h
b/arch/arm/include/asm/arch-exynos/tzpc.h
index 2c9a07b..63736ae 100644
--- a/arch/arm/include/asm/arch-exynos/tzpc.h
+++ b/arch/arm/include/asm/arch-exynos/tzpc.h
@@ -22,7 +22,7 @@
#define __TZPC_H_
#ifndef __ASSEMBLY__
-struct exynos5_tzpc {
+struct s5p_tzpc {
I think 'exynos' is preferable. Even though each SOC has different
number of tzpc. It can be covered one exynos_tzpc. or we can define
it for each SoC.
Thank you,
Kyungmin Park
unsigned int r0size;
char res1[0x7FC];
unsigned int decprot0stat;
diff --git a/board/samsung/smdk5250/tzpc_init.c
b/board/samsung/smdk5250/tzpc_init.c
index c2ccef3..03e46bb 100644
--- a/board/samsung/smdk5250/tzpc_init.c
+++ b/board/samsung/smdk5250/tzpc_init.c
@@ -28,7 +28,7 @@
/* Setting TZPC[TrustZone Protection Controller] */
void tzpc_init(void)
{
- struct exynos5_tzpc *tzpc;
+ struct s5p_tzpc *tzpc;
unsigned int addr;
for (addr = TZPC0_BASE; addr = TZPC9_BASE; addr += TZPC_BASE_OFFSET) {
--
1.7.5.4
___
linaro-dev mailing list
linaro-...@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] EXYNOS: Rename exynos5_tzpc structure to s5p_tzpc
Hi Kyungmin Park,
On 14 March 2012 19:02, Kyungmin Park kmp...@infradead.org wrote:
Hi Chander,
On Wed, Mar 14, 2012 at 10:14 PM, Chander Kashyap
chander.kash...@linaro.org wrote:
TZPC IP is common across S5P and Exynos based SoC'c. Renaming exynos5_tzpc
in arch/arm/include/asm/arch-exynos/tzpc.h to s5p_tzpc will allow generic
usase of tzpc.
Also modify board/samsung/smdk5250/tzpc_init.c to use s5p_tzpc.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
arch/arm/include/asm/arch-exynos/tzpc.h | 2 +-
board/samsung/smdk5250/tzpc_init.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/tzpc.h
b/arch/arm/include/asm/arch-exynos/tzpc.h
index 2c9a07b..63736ae 100644
--- a/arch/arm/include/asm/arch-exynos/tzpc.h
+++ b/arch/arm/include/asm/arch-exynos/tzpc.h
@@ -22,7 +22,7 @@
#define __TZPC_H_
#ifndef __ASSEMBLY__
-struct exynos5_tzpc {
+struct s5p_tzpc {
I think 'exynos' is preferable. Even though each SOC has different
I tried to carry forward old conventions as in case of watchdog. I
will change it to exynos.
number of tzpc. It can be covered one exynos_tzpc. or we can define
it for each SoC.
One structure is enough as fields are same.
Thank you,
Kyungmin Park
unsigned int r0size;
char res1[0x7FC];
unsigned int decprot0stat;
diff --git a/board/samsung/smdk5250/tzpc_init.c
b/board/samsung/smdk5250/tzpc_init.c
index c2ccef3..03e46bb 100644
--- a/board/samsung/smdk5250/tzpc_init.c
+++ b/board/samsung/smdk5250/tzpc_init.c
@@ -28,7 +28,7 @@
/* Setting TZPC[TrustZone Protection Controller] */
void tzpc_init(void)
{
- struct exynos5_tzpc *tzpc;
+ struct s5p_tzpc *tzpc;
unsigned int addr;
for (addr = TZPC0_BASE; addr = TZPC9_BASE; addr += TZPC_BASE_OFFSET)
{
--
1.7.5.4
___
linaro-dev mailing list
linaro-...@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
--
with warm regards,
Chander Kashyap
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Device tree in uboot eeprom environment
We have multiple versions of hardware that all boot from SD card. Uboot is on the SD card. Since these SD cards can be put into different devices they can't carry the device tree. The hardware has a good sized eeprom on it. Is there any uboot support for having device trees or partial devices trees in the eeprom? Could the device tree be part of the uboot environment? -- Jon Smirl jonsm...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] kirkwood: add support for Cloud Engines Pogoplug E02
-Original Message- From: David C. Purdy [mailto:david.c.pu...@gmail.com] Sent: 14 March 2012 05:47 To: u-boot@lists.denx.de Cc: Prafulla Wadaskar; albert.u.b...@aribaud.net Subject: [PATCH v2] kirkwood: add support for Cloud Engines Pogoplug E02 [PATCH v2] add support for Cloud Engines Pogoplug E02 This patch adds support for Cloud Engines Pogoplug E02. May you please add here a pointer of the board information here? May you please explain how different this board is if compared to Sheevaplug, Guruplug, DreamPlug ? Signed-off-by: David Purdy david.c.pu...@gmail.com Cc: prafu...@marvell.com Cc: albert.u.b...@aribaud.net --- Changes for v2: - added MAINTAINERS info for pogoplug_e02 - fixed format to ensure capture of all files in path MAINTAINERS|4 + board/cloudengines/pogoplug_e02/Makefile | 49 +++ board/cloudengines/pogoplug_e02/kwbimage.cfg | 165 Is this file 100% clone of existing file on the repository? Or you have modified it further for your board, if not, you can reuse the old one. board/cloudengines/pogoplug_e02/pogoplug_e02.c | 148 + board/cloudengines/pogoplug_e02/pogoplug_e02.h | 46 +++ boards.cfg |1 + include/configs/pogoplug_e02.h | 123 ++ 7 files changed, 536 insertions(+), 0 deletions(-) create mode 100644 board/cloudengines/pogoplug_e02/Makefile create mode 100644 board/cloudengines/pogoplug_e02/kwbimage.cfg create mode 100644 board/cloudengines/pogoplug_e02/pogoplug_e02.c create mode 100644 board/cloudengines/pogoplug_e02/pogoplug_e02.h create mode 100644 include/configs/pogoplug_e02.h diff --git a/MAINTAINERS b/MAINTAINERS index 46f63a0..ae65ff3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -793,6 +793,10 @@ Stelian Pop stel...@popies.net at91sam9263ek ARM926EJS (AT91SAM9263 SoC) at91sam9rlekARM926EJS (AT91SAM9RL SoC) +Dave Purdy david.c.pu...@gmail.com + + pogoplug_e02ARM926EJS (Kirkwood SoC) + Please maintain the order here? Thierry Reding thierry.red...@avionic-design.de plutux Tegra2 (ARM7 A9 Dual Core) diff --git a/board/cloudengines/pogoplug_e02/Makefile b/board/cloudengines/pogoplug_e02/Makefile new file mode 100644 index 000..fe92238 --- /dev/null +++ b/board/cloudengines/pogoplug_e02/Makefile @@ -0,0 +1,49 @@ +# +# Copyright (C) 2012 +# David Purdy david.c.pu...@gmail.com +# +# Based on Kirkwood support: +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Written-by: Prafulla Wadaskar prafu...@marvell.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., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# + +include $(TOPDIR)/config.mk + +LIB = $(obj)lib$(BOARD).o + +COBJS:= pogoplug_e02.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS:= $(addprefix $(obj),$(SOBJS)) + +$(LIB): $(obj).depend $(OBJS) $(SOBJS) + $(call cmd_link_o_target, $(OBJS) $(SOBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/cloudengines/pogoplug_e02/kwbimage.cfg b/board/cloudengines/pogoplug_e02/kwbimage.cfg new file mode 100644 index 000..e482f16 --- /dev/null +++ b/board/cloudengines/pogoplug_e02/kwbimage.cfg @@ -0,0 +1,165 @@ +# +# Copyright (C) 2012 +# David Purdy david.c.pu...@gmail.com +# +# Based on Kirkwood support: +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Written-by: Prafulla Wadaskar prafulla at marvell.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
Re: [U-Boot] [PATCH V2] i.MX6: mx6q_sabrelite: add SATA bindings
On 13.03.2012 17:59, Eric Nelson wrote: ... --- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c +++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c ... + /* Enable sata clock */ + reg = readl(imx_ccm-CCGR5); /* CCGR5 */ + reg |= MXC_CCM_CCGR5_CG2_MASK; + writel(reg, imx_ccm-CCGR5); We touch the CCGR5 already in the imximage.cfg. So we could drop this code completely and just add the MXC_CCM_CCGR5_CG2_MASK to the imximage.cfg. What are the advantages/disadvantages of this? Advantages: Less code, touch the register only once in imximage.cfg. Disadvantages: Less readability, doing it in setup_sata() instead of imximage.cfg is easier to understand and disable (by removing CONFIG_CMD_SATA). Opinions? It sounds like this results in the basic question: Which registers should be touched in imximage.cfg, and which by explicit code in drivers/board files? Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Is it possible to send HDMI signal from u-boot on PandaBoard?
Hi everyone, I'm working on modifying u-boot source code for testing HDMI function on PandaBoard (CPU is TI OMAP4430). There seems no related information on the web. I've studied the android kernel source, and it confused me that the linux video driver access lots of registers which are not mentioned in the OMAP4430 Technical Reference Manual. However, the driver of android is so huge and complicated that I can't port it on u-boot. Can anyone tell me how to control HDMI module inside OMAP4430 by u-boot? I just want to do some tiny tasks, such as showing the Android logo or filling the screen of specified color. Maybe give some suggestions or directions for me to study is OK. Or is it impossible? and why? Thanks a lot. Qiao ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] mx6: Read silicon revision from register
On 03/14/2012 05:10 AM, Wolfgang Grandegger wrote: Hi Fabio, On 03/14/2012 11:24 AM, Fabio Estevam wrote: On Wed, Mar 14, 2012 at 3:09 AM, Liu Hui-R64343r64...@freescale.com wrote: I'm afraid whether this is correct to add it here since some registers of anatop was included into the ccm_reg. ANATOP is a collection of analog and anadig. So, ANATOP register mostly is consist of 4 parts: ANADIG in CCM: for example: PLL/PFD, ANAREG in power: internal analog regulator, power tree. ANAUSB in usb: for usb vbus dection, charge, etc. ANAMISC: misc feature, only one register now for the Chip Silicon Version So the siliconid is in the last register. In the mx6 reference manual version I have I cannot find all the fields you mentioned. Can you send me offline the anatop register layout so that I can complete this structure? I think arch/arm/mach-mx6/regs-anadig.h from Freescale's 2.6.38 kernel tree does define the register layout. Do you have that file? If not, you can grab it from here: http://opensource.freescale.com/git?p=imx/uboot-imx.git;a=blob;f=include/asm-arm/arch-mx6/regs-anadig.h;h=581064b876244c65b3a0c82bf14a2f3639864b9f;hb=imx_v2009.08_11.11.01 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4] net: fec_mxc: allow use with cache enabled
ensure that transmit and receive buffers are cache-line aligned
invalidate cache for each packet as received
update receive buffer descriptors one cache line at a time
flush cache before transmitting
Original patch by Marek:
http://lists.denx.de/pipermail/u-boot/2012-February/117695.html
Signed-off-by: Eric Nelson eric.nelson at boundarydevices.com
---
V2 addresses some concerns from the ML:
- Use readl()/writel() instead of mapped data structure
accesses
- Wrong comment style
- rbd_base[0] == rbd_base
removed 'volatile' from fec_send().
V3 updates from ML (and Marek):
consolidated CONFIG_FEC_DATA_ALIGNMENT and CONFIG_FEC_DESC_ALIGNMENT
added cache flushes after initialization of TBD/RBD
V4 updates from ML
http://lists.denx.de/pipermail/u-boot/2012-March#120139
remove tabs after #define/#if/#error
replace CONFIG_FEC_ALIGN with ARCH_DMA_MINALIGN
drivers/net/fec_mxc.c | 277 ++---
drivers/net/fec_mxc.h | 19 +---
2 files changed, 192 insertions(+), 104 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 1fdd071..9e71118 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -38,16 +38,28 @@ DECLARE_GLOBAL_DATA_PTR;
#error CONFIG_MII has to be defined!
#endif
-#ifndefCONFIG_FEC_XCV_TYPE
-#defineCONFIG_FEC_XCV_TYPE MII100
+#ifndef CONFIG_FEC_XCV_TYPE
+#define CONFIG_FEC_XCV_TYPE MII100
#endif
/*
* The i.MX28 operates with packets in big endian. We need to swap them before
* sending and after receiving.
*/
-#ifdef CONFIG_MX28
-#defineCONFIG_FEC_MXC_SWAP_PACKET
+#ifdef CONFIG_MX28
+#define CONFIG_FEC_MXC_SWAP_PACKET
+#endif
+
+#define RXDESC_PER_CACHELINE (ARCH_DMA_MINALIGN/sizeof(struct fec_bd))
+
+/* Check various alignment issues at compile time */
+#if ((ARCH_DMA_MINALIGN 16) || (ARCH_DMA_MINALIGN % 16 != 0))
+#error ARCH_DMA_MINALIGN must be multiple of 16!
+#endif
+
+#if ((PKTALIGN ARCH_DMA_MINALIGN) || \
+ (PKTALIGN % ARCH_DMA_MINALIGN != 0))
+#error PKTALIGN must be multiple of ARCH_DMA_MINALIGN!
#endif
#undef DEBUG
@@ -59,7 +71,7 @@ struct nbuf {
uint8_t head[16]; /** MAC header(6 + 6 + 2) + 2(aligned) */
};
-#ifdef CONFIG_FEC_MXC_SWAP_PACKET
+#ifdef CONFIG_FEC_MXC_SWAP_PACKET
static void swap_packet(uint32_t *packet, int length)
{
int i;
@@ -259,43 +271,52 @@ static int fec_tx_task_disable(struct fec_priv *fec)
* Initialize receive task's buffer descriptors
* @param[in] fec all we know about the device yet
* @param[in] count receive buffer count to be allocated
- * @param[in] size size of each receive buffer
+ * @param[in] dsize desired size of each receive buffer
* @return 0 on success
*
* For this task we need additional memory for the data buffers. And each
* data buffer requires some alignment. Thy must be aligned to a specific
- * boundary each (DB_DATA_ALIGNMENT).
+ * boundary each.
*/
-static int fec_rbd_init(struct fec_priv *fec, int count, int size)
+static int fec_rbd_init(struct fec_priv *fec, int count, int dsize)
{
- int ix;
- uint32_t p = 0;
-
- /* reserve data memory and consider alignment */
- if (fec-rdb_ptr == NULL)
- fec-rdb_ptr = malloc(size * count + DB_DATA_ALIGNMENT);
- p = (uint32_t)fec-rdb_ptr;
- if (!p) {
- puts(fec_mxc: not enough malloc memory\n);
- return -ENOMEM;
- }
- memset((void *)p, 0, size * count + DB_DATA_ALIGNMENT);
- p += DB_DATA_ALIGNMENT-1;
- p = ~(DB_DATA_ALIGNMENT-1);
-
- for (ix = 0; ix count; ix++) {
- writel(p, fec-rbd_base[ix].data_pointer);
- p += size;
- writew(FEC_RBD_EMPTY, fec-rbd_base[ix].status);
- writew(0, fec-rbd_base[ix].data_length);
- }
+ uint32_t size;
+ int i;
+
/*
-* mark the last RBD to close the ring
+* Allocate memory for the buffers. This allocation respects the
+* alignment
*/
- writew(FEC_RBD_WRAP | FEC_RBD_EMPTY, fec-rbd_base[ix - 1].status);
+ size = roundup(dsize, ARCH_DMA_MINALIGN);
+ for (i = 0; i count; i++) {
+ uint32_t data_ptr = readl(fec-rbd_base[i].data_pointer);
+ if (data_ptr == 0) {
+ uint8_t *data = memalign(ARCH_DMA_MINALIGN,
+size);
+ if (!data) {
+ printf(%s: error allocating rxbuf %d\n,
+ __func__, i);
+ goto err;
+ }
+ writel((uint32_t)data, fec-rbd_base[i].data_pointer);
+ } /* needs allocation */
+ writew(FEC_RBD_EMPTY, fec-rbd_base[i].status);
+ writew(0,
Re: [U-Boot] [PATCH V5] BOOT: Add bootz command to boot Linux zImage on ARM
On 03/13/2012 09:47 PM, Marek Vasut wrote: From: Marek Vasut marek.va...@gmail.com This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported. Tested on i.MX28 based DENX M28EVK Tested on PXA270 based Voipac PXA270. NOTE: This currently only supports ARM, but other architectures can be easily added by defining bootz_setup(). Signed-off-by: Marek Vasut marek.va...@gmail.com On Tegra20 Harmony with and without device tree (against mainline) and Tegra30 Cardhu with device tree (against an NVIDIA-internal U-Boot tree), Tested-by: Stephen Warren swar...@wwwdotorg.org The code looks good too; I believe you've take care of any comments I had on the first very you posted. Thanks very much - this is awesome! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5] BOOT: Add bootz command to boot Linux zImage on ARM
Dear Stephen Warren, On 03/13/2012 09:47 PM, Marek Vasut wrote: From: Marek Vasut marek.va...@gmail.com This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported. Tested on i.MX28 based DENX M28EVK Tested on PXA270 based Voipac PXA270. NOTE: This currently only supports ARM, but other architectures can be easily added by defining bootz_setup(). Signed-off-by: Marek Vasut marek.va...@gmail.com On Tegra20 Harmony with and without device tree (against mainline) and Tegra30 Cardhu with device tree (against an NVIDIA-internal U-Boot tree), Tested-by: Stephen Warren swar...@wwwdotorg.org The code looks good too; I believe you've take care of any comments I had on the first very you posted. Thanks very much - this is awesome! You're welcome :) I'm glad we're finally going to squash one of the biggest sources of friction between linux-arm and uboot :) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling nand createbbt command
On Wednesday 14 March 2012 17:00:58 Bud Miljkovic wrote: Charles That is interesting. Any clue how to configure the start and end blocks manually? Yes I do since I wrote yaffs :-). Set the statrt_block and end_block (might be startBlock and endBlock) values as needed BEFORE the mount/init happens. In a normal situation with mtd partitioning these are set to 0 and n-blocks-in-partition -1, but they can be set manually too. -- Charles Bud -Original Message- From: Charles Manning [mailto:mannin...@actrix.gen.nz] Sent: Monday, 12 March 2012 8:20 a.m. To: Bud Miljkovic Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Enabling nand createbbt command Bud Yaffs can work without mtdpart. To do that you just need to configure the start and end blocks manually instead of using the partition info to do this. On Friday 09 March 2012 13:58:48 Bud Miljkovic wrote: Thank you Scott and Fabio, You help is much appreciated. I will try to add the nand support for mx53 mainline. However, what I am trying to do is to build a u-boot that supports NAND and have YAFFS2 as well and at moment I use the mx53_ard board since this is very close to what my custom board will be. I was able to build such a version, using Freescale u-boot sources, which included nand subsystem, and yaffs commands. Then I needed to create partitions in the nand and this is where i discovered I needed the support of mtdparts command. So I, guess, I need to configure the u-boot for mtdparts support. This is where I am at. -Bud -Original Message- From: Scott Wood Sent: Friday, 9 March 2012 12:04 p.m. To: Bud Miljkovic Cc: Fabio Estevam; Subject: Re: [U-Boot] Enabling nand createbbt command I do expect mainline is better maintained and supported, except for missing particular features/hardware support that nobody ever bothered to submit to mainline -- which in this case appears to be hardware that you care about, so unless you're prepared to do a fair bit of work to add support to mainline, I'd try again to find a support channel for your Freescale-provided U-Boot. Or maybe we could help you figure out what it is you want to do, instead of scrubbing, if the answer doesn't depend on details of a non-standard U-Boot. Oh, and if you're curious about my freescale.com e-mail address, I work in a different part of the company and don't have i.MX knowledge or contacts. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] net: fec_mxc: allow use with cache enabled
On Wednesday 14 March 2012 01:12:38 Eric Nelson wrote: Most of the PPC devices seem to have values of 16 or 32 for ARCH_DMA_MINALIGN, but PPC64BRIDGE and E500MC would have a problem if their drivers don't implement a bounce buffer because PKTALIGN ARCH_DMA_MINALIGN. (see arch/powerpc/include/asm/cache.h) This condition is properly tested for in fec_mxc.c. so fix this in common code instead of hacking around it in individual drivers. seems to me that PKTALIGN should be defined to ARCH_DMA_MINALIGN and ultimately removed. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] kirkwood: add support for Cloud Engines Pogoplug E02
Thank you Prafulla, I supplied 4 responses and some questions ... On Wed, Mar 14, 2012 at 9:23 AM, Prafulla Wadaskar prafu...@marvell.com wrote: -Original Message- From: David C. Purdy [mailto:david.c.pu...@gmail.com] Sent: 14 March 2012 05:47 To: u-boot@lists.denx.de Cc: Prafulla Wadaskar; albert.u.b...@aribaud.net Subject: [PATCH v2] kirkwood: add support for Cloud Engines Pogoplug E02 [PATCH v2] add support for Cloud Engines Pogoplug E02 This patch adds support for Cloud Engines Pogoplug E02. 1. May you please add here a pointer of the board information here? Will this suffice for pointer regarding board information: http://archlinuxarm.org/platforms/armv5/pogoplug-v2-pinkgray ... or do you need something more specific? (not sure what level of detail you wish) 2. May you please explain how different this board is if compared to Sheevaplug, Guruplug, DreamPlug ? Sheevaplug - 512MB NAND, 512MB RAM, USB, SD card slot other differences Guruplug - 512MB NAND, 512MB RAM, USB, SATA other differences Dreamplug- 2MB NAND, 512MB RAM, Audio, USB, eSATA other differences Pogoplug E02 - 128MB NAND, 256MB RAM, USB ... actually it is probably closest to the Seagate Dockstar (which is supported in U-Boot stable since 2010.12 IIRC), but there are enough differences that the Dockstar's u-boot binary will not work correctly in the Pogoplug E02. Signed-off-by: David Purdy david.c.pu...@gmail.com Cc: prafu...@marvell.com Cc: albert.u.b...@aribaud.net --- Changes for v2: - added MAINTAINERS info for pogoplug_e02 - fixed format to ensure capture of all files in path MAINTAINERS | 4 + board/cloudengines/pogoplug_e02/Makefile | 49 +++ board/cloudengines/pogoplug_e02/kwbimage.cfg | 165 3. Is this file 100% clone of existing file on the repository? Or you have modified it further for your board, if not, you can reuse the old one. I may make some modest/minor modifications to it in the future. Perhaps in the GPIO section. For that reason I'd like the pogoE02 to have its own. Does that sound OK? board/cloudengines/pogoplug_e02/pogoplug_e02.c | 148 + board/cloudengines/pogoplug_e02/pogoplug_e02.h | 46 +++ boards.cfg | 1 + include/configs/pogoplug_e02.h | 123 ++ 7 files changed, 536 insertions(+), 0 deletions(-) create mode 100644 board/cloudengines/pogoplug_e02/Makefile create mode 100644 board/cloudengines/pogoplug_e02/kwbimage.cfg create mode 100644 board/cloudengines/pogoplug_e02/pogoplug_e02.c create mode 100644 board/cloudengines/pogoplug_e02/pogoplug_e02.h create mode 100644 include/configs/pogoplug_e02.h diff --git a/MAINTAINERS b/MAINTAINERS index 46f63a0..ae65ff3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -793,6 +793,10 @@ Stelian Pop stel...@popies.net at91sam9263ek ARM926EJS (AT91SAM9263 SoC) at91sam9rlek ARM926EJS (AT91SAM9RL SoC) +Dave Purdy david.c.pu...@gmail.com + + pogoplug_e02 ARM926EJS (Kirkwood SoC) + 3. Please maintain the order here? Thierry Reding thierry.red...@avionic-design.de plutux Tegra2 (ARM7 A9 Dual Core) I'm not at all sure I understand you there. Alphabetically: Pop, Purdy, Reding... all in the ARM section.. +#endif /* __POGOPLUG_E02_H */ diff --git a/boards.cfg b/boards.cfg index 28cc345..3cdf17e 100644 --- a/boards.cfg +++ b/boards.cfg @@ -154,6 +154,7 @@ openrd_ultimate arm arm926ejs openrd Marvell rd6281a arm arm926ejs - Marvell kirkwood sheevaplug arm arm926ejs - Marvell kirkwood dockstar arm arm926ejs - Seagate kirkwood +pogoplug_e02 arm arm926ejs - cloudengines Kirkwood 4. Please maintain an order here too. Yes, I see. If I understand you, this would become: calimain arm arm926ejs calimain omicrondavinci pogoplug_e02 arm arm926ejs - cloudengines kirkwood dns325 arm arm926ejs - d-link kirkwood Regards.. Prafulla . . . Thanks and regards, Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5] BOOT: Add bootz command to boot Linux zImage on ARM
On Wednesday 14 March 2012 01:38:45 Marek Vasut wrote: On Tuesday 13 March 2012 23:47:56 Marek Vasut wrote: This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported. i've got no opinion on the matter of supporting zImage directly (although, i guess it'd be nice since some legacy platforms still use it like netwinders) Does anyone else but RMK have a working netwinder these days? :-) i've got 3, but only one is actively running +int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) static NAK, compiler won't chew that what are you talking about ? you need to provide real details when making statements like this. plenty of other cmd's in u-boot mark their do_xxx func static and they work just fine. this do_bootz isn't used externally, so it makes no sense to have it be public. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] net: fec_mxc: allow use with cache enabled
On 03/13/2012 10:41 PM, Mike Frysinger wrote: On Wednesday 14 March 2012 01:12:38 Eric Nelson wrote: Most of the PPC devices seem to have values of 16 or 32 for ARCH_DMA_MINALIGN, but PPC64BRIDGE and E500MC would have a problem if their drivers don't implement a bounce buffer because PKTALIGN ARCH_DMA_MINALIGN. (see arch/powerpc/include/asm/cache.h) This condition is properly tested for in fec_mxc.c. so fix this in common code instead of hacking around it in individual drivers. seems to me that PKTALIGN should be defined to ARCH_DMA_MINALIGN and ultimately removed. -mike Hi Mike, I'm not in a position to test against MAKEALL, but it appears that all architectures have cache.h and define ARCH_DMA_MINALIGN, so it should be trivially easy to fix PKTALIGN to be at least ARCH_DMA_MINALIGN as shown below. PKTSIZE_ALIGN seems safe for all architectures at 1536. Note that this will reduce the value to 16 for some PPC devices, but I haven't found any place that this would break things. Is this what you're after? Are you in a position to run MAKEALL or can you advise about the requirements? Please advise, Eric ~/u-boot-imx6$ git diff diff --git a/include/net.h b/include/net.h index e4d42c2..ff428d0 100644 --- a/include/net.h +++ b/include/net.h @@ -16,6 +16,7 @@ #include commproc.h #endif /* CONFIG_8xx */ +#include asm/cache.h #include asm/byteorder.h /* for nton* / ntoh* stuff */ @@ -31,7 +32,7 @@ # define PKTBUFSRX 4 #endif -#define PKTALIGN 32 +#define PKTALIGN ARCH_DMA_MINALIGN /* IPv4 addresses are always 32 bits in size */ typedef u32IPaddr_t; ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5] BOOT: Add bootz command to boot Linux zImage on ARM
Dear Mike Frysinger, On Wednesday 14 March 2012 01:38:45 Marek Vasut wrote: On Tuesday 13 March 2012 23:47:56 Marek Vasut wrote: This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported. i've got no opinion on the matter of supporting zImage directly (although, i guess it'd be nice since some legacy platforms still use it like netwinders) Does anyone else but RMK have a working netwinder these days? :-) i've got 3, but only one is actively running You should run DNA test on yourself against RMK's bloodsample :) +int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) static NAK, compiler won't chew that what are you talking about ? you need to provide real details when making statements like this. plenty of other cmd's in u-boot mark their do_xxx func static and they work just fine. this do_bootz isn't used externally, so it makes no sense to have it be public. Oh you mean staticize the function, not the weak stuff, ok. -mike 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 1/4] doc: Add documentation for mpc85xx debugger support
On 03/14/2012 04:35 AM, Prabhakar Kushwaha wrote: Hi Wolfgang, On Tuesday 13 March 2012 12:44 PM, Prabhakar Kushwaha wrote: Hi Wolfgang, On Wednesday 07 March 2012 06:00 PM, Wolfgang Denk wrote: Dear Prabhakar Kushwaha, In message4f572159.9020...@freescale.com you wrote: Also, what's the V1_V2 ? Are there also other systems (say, e500 v3 cores), and are this not affected? We already have CONFIG_E500 and CONFIG_E500MC so CONFIG_E500_V1_V2 appears to belong to this group, but if I understand your intentions it does something completely unrelated. V1_V2 is used because it applied to e500v1 and e500v2 not e500mc processor. So CONFIG_E500MC cant be used. Also I cant use CONFIG_E500 as it refer the entire e500 family which includes e500mc. Hm... I am not sure if CONFIG_E500 was supposed to include CONFIG_E500MC; it's nowhere documented. Let's assume it is. What happens if you enable this code on a E500MC system? Debug restrictions are not valid for e500mc system. At first sight it should not hurt e500mc execution (other than some seemingly unnecessary steps). However i will check this point. We tried by enabling CONFIG_E500_V2_V2 for E500MC with u-boot patches. It boots fine and debugging can be done. Be sure to mention in comments that the hack is only really needed for v1/v2. So, we can use CONFIG_E500 #define instead of CONFIG_E500_V2_V2 i.e. debugging will always be enabled. One have to define CONFIG_DEBUGGER_TEMP_TLB for debugging in AS1 ( Part of patch powerpc/85xx:Update NOR code base to support debugger ) CONFIG_SYS_PPC_E500_DEBUG_TLB CONFIG_DEBUGGER_TEMP_TLB can also be used for placing code which can only be required during debugging (specially code of temporary TLB creation) Is there something specific you had in mind, other than the use that is already present in this patchset? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] net: fec_mxc: allow use with cache enabled
On Wednesday 14 March 2012 15:12:10 Eric Nelson wrote: On 03/13/2012 10:41 PM, Mike Frysinger wrote: On Wednesday 14 March 2012 01:12:38 Eric Nelson wrote: Most of the PPC devices seem to have values of 16 or 32 for ARCH_DMA_MINALIGN, but PPC64BRIDGE and E500MC would have a problem if their drivers don't implement a bounce buffer because PKTALIGN ARCH_DMA_MINALIGN. (see arch/powerpc/include/asm/cache.h) This condition is properly tested for in fec_mxc.c. so fix this in common code instead of hacking around it in individual drivers. seems to me that PKTALIGN should be defined to ARCH_DMA_MINALIGN and ultimately removed. I'm not in a position to test against MAKEALL, but it appears that all architectures have cache.h and define ARCH_DMA_MINALIGN ARCH_DMA_MINALIGN is required. if an arch/board omits it, they are broken and you need not worry about it. we already have common code requiring int. --- a/include/net.h +++ b/include/net.h -#define PKTALIGN 32 +#define PKTALIGN ARCH_DMA_MINALIGN looks fine to me -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] net: fec_mxc: allow use with cache enabled
On 03/14/2012 01:33 PM, Mike Frysinger wrote: On Wednesday 14 March 2012 15:12:10 Eric Nelson wrote: On 03/13/2012 10:41 PM, Mike Frysinger wrote: On Wednesday 14 March 2012 01:12:38 Eric Nelson wrote: Most of the PPC devices seem to have values of 16 or 32 for ARCH_DMA_MINALIGN, but PPC64BRIDGE and E500MC would have a problem if their drivers don't implement a bounce buffer because PKTALIGN ARCH_DMA_MINALIGN. (see arch/powerpc/include/asm/cache.h) This condition is properly tested for in fec_mxc.c. so fix this in common code instead of hacking around it in individual drivers. seems to me that PKTALIGN should be defined to ARCH_DMA_MINALIGN and ultimately removed. I'm not in a position to test against MAKEALL, but it appears that all architectures have cache.h and define ARCH_DMA_MINALIGN ARCH_DMA_MINALIGN is required. if an arch/board omits it, they are broken and you need not worry about it. we already have common code requiring int. Sounds good. --- a/include/net.h +++ b/include/net.h -#define PKTALIGN 32 +#define PKTALIGN ARCH_DMA_MINALIGN looks fine to me -mike You want I should send a formal patch? Should I consider looks fine to be an ack? If so, I'll also send an update (V5) to fec_mxc that removes the check on PKTALIGN. Please advise, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] net: fec_mxc: allow use with cache enabled
On Wednesday 14 March 2012 17:04:32 Eric Nelson wrote: You want I should send a formal patch? yes please Should I consider looks fine to be an ack? i'll post an acked-by tag to that and then patchwork will do the right thing for people to track -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net: force PKTALIGN to ARCH_DMA_MINALIGN
This will prevent the need for architectures whose DMA alignment is greater than 32 to have bounce buffers. Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- include/net.h |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/include/net.h b/include/net.h index e4d42c2..ff428d0 100644 --- a/include/net.h +++ b/include/net.h @@ -16,6 +16,7 @@ #include commproc.h #endif /* CONFIG_8xx */ +#include asm/cache.h #include asm/byteorder.h /* for nton* / ntoh* stuff */ @@ -31,7 +32,7 @@ # define PKTBUFSRX 4 #endif -#define PKTALIGN 32 +#define PKTALIGN ARCH_DMA_MINALIGN /* IPv4 addresses are always 32 bits in size */ typedef u32IPaddr_t; -- 1.7.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: force PKTALIGN to ARCH_DMA_MINALIGN
Acked-by: Mike Frysinger vap...@gentoo.org -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPI flash writing
On Tue, Mar 13, 2012 at 10:31:02PM +0100, Falauto, Gerlando wrote: -Original Message- From: Mike Frysinger [mailto:vap...@gentoo.org] Sent: Tue 13.03.2012 21:35 To: Jason Cooper Cc: Falauto, Gerlando; u-boot; Brunck, Holger Subject: Re: [U-Boot] SPI flash writing On Tuesday 13 March 2012 16:17:52 Jason Cooper wrote: On Tue, Mar 13, 2012 at 04:11:29PM -0400, Mike Frysinger wrote: On Tuesday 13 March 2012 14:25:07 Gerlando Falauto wrote: 2) an out-of-boundary-check againts the flash size so at least a warning is issued when you use too big a size value i'm not sure about this. if you want to do size checking, then enable the hush shell and do it in a script. Is there a programatic way to get the size of the flash at runtime from the hush script? no. question is, do you really need that ? sounds like you know ahead of time how big the space is for u-boot, so the size of the flash doesn't matter. Can't the same command also be used for burning something *other than* u-boot (e.g. a kernel, config section, or something like that)? So the size of the flash *does matter*, doesn't it? How about using mtdparts which I think will tell you when you're going to write something larger than the defined partition? If it doesn't, that would be a handy thing to add (and be a general feature too). -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPI flash writing
On Wednesday 14 March 2012 02:44:45 Gerlando Falauto wrote: The thing is, if you issue e write (or erase) and accidentally cross the flash size boundary, you get a wraparound (or aliasing, or whatever you want to call it) so that you end up overwriting (e.g. zeroing out bits) the initial sectors of the flash. this is a bug that should be fixed. i thought there was size checking in there, but maybe it got lost in the shuffle, or i'm just making sh*t up. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPI flash writing
On Wednesday 14 March 2012 20:02:27 Tom Rini wrote: On Tue, Mar 13, 2012 at 10:31:02PM +0100, Falauto, Gerlando wrote: Can't the same command also be used for burning something *other than* u-boot (e.g. a kernel, config section, or something like that)? So the size of the flash *does matter*, doesn't it? How about using mtdparts which I think will tell you when you're going to write something larger than the defined partition? If it doesn't, that would be a handy thing to add (and be a general feature too). i was about to suggest this :). unfortunately, in order to make that work, i think the spi flash code needs to be migrated to the mtd layers ? -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] EXYNOS: Rename exynos5_tzpc structure to s5p_tzpc
Dear Chander Kashyap,
On 14 March 2012 22:38, Chander Kashyap chander.kash...@linaro.org wrote:
Hi Kyungmin Park,
On 14 March 2012 19:02, Kyungmin Park kmp...@infradead.org wrote:
Hi Chander,
On Wed, Mar 14, 2012 at 10:14 PM, Chander Kashyap
chander.kash...@linaro.org wrote:
TZPC IP is common across S5P and Exynos based SoC'c. Renaming exynos5_tzpc
in arch/arm/include/asm/arch-exynos/tzpc.h to s5p_tzpc will allow generic
usase of tzpc.
Also modify board/samsung/smdk5250/tzpc_init.c to use s5p_tzpc.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
arch/arm/include/asm/arch-exynos/tzpc.h | 2 +-
board/samsung/smdk5250/tzpc_init.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/tzpc.h
b/arch/arm/include/asm/arch-exynos/tzpc.h
index 2c9a07b..63736ae 100644
--- a/arch/arm/include/asm/arch-exynos/tzpc.h
+++ b/arch/arm/include/asm/arch-exynos/tzpc.h
@@ -22,7 +22,7 @@
#define __TZPC_H_
#ifndef __ASSEMBLY__
-struct exynos5_tzpc {
+struct s5p_tzpc {
I think 'exynos' is preferable. Even though each SOC has different
I tried to carry forward old conventions as in case of watchdog. I
will change it to exynos.
I agreed with Kyungmin.
From now, let's called exynos for common name including s5pc1xx and
s5pc2xx and exynos4 and exynos5.. etc.
number of tzpc. It can be covered one exynos_tzpc. or we can define
it for each SoC.
One structure is enough as fields are same.
Thanks
Minkyu Kang.
--
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/27] Create generic board init for ARM, x86, PPC
This series creates a generic board.c implementation which contains the essential functions of the major arch/xxx/lib/board.c files. What is the motivation for this change? 1. There is a lot of repeated code in the board.c files. Any change to things like setting up the baud rate requires a change in 10 separate places. 2. Since there are 10 separate files, adding a new feature which requires initialisation is painful since it must be independently added in 10 places. 3. As time goes by the architectures naturely diverge since there is limited pressure to compare features or even CONFIG options against simiilar things in other board.c files. 4. New architectures must implement all the features all over again, and sometimes in subtley different ways. This places an unfair burden on getting a new architecture fully functional and running with U-Boot. 5. While it is a bit of a tricky change, I believe it is worthwhile and achievable. There is no requirement that all code be common, only that the code that is common should be located in common/board.c rather than arch/xxx/lib/board.c. All the functions of board_init_f() and board_init_r() are broken into separate function calls so that they can easily be included or excluded for a particular architecture. It also makes it easier to adopt Graeme's initcall proposal when it is ready. http://lists.denx.de/pipermail/u-boot/2012-January/114499.html This series removes the dependency on generic relocation. So relocation happens as one big chunk and is still completely arch-specific. See the relocation series for a proposed solution to this for ARM: http://lists.denx.de/pipermail/u-boot/2011-December/112928.html or Graeme's recent x86 series v2: http://lists.denx.de/pipermail/u-boot/2012-January/114467.html Instead of moving over a whole architecture, this series takes the approach of simply enabling generic board support for an architecture. It is then up to each board to opt in by defining CONFIG_SYS_GENERIC_BOARD in the board config file. If this is not done, then the code will be generated as before. This allows both sets of code to co-exist until we are comfortable with the generic approach, and enough boards run. ARM is a relatively large board.c file and one which I can test, therefore I think it is a good target for this series. On the other hand, x86 is relatively small and simple, but different enough that it introduces a few issues to be solved. So I have chosen both ARM and x86 for this series. After a suggestion from Wolfgang I have added PPC also. This is the largest and most feature-full board, so hopefully we have all bases covered in this RFC. A generic global_data structure is also required. This might upset a few people. Here is my basic reasoning: most fields are the same, all architectures include and need it, most global_data.h files already have #ifdefs to select fields for a particular SOC, so it is hard to see why architecures are different in this area. We can perhaps add a way to put architecture-specific fields into a separate header file, but for now I have judged that to be counter-productive. Similarly we need a generic bd_info structure, since generic code will be accessing it. I have done this in the same way as global_data and the same comments apply. There was dicussion on the list about passing gd_t around as a parameter to pre-relocation init functions. I think this makes sense, but it can be done as a separate change, and this series does not require it. While this series needs to stand on its own (as with the link script cleanup series and the generic relocation series) the goal is the unification of the board init code. So I hope we can address issues with this in mind, rather than focusing too narrowly on particular ARM, x86 or PPC issues. I have run-tested ARM on Tegra Seaboard only. To try it out, define CONFIG_SYS_GENERIC_BOARD in your board file and rebuild. Most likely on x86 and PPC at least it will hang, but if you are lucky it will print something first :-) I have run this though MAKEALL with CONFIG_SYS_GENERIC_BOARD on for all ARM, PPC and x86 boards. There are a few failures due to errors in the board config, which I have sent patches for. The main issue is just the difference between __bss_end and __bss_end__. Note: the first group of commits are required for this series to build, but could be separated out if required. I have included them here for convenience. Comments welcome. Changes in v2: - Add CONFIG_SYS_GENERIC_BOARD to allow board to select generic board - Add PowerPC support - Change generic board to an opt-in system on a per-board basic - Rebase to master Changes in v3: - Add header to new x86 relocate.c and init_helpers.c - Cast away the volatile on gd for memcpy() - Rebase on top of x86/master (which has not yet been pulled to master) - Rebase to master Changes in v4: - Add asm/sections.h for each architecture - Add three more fields required for ARM - Drop sc520_timer.c patch
[U-Boot] [PATCH v4 01/27] arm: Change board baud_rate to ulong
This is a ulong for some architectures and just unsigned for others.
Change ARM to be consistent.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/arm/include/asm/u-boot.h |2 +-
common/cmd_bdinfo.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/u-boot.h b/arch/arm/include/asm/u-boot.h
index 20e1653..a0691b7 100644
--- a/arch/arm/include/asm/u-boot.h
+++ b/arch/arm/include/asm/u-boot.h
@@ -37,7 +37,7 @@
#define _U_BOOT_H_ 1
typedef struct bd_info {
-intbi_baudrate;/* serial console baudrate */
+ unsigned long bi_baudrate;/* serial console baudrate */
unsigned long bi_ip_addr; /* IP Address */
ulong bi_arch_number; /* unique id for this board */
ulong bi_boot_params; /* where this board expects params */
diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c
index 5359a47..c034ec9 100644
--- a/common/cmd_bdinfo.c
+++ b/common/cmd_bdinfo.c
@@ -361,7 +361,7 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
print_eth(0);
printf(ip_addr = %pI4\n, bd-bi_ip_addr);
#endif
- printf(baudrate= %d bps\n, bd-bi_baudrate);
+ printf(baudrate= %ld bps\n, bd-bi_baudrate);
#if !(defined(CONFIG_SYS_ICACHE_OFF) defined(CONFIG_SYS_DCACHE_OFF))
print_num(TLB addr, gd-tlb_addr);
#endif
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 04/27] x86: Remove dead code in eNET
This avoids a compiler warning about unused variables.
Signed-off-by: Simon Glass s...@chromium.org
---
board/eNET/eNET.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/board/eNET/eNET.c b/board/eNET/eNET.c
index 429fe1b..2f26470 100644
--- a/board/eNET/eNET.c
+++ b/board/eNET/eNET.c
@@ -178,11 +178,6 @@ void show_boot_progress(int val)
int last_stage_init(void)
{
- int minor;
- int major;
-
- major = minor = 0;
-
outb(0x00, LED_LATCH_ADDRESS);
register_timer_isr(enet_timer_isr);
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 09/27] Introduce generic link section.h symbol files
We create a separate header file for link symbols defined by the link scripts. It is helpful to have these all in one place and try to make them common across architectures. Since Linux already has a similar file, we bring this in even though many of the symbols there are not relevant to us. Each architecture has its own asm/sections.h where symbols specifc to that architecture can be added. For now everything except AVR32 just includes the generic header. One change is needed in arch/avr32/lib/board.c to make this conversion work. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v4: - Add asm/sections.h for each architecture arch/arm/include/asm/sections.h| 27 +++ arch/avr32/include/asm/sections.h |6 +- arch/avr32/lib/board.c |2 +- arch/blackfin/include/asm/sections.h | 27 +++ arch/m68k/include/asm/sections.h | 27 +++ arch/microblaze/include/asm/sections.h | 27 +++ arch/mips/include/asm/sections.h | 27 +++ arch/nds32/include/asm/sections.h | 27 +++ arch/nios2/include/asm/sections.h | 27 +++ arch/openrisc/include/asm/sections.h | 27 +++ arch/powerpc/include/asm/sections.h| 27 +++ arch/sandbox/include/asm/sections.h| 27 +++ arch/sh/include/asm/sections.h | 27 +++ arch/sparc/include/asm/sections.h | 27 +++ arch/x86/include/asm/sections.h| 27 +++ include/asm-generic/sections.h | 124 16 files changed, 479 insertions(+), 4 deletions(-) create mode 100644 arch/arm/include/asm/sections.h create mode 100644 arch/blackfin/include/asm/sections.h create mode 100644 arch/m68k/include/asm/sections.h create mode 100644 arch/microblaze/include/asm/sections.h create mode 100644 arch/mips/include/asm/sections.h create mode 100644 arch/nds32/include/asm/sections.h create mode 100644 arch/nios2/include/asm/sections.h create mode 100644 arch/openrisc/include/asm/sections.h create mode 100644 arch/powerpc/include/asm/sections.h create mode 100644 arch/sandbox/include/asm/sections.h create mode 100644 arch/sh/include/asm/sections.h create mode 100644 arch/sparc/include/asm/sections.h create mode 100644 arch/x86/include/asm/sections.h create mode 100644 include/asm-generic/sections.h diff --git a/arch/arm/include/asm/sections.h b/arch/arm/include/asm/sections.h new file mode 100644 index 000..c042cb6 --- /dev/null +++ b/arch/arm/include/asm/sections.h @@ -0,0 +1,27 @@ +/* + * Copyright (c) 2012 The Chromium OS Authors. + * 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 + */ + +#ifndef __ASM_ARM_SECTIONS_H +#define __ASM_ARM_SECTIONS_H + +#include asm-generic/sections.h + +#endif diff --git a/arch/avr32/include/asm/sections.h b/arch/avr32/include/asm/sections.h index 3f15788..056d7a0 100644 --- a/arch/avr32/include/asm/sections.h +++ b/arch/avr32/include/asm/sections.h @@ -22,11 +22,11 @@ #ifndef __ASM_AVR32_SECTIONS_H #define __ASM_AVR32_SECTIONS_H +#include asm-generic/sections.h + /* References to section boundaries */ -extern char _text[], _etext[]; -extern char _data[], __data_lma[], _edata[], __edata_lma[]; +extern char __data_lma[], __edata_lma[]; extern char __got_start[], __got_lma[], __got_end[]; -extern char __bss_end__[]; #endif /* __ASM_AVR32_SECTIONS_H */ diff --git a/arch/avr32/lib/board.c b/arch/avr32/lib/board.c index 63fe297..de1b127 100644 --- a/arch/avr32/lib/board.c +++ b/arch/avr32/lib/board.c @@ -176,7 +176,7 @@ void board_init_f(ulong board_type) * - stack */ addr = CONFIG_SYS_SDRAM_BASE + sdram_size; - monitor_len = __bss_end__ - _text; + monitor_len = (char *)__bss_end__ - _text; /* * Reserve memory for u-boot code, data and bss. diff --git a/arch/blackfin/include/asm/sections.h b/arch/blackfin/include/asm/sections.h new file mode 100644 index 000..85af42c --- /dev/null +++ b/arch/blackfin/include/asm/sections.h @@ -0,0 +1,27 @@ +/* + * Copyright (c) 2012 The Chromium OS Authors. + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + *
[U-Boot] [PATCH v4 05/27] x86: Add initial memory barrier macros
These are available on other architectures, so add them on x86. Signed-off-by: Simon Glass s...@chromium.org --- arch/x86/include/asm/io.h |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index 9b757d4..b12bdd8 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -234,4 +234,12 @@ static inline phys_addr_t virt_to_phys(void * vaddr) return (phys_addr_t)(vaddr); } +/* + * TODO: The kernel offers some more advanced versions of barriers, it might + * have some advantages to use them instead of the simple one here. + */ +#define dmb() __asm__ __volatile__ ( : : : memory) +#define __iormb() dmb() +#define __iowmb() dmb() + #endif -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 07/27] Introduce generic global_data
We want to unify the global_data structure. Most fields are common across
architectures, but there are a fair number of SOC-specific additions. It
isn't clear how best to deal with these, but for now we just use #ifdef.
Checkpatch warnings here might be unavoidable:
warning: include/asm-generic/global_data.h,43: do not add new typedefs
warning: include/asm-generic/global_data.h,117: Use of volatile is usually
wrong: see Documentation/volatile-considered-harmful.txt
warning: include/asm-generic/global_data.h,121: storage class should be at the
beginning of the declaration
Signed-off-by: Simon Glass s...@chromium.org
---
include/asm-generic/global_data.h | 115 +
1 files changed, 115 insertions(+), 0 deletions(-)
create mode 100644 include/asm-generic/global_data.h
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
new file mode 100644
index 000..6199926
--- /dev/null
+++ b/include/asm-generic/global_data.h
@@ -0,0 +1,115 @@
+/*
+ * (C) Copyright 2002-2010
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * 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
+ */
+
+#ifndef__ASM_GENERIC_GBL_DATA_H
+#define __ASM_GENERIC_GBL_DATA_H
+/*
+ * The following data structure is placed in some memory which is
+ * available very early after boot (like DPRAM on MPC8xx/MPC82xx, or
+ * some locked parts of the data cache) to allow for a minimum set of
+ * global variables during system initialization (until we have set
+ * up the memory controller so that we can use RAM).
+ *
+ * Keep it *SMALL* and remember to set GENERATED_GBL_DATA_SIZE sizeof(gd_t)
+ *
+ * s...@chromium.org: Well it would be nice to have a generic one of these
+ * since so many fields are similar. But it means that everyone architecture
+ * will want to add its own nutty fields. Perhaps that is no bad thing since
+ * it shows up inconsistences and might produce downward pressure on the
+ * number of fields.
+ */
+
+#ifndef __ASSEMBLY__
+typedef struct global_data {
+ bd_t*bd;
+ unsigned long flags;
+ unsigned long baudrate;
+#if defined(CONFIG_LCD) || defined(CONFIG_VIDEO)
+ unsigned long fb_base;/* Base address of framebuffer mem */
+#endif
+#if defined(CONFIG_POST) || defined(CONFIG_LOGBUFFER)
+ unsigned long post_log_word; /* Record POST activities */
+ unsigned long post_log_res; /* success of POST test */
+ unsigned long post_init_f_time; /* When post_init_f started */
+#endif
+ unsigned long have_console; /* serial_init() was called */
+#ifdef CONFIG_PRE_CONSOLE_BUFFER
+ unsigned long precon_buf_idx; /* Pre-Console buffer index */
+#endif
+ unsigned long env_addr; /* Address of Environment struct */
+ unsigned long env_valid; /* Checksum of Environment valid? */
+ /* Here begins ARM-specific things. Needs discussion */
+#ifdef CONFIG_AT91FAMILY
+ /* static data needed by at91's clock.c */
+ unsigned long cpu_clk_rate_hz;
+ unsigned long main_clk_rate_hz;
+ unsigned long mck_rate_hz;
+ unsigned long plla_rate_hz;
+ unsigned long pllb_rate_hz;
+ unsigned long at91_pllb_usb_init;
+#endif
+#ifdef CONFIG_ARM
+ /* static data needed by most of timer.c on ARM platforms */
+ unsigned long timer_rate_hz;
+ unsigned long tbl;
+ unsigned long tbu;
+ unsigned long long timer_reset_value;
+ unsigned long lastinc;
+#endif
+#ifdef CONFIG_IXP425
+ unsigned long timestamp;
+#endif
+ /* TODO: is this the same as relocaddr, or something else? */
+ unsigned long dest_addr; /* Post-relocation address of U-Boot */
+ unsigned long dest_addr_sp;
+ unsigned long ram_top;/* Top address of RAM used by U-Boot */
+
+ unsigned long relocaddr; /* Start address of U-Boot in RAM */
+ phys_size_t ram_size; /* RAM size */
+ unsigned long mon_len;/* monitor len */
+ unsigned long irq_sp; /* irq stack pointer */
+ unsigned long start_addr_sp; /* start_addr_stackpointer */
+ unsigned
[U-Boot] [PATCH v4 06/27] ppc: Add initial memory barrier macros
These are available on other architectures, so add them on ppc. Signed-off-by: Simon Glass s...@chromium.org --- arch/powerpc/include/asm/io.h |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h index 56ac9fe..d246fd8 100644 --- a/arch/powerpc/include/asm/io.h +++ b/arch/powerpc/include/asm/io.h @@ -318,4 +318,12 @@ static inline phys_addr_t virt_to_phys(void * vaddr) #endif } +/* + * TODO: The kernel offers some more advanced versions of barriers, it might + * have some advantages to use them instead of the simple one here. + */ +#define dmb() __asm__ __volatile__ ( : : : memory) +#define __iormb() dmb() +#define __iowmb() dmb() + #endif -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 03/27] arm: Only display frame buffer info if there is LCD/video support
This value has no meaning otherwise. Signed-off-by: Simon Glass s...@chromium.org --- common/cmd_bdinfo.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c index 54a56f4..80c100c 100644 --- a/common/cmd_bdinfo.c +++ b/common/cmd_bdinfo.c @@ -369,7 +369,9 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) print_num(reloc off, gd-reloc_off); print_num(irq_sp, gd-irq_sp);/* irq stack pointer */ print_num(sp start , gd-start_addr_sp); +#if defined(CONFIG_LCD) || defined(CONFIG_VIDEO) print_num(FB base , gd-fb_base); +#endif /* * TODO: Currently only support for davinci SOC's is added. * Remove this check once all the board implement this. -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 02/27] x86: Change board baud_rate to ulong
This is a ulong for some architectures and just unsigned for others.
Change x86 to be consistent.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/include/asm/u-boot.h |2 +-
common/cmd_bdinfo.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/u-boot.h b/arch/x86/include/asm/u-boot.h
index 26450eb..dd42209 100644
--- a/arch/x86/include/asm/u-boot.h
+++ b/arch/x86/include/asm/u-boot.h
@@ -49,7 +49,7 @@ typedef struct bd_info {
unsigned short bi_ethspeed;/* Ethernet speed in Mbps */
unsigned long bi_intfreq; /* Internal Freq, in MHz */
unsigned long bi_busfreq; /* Bus Freq, in MHz */
- unsigned intbi_baudrate;/* Console Baudrate */
+ unsigned long bi_baudrate;/* Console Baudrate */
unsigned long bi_boot_params; /* where this board expects params */
struct /* RAM configuration */
{
diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c
index c034ec9..54a56f4 100644
--- a/common/cmd_bdinfo.c
+++ b/common/cmd_bdinfo.c
@@ -431,7 +431,7 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
printf(ip_addr = %pI4\n, bd-bi_ip_addr);
print_mhz(ethspeed, bd-bi_ethspeed);
#endif
- printf(baudrate= %d bps\n, bd-bi_baudrate);
+ printf(baudrate= %ld bps\n, bd-bi_baudrate);
return 0;
}
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 10/27] arm: Use sections header to obtain link symbols
Include this header to get access to link symbols, which are otherwise removed. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v4: - Use asm/sections.h instead of asm-generic/sections.h arch/arm/include/asm/u-boot-arm.h |4 arch/arm/lib/board.c |1 + arch/avr32/cpu/start.S|2 +- arch/avr32/cpu/u-boot.lds |2 +- board/cm4008/flash.c |1 + board/cm41xx/flash.c |1 + 6 files changed, 5 insertions(+), 6 deletions(-) diff --git a/arch/arm/include/asm/u-boot-arm.h b/arch/arm/include/asm/u-boot-arm.h index 4ca75f9..7cfae9b 100644 --- a/arch/arm/include/asm/u-boot-arm.h +++ b/arch/arm/include/asm/u-boot-arm.h @@ -30,12 +30,8 @@ #define _U_BOOT_ARM_H_ 1 /* for the following variables, see start.S */ -extern ulong _bss_start_ofs; /* BSS start relative to _start */ -extern ulong _bss_end_ofs; /* BSS end relative to _start */ -extern ulong _end_ofs; /* end of image relative to _start */ extern ulong IRQ_STACK_START; /* top of IRQ stack */ extern ulong FIQ_STACK_START; /* top of FIQ stack */ -extern ulong _TEXT_BASE; /* code start */ extern ulong _datarel_start_ofs; extern ulong _datarelrolocal_start_ofs; extern ulong _datarellocal_start_ofs; diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index 500e216..fdd5d15 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -63,6 +63,7 @@ #ifdef CONFIG_DRIVER_LAN91C96 #include ../drivers/net/lan91c96.h #endif +#include asm/sections.h DECLARE_GLOBAL_DATA_PTR; diff --git a/arch/avr32/cpu/start.S b/arch/avr32/cpu/start.S index 71cbc52..c8decea 100644 --- a/arch/avr32/cpu/start.S +++ b/arch/avr32/cpu/start.S @@ -244,7 +244,7 @@ relocate_code: /* zero out .bss */ mov r0, 0 mov r1, 0 - lda.w r9, __bss_end__ + lda.w r9, __bss_end sub r9, r8 1: st.dr10++, r0 sub r9, 8 diff --git a/arch/avr32/cpu/u-boot.lds b/arch/avr32/cpu/u-boot.lds index 0e532f2..4de2fff 100644 --- a/arch/avr32/cpu/u-boot.lds +++ b/arch/avr32/cpu/u-boot.lds @@ -68,5 +68,5 @@ SECTIONS *(.bss.*) } . = ALIGN(8); - __bss_end__ = .; + __bss_end = .; } diff --git a/board/cm4008/flash.c b/board/cm4008/flash.c index 5522bf0..0faf197 100644 --- a/board/cm4008/flash.c +++ b/board/cm4008/flash.c @@ -29,6 +29,7 @@ #include common.h #include linux/byteorder/swab.h +#include asm/sections.h flash_info_t flash_info[CONFIG_SYS_MAX_FLASH_BANKS]; /* info for FLASH chips */ diff --git a/board/cm41xx/flash.c b/board/cm41xx/flash.c index 5522bf0..0faf197 100644 --- a/board/cm41xx/flash.c +++ b/board/cm41xx/flash.c @@ -29,6 +29,7 @@ #include common.h #include linux/byteorder/swab.h +#include asm/sections.h flash_info_t flash_info[CONFIG_SYS_MAX_FLASH_BANKS]; /* info for FLASH chips */ -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 14/27] Introduce generic pre-relocation board_f.c
This file handles common pre-relocation init for boards which use
the generic framework.
It starts up the console, DRAM, performs relocation and then jumps
to post-relocation init.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3:
- Cast away the volatile on gd for memcpy()
Changes in v4:
- Use asm/sections.h instead of asm-generic/sections.h
common/Makefile |3 +
common/board_f.c | 490 ++
2 files changed, 493 insertions(+), 0 deletions(-)
create mode 100644 common/board_f.c
diff --git a/common/Makefile b/common/Makefile
index 2a31c62..125c2a9 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -36,6 +36,9 @@ COBJS-y += s_record.o
COBJS-$(CONFIG_SERIAL_MULTI) += serial.o
COBJS-y += xyzModem.o
+# boards
+COBJS-$(CONFIG_SYS_GENERIC_BOARD) += board_f.o
+
# core command
COBJS-y += cmd_boot.o
COBJS-$(CONFIG_CMD_BOOTM) += cmd_bootm.o
diff --git a/common/board_f.c b/common/board_f.c
new file mode 100644
index 000..9477721
--- /dev/null
+++ b/common/board_f.c
@@ -0,0 +1,490 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * (C) Copyright 2002-2006
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * (C) Copyright 2002
+ * Sysgo Real-Time Solutions, GmbH www.elinos.com
+ * Marius Groeger mgroe...@sysgo.de
+ *
+ * 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 linux/compiler.h
+#include version.h
+#include environment.h
+#include initcall.h
+#include logbuff.h
+#include post.h
+#include asm/io.h
+#include asm/sections.h
+
+/*
+ * Pointer to initial global data area
+ *
+ * Here we initialize it if needed.
+ */
+#ifdef XTRN_DECLARE_GLOBAL_DATA_PTR
+#undef XTRN_DECLARE_GLOBAL_DATA_PTR
+#define XTRN_DECLARE_GLOBAL_DATA_PTR /* empty = allocate here */
+DECLARE_GLOBAL_DATA_PTR = (gd_t *) (CONFIG_SYS_INIT_GD_ADDR);
+#else
+DECLARE_GLOBAL_DATA_PTR;
+#endif
+
+/* TODO: Move to header file */
+int print_cpuinfo(void);
+
+/*
+ * sjg: IMO this code should be
+ * refactored to a single function, something like:
+ *
+ * void led_set_state(enum led_colour_t colour, int on);
+ */
+/
+ * Coloured LED functionality
+
+ * May be supplied by boards if desired
+ */
+inline void __coloured_LED_init(void) {}
+void coloured_LED_init(void)
+ __attribute__((weak, alias(__coloured_LED_init)));
+inline void __red_led_on(void) {}
+void red_led_on(void) __attribute__((weak, alias(__red_led_on)));
+inline void __red_led_off(void) {}
+void red_led_off(void) __attribute__((weak, alias(__red_led_off)));
+inline void __green_led_on(void) {}
+void green_led_on(void) __attribute__((weak, alias(__green_led_on)));
+inline void __green_led_off(void) {}
+void green_led_off(void) __attribute__((weak, alias(__green_led_off)));
+inline void __yellow_led_on(void) {}
+void yellow_led_on(void) __attribute__((weak, alias(__yellow_led_on)));
+inline void __yellow_led_off(void) {}
+void yellow_led_off(void) __attribute__((weak, alias(__yellow_led_off)));
+inline void __blue_led_on(void) {}
+void blue_led_on(void) __attribute__((weak, alias(__blue_led_on)));
+inline void __blue_led_off(void) {}
+void blue_led_off(void) __attribute__((weak, alias(__blue_led_off)));
+
+/*
+ * Why is gd allocated a register? Prior to reloc it might be better to
+ * just pass it around to each function in this file?
+ *
+ * After reloc one could argue that it is hardly used and doesn't need
+ * to be in a register. Or if it is it should perhaps hold pointers to all
+ * global data for all modules, so that post-reloc we can avoid the massive
+ * literal pool we get on ARM. Or perhaps just encourage each module to use
+ * a structure...
+ */
+
+/*
+ * Could the CONFIG_SPL_BUILD infection become a flag in gd?
+ */
+
+static int init_baud_rate(void)
+{
+ gd-baudrate = getenv_ulong(baudrate, 10, CONFIG_BAUDRATE);
+ return 0;
+}
+
+static int display_text_info(void)
+{
+ ulong bss_start, bss_end;
+
+ bss_start = _bss_start_ofs + _TEXT_BASE;
+ bss_end = _bss_end_ofs + _TEXT_BASE;
+ debug(U-Boot code: %08X - %08lX
[U-Boot] [PATCH v4 11/27] x86: Change stub example to use asm-generic/sections.h
We can use the declarations of __bss_start and _end from this header
instead of declaring them locally.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v4:
- Use asm/sections.h instead of asm-generic/sections.h
examples/standalone/stubs.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/examples/standalone/stubs.c b/examples/standalone/stubs.c
index 15e9afc..8fb1765 100644
--- a/examples/standalone/stubs.c
+++ b/examples/standalone/stubs.c
@@ -217,16 +217,15 @@ void __attribute__((unused)) dummy(void)
#include _exports.h
}
-extern unsigned long __bss_start, _end;
+#include asm/sections.h
void app_startup(char * const *argv)
{
- unsigned char * cp = (unsigned char *) __bss_start;
+ char *cp = __bss_start;
/* Zero out BSS */
- while (cp (unsigned char *)_end) {
+ while (cp _end)
*cp++ = 0;
- }
#if defined(CONFIG_X86)
/* x86 does not have a dedicated register for passing global_data */
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 12/27] Introduce a basic initcall implementation
This library supports calling a list of functions one after the
other.
It is intended that we move to a more powerful initcall implementation
as proposed by Graeme Russ graeme.r...@gmail.com. For now, this allows
us to do the basics.
Signed-off-by: Simon Glass s...@chromium.org
---
include/initcall.h | 25 +
lib/Makefile |1 +
lib/initcall.c | 41 +
3 files changed, 67 insertions(+), 0 deletions(-)
create mode 100644 include/initcall.h
create mode 100644 lib/initcall.c
diff --git a/include/initcall.h b/include/initcall.h
new file mode 100644
index 000..9e54fa5
--- /dev/null
+++ b/include/initcall.h
@@ -0,0 +1,25 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ *
+ * 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
+ */
+
+typedef int (*init_fnc_t)(void);
+
+int initcall_run_list(init_fnc_t init_sequence[]);
diff --git a/lib/Makefile b/lib/Makefile
index e6e6ec6..f4d3325 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -41,6 +41,7 @@ COBJS-y += display_options.o
COBJS-y += errno.o
COBJS-$(CONFIG_OF_CONTROL) += fdtdec.o
COBJS-$(CONFIG_GZIP) += gunzip.o
+COBJS-y += initcall.o
COBJS-y += hashtable.o
COBJS-$(CONFIG_LMB) += lmb.o
COBJS-y += ldiv.o
diff --git a/lib/initcall.c b/lib/initcall.c
new file mode 100644
index 000..b11048e
--- /dev/null
+++ b/lib/initcall.c
@@ -0,0 +1,41 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * (C) Copyright 2002-2006
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * (C) Copyright 2002
+ * Sysgo Real-Time Solutions, GmbH www.elinos.com
+ * Marius Groeger mgroe...@sysgo.de
+ *
+ * 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 initcall.h
+
+int initcall_run_list(init_fnc_t init_sequence[])
+{
+ init_fnc_t *init_fnc_ptr;
+
+ for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
+ if ((*init_fnc_ptr)())
+ return -1;
+ }
+ return 0;
+}
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 08/27] Introduce generic u-boot.h file
This file holds the board info structure. We need this to be generic
for the unified board series, so create a structure which contains
the basic fields required by the main architectures.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v4:
- Add three more fields required for ARM
include/asm-generic/u-boot.h | 160 ++
1 files changed, 160 insertions(+), 0 deletions(-)
create mode 100644 include/asm-generic/u-boot.h
diff --git a/include/asm-generic/u-boot.h b/include/asm-generic/u-boot.h
new file mode 100644
index 000..8a684fb
--- /dev/null
+++ b/include/asm-generic/u-boot.h
@@ -0,0 +1,160 @@
+/*
+ * (C) Copyright 2000 - 2002
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+
+ * NOTE: This header file defines an interface to U-Boot. Including
+ * this (unmodified) header file in another file is considered normal
+ * use of U-Boot, and does *not* fall under the heading of derived
+ * work.
+
+ */
+
+#ifndef __ASM_GENERIC_U_BOOT_H__
+#define __ASM_GENERIC_U_BOOT_H__
+
+/*
+ * Board information passed to Linux kernel from U-Boot
+ *
+ * include/asm-ppc/u-boot.h
+ */
+
+#ifndef __ASSEMBLY__
+
+typedef struct bd_info {
+ unsigned long bi_memstart;/* start of DRAM memory */
+ phys_size_t bi_memsize; /* size of DRAM memory in bytes */
+ unsigned long bi_flashstart; /* start of FLASH memory */
+ unsigned long bi_flashsize; /* size of FLASH memory */
+ unsigned long bi_flashoffset; /* reserved area for startup monitor */
+ unsigned long bi_sramstart; /* start of SRAM memory */
+ unsigned long bi_sramsize;/* size of SRAM memory */
+#ifdef CONFIG_ARM
+ unsigned long bi_arm_freq; /* arm frequency */
+ unsigned long bi_dsp_freq; /* dsp core frequency */
+ unsigned long bi_ddr_freq; /* ddr frequency */
+#endif
+#if defined(CONFIG_5xx) || defined(CONFIG_8xx) || defined(CONFIG_8260) \
+ || defined(CONFIG_E500) || defined(CONFIG_MPC86xx)
+ unsigned long bi_immr_base; /* base of IMMR register */
+#endif
+#if defined(CONFIG_MPC5xxx)
+ unsigned long bi_mbar_base; /* base of internal registers */
+#endif
+#if defined(CONFIG_MPC83xx)
+ unsigned long bi_immrbar;
+#endif
+#if defined(CONFIG_MPC8220)
+ unsigned long bi_mbar_base; /* base of internal registers */
+ unsigned long bi_inpfreq; /* Input Freq, In MHz */
+ unsigned long bi_pcifreq; /* PCI Freq, in MHz */
+ unsigned long bi_pevfreq; /* PEV Freq, in MHz */
+ unsigned long bi_flbfreq; /* Flexbus Freq, in MHz */
+ unsigned long bi_vcofreq; /* VCO Freq, in MHz */
+#endif
+ unsigned long bi_bootflags; /* boot / reboot flag (Unused) */
+ unsigned long bi_ip_addr; /* IP Address */
+ unsigned char bi_enetaddr[6]; /* OLD: see README.enetaddr */
+ unsigned short bi_ethspeed;/* Ethernet speed in Mbps */
+ unsigned long bi_intfreq; /* Internal Freq, in MHz */
+ unsigned long bi_busfreq; /* Bus Freq, in MHz */
+#if defined(CONFIG_CPM2)
+ unsigned long bi_cpmfreq; /* CPM_CLK Freq, in MHz */
+ unsigned long bi_brgfreq; /* BRG_CLK Freq, in MHz */
+ unsigned long bi_sccfreq; /* SCC_CLK Freq, in MHz */
+ unsigned long bi_vco; /* VCO Out from PLL, in MHz */
+#endif
+#if defined(CONFIG_MPC512X)
+ unsigned long bi_ipsfreq; /* IPS Bus Freq, in MHz */
+#endif /* CONFIG_MPC512X */
+#if defined(CONFIG_MPC5xxx)
+ unsigned long bi_ipbfreq; /* IPB Bus Freq, in MHz */
+ unsigned long bi_pcifreq; /* PCI Bus Freq, in MHz */
+#endif
+ unsigned long bi_baudrate;/* Console Baudrate */
+#if defined(CONFIG_405) || \
+ defined(CONFIG_405GP) || \
+ defined(CONFIG_405CR) || \
+ defined(CONFIG_405EP) || \
+ defined(CONFIG_405EZ) || \
+ defined(CONFIG_405EX) || \
+ defined(CONFIG_440)
+ unsigned char bi_s_version[4];
[U-Boot] [PATCH v4 21/27] x86: Enable generic board support
This enables generic board support so that x86 boards can define
CONFIG_SYS_GENERIC_BOARD.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/config.mk |3 ---
arch/x86/include/asm/global_data.h |7 +++
arch/x86/include/asm/u-boot.h | 11 +++
arch/x86/lib/Makefile |4 +++-
common/board_r.c |5 +
5 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/arch/x86/config.mk b/arch/x86/config.mk
index 7be3036..23cacff 100644
--- a/arch/x86/config.mk
+++ b/arch/x86/config.mk
@@ -48,6 +48,3 @@ NORMAL_LIBGCC = $(shell $(CC) $(CFLAGS)
-print-libgcc-file-name)
PREFIXED_LIBGCC = $(OBJTREE)/arch/$(ARCH)/lib/$(shell basename
$(NORMAL_LIBGCC))
export USE_PRIVATE_LIBGCC=$(shell dirname $(PREFIXED_LIBGCC))
-
-# Move to unified board system later
-CONFIG_SYS_LEGACY_BOARD := y
diff --git a/arch/x86/include/asm/global_data.h
b/arch/x86/include/asm/global_data.h
index 908a02c..fe50856 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -23,6 +23,11 @@
#ifndef__ASM_GBL_DATA_H
#define __ASM_GBL_DATA_H
+
+#ifdef CONFIG_SYS_GENERIC_BOARD
+/* Use the generic board which requires a unified global_data */
+#include asm-generic/global_data.h
+#else
/*
* The following data structure is placed in some memory wich is
* available very early after boot (like DPRAM on MPC8xx/MPC82xx, or
@@ -86,6 +91,8 @@ static inline gd_t *get_fs_gd_ptr(void)
#define GD_FLG_DISABLE_CONSOLE 0x00040 /* Disable console (in out)
*/
#define GD_FLG_ENV_READY 0x00080 /* Environment imported into hash table
*/
+#endif /* nCONFIG_SYS_GENERIC_BOARD */
+
#define DECLARE_GLOBAL_DATA_PTR
#endif /* __ASM_GBL_DATA_H */
diff --git a/arch/x86/include/asm/u-boot.h b/arch/x86/include/asm/u-boot.h
index dd42209..ef8b7d5 100644
--- a/arch/x86/include/asm/u-boot.h
+++ b/arch/x86/include/asm/u-boot.h
@@ -36,6 +36,13 @@
#ifndef _U_BOOT_H_
#define _U_BOOT_H_ 1
+#ifdef CONFIG_SYS_GENERIC_BOARD
+/* Use the generic board which requires a unified bd_info */
+#include asm-generic/u-boot.h
+#else
+
+#ifndef __ASSEMBLY__
+
typedef struct bd_info {
unsigned long bi_memstart;/* start of DRAM memory */
phys_size_t bi_memsize; /* size of DRAM memory in bytes */
@@ -58,6 +65,10 @@ typedef struct bd_info {
}bi_dram[CONFIG_NR_DRAM_BANKS];
} bd_t;
+#endif /* __ASSEMBLY__ */
+
+#endif /* nCONFIG_SYS_GENERIC_BOARD */
+
/* For image.h:image_check_target_arch() */
#define IH_ARCH_DEFAULT IH_ARCH_I386
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 51836da..a2083f4 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -30,7 +30,9 @@ SOBJS-$(CONFIG_SYS_PCI_BIOS) += bios_pci.o
SOBJS-$(CONFIG_SYS_X86_REALMODE) += realmode_switch.o
COBJS-$(CONFIG_SYS_PC_BIOS)+= bios_setup.o
-COBJS-y+= board.o
+ifeq ($(CONFIG_SYS_GENERIC_BOARD),)
+COBJS-y += board.o
+endif
COBJS-y+= bootm.o
COBJS-y+= cmd_boot.o
COBJS-y+= gcc.o
diff --git a/common/board_r.c b/common/board_r.c
index 8b9adc2..f587c03 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -56,12 +56,15 @@ static int initr_reloc(void)
* Some of these functions are needed purely because the functions they
* call return void. If we change them to return 0, these stubs can go away.
*/
+#ifdef CONFIG_ARM
static int initr_caches(void)
{
+ /* TODO: sort out x86 code here */
/* Enable caches */
enable_caches();
return 0;
}
+#endif
static int initr_reloc_global_data(void)
{
@@ -232,11 +235,13 @@ static int initr_api(void)
#endif
/* enable exceptions */
+#ifdef CONFIG_ARM
static int initr_enable_interrupts(void)
{
enable_interrupts();
return 0;
}
+#endif
#ifdef CONFIG_CMD_NET
static int initr_ethaddr(void)
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 18/27] Add CONFIG_SYS_SYM_OFFSETS to support offset symbols
Link symbols as created by the link script can either be absolute or
relative to the text start. This option switches between the two options
so that we can support both.
As we convert architectures over to generic board, we can see if this
option is actually needed, or whether it is possible to unify this feature
also.
Signed-off-by: Simon Glass s...@chromium.org
---
README |6 ++
common/board_f.c | 11 +++
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/README b/README
index f471627..251afaf 100644
--- a/README
+++ b/README
@@ -2780,6 +2780,12 @@ Configuration Settings:
its config.mk file). If you find problems enabling this option on
your board please report the problem and send patches!
+- CONFIG_SYS_SYM_OFFSETS
+ This is set by architectures that use offsets for link symbols
+ instead of absolute values. So bss_start is obtained using an
+ offset _bss_start_ofs from CONFIG_SYS_TEXT_BASE, rather than
+ directly. You should not need to touch this setting.
+
The following definitions that deal with the placement and management
of environment data (variable area); in general, we support the
diff --git a/common/board_f.c b/common/board_f.c
index a08f0a1..2f14118 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -108,8 +108,13 @@ static int display_text_info(void)
{
ulong bss_start, bss_end;
+#ifdef CONFIG_SYS_SYM_OFFSETS
bss_start = _bss_start_ofs + _TEXT_BASE;
bss_end = _bss_end_ofs + _TEXT_BASE;
+#else
+ bss_start = (ulong)__bss_start;
+ bss_end = (ulong)__bss_end;
+#endif
debug(U-Boot code: %08X - %08lX BSS: - %08lX\n,
CONFIG_SYS_TEXT_BASE, bss_start, bss_end);
@@ -186,7 +191,11 @@ static int zero_global_data(void)
static int setup_mon_len(void)
{
+#ifdef CONFIG_SYS_SYM_OFFSETS
gd-mon_len = _bss_end_ofs;
+#else
+ gd-mon_len = (ulong)__bss_end - (ulong)__text_start;
+#endif
return 0;
}
@@ -423,6 +432,7 @@ static int jump_to_copy(void)
static init_fnc_t init_sequence_f[] = {
setup_global_data_ptr,
+ zero_global_data,
setup_fdt,
setup_mon_len,
#if defined(CONFIG_ARCH_CPU_INIT)
@@ -457,6 +467,7 @@ static init_fnc_t init_sequence_f[] = {
#ifdef CONFIG_POST
init_post,
#endif
+ setup_dram_config,
setup_reloc,
#if defined(CONFIG_LOGBUFFER) !defined(CONFIG_ALT_LB_ADDR)
reserve_logbuffer,
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 16/27] Add spl load feature
This adds secondary program loader support to the generic board.
Signed-off-by: Simon Glass s...@chromium.org
---
common/board_f.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c
index 9477721..a08f0a1 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -305,6 +305,7 @@ static int reserve_uboot(void)
return 0;
}
+#ifndef CONFIG_SPL_BUILD
/* reserve memory for malloc() area */
static int reserve_malloc(void)
{
@@ -324,6 +325,7 @@ static int reserve_board(void)
sizeof(bd_t), gd-dest_addr_sp);
return 0;
}
+#endif
static int setup_machine(void)
{
@@ -342,6 +344,7 @@ static int reserve_global_data(void)
return 0;
}
+#ifndef CONFIG_SPL_BUILD
static int reserve_stacks(void)
{
/* setup stack pointer for exceptions */
@@ -359,6 +362,17 @@ static int reserve_stacks(void)
return 0;
}
+#endif
+
+#ifdef CONFIG_SPL_BUILD
+static int reserve_stacks_spl(void)
+{
+ /* Why not -= ? */
+ gd-dest_addr_sp += 128;/* leave 32 words for abort-stack */
+ gd-irq_sp = gd-dest_addr_sp;
+ return 0;
+}
+#endif
static int display_new_sp(void)
{
@@ -458,11 +472,17 @@ static init_fnc_t init_sequence_f[] = {
reserve_lcd,
#endif
reserve_uboot,
+#ifndef CONFIG_SPL_BUILD
reserve_malloc,
reserve_board,
+#endif
setup_machine,
reserve_global_data,
+#ifdef CONFIG_SPL_BUILD
+ reserve_stacks_spl,
+#else
reserve_stacks,
+#endif
setup_baud_rate,
display_new_sp,
jump_to_copy,
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 15/27] Introduce generic post-relocation board_r.c
This file handles common post-relocation init for boards which use
the generic framework.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v4:
- Use asm/sections.h instead of asm-generic/sections.h
common/Makefile |1 +
common/board_r.c | 401 ++
2 files changed, 402 insertions(+), 0 deletions(-)
create mode 100644 common/board_r.c
diff --git a/common/Makefile b/common/Makefile
index 125c2a9..a10e5a9 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -38,6 +38,7 @@ COBJS-y += xyzModem.o
# boards
COBJS-$(CONFIG_SYS_GENERIC_BOARD) += board_f.o
+COBJS-$(CONFIG_SYS_GENERIC_BOARD) += board_r.o
# core command
COBJS-y += cmd_boot.o
diff --git a/common/board_r.c b/common/board_r.c
new file mode 100644
index 000..8b9adc2
--- /dev/null
+++ b/common/board_r.c
@@ -0,0 +1,401 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * (C) Copyright 2002-2006
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * (C) Copyright 2002
+ * Sysgo Real-Time Solutions, GmbH www.elinos.com
+ * Marius Groeger mgroe...@sysgo.de
+ *
+ * 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
+#ifdef CONFIG_HAS_DATAFLASH
+#include dataflash.h
+#endif
+#include environment.h
+#include initcall.h
+#include logbuff.h
+#include malloc.h
+#include mmc.h
+#include nand.h
+#include onenand_uboot.h
+#include serial.h
+#include stdio_dev.h
+#include asm/sections.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+ulong monitor_flash_len;
+
+
+static int initr_reloc(void)
+{
+ gd-flags |= GD_FLG_RELOC; /* tell others: relocation done */
+ return 0;
+}
+
+/*
+ * Some of these functions are needed purely because the functions they
+ * call return void. If we change them to return 0, these stubs can go away.
+ */
+static int initr_caches(void)
+{
+ /* Enable caches */
+ enable_caches();
+ return 0;
+}
+
+static int initr_reloc_global_data(void)
+{
+#ifdef CONFIG_SYS_SYM_OFFSETS
+ monitor_flash_len = _end_ofs;
+#else
+ monitor_flash_len = (ulong)__init_end - gd-dest_addr;
+#endif
+}
+
+#ifdef CONFIG_SERIAL_MULTI
+static int initr_serial(void)
+{
+ serial_initialize();
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_LOGBUFFER
+unsigned long logbuffer_base(void)
+{
+ return gd-ram_top - LOGBUFF_LEN;
+}
+
+static int initr_logbuffer(void)
+{
+ logbuff_init_ptrs();
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_POST
+static int initr_post_backlog(void)
+{
+ post_output_backlog();
+ return 0;
+}
+#endif
+
+static int initr_malloc(void)
+{
+ ulong malloc_start;
+
+ /* The malloc area is immediately below the monitor copy in DRAM */
+ malloc_start = gd-dest_addr - TOTAL_MALLOC_LEN;
+ mem_malloc_init(malloc_start, TOTAL_MALLOC_LEN);
+ return 0;
+}
+
+static int initr_announce(void)
+{
+ debug(Now running in RAM - U-Boot at: %08lx\n, gd-dest_addr);
+ return 0;
+}
+
+#if !defined(CONFIG_SYS_NO_FLASH)
+static int initr_flash(void)
+{
+ ulong flash_size;
+
+ puts(Flash: );
+
+ flash_size = flash_init();
+ if (flash_size = 0) {
+ puts(*** failed ***\n);
+ return -1;
+ }
+ print_size(flash_size, );
+#ifdef CONFIG_SYS_FLASH_CHECKSUM
+ {
+ char *s;
+
+ s = getenv(flashchecksum);
+
+ /*
+ * Compute and print flash CRC if flashchecksum is set to 'y'
+ *
+ * NOTE: Maybe we should add some WATCHDOG_RESET()? XXX
+ */
+ if (s (*s == 'y')) {
+ printf( CRC: %08X, crc32(0,
+ (const unsigned char *) CONFIG_SYS_FLASH_BASE,
+ flash_size));
+ }
+ }
+#endif /* CONFIG_SYS_FLASH_CHECKSUM */
+ putc('\n');
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_CMD_NAND
+/* go init the NAND */
+int initr_nand(void)
+{
+ puts(NAND: );
+ nand_init();
+ return 0;
+}
+#endif
+
+#if defined(CONFIG_CMD_ONENAND)
+/* go init the NAND */
+int initr_onenand(void)
+{
+ puts(NAND: );
+ onenand_init();
+ return 0;
+}
[U-Boot] [PATCH v4 17/27] arm: Enable generic board support
This enables generic board support so that ARM boards can define
CONFIG_SYS_GENERIC_BOARD.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/arm/config.mk |3 ---
arch/arm/include/asm/global_data.h |7 +++
arch/arm/include/asm/u-boot.h |9 +
arch/arm/lib/Makefile |4 +++-
4 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 31e9ef9..45f9dca 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -33,9 +33,6 @@ endif
PLATFORM_CPPFLAGS += -DCONFIG_ARM -D__ARM__
-# Move to unified board system later
-CONFIG_SYS_LEGACY_BOARD := y
-
# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
PF_CPPFLAGS_ARM := $(call cc-option,-marm,)
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index c3ff789..aced4fe 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -23,6 +23,11 @@
#ifndef__ASM_GBL_DATA_H
#define __ASM_GBL_DATA_H
+
+#ifdef CONFIG_SYS_GENERIC_BOARD
+/* Use the generic board which requires a unified global_data */
+#include asm-generic/global_data.h
+#else
/*
* The following data structure is placed in some memory which is
* available very early after boot (like DPRAM on MPC8xx/MPC82xx, or
@@ -98,6 +103,8 @@ typedef struct global_data {
#define GD_FLG_DISABLE_CONSOLE 0x00040 /* Disable console (in out)
*/
#define GD_FLG_ENV_READY 0x00080 /* Environment imported into hash table
*/
+#endif /* nCONFIG_SYS_GENERIC_BOARD */
+
#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm (r8)
#endif /* __ASM_GBL_DATA_H */
diff --git a/arch/arm/include/asm/u-boot.h b/arch/arm/include/asm/u-boot.h
index a0691b7..fe336b3 100644
--- a/arch/arm/include/asm/u-boot.h
+++ b/arch/arm/include/asm/u-boot.h
@@ -36,6 +36,12 @@
#ifndef _U_BOOT_H_
#define _U_BOOT_H_ 1
+#ifdef CONFIG_SYS_GENERIC_BOARD
+/* Use the generic board which requires a unified bd_info */
+#include asm-generic/u-boot.h
+#else
+
+#ifndef __ASSEMBLY__
typedef struct bd_info {
unsigned long bi_baudrate;/* serial console baudrate */
unsigned long bi_ip_addr; /* IP Address */
@@ -50,6 +56,9 @@ typedef struct bd_info {
ulong size;
} bi_dram[CONFIG_NR_DRAM_BANKS];
} bd_t;
+#endif
+
+#endif /* nCONFIG_SYS_GENERIC_BOARD */
/* For image.h:image_check_target_arch() */
#define IH_ARCH_DEFAULT IH_ARCH_ARM
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 300c8fa..11cfc00 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -37,7 +37,9 @@ GLSOBJS += _umodsi3.o
GLCOBJS+= div0.o
-COBJS-y+= board.o
+ifeq ($(CONFIG_SYS_GENERIC_BOARD),)
+COBJS-y += board.o
+endif
COBJS-y+= bootm.o
COBJS-y+= cache.o
COBJS-y+= cache-cp15.o
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 19/27] x86: Use sections header to obtain link symbols
These are defined in asm-generic/sections.h, so remove them from architecture-specific files. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: - Add header to new x86 relocate.c and init_helpers.c Changes in v4: - Use asm/sections.h instead of asm-generic/sections.h arch/x86/include/asm/u-boot-x86.h |8 arch/x86/lib/board.c |1 + arch/x86/lib/init_helpers.c |1 + arch/x86/lib/relocate.c |1 + 4 files changed, 3 insertions(+), 8 deletions(-) diff --git a/arch/x86/include/asm/u-boot-x86.h b/arch/x86/include/asm/u-boot-x86.h index 878a1ee..069cbbc 100644 --- a/arch/x86/include/asm/u-boot-x86.h +++ b/arch/x86/include/asm/u-boot-x86.h @@ -24,14 +24,6 @@ #ifndef _U_BOOT_I386_H_ #define _U_BOOT_I386_H_1 -/* Exports from the Linker Script */ -extern ulong __text_start; -extern ulong __data_end; -extern ulong __rel_dyn_start; -extern ulong __rel_dyn_end; -extern ulong __bss_start; -extern ulong __bss_end; - /* cpu/.../cpu.c */ int x86_cpu_init_r(void); int cpu_init_r(void); diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c index 5f0b62c..5931153 100644 --- a/arch/x86/lib/board.c +++ b/arch/x86/lib/board.c @@ -36,6 +36,7 @@ #include stdio_dev.h #include asm/u-boot-x86.h #include asm/relocate.h +#include asm/sections.h #include asm/init_helpers.h #include asm/init_wrappers.h diff --git a/arch/x86/lib/init_helpers.c b/arch/x86/lib/init_helpers.c index 9f4dee0..633b72b 100644 --- a/arch/x86/lib/init_helpers.c +++ b/arch/x86/lib/init_helpers.c @@ -31,6 +31,7 @@ #include status_led.h #include asm/processor.h #include asm/u-boot-x86.h +#include asm/sections.h #include asm/init_helpers.h diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c index 200baab..cd26636 100644 --- a/arch/x86/lib/relocate.c +++ b/arch/x86/lib/relocate.c @@ -35,6 +35,7 @@ #include malloc.h #include asm/u-boot-x86.h #include asm/relocate.h +#include asm/sections.h #include elf.h int copy_uboot_to_ram(void) -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 20/27] Add x86 fields to generic global_data
These fields are needed for x86.
Signed-off-by: Simon Glass s...@chromium.org
---
include/asm-generic/global_data.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index 6199926..fb976f9 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -44,6 +44,8 @@ typedef struct global_data {
bd_t*bd;
unsigned long flags;
unsigned long baudrate;
+ unsigned long cpu_clk;/* CPU clock in Hz! */
+ unsigned long bus_clk;
#if defined(CONFIG_LCD) || defined(CONFIG_VIDEO)
unsigned long fb_base;/* Base address of framebuffer mem */
#endif
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 27/27] tegra: Enable generic board for Seaboard.
Enable CONFIG_SYS_GENERIC_BOARD for Tegra 2 Seaboard. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Add CONFIG_SYS_GENERIC_BOARD to allow board to select generic board - Add PowerPC support - Change generic board to an opt-in system on a per-board basic - Rebase to master Changes in v3: - Rebase on top of x86/master (which has not yet been pulled to master) - Rebase to master Changes in v4: - Drop sc520_timer.c patch (warning already fixed by previous patch) - Rebase to master include/configs/seaboard.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h index 261f952..11d9e8d 100644 --- a/include/configs/seaboard.h +++ b/include/configs/seaboard.h @@ -27,6 +27,8 @@ #include asm/sizes.h #include tegra2-common.h +#define CONFIG_SYS_GENERIC_BOARD + /* High-level configuration options */ #define TEGRA2_SYSMEM mem=384M@0M nvmem=128M@384M mem=512M@512M #define V_PROMPT Tegra2 (SeaBoard) # -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 26/27] tegra: Mark board init files for ARMv4t
Since Tegra executes early code on an ARMv4T (but the rest on ARMv7) we must mark the new board init files for compilation with ARMv4t architecture. Signed-off-by: Simon Glass s...@chromium.org --- arch/arm/cpu/armv7/tegra2/config.mk |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/armv7/tegra2/config.mk b/arch/arm/cpu/armv7/tegra2/config.mk index 2303dba..4b43dde 100644 --- a/arch/arm/cpu/armv7/tegra2/config.mk +++ b/arch/arm/cpu/armv7/tegra2/config.mk @@ -28,6 +28,8 @@ # file with compatible flags ifdef CONFIG_TEGRA2 CFLAGS_arch/arm/lib/board.o += -march=armv4t +CFLAGS_common/board_f.o += -march=armv4t +CFLAGS_lib/initcall.o += -march=armv4t endif USE_PRIVATE_LIBGCC = yes -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 25/27] ppc: Enable generic board board
This enables generic board support so that ppc boards can define
CONFIG_SYS_GENERIC_BOARD.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/powerpc/config.mk |3 ---
arch/powerpc/include/asm/global_data.h |7 +++
arch/powerpc/include/asm/u-boot.h |7 +++
arch/powerpc/lib/Makefile |4 +++-
4 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk
index e6203dd..a307154 100644
--- a/arch/powerpc/config.mk
+++ b/arch/powerpc/config.mk
@@ -29,9 +29,6 @@ PLATFORM_RELFLAGS += -fpic -mrelocatable -ffunction-sections
-fdata-sections
PLATFORM_CPPFLAGS += -DCONFIG_PPC -D__powerpc__
PLATFORM_LDFLAGS += -n
-# Move to unified board system later
-CONFIG_SYS_LEGACY_BOARD := y
-
#
# When cross-compiling on NetBSD, we have to define __PPC__ or else we
# will pick up a va_list declaration that is incompatible with the
diff --git a/arch/powerpc/include/asm/global_data.h
b/arch/powerpc/include/asm/global_data.h
index 01f1d4a..3200443 100644
--- a/arch/powerpc/include/asm/global_data.h
+++ b/arch/powerpc/include/asm/global_data.h
@@ -27,6 +27,11 @@
#include config.h
#include asm/types.h
+#ifdef CONFIG_SYS_GENERIC_BOARD
+/* Use the generic board which requires a unified global_data */
+#include asm-generic/global_data.h
+#else
+
/*
* The following data structure is placed in some memory wich is
* available very early after boot (like DPRAM on MPC8xx/MPC82xx, or
@@ -198,6 +203,8 @@ typedef struct global_data {
#define GD_FLG_DISABLE_CONSOLE 0x00040 /* Disable console (in out)
*/
#define GD_FLG_ENV_READY 0x00080 /* Environment imported into hash table
*/
+#endif /* nCONFIG_SYS_GENERIC_BOARD */
+
#if 1
#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm (r2)
#else /* We could use plain global data, but the resulting code is bigger */
diff --git a/arch/powerpc/include/asm/u-boot.h
b/arch/powerpc/include/asm/u-boot.h
index b2fa2b5..7cc9af7 100644
--- a/arch/powerpc/include/asm/u-boot.h
+++ b/arch/powerpc/include/asm/u-boot.h
@@ -34,6 +34,11 @@
* include/asm-ppc/u-boot.h
*/
+#ifdef CONFIG_SYS_GENERIC_BOARD
+/* Use the generic board which requires a unified bd_info */
+#include asm-generic/u-boot.h
+#else
+
#ifndef __ASSEMBLY__
typedef struct bd_info {
@@ -144,6 +149,8 @@ typedef struct bd_info {
#endif /* __ASSEMBLY__ */
+#endif /* nCONFIG_SYS_GENERIC_BOARD */
+
/* For image.h:image_check_target_arch() */
#define IH_ARCH_DEFAULT IH_ARCH_PPC
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index cdd62a2..eef76b5 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -44,7 +44,9 @@ SOBJS-y += ticks.o
SOBJS-y+= reloc.o
COBJS-$(CONFIG_BAT_RW) += bat_rw.o
-COBJS-y+= board.o
+ifeq ($(CONFIG_SYS_GENERIC_BOARD),)
+COBJS-y += board.o
+endif
COBJS-y+= bootm.o
COBJS-$(CONFIG_BOOTCOUNT_LIMIT) += bootcount.o
COBJS-y+= cache.o
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 24/27] Adjust board_r.c for PowerPC
This adds ppc features to the generic post-relocation board init.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v4:
- Updates to sit on top of earlier patches
common/board_r.c | 462 +-
1 files changed, 459 insertions(+), 3 deletions(-)
diff --git a/common/board_r.c b/common/board_r.c
index f587c03..19d162b 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -27,24 +27,84 @@
*/
#include common.h
+/* TODO: can we just include all these headers whether needed or not? */
+#if defined(CONFIG_CMD_BEDBUG)
+#include bedbug/type.h
+#endif
#ifdef CONFIG_HAS_DATAFLASH
#include dataflash.h
#endif
#include environment.h
+#if defined(CONFIG_CMD_IDE)
+#include ide.h
+#endif
#include initcall.h
+#ifdef CONFIG_PS2KBD
+#include keyboard.h
+#endif
+#if defined(CONFIG_CMD_KGDB)
+#include kgdb.h
+#endif
#include logbuff.h
#include malloc.h
+#ifdef CONFIG_BITBANGMII
+#include miiphy.h
+#endif
#include mmc.h
#include nand.h
#include onenand_uboot.h
+#include scsi.h
#include serial.h
+#include spi.h
#include stdio_dev.h
+#include watchdog.h
+#ifdef CONFIG_ADDR_MAP
+#include asm/mmu.h
+#endif
#include asm/sections.h
DECLARE_GLOBAL_DATA_PTR;
ulong monitor_flash_len;
+/* TODO: Move this prototype to a header? */
+#ifdef CONFIG_SYS_UPDATE_FLASH_SIZE
+extern int update_flash_size(int flash_size);
+#endif
+
+int __board_flash_wp_on(void)
+{
+ /*
+* Most flashes can't be detected when write protection is enabled,
+* so provide a way to let U-Boot gracefully ignore write protected
+* devices.
+*/
+ return 0;
+}
+
+int board_flash_wp_on(void)
+ __attribute__ ((weak, alias(__board_flash_wp_on)));
+
+void __cpu_secondary_init_r(void)
+{
+}
+
+void cpu_secondary_init_r(void)
+ __attribute__ ((weak, alias(__cpu_secondary_init_r)));
+
+static int initr_secondary_cpu(void)
+{
+ /*
+* after non-volatile devices environment is setup and cpu code have
+* another round to deal with any initialization that might require
+* full access to the environment or loading of some image (firmware)
+* from a non-volatile device
+*/
+ /* TODO: maybe define this for all archs? */
+ cpu_secondary_init_r();
+
+ return 0;
+}
static int initr_reloc(void)
{
@@ -73,6 +133,25 @@ static int initr_reloc_global_data(void)
#else
monitor_flash_len = (ulong)__init_end - gd-dest_addr;
#endif
+#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
+ /*
+* The gd-cpu pointer is set to an address in flash before relocation.
+* We need to update it to point to the same CPU entry in RAM.
+* TODO: why not just add gd-reloc_ofs?
+*/
+ gd-cpu += gd-dest_addr - CONFIG_SYS_MONITOR_BASE;
+#endif
+#ifdef CONFIG_SYS_EXTRA_ENV_RELOC
+ /*
+* Some systems need to relocate the env_addr pointer early because the
+* location it points to will get invalidated before env_relocate is
+* called. One example is on systems that might use a L2 or L3 cache
+* in SRAM mode and initialize that cache from SRAM mode back to being
+* a cache in cpu_init_r.
+*/
+ gd-env_addr += gd-dest_addr - CONFIG_SYS_MONITOR_BASE;
+#endif
+ return 0;
}
#ifdef CONFIG_SERIAL_MULTI
@@ -83,6 +162,27 @@ static int initr_serial(void)
}
#endif
+#ifdef CONFIG_PPC
+static int initr_trap(void)
+{
+ /*
+* Setup trap handlers
+*/
+ trap_init(gd-dest_addr);
+
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_ADDR_MAP
+static int initr_addr_map(void)
+{
+ init_addr_map();
+
+ return 0;
+}
+#endif
+
#ifdef CONFIG_LOGBUFFER
unsigned long logbuffer_base(void)
{
@@ -104,6 +204,50 @@ static int initr_post_backlog(void)
}
#endif
+#ifdef CONFIG_SYS_DELAYED_ICACHE
+static int initr_icache_enable(void)
+{
+ return 0;
+}
+#endif
+
+#if defined(CONFIG_SYS_INIT_RAM_LOCK) defined(CONFIG_E500)
+static int initr_unlock_ram_in_cache(void)
+{
+ unlock_ram_in_cache(); /* it's time to unlock D-cache in e500 */
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_PCI
+static int initr_pci(void)
+{
+ pci_init();
+
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_WINBOND_83C553
+static int initr_w83c553f(void)
+{
+ /*
+* Initialise the ISA bridge
+*/
+ initialise_w83c553f();
+ return 0;
+}
+#endif
+
+static int initr_barrier(void)
+{
+#ifdef CONFIG_PPC
+ /* TODO: Can we not use dmb() macros for this? */
+ asm(sync ; isync);
+#endif
+ return 0;
+}
+
static int initr_malloc(void)
{
ulong malloc_start;
@@ -123,13 +267,26 @@ static int initr_announce(void)
#if !defined(CONFIG_SYS_NO_FLASH)
static int initr_flash(void)
{
- ulong flash_size;
+ ulong flash_size = 0;
+ bd_t *bd = gd-bd;
+ int ok;
puts(Flash: );
- flash_size = flash_init();
- if
[U-Boot] [PATCH v4 23/27] Adjust board_f for ppc
This adds ppc features to the generic pre-relocation board init.
This is a separate commit so that these features are clearly shown.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v4:
- Updates to sit on top of earlier patches
common/board_f.c | 373 +-
include/common.h | 16 +++
2 files changed, 386 insertions(+), 3 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c
index 2f14118..bcbc809 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -30,10 +30,31 @@
#include linux/compiler.h
#include version.h
#include environment.h
+#if defined(CONFIG_CMD_IDE)
+#include ide.h
+#endif
+#include i2c.h
#include initcall.h
#include logbuff.h
+
+/* TODO: Can we move these into arch/ headers? */
+#ifdef CONFIG_8xx
+#include mpc8xx.h
+#endif
+#ifdef CONFIG_5xx
+#include mpc5xx.h
+#endif
+#ifdef CONFIG_MPC5xxx
+#include mpc5xxx.h
+#endif
+
#include post.h
+#include spi.h
+#include watchdog.h
#include asm/io.h
+#ifdef CONFIG_MP
+#include asm/mp.h
+#endif
#include asm/sections.h
/*
@@ -98,6 +119,34 @@ void blue_led_off(void) __attribute__((weak,
alias(__blue_led_off)));
* Could the CONFIG_SPL_BUILD infection become a flag in gd?
*/
+#if defined(CONFIG_WATCHDOG)
+static int init_func_watchdog_init(void)
+{
+ puts( Watchdog enabled\n);
+ WATCHDOG_RESET();
+ return 0;
+}
+
+#define INIT_FUNC_WATCHDOG_INITinit_func_watchdog_init,
+
+int init_func_watchdog_reset(void)
+{
+ WATCHDOG_RESET();
+ return 0;
+}
+
+#else
+#define INIT_FUNC_WATCHDOG_INIT
+#endif /* CONFIG_WATCHDOG */
+
+void __board_add_ram_info(int use_default)
+{
+ /* please define platform specific board_add_ram_info() */
+}
+
+void board_add_ram_info(int)
+ __attribute__ ((weak, alias(__board_add_ram_info)));
+
static int init_baud_rate(void)
{
gd-baudrate = getenv_ulong(baudrate, 10, CONFIG_BAUDRATE);
@@ -135,6 +184,25 @@ static int announce_dram_init(void)
return 0;
}
+#ifdef CONFIG_PPC
+static int init_func_ram(void)
+{
+#ifdef CONFIG_BOARD_TYPES
+ int board_type = gd-board_type;
+#else
+ int board_type = 0; /* use dummy arg */
+#endif
+
+ gd-ram_size = initdram(board_type);
+
+ if (gd-ram_size 0)
+ return 0;
+
+ puts(*** failed ***\n);
+ return 1;
+}
+#endif
+
static int display_dram_config(void)
{
ulong size;
@@ -155,11 +223,24 @@ static int display_dram_config(void)
size = gd-ram_size;
#endif
- print_size(size, \n);
+ print_size(size, );
+ board_add_ram_info(0);
+ putc('\n');
return 0;
}
+ulong get_effective_memsize(void)
+{
+#ifndefCONFIG_VERY_BIG_RAM
+ return gd-ram_size;
+#else
+ /* limit stack to what we can reasonable map */
+ return ((gd-ram_size CONFIG_MAX_MEM_MAPPED) ?
+ CONFIG_MAX_MEM_MAPPED : gd-ram_size);
+#endif
+}
+
void __dram_init_banksize(void)
{
#if defined(CONFIG_NR_DRAM_BANKS) defined(CONFIG_SYS_SDRAM_BASE)
@@ -171,10 +252,37 @@ void __dram_init_banksize(void)
void dram_init_banksize(void)
__attribute__((weak, alias(__dram_init_banksize)));
+#if defined(CONFIG_HARD_I2C) || defined(CONFIG_SOFT_I2C)
+static int init_func_i2c(void)
+{
+ puts(I2C: );
+ i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+ puts(ready\n);
+ return 0;
+}
+#endif
+
+#if defined(CONFIG_HARD_SPI)
+static int init_func_spi(void)
+{
+ puts(SPI: );
+ spi_init();
+ puts(ready\n);
+ return 0;
+}
+#endif
+
static int setup_global_data_ptr(void)
{
- /* Pointer is writable since we allocated a register for it */
+ /*
+* Pointer is writable since we allocated a register for it.
+* Can we choose one of these two methods instead of offering both?
+*/
+#ifdef CONFIG_SYS_INIT_SP_ADDR
gd = (gd_t *) ((CONFIG_SYS_INIT_SP_ADDR) ~0x07);
+#else
+ gd = (gd_t *) (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET);
+#endif
/* compiler optimization barrier needed for GCC = 3.4 */
dmb();
@@ -182,6 +290,7 @@ static int setup_global_data_ptr(void)
return 0;
}
+__maybe_unused
static int zero_global_data(void)
{
memset((void *)gd, '\0', sizeof(gd_t));
@@ -194,7 +303,8 @@ static int setup_mon_len(void)
#ifdef CONFIG_SYS_SYM_OFFSETS
gd-mon_len = _bss_end_ofs;
#else
- gd-mon_len = (ulong)__bss_end - (ulong)__text_start;
+ /* TODO: use (ulong)__bss_end - (ulong)__text_start; ? */
+ gd-mon_len = (ulong)__bss_end__ - CONFIG_SYS_MONITOR_BASE;
#endif
return 0;
}
@@ -234,7 +344,22 @@ static int setup_reloc(void)
*/
gd-ram_size -= CONFIG_SYS_MEM_TOP_HIDE;
#endif
+#ifdef CONFIG_NR_DRAM_BANKS
gd-dest_addr = gd-bd-bi_dram[0].start + gd-bd-bi_dram[0].size;
+#else
+ gd-dest_addr = CONFIG_SYS_SDRAM_BASE + get_effective_memsize();
+#endif
+
[U-Boot] [PATCH v4 22/27] Add ppc fields to generic global data
This adds fields required by PowerPC to the global data.
Signed-off-by: Simon Glass s...@chromium.org
---
include/asm-generic/global_data.h | 124 +
1 files changed, 124 insertions(+), 0 deletions(-)
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index fb976f9..fb2891e 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -46,6 +46,114 @@ typedef struct global_data {
unsigned long baudrate;
unsigned long cpu_clk;/* CPU clock in Hz! */
unsigned long bus_clk;
+#if defined(CONFIG_8xx)
+ unsigned long brg_clk;
+#endif
+#if defined(CONFIG_CPM2)
+ /* There are many clocks on the MPC8260 - see page 9-5 */
+ unsigned long vco_out;
+ unsigned long cpm_clk;
+ unsigned long scc_clk;
+ unsigned long brg_clk;
+#ifdef CONFIG_PCI
+ unsigned long pci_clk;
+#endif
+#endif
+ unsigned long mem_clk;
+#if defined(CONFIG_MPC83xx)
+ /* There are other clocks in the MPC83XX */
+ u32 csb_clk;
+#if defined(CONFIG_MPC8308) || defined(CONFIG_MPC831x) || \
+ defined(CONFIG_MPC834x) || defined(CONFIG_MPC837x)
+ u32 tsec1_clk;
+ u32 tsec2_clk;
+ u32 usbdr_clk;
+#endif
+#if defined(CONFIG_MPC834x)
+ u32 usbmph_clk;
+#endif /* CONFIG_MPC834x */
+#if defined(CONFIG_MPC8315)
+ u32 tdm_clk;
+#endif
+ u32 core_clk;
+ u32 enc_clk;
+ u32 lbiu_clk;
+ u32 lclk_clk;
+ u32 pci_clk;
+#if defined(CONFIG_MPC8308) || defined(CONFIG_MPC831x) || \
+ defined(CONFIG_MPC837x)
+ u32 pciexp1_clk;
+ u32 pciexp2_clk;
+#endif
+#if defined(CONFIG_MPC837x) || defined(CONFIG_MPC8315)
+ u32 sata_clk;
+#endif
+#if defined(CONFIG_MPC8360)
+ u32 mem_sec_clk;
+#endif /* CONFIG_MPC8360 */
+#endif
+#if defined(CONFIG_FSL_ESDHC)
+ u32 sdhc_clk;
+#endif
+#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
+ u32 lbc_clk;
+ void *cpu;
+#endif /* CONFIG_MPC85xx || CONFIG_MPC86xx */
+#if defined(CONFIG_MPC83xx) || defined(CONFIG_MPC85xx) \
+ || defined(CONFIG_MPC86xx)
+ u32 i2c1_clk;
+ u32 i2c2_clk;
+#endif
+#if defined(CONFIG_QE)
+ u32 qe_clk;
+ u32 brg_clk;
+ uint mp_alloc_base;
+ uint mp_alloc_top;
+#endif /* CONFIG_QE */
+#if defined(CONFIG_FSL_LAW)
+ u32 used_laws;
+#endif
+#if defined(CONFIG_E500)
+ u32 used_tlb_cams[(CONFIG_SYS_NUM_TLBCAMS+31)/32];
+#endif
+#if defined(CONFIG_MPC5xxx)
+ unsigned long ipb_clk;
+ unsigned long pci_clk;
+#endif
+#if defined(CONFIG_MPC512X)
+ u32 ips_clk;
+ u32 csb_clk;
+ u32 pci_clk;
+#endif /* CONFIG_MPC512X */
+#if defined(CONFIG_MPC8220)
+ unsigned long bExtUart;
+ unsigned long inp_clk;
+ unsigned long pci_clk;
+ unsigned long vco_clk;
+ unsigned long pev_clk;
+ unsigned long flb_clk;
+#endif
+ unsigned long reset_status; /* reset status register at boot */
+#if defined(CONFIG_MPC83xx)
+ unsigned long arbiter_event_attributes;
+ unsigned long arbiter_event_address;
+#endif
+#if defined(CONFIG_SYS_ALLOC_DPRAM) || defined(CONFIG_CPM2)
+ unsigned intdp_alloc_base;
+ unsigned intdp_alloc_top;
+#endif
+#if defined(CONFIG_4xx)
+ u32 uart_clk;
+#endif /* CONFIG_4xx */
+#if defined(CONFIG_SYS_GT_6426x)
+ unsigned intmirror_hack[16];
+#endif
+#if defined(CONFIG_A3000) || \
+ defined(CONFIG_HIDDEN_DRAGON) || \
+ defined(CONFIG_MUSENKI) || \
+ defined(CONFIG_SANDPOINT)
+ void *console_addr;
+#endif
#if defined(CONFIG_LCD) || defined(CONFIG_VIDEO)
unsigned long fb_base;/* Base address of framebuffer mem */
#endif
@@ -54,6 +162,22 @@ typedef struct global_data {
unsigned long post_log_res; /* success of POST test */
unsigned long post_init_f_time; /* When post_init_f started */
#endif
+#ifdef CONFIG_BOARD_TYPES
+ unsigned long board_type;
+#endif
+#ifdef CONFIG_MODEM_SUPPORT
+ unsigned long do_mdm_init;
+ unsigned long be_quiet;
+#endif
+#if defined(CONFIG_LWMON) || defined(CONFIG_LWMON5)
+ unsigned long kbd_status;
+#endif
+#ifdef CONFIG_SYS_FPGA_COUNT
+ unsigned fpga_state[CONFIG_SYS_FPGA_COUNT];
+#endif
+#if defined(CONFIG_WD_MAX_RATE)
+ unsigned long long wdt_last;/* trace watch-dog triggering rate */
+#endif
unsigned long have_console; /* serial_init() was called */
#ifdef CONFIG_PRE_CONSOLE_BUFFER
unsigned long precon_buf_idx; /* Pre-Console buffer index */
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 13/27] Define CONFIG_SYS_LEGACY_BOARD everywhere
We are introducing a new unified board setup and we want this to be the default. So we need to opt all architectures out first. Signed-off-by: Simon Glass s...@chromium.org --- README| 11 +++ arch/arm/config.mk|3 +++ arch/avr32/config.mk |3 +++ arch/blackfin/config.mk |3 +++ arch/m68k/config.mk |3 +++ arch/microblaze/config.mk |3 +++ arch/mips/config.mk |3 +++ arch/nds32/config.mk |3 +++ arch/nios2/config.mk |3 +++ arch/powerpc/config.mk|3 +++ arch/sandbox/config.mk|3 +++ arch/sh/config.mk |3 +++ arch/sparc/config.mk |3 +++ arch/x86/config.mk|3 +++ config.mk |8 15 files changed, 58 insertions(+), 0 deletions(-) diff --git a/README b/README index 8964672..f471627 100644 --- a/README +++ b/README @@ -2770,6 +2770,17 @@ Configuration Settings: cases. This setting can be used to tune behaviour; see lib/hashtable.c for details. +- CONFIG_SYS_GENERIC_BOARD + This selects the architecture-generic board system instead of the + architecture-specific board files. It is intended to move boards + to this new framework over time. Defining this will disable the + arch/foo/lib/board.c file and use common/board_f.c and + common/board_r.c instead. To use this option your architecture + must support it (i.e. must NOT define CONFIG_SYS_LEGACY_BOARD in + its config.mk file). If you find problems enabling this option on + your board please report the problem and send patches! + + The following definitions that deal with the placement and management of environment data (variable area); in general, we support the following configurations: diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 45f9dca..31e9ef9 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -33,6 +33,9 @@ endif PLATFORM_CPPFLAGS += -DCONFIG_ARM -D__ARM__ +# Move to unified board system later +CONFIG_SYS_LEGACY_BOARD := y + # Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb: PF_CPPFLAGS_ARM := $(call cc-option,-marm,) diff --git a/arch/avr32/config.mk b/arch/avr32/config.mk index d8e7ebb..6eb00f6 100644 --- a/arch/avr32/config.mk +++ b/arch/avr32/config.mk @@ -31,3 +31,6 @@ PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections LDFLAGS_u-boot = --gc-sections --relax LDSCRIPT = $(SRCTREE)/$(CPUDIR)/u-boot.lds + +# Move to unified board system later +CONFIG_SYS_LEGACY_BOARD := y diff --git a/arch/blackfin/config.mk b/arch/blackfin/config.mk index 3595aa2..972afb1 100644 --- a/arch/blackfin/config.mk +++ b/arch/blackfin/config.mk @@ -37,6 +37,9 @@ CONFIG_BFIN_BOOT_MODE := $(strip $(subst ,,$(CONFIG_BFIN_BOOT_MODE))) PLATFORM_RELFLAGS += -ffixed-P3 -fomit-frame-pointer -mno-fdpic PLATFORM_CPPFLAGS += -DCONFIG_BLACKFIN +# Move to unified board system later +CONFIG_SYS_LEGACY_BOARD := y + LDFLAGS_FINAL += --gc-sections LDFLAGS += -m elf32bfin PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections diff --git a/arch/m68k/config.mk b/arch/m68k/config.mk index 11ba334..11ad9a5 100644 --- a/arch/m68k/config.mk +++ b/arch/m68k/config.mk @@ -29,3 +29,6 @@ PLATFORM_CPPFLAGS += -DCONFIG_M68K -D__M68K__ PLATFORM_LDFLAGS += -n PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections LDFLAGS_FINAL += --gc-sections + +# Move to unified board system later +CONFIG_SYS_LEGACY_BOARD := y diff --git a/arch/microblaze/config.mk b/arch/microblaze/config.mk index abea70b..119a596 100644 --- a/arch/microblaze/config.mk +++ b/arch/microblaze/config.mk @@ -29,3 +29,6 @@ CROSS_COMPILE ?= mb- CONFIG_STANDALONE_LOAD_ADDR ?= 0x80F0 PLATFORM_CPPFLAGS += -ffixed-r31 -D__microblaze__ + +# Move to unified board system later +CONFIG_SYS_LEGACY_BOARD := y diff --git a/arch/mips/config.mk b/arch/mips/config.mk index 6ab8acd..8f5305e 100644 --- a/arch/mips/config.mk +++ b/arch/mips/config.mk @@ -27,6 +27,9 @@ CONFIG_STANDALONE_LOAD_ADDR ?= 0x8020 -T mips.lds PLATFORM_CPPFLAGS += -DCONFIG_MIPS -D__MIPS__ +# Move to unified board system later +CONFIG_SYS_LEGACY_BOARD := y + # # From Linux arch/mips/Makefile # diff --git a/arch/nds32/config.mk b/arch/nds32/config.mk index c589829..f989053 100644 --- a/arch/nds32/config.mk +++ b/arch/nds32/config.mk @@ -33,3 +33,6 @@ PLATFORM_RELFLAGS += -gdwarf-2 PLATFORM_CPPFLAGS += -DCONFIG_NDS32 -D__nds32__ -G0 -ffixed-10 -fpie LDFLAGS_u-boot = --gc-sections --relax + +# Move to unified board system later +CONFIG_SYS_LEGACY_BOARD := y diff --git a/arch/nios2/config.mk b/arch/nios2/config.mk index 7b03ed8..0172f70 100644 --- a/arch/nios2/config.mk +++ b/arch/nios2/config.mk @@ -31,3 +31,6 @@ PLATFORM_CPPFLAGS += -G0 LDFLAGS_FINAL += --gc-sections PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections + +# Move to unified board system
Re: [U-Boot] [PATCH v4 04/27] x86: Remove dead code in eNET
Hi Simon, On Thu, Mar 15, 2012 at 1:16 PM, Simon Glass s...@chromium.org wrote: This avoids a compiler warning about unused variables. Signed-off-by: Simon Glass s...@chromium.org --- board/eNET/eNET.c | 5 - 1 files changed, 0 insertions(+), 5 deletions(-) Acked-By: Graeme Russ graeme.r...@gmail.com I'll apply this to x86/master directly and send a pull request Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 04/27] x86: Remove dead code in eNET
On Wed, Mar 14, 2012 at 7:27 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, On Thu, Mar 15, 2012 at 1:16 PM, Simon Glass s...@chromium.org wrote: This avoids a compiler warning about unused variables. Signed-off-by: Simon Glass s...@chromium.org --- board/eNET/eNET.c | 5 - 1 files changed, 0 insertions(+), 5 deletions(-) Acked-By: Graeme Russ graeme.r...@gmail.com I'll apply this to x86/master directly and send a pull request Thanks Graeme. Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 11/27] x86: Change stub example to use asm-generic/sections.h
Hi Simon,
On Thu, Mar 15, 2012 at 1:16 PM, Simon Glass s...@chromium.org wrote:
We can use the declarations of __bss_start and _end from this header
instead of declaring them locally.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v4:
- Use asm/sections.h instead of asm-generic/sections.h
examples/standalone/stubs.c | 7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/examples/standalone/stubs.c b/examples/standalone/stubs.c
index 15e9afc..8fb1765 100644
--- a/examples/standalone/stubs.c
+++ b/examples/standalone/stubs.c
@@ -217,16 +217,15 @@ void __attribute__((unused)) dummy(void)
#include _exports.h
}
-extern unsigned long __bss_start, _end;
+#include asm/sections.h
void app_startup(char * const *argv)
{
- unsigned char * cp = (unsigned char *) __bss_start;
+ char *cp = __bss_start;
/* Zero out BSS */
- while (cp (unsigned char *)_end) {
+ while (cp _end)
*cp++ = 0;
- }
#if defined(CONFIG_X86)
/* x86 does not have a dedicated register for passing global_data */
--
1.7.7.3
Does not look like x86 to me - looks like common code
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 07/27] Introduce generic global_data
Hi Simon, On Thu, Mar 15, 2012 at 1:16 PM, Simon Glass s...@chromium.org wrote: We want to unify the global_data structure. Most fields are common across architectures, but there are a fair number of SOC-specific additions. It isn't clear how best to deal with these, but for now we just use #ifdef. Checkpatch warnings here might be unavoidable: warning: include/asm-generic/global_data.h,43: do not add new typedefs warning: include/asm-generic/global_data.h,117: Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt warning: include/asm-generic/global_data.h,121: storage class should be at the beginning of the declaration IMHO global data does not need to be (and should not be) typedef'd Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 07/27] Introduce generic global_data
Hi Simon, On Thu, Mar 15, 2012 at 1:16 PM, Simon Glass s...@chromium.org wrote: We want to unify the global_data structure. Most fields are common across architectures, but there are a fair number of SOC-specific additions. It isn't clear how best to deal with these, but for now we just use #ifdef. Checkpatch warnings here might be unavoidable: warning: include/asm-generic/global_data.h,43: do not add new typedefs warning: include/asm-generic/global_data.h,117: Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt warning: include/asm-generic/global_data.h,121: storage class should be at the beginning of the declaration Signed-off-by: Simon Glass s...@chromium.org --- +#ifdef CONFIG_AT91FAMILY + /* static data needed by at91's clock.c */ + unsigned long cpu_clk_rate_hz; + unsigned long main_clk_rate_hz; + unsigned long mck_rate_hz; + unsigned long plla_rate_hz; + unsigned long pllb_rate_hz; + unsigned long at91_pllb_usb_init; +#endif +#ifdef CONFIG_ARM + /* static data needed by most of timer.c on ARM platforms */ + unsigned long timer_rate_hz; + unsigned long tbl; + unsigned long tbu; + unsigned long long timer_reset_value; + unsigned long lastinc; +#endif IMHO, global data should contain only globally common members and an arch- specific struct and ditch (most of) the #ifdefs Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 20/27] Add x86 fields to generic global_data
Hi Simon,
On Thu, Mar 15, 2012 at 1:16 PM, Simon Glass s...@chromium.org wrote:
These fields are needed for x86.
Signed-off-by: Simon Glass s...@chromium.org
---
include/asm-generic/global_data.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index 6199926..fb976f9 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -44,6 +44,8 @@ typedef struct global_data {
bd_t *bd;
unsigned long flags;
unsigned long baudrate;
+ unsigned long cpu_clk; /* CPU clock in Hz! */
+ unsigned long bus_clk;
Refer to my other comment, but this impacts all arches for no good reason
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 11/27] x86: Change stub example to use asm-generic/sections.h
Hi Graeme,
On Wed, Mar 14, 2012 at 7:29 PM, Graeme Russ graeme.r...@gmail.com wrote:
Hi Simon,
On Thu, Mar 15, 2012 at 1:16 PM, Simon Glass s...@chromium.org wrote:
We can use the declarations of __bss_start and _end from this header
instead of declaring them locally.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v4:
- Use asm/sections.h instead of asm-generic/sections.h
examples/standalone/stubs.c | 7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/examples/standalone/stubs.c b/examples/standalone/stubs.c
index 15e9afc..8fb1765 100644
--- a/examples/standalone/stubs.c
+++ b/examples/standalone/stubs.c
@@ -217,16 +217,15 @@ void __attribute__((unused)) dummy(void)
#include _exports.h
}
-extern unsigned long __bss_start, _end;
+#include asm/sections.h
void app_startup(char * const *argv)
{
- unsigned char * cp = (unsigned char *) __bss_start;
+ char *cp = __bss_start;
/* Zero out BSS */
- while (cp (unsigned char *)_end) {
+ while (cp _end)
*cp++ = 0;
- }
#if defined(CONFIG_X86)
/* x86 does not have a dedicated register for passing global_data */
--
1.7.7.3
Does not look like x86 to me - looks like common code
Yes that tag is wrong. Should I re-issue the patch?
Regards,
Simon
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 11/27] x86: Change stub example to use asm-generic/sections.h
Hi Simon, On Thu, Mar 15, 2012 at 1:44 PM, Simon Glass s...@chromium.org wrote: Hi Graeme, On Wed, Mar 14, 2012 at 7:29 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, Does not look like x86 to me - looks like common code Yes that tag is wrong. Should I re-issue the patch? Yes, but wait until you rev the whole series Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 07/27] Introduce generic global_data
Hi Graeme, On Wed, Mar 14, 2012 at 7:35 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, On Thu, Mar 15, 2012 at 1:16 PM, Simon Glass s...@chromium.org wrote: We want to unify the global_data structure. Most fields are common across architectures, but there are a fair number of SOC-specific additions. It isn't clear how best to deal with these, but for now we just use #ifdef. Checkpatch warnings here might be unavoidable: warning: include/asm-generic/global_data.h,43: do not add new typedefs warning: include/asm-generic/global_data.h,117: Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt warning: include/asm-generic/global_data.h,121: storage class should be at the beginning of the declaration Signed-off-by: Simon Glass s...@chromium.org --- +#ifdef CONFIG_AT91FAMILY + /* static data needed by at91's clock.c */ + unsigned long cpu_clk_rate_hz; + unsigned long main_clk_rate_hz; + unsigned long mck_rate_hz; + unsigned long plla_rate_hz; + unsigned long pllb_rate_hz; + unsigned long at91_pllb_usb_init; +#endif +#ifdef CONFIG_ARM + /* static data needed by most of timer.c on ARM platforms */ + unsigned long timer_rate_hz; + unsigned long tbl; + unsigned long tbu; + unsigned long long timer_reset_value; + unsigned long lastinc; +#endif IMHO, global data should contain only globally common members and an arch- specific struct and ditch (most of) the #ifdefs My thinking here was to try to bring everything into a single file. It then should be clearer when things are common between different architectures. Patches to the generic file can be made without also having to patch the non-generic files, etc. A fair number of the #ifdefs are not needed, or are there because some archs don't implement all the features of U-Boot. You have an example right there: cpu_clk_rate_hz is similar to cpu_clk and core_clk. That said it is a bit of a daunting task to amalgamate them. Also there is the purely practical consideration that if we continue to have an asm/global_data.h then we end up with two global datas. One is for CONFIG_SYS_GENERIC_BOARD and contains just the non-common fields. The other is for non-CONFIG_SYS_GENERIC_BOARD and contains all fields. Ick. So what do you think? Regards, Simon Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 20/27] Add x86 fields to generic global_data
Hi Graeme,
On Wed, Mar 14, 2012 at 7:36 PM, Graeme Russ graeme.r...@gmail.com wrote:
Hi Simon,
On Thu, Mar 15, 2012 at 1:16 PM, Simon Glass s...@chromium.org wrote:
These fields are needed for x86.
Signed-off-by: Simon Glass s...@chromium.org
---
include/asm-generic/global_data.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index 6199926..fb976f9 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -44,6 +44,8 @@ typedef struct global_data {
bd_t *bd;
unsigned long flags;
unsigned long baudrate;
+ unsigned long cpu_clk; /* CPU clock in Hz! */
+ unsigned long bus_clk;
Refer to my other comment, but this impacts all arches for no good reason
See my other reply. Let me just add that these values would be pretty
useful to most archs.
Regards,
Simon
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 07/27] Introduce generic global_data
Hi Simon, On Thu, Mar 15, 2012 at 1:50 PM, Simon Glass s...@chromium.org wrote: Hi Graeme, On Wed, Mar 14, 2012 at 7:35 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, [snip] IMHO, global data should contain only globally common members and an arch- specific struct and ditch (most of) the #ifdefs My thinking here was to try to bring everything into a single file. It then should be clearer when things are common between different architectures. Patches to the generic file can be made without also having to patch the non-generic files, etc. A fair number of the #ifdefs are not needed, or are there because some archs don't implement all the features of U-Boot. You have an example right there: cpu_clk_rate_hz is similar to cpu_clk and core_clk. That said it is a bit of a daunting task to amalgamate them. Also there is the purely practical consideration that if we continue to have an asm/global_data.h then we end up with two global datas. One is for CONFIG_SYS_GENERIC_BOARD and contains just the non-common fields. The other is for non-CONFIG_SYS_GENERIC_BOARD and contains all fields. Ick. So what do you think? Do you really need to unify global data to achieve what the title of the patch series suggests (i.e. to unify the init processing loop)? Maybe you could leave global data as is (or slightly tweak the odd arch) and leave the resolution of just how bad global data is becoming for another day I only say this because this is turning into let's do a dirty hack now to partially fix it and leave the rest for later (it'll get done, really, honestly, I promise) ;) There will always be arch specific global data members - I see a few options: - Move them into bd - Move them into an arch_global_data struct inside gd - Move them into an arch_global_data struct totally seperate from gd - Question how many are really required to be in gd (remember, gd is only there to cart around writable global variable before .bss and .data are available after relocation) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/28] arm: Use sections header to obtain link symbols
Hi Mike, On Sat, Mar 10, 2012 at 5:54 PM, Mike Frysinger vap...@gentoo.org wrote: On Thursday 08 March 2012 01:39:53 Simon Glass wrote: On Tue, Mar 6, 2012 at 8:17 AM, Mike Frysinger wrote: On Tuesday 06 March 2012 01:24:21 Simon Glass wrote: On Mon, Mar 5, 2012 at 9:03 PM, Mike Frysinger wrote: On Thursday 16 February 2012 09:48:58 Simon Glass wrote: --- a/board/cm4008/flash.c +++ b/board/cm4008/flash.c #include common.h +#include asm-generic/sections.h arches should provide asm/sections.h, and those are the only headers that should know about asm-generic/sections.h Similar to my previous comment, but why does each arch have to have subtly-different section symbol names? From what I have seen so far there can be unified also. Blackfin has linker symbols that don't belong in any other port. this is also how the kernel does it, and i don't see value in diverging here. OK, so I think I should update the sections.h patch to add asm/sections.h for every arch, initially just with an include to asm-generic/sections.h in each one? Does that sound right? yep. unless we want to get really ambitious and extend the generated support like the kernel has now -- it automatically generates sub headers for asm/ redirects to asm-generic/ if the arch hasn't provided one. I am ambitious enough already :-) I have added these files into the v4 version of the patch. Regards, Simon -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] EXYNOS: Rename exynos5_tzpc structure to s5p_tzpc
Dear Minkyu,
On 15 March 2012 06:53, Minkyu Kang proms...@gmail.com wrote:
Dear Chander Kashyap,
On 14 March 2012 22:38, Chander Kashyap chander.kash...@linaro.org wrote:
Hi Kyungmin Park,
On 14 March 2012 19:02, Kyungmin Park kmp...@infradead.org wrote:
Hi Chander,
On Wed, Mar 14, 2012 at 10:14 PM, Chander Kashyap
chander.kash...@linaro.org wrote:
TZPC IP is common across S5P and Exynos based SoC'c. Renaming exynos5_tzpc
in arch/arm/include/asm/arch-exynos/tzpc.h to s5p_tzpc will allow generic
usase of tzpc.
Also modify board/samsung/smdk5250/tzpc_init.c to use s5p_tzpc.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
arch/arm/include/asm/arch-exynos/tzpc.h | 2 +-
board/samsung/smdk5250/tzpc_init.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/tzpc.h
b/arch/arm/include/asm/arch-exynos/tzpc.h
index 2c9a07b..63736ae 100644
--- a/arch/arm/include/asm/arch-exynos/tzpc.h
+++ b/arch/arm/include/asm/arch-exynos/tzpc.h
@@ -22,7 +22,7 @@
#define __TZPC_H_
#ifndef __ASSEMBLY__
-struct exynos5_tzpc {
+struct s5p_tzpc {
I think 'exynos' is preferable. Even though each SOC has different
I tried to carry forward old conventions as in case of watchdog. I
will change it to exynos.
I agreed with Kyungmin.
From now, let's called exynos for common name including s5pc1xx and
s5pc2xx and exynos4 and exynos5.. etc.
Thanks for the inputs. Let us follow the convention. I will resubmit the patch.
number of tzpc. It can be covered one exynos_tzpc. or we can define
it for each SoC.
One structure is enough as fields are same.
Thanks
Minkyu Kang.
--
from. prom.
www.promsoft.net
--
with warm regards,
Chander Kashyap
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] EXYNOS: Rename exynos5_tzpc structure to exynos_tzpc
TZPC IP is common across Exynos based SoC'c. Renaming exynos5_tzpc
in arch/arm/include/asm/arch-exynos/tzpc.h to exynos_tzpc will allow generic
usase of tzpc.
Also modify board/samsung/smdk5250/tzpc_init.c to use exynos_tzpc.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
Changes in V2:
- Renaming is changed from s5p_ctzpc to exynos_tzpc as per
Kyungmin's Comments.
arch/arm/include/asm/arch-exynos/tzpc.h |2 +-
board/samsung/smdk5250/tzpc_init.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/tzpc.h
b/arch/arm/include/asm/arch-exynos/tzpc.h
index 2c9a07b..c5eb4b1 100644
--- a/arch/arm/include/asm/arch-exynos/tzpc.h
+++ b/arch/arm/include/asm/arch-exynos/tzpc.h
@@ -22,7 +22,7 @@
#define __TZPC_H_
#ifndef __ASSEMBLY__
-struct exynos5_tzpc {
+struct exynos_tzpc {
unsigned int r0size;
char res1[0x7FC];
unsigned int decprot0stat;
diff --git a/board/samsung/smdk5250/tzpc_init.c
b/board/samsung/smdk5250/tzpc_init.c
index c2ccef3..f39bd55 100644
--- a/board/samsung/smdk5250/tzpc_init.c
+++ b/board/samsung/smdk5250/tzpc_init.c
@@ -28,7 +28,7 @@
/* Setting TZPC[TrustZone Protection Controller] */
void tzpc_init(void)
{
- struct exynos5_tzpc *tzpc;
+ struct exynos_tzpc *tzpc;
unsigned int addr;
for (addr = TZPC0_BASE; addr = TZPC9_BASE; addr += TZPC_BASE_OFFSET) {
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 07/27] Introduce generic global_data
Hi Graeme, On Wed, Mar 14, 2012 at 8:02 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, On Thu, Mar 15, 2012 at 1:50 PM, Simon Glass s...@chromium.org wrote: Hi Graeme, On Wed, Mar 14, 2012 at 7:35 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, [snip] IMHO, global data should contain only globally common members and an arch- specific struct and ditch (most of) the #ifdefs My thinking here was to try to bring everything into a single file. It then should be clearer when things are common between different architectures. Patches to the generic file can be made without also having to patch the non-generic files, etc. A fair number of the #ifdefs are not needed, or are there because some archs don't implement all the features of U-Boot. You have an example right there: cpu_clk_rate_hz is similar to cpu_clk and core_clk. That said it is a bit of a daunting task to amalgamate them. Also there is the purely practical consideration that if we continue to have an asm/global_data.h then we end up with two global datas. One is for CONFIG_SYS_GENERIC_BOARD and contains just the non-common fields. The other is for non-CONFIG_SYS_GENERIC_BOARD and contains all fields. Ick. So what do you think? Do you really need to unify global data to achieve what the title of the patch series suggests (i.e. to unify the init processing loop)? Maybe you could leave global data as is (or slightly tweak the odd arch) and leave the resolution of just how bad global data is becoming for another day It's not that easy, because in board_f.c and board_r.c and other files there are certain fields required. It doesn't make a huge amount of sense to have generic code which accesses a different global structure depending on what architecture it is built for. Then there are fields are are only used when certain options are defined. Ick. If I am going to pull this off I need a bit of flexibility. I've looked into this quite a bit and mapped a path through this which I think will work. It requires doing things in stages, or it will never happen. I only say this because this is turning into let's do a dirty hack now to partially fix it and leave the rest for later (it'll get done, really, honestly, I promise) ;) It was always like that. Although I wouldn't characterise it as a dirty hack. If there was a requirement to do all of this in one big bang then I wouldn't have even started. It is just too hard :-( There will always be arch specific global data members - I see a few options: - Move them into bd I recall talk of getting rid of this (Mike?) - Move them into an arch_global_data struct inside gd This was Mike's idea. It is probably the easiest thing to do. - Move them into an arch_global_data struct totally seperate from gd I sort-of like this except it would slow down access and maybe increase code size. Then again perhaps that's a good thing if it provides an incentive to reduce the number of arch-specific fields. - Question how many are really required to be in gd (remember, gd is only there to cart around writable global variable before .bss and .data are available after relocation) Well yes, I feel there are far more at present than are needed. Having them all there in the open feels like a nice way to draw attention to the mess. Regards, Simon Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Don't use printf() in SPL builds
Hi Sughosh,
On Sat, Mar 10, 2012 at 12:33 AM, Sughosh Ganu urwithsugh...@gmail.com wrote:
hi Simon,
On Sat Mar 03, 2012 at 12:33:15PM -0800, Simon Glass wrote:
raise() likes to call printf() if it is available, but in SPL builds it
either is not available, or adds a large chunk to the resulting image
size.
So don't call it even if it is available.
This change reduces SPL size from 10KB to 6.3KB on hawkboard, for
example, using generic relocation.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/arm/lib/eabi_compat.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/lib/eabi_compat.c b/arch/arm/lib/eabi_compat.c
index 2028dbd..44eebe0 100644
--- a/arch/arm/lib/eabi_compat.c
+++ b/arch/arm/lib/eabi_compat.c
@@ -13,7 +13,8 @@
int raise (int signum)
{
-#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
+ /* Even if printf() is available, it's large. Punt it for SPL builds */
+#if !defined(CONFIG_SPL_BUILD)
printf(raise: Signal # %d caught\n, signum);
#endif
I tested with this change on hawkboard, and after applying this
change, the spl size increase is 412 bytes against the 4k increase
that we get with libcommon changes introduced. So this patch works
fine.
OK good.
Can you please check if libcommon support is needed for the
cam_enc_4xx board -- your relocation patch series did not add
CONFIG_SPL_LIBCOMMON_SUPPORT to this board. This will affect my
patch to initialise gd and bd objects for hawkboard. Please let me
know, and i will spin a patch accordingly.
Yes I think this board needs both of these:
#define CONFIG_SPL_LIBCOMMON_SUPPORT
#define CONFIG_SPL_LIBGENERIC_SUPPORT
Regards,
Simon
-sughosh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] doc: Add documentation for mpc85xx debugger support
Hi Scott, On Thursday 15 March 2012 01:00 AM, Scott Wood wrote: On 03/14/2012 04:35 AM, Prabhakar Kushwaha wrote: Hi Wolfgang, On Tuesday 13 March 2012 12:44 PM, Prabhakar Kushwaha wrote: Hi Wolfgang, On Wednesday 07 March 2012 06:00 PM, Wolfgang Denk wrote: Dear Prabhakar Kushwaha, In message4f572159.9020...@freescale.com you wrote: Also, what's the V1_V2 ? Are there also other systems (say, e500 v3 cores), and are this not affected? We already have CONFIG_E500 and CONFIG_E500MC so CONFIG_E500_V1_V2 appears to belong to this group, but if I understand your intentions it does something completely unrelated. V1_V2 is used because it applied to e500v1 and e500v2 not e500mc processor. So CONFIG_E500MC cant be used. Also I cant use CONFIG_E500 as it refer the entire e500 family which includes e500mc. Hm... I am not sure if CONFIG_E500 was supposed to include CONFIG_E500MC; it's nowhere documented. Let's assume it is. What happens if you enable this code on a E500MC system? Debug restrictions are not valid for e500mc system. At first sight it should not hurt e500mc execution (other than some seemingly unnecessary steps). However i will check this point. We tried by enabling CONFIG_E500_V2_V2 for E500MC with u-boot patches. It boots fine and debugging can be done. Be sure to mention in comments that the hack is only really needed for v1/v2. I will clearly mention in doc So, we can use CONFIG_E500 #define instead of CONFIG_E500_V2_V2 i.e. debugging will always be enabled. One have to define CONFIG_DEBUGGER_TEMP_TLB for debugging in AS1 ( Part of patch powerpc/85xx:Update NOR code base to support debugger ) CONFIG_SYS_PPC_E500_DEBUG_TLB OK CONFIG_DEBUGGER_TEMP_TLB can also be used for placing code which can only be required during debugging (specially code of temporary TLB creation) Is there something specific you had in mind, other than the use that is already present in this patchset? There is no specific use case in my mind other than the patch-set. Actually, Wolfgang is having concern about code size increase because of temporary TLB creation in start.S for debugging. That's why i am planning to use this #define for temporary TLB creation --Prabhakar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3 v3] sandbox: SPI emulation bus
Hi Mike,
On Mon, Mar 12, 2012 at 8:22 AM, Mike Frysinger vap...@gentoo.org wrote:
This adds a SPI framework for people to hook up simulated SPI clients.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
v3
- rearchitected on top of state/getopt support
arch/sandbox/include/asm/config.h | 8 ++
arch/sandbox/include/asm/spi.h | 58
arch/sandbox/include/asm/state.h | 1 +
drivers/spi/Makefile | 1 +
drivers/spi/sandbox_spi.c | 186
+
5 files changed, 254 insertions(+), 0 deletions(-)
create mode 100644 arch/sandbox/include/asm/spi.h
create mode 100644 drivers/spi/sandbox_spi.c
diff --git a/arch/sandbox/include/asm/config.h
b/arch/sandbox/include/asm/config.h
index 2ef0564..a9590bc 100644
--- a/arch/sandbox/include/asm/config.h
+++ b/arch/sandbox/include/asm/config.h
@@ -23,4 +23,12 @@
#define CONFIG_SANDBOX_ARCH
+/* Used by drivers/spi/sandbox_spi.c */
+#ifndef CONFIG_SANDBOX_SPI_MAX_BUS
+#define CONFIG_SANDBOX_SPI_MAX_BUS 1
+#endif
+#ifndef CONFIG_SANDBOX_SPI_MAX_CS
+#define CONFIG_SANDBOX_SPI_MAX_CS 10
+#endif
Why not put this at the top of that driver? Also shouldn't these be
added to the README?
+
#endif
diff --git a/arch/sandbox/include/asm/spi.h b/arch/sandbox/include/asm/spi.h
new file mode 100644
index 000..f96a926
--- /dev/null
+++ b/arch/sandbox/include/asm/spi.h
@@ -0,0 +1,58 @@
+/*
+ * Simulate a SPI port and clients
It would be nice if you could add a few more details about what is
simulated and how to use it.
+ *
+ * Copyright (c) 2011-2012 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#ifndef __ASM_SPI_H__
+#define __ASM_SPI_H__
+
+#include linux/types.h
+
+/*
+ * The interface between the SPI bus and the SPI client. The bus will
+ * instantiate a client, and that then call into it via these entry
+ * points. These should be enough for the client to emulate the SPI
+ * device just like the real hardware.
+ */
+struct sb_spi_emu_ops {
I would really like to have sandbox_ written out instead of sb_. I
thought you were ok with that for exported functions / structures at
least?
+ /* The bus wants to instantiate a new client, so setup everything */
+ int (*setup)(void **priv, const char *spec);
+ /* The bus is done with us, so break things down */
+ void (*free)(void *priv);
+ /* The CS has been activated -- we won't worry about low/high */
+ void (*cs_activate)(void *priv);
+ /* The CS has been deactivated -- we won't worry about low/high */
+ void (*cs_deactivate)(void *priv);
+ /* The client is rx-ing bytes from the bus, so it should tx some */
+ int (*xfer)(void *priv, const u8 *rx, u8 *tx, uint bytes);
Can we have full docs on each of these functions? They look similar to
spi.h but not the same?
+};
+
+/*
+ * There are times when the data lines are allowed to tristate. What
+ * is actually sensed on the line depends on the hardware. It could
+ * always be 0xFF/0x00 (if there are pull ups/downs), or things could
+ * float and so we'd get garbage back. This func encapsulates that
+ * scenario so we can worry about the details here.
+ */
+static inline void sb_spi_tristate(u8 *buf, uint len)
+{
+ /* XXX: make this into a user config option ? */
+ memset(buf, 0xff, len);
+}
+
+/*
+ * Extract the bus/cs from the spi spec and return the start of the spi
+ * client spec. If the bus/cs are invalid for the current config, then
+ * it returns NULL.
+ *
+ * Example: arg=0:1:foo will set bus to 0, cs to 1, and return foo
+ */
+const char *sb_spi_parse_spec(const char *arg, unsigned long *bus,
+ unsigned long *cs);
+
+#endif
diff --git a/arch/sandbox/include/asm/state.h
b/arch/sandbox/include/asm/state.h
index 2b62b46..ea5fbe0 100644
--- a/arch/sandbox/include/asm/state.h
+++ b/arch/sandbox/include/asm/state.h
@@ -38,6 +38,7 @@ struct sandbox_state {
const char *parse_err; /* Error to report from parsing */
int argc; /* Program arguments */
char **argv;
+ const void
*spi[CONFIG_SANDBOX_SPI_MAX_BUS][CONFIG_SANDBOX_SPI_MAX_CS][2];
OK now I see why you need it in config.h.
};
/**
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index c967d87..d80ff8b 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -40,6 +40,7 @@ COBJS-$(CONFIG_MXC_SPI) += mxc_spi.o
COBJS-$(CONFIG_MXS_SPI) += mxs_spi.o
COBJS-$(CONFIG_OC_TINY_SPI) += oc_tiny_spi.o
COBJS-$(CONFIG_OMAP3_SPI) += omap3_spi.o
+COBJS-$(CONFIG_SANDBOX_SPI) += sandbox_spi.o
COBJS-$(CONFIG_SOFT_SPI) += soft_spi.o
COBJS-$(CONFIG_SH_SPI) += sh_spi.o
COBJS-$(CONFIG_FSL_ESPI) += fsl_espi.o
diff --git a/drivers/spi/sandbox_spi.c
Re: [U-Boot] [PATCH 2/3 v3] sandbox: new SPI flash driver
Hi Mike,
On Mon, Mar 12, 2012 at 8:22 AM, Mike Frysinger vap...@gentoo.org wrote:
This adds a SPI flash driver which simulates SPI flash clients.
Currently supports the bare min that U-Boot requires: you can
probe, read, erase, and write. Should be easy to extend to make
it behave more exactly like a real SPI flash, but this is good
enough to merge now.
Signed-off-by: Mike Frysinger vap...@gentoo.org
Looks really nice. I have a few nits below.
---
v3
- rearchitected on top of state/getopt support
drivers/mtd/spi/Makefile | 1 +
drivers/mtd/spi/sandbox.c | 402
+
2 files changed, 403 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/spi/sandbox.c
diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
index 90f8392..fb37807 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -33,6 +33,7 @@ COBJS-$(CONFIG_SPI_FLASH) += spi_flash.o
COBJS-$(CONFIG_SPI_FLASH_ATMEL) += atmel.o
COBJS-$(CONFIG_SPI_FLASH_EON) += eon.o
COBJS-$(CONFIG_SPI_FLASH_MACRONIX) += macronix.o
+COBJS-$(CONFIG_SPI_FLASH_SANDBOX) += sandbox.o
COBJS-$(CONFIG_SPI_FLASH_SPANSION) += spansion.o
COBJS-$(CONFIG_SPI_FLASH_SST) += sst.o
COBJS-$(CONFIG_SPI_FLASH_STMICRO) += stmicro.o
diff --git a/drivers/mtd/spi/sandbox.c b/drivers/mtd/spi/sandbox.c
new file mode 100644
index 000..1cbe454
--- /dev/null
+++ b/drivers/mtd/spi/sandbox.c
@@ -0,0 +1,402 @@
+/*
+ * Simulate a SPI flash
+ *
+ * Copyright (c) 2011-2012 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#include common.h
+#include malloc.h
+#include spi.h
+#include os.h
+
+#include spi_flash.h
+#include spi_flash_internal.h
+
+#include asm/getopt.h
+#include asm/spi.h
+#include asm/state.h
+
+/*
+ * The different states that our SPI flash transitions between.
+ * We need to keep track of this across multiple xfer calls since
+ * the SPI bus could possibly call down into us multiple times.
+ */
+typedef enum {
+ SF_CMD, /* default state -- we're awaiting a command */
+ SF_ID, /* read the flash's (jedec) ID code */
+ SF_ADDR, /* processing the offset in the flash to read/etc... */
+ SF_READ, /* reading data from the flash */
+ SF_WRITE, /* writing data to the flash, i.e. page programming */
+ SF_ERASE, /* erase the flash */
+ SF_READ_STATUS, /* read the flash's status register */
+} sb_sf_state;
+
+static const char *sb_sf_state_name(sb_sf_state state)
+{
+ static const char * const states[] = {
+ CMD, ID, ADDR, READ, WRITE, ERASE, READ_STATUS,
+ };
+ return states[state];
+}
+
+/* Bits for the status register */
+#define STAT_WIP (1 0)
+#define STAT_WEL (1 1)
+
+/* Assume all SPI flashes have 3 byte addresses since they do atm */
+#define SF_ADDR_LEN 3
+
+struct sb_spi_flash_erase_commands {
+ u8 cmd;
+ u32 size;
+};
+#define IDCODE_LEN 5
+#define MAX_ERASE_CMDS 2
+struct sb_spi_flash_data {
+ const char *name;
+ u8 idcode[IDCODE_LEN];
+ u32 size;
+ const struct sb_spi_flash_erase_commands erase_cmds[MAX_ERASE_CMDS];
+};
+
+/* Structure describing all the flashes we know how to emulate */
+static const struct sb_spi_flash_data sb_sf_flashes[] = {
+ {
+ M25P16, { 0x20, 0x20, 0x15 }, (2 * 1024 * 1024),
+ { /* erase commands */
+ { 0xd8, (64 * 1024), }, /* sector */
+ { 0xc7, (2 * 1024 * 1024), }, /* bulk */
+ },
+ },
+};
+
+/* Used to quickly bulk erase backing store */
+static u8 sb_sf_0xff[0x1];
Ick, Does it really need to be so large?
+
+/* Internal state data for each SPI flash */
+struct sb_spi_flash {
+ /*
+ * As we receive data over the SPI bus, our flash transitions
+ * between states. For example, we start off in the SF_CMD
+ * state where the first byte tells us what operation to perform
+ * (such as read or write the flash). But the operation itself
+ * can go through a few states such as first reading in the
+ * offset in the flash to perform the requested operation.
+ * Thus state stores the exact state that our machine is in
+ * while cmd stores the overall command we're processing.
+ */
+ sb_sf_state state;
+ uint cmd;
+ const void *cmd_data;
+ /* Current position in the flash; used when reading/writing/etc... */
+ uint off;
+ /* How many address bytes we've consumed */
+ uint addr_bytes, pad_addr_bytes;
+ /* The current flash status (see STAT_XXX defines above) */
+ u8 status;
+ /* Data describing the flash we're emulating */
+
Re: [U-Boot] [Samsung] [PATCH] EXYNOS: Rename exynos5_tzpc structure to s5p_tzpc
On 03/15/2012 06:53 AM, Minkyu Kang wrote:
Dear Chander Kashyap,
On 14 March 2012 22:38, Chander Kashyap chander.kash...@linaro.org wrote:
Hi Kyungmin Park,
On 14 March 2012 19:02, Kyungmin Park kmp...@infradead.org wrote:
Hi Chander,
On Wed, Mar 14, 2012 at 10:14 PM, Chander Kashyap
chander.kash...@linaro.org wrote:
TZPC IP is common across S5P and Exynos based SoC'c. Renaming exynos5_tzpc
in arch/arm/include/asm/arch-exynos/tzpc.h to s5p_tzpc will allow generic
usase of tzpc.
Also modify board/samsung/smdk5250/tzpc_init.c to use s5p_tzpc.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
arch/arm/include/asm/arch-exynos/tzpc.h |2 +-
board/samsung/smdk5250/tzpc_init.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/tzpc.h
b/arch/arm/include/asm/arch-exynos/tzpc.h
index 2c9a07b..63736ae 100644
--- a/arch/arm/include/asm/arch-exynos/tzpc.h
+++ b/arch/arm/include/asm/arch-exynos/tzpc.h
@@ -22,7 +22,7 @@
#define __TZPC_H_
#ifndef __ASSEMBLY__
-struct exynos5_tzpc {
+struct s5p_tzpc {
I think 'exynos' is preferable. Even though each SOC has different
I tried to carry forward old conventions as in case of watchdog. I
will change it to exynos.
I agreed with Kyungmin.
From now, let's called exynos for common name including s5pc1xx and
s5pc2xx and exynos4 and exynos5.. etc.
From the above list, only s5pc1xx series was not named EXYNOS.
number of tzpc. It can be covered one exynos_tzpc. or we can define
it for each SoC.
One structure is enough as fields are same.
Thanks
Minkyu Kang.
--
Tushar Behera
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] WIP: fdt: Add serial port controlled by device tree
Hi Mike,
On Tue, Feb 21, 2012 at 7:47 AM, Mike Frysinger vap...@gentoo.org wrote:
On Tuesday 21 February 2012 01:41:21 Simon Glass wrote:
--- /dev/null
+++ b/common/fdt_decode.c
This whole file was not supposed to be there. I removed it from being
needed but somehow not from the patch, sorry.
+static struct fdt_compat compat_types[] = {
const
+void fdt_decode_uart_calc_divisor(struct fdt_uart *uart)
+{
+ if (uart-multiplier uart-baudrate)
+ uart-divisor = (uart-clock_freq +
+ (uart-baudrate * (uart-multiplier / 2))) /
+ (uart-multiplier * uart-baudrate);
+}
does the multiplier really need to be part of device tree ?
+int fdt_decode_get_spi_switch(const void *blob, struct fdt_spi_uart
*config) +{
+ int node, uart_node;
+ const u32 *gpio;
+
+ node = fdt_node_offset_by_compatible(blob, 0,
+ nvidia,spi-uart-switch);
what's with the hardcoded SoC names in common code ?
--- /dev/null
+++ b/drivers/serial/serial_fdt.c
+void uart_calc_divisor(struct fdt_uart *uart)
+{
+ if (uart-multiplier uart-baudrate)
+ uart-divisor = (uart-clock_freq +
+ (uart-baudrate * (uart-multiplier / 2))) /
+ (uart-multiplier * uart-baudrate);
+}
isn't this exactly the same as fdt_decode_uart_calc_divisor ?
Yes, I copied these functions out.
This patch was just for hanumant but I am going to create a proper
version of this and will post to the list soon.
-mike
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Don't use printf() in SPL builds
Hello Simon,
Simon Glass wrote:
Hi Sughosh,
On Sat, Mar 10, 2012 at 12:33 AM, Sughosh Ganu urwithsugh...@gmail.com
wrote:
hi Simon,
On Sat Mar 03, 2012 at 12:33:15PM -0800, Simon Glass wrote:
raise() likes to call printf() if it is available, but in SPL builds it
either is not available, or adds a large chunk to the resulting image
size.
So don't call it even if it is available.
This change reduces SPL size from 10KB to 6.3KB on hawkboard, for
example, using generic relocation.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/arm/lib/eabi_compat.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/lib/eabi_compat.c b/arch/arm/lib/eabi_compat.c
index 2028dbd..44eebe0 100644
--- a/arch/arm/lib/eabi_compat.c
+++ b/arch/arm/lib/eabi_compat.c
@@ -13,7 +13,8 @@
int raise (int signum)
{
-#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
+ /* Even if printf() is available, it's large. Punt it for SPL builds
*/
+#if !defined(CONFIG_SPL_BUILD)
printf(raise: Signal # %d caught\n, signum);
#endif
I tested with this change on hawkboard, and after applying this
change, the spl size increase is 412 bytes against the 4k increase
that we get with libcommon changes introduced. So this patch works
fine.
OK good.
Can you please check if libcommon support is needed for the
cam_enc_4xx board -- your relocation patch series did not add
CONFIG_SPL_LIBCOMMON_SUPPORT to this board. This will affect my
patch to initialise gd and bd objects for hawkboard. Please let me
know, and i will spin a patch accordingly.
Yes I think this board needs both of these:
#define CONFIG_SPL_LIBCOMMON_SUPPORT
#define CONFIG_SPL_LIBGENERIC_SUPPORT
I posted a patch, which adds CONFIG_SPL_LIBGENERIC_SUPPORT, see
http://patchwork.ozlabs.org/patch/145280/
for this board. Build/works fine without CONFIG_SPL_LIBCOMMON_SUPPORT
maybe I miss something?
Builded with ELDK-4.2 and ELDK-5.1 based on commit:
commit e37ae40e9dec9af417c19de72f76becebf160730
Author: Stephen Warren swar...@nvidia.com
Date: Tue Nov 1 06:28:21 2011 +
image: Support FDTs already loaded at their load address
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] arm: Don't use printf() in SPL builds
Hi Heiko,
On Wed, Mar 14, 2012 at 10:13 PM, Heiko Schocher h...@denx.de wrote:
Hello Simon,
Simon Glass wrote:
Hi Sughosh,
On Sat, Mar 10, 2012 at 12:33 AM, Sughosh Ganu urwithsugh...@gmail.com
wrote:
hi Simon,
On Sat Mar 03, 2012 at 12:33:15PM -0800, Simon Glass wrote:
raise() likes to call printf() if it is available, but in SPL builds it
either is not available, or adds a large chunk to the resulting image
size.
So don't call it even if it is available.
This change reduces SPL size from 10KB to 6.3KB on hawkboard, for
example, using generic relocation.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/arm/lib/eabi_compat.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/lib/eabi_compat.c b/arch/arm/lib/eabi_compat.c
index 2028dbd..44eebe0 100644
--- a/arch/arm/lib/eabi_compat.c
+++ b/arch/arm/lib/eabi_compat.c
@@ -13,7 +13,8 @@
int raise (int signum)
{
-#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
+ /* Even if printf() is available, it's large. Punt it for SPL builds
*/
+#if !defined(CONFIG_SPL_BUILD)
printf(raise: Signal # %d caught\n, signum);
#endif
I tested with this change on hawkboard, and after applying this
change, the spl size increase is 412 bytes against the 4k increase
that we get with libcommon changes introduced. So this patch works
fine.
OK good.
Can you please check if libcommon support is needed for the
cam_enc_4xx board -- your relocation patch series did not add
CONFIG_SPL_LIBCOMMON_SUPPORT to this board. This will affect my
patch to initialise gd and bd objects for hawkboard. Please let me
know, and i will spin a patch accordingly.
Yes I think this board needs both of these:
#define CONFIG_SPL_LIBCOMMON_SUPPORT
#define CONFIG_SPL_LIBGENERIC_SUPPORT
I posted a patch, which adds CONFIG_SPL_LIBGENERIC_SUPPORT, see
http://patchwork.ozlabs.org/patch/145280/
for this board. Build/works fine without CONFIG_SPL_LIBCOMMON_SUPPORT
maybe I miss something?
Builded with ELDK-4.2 and ELDK-5.1 based on commit:
commit e37ae40e9dec9af417c19de72f76becebf160730
Author: Stephen Warren swar...@nvidia.com
Date: Tue Nov 1 06:28:21 2011 +
image: Support FDTs already loaded at their load address
Yes I am talking about building with the generic relocation series
included, so a slightly different point. With that I get:
$ make -j8 -s
Generating include/generated/asm-offsets.h
arch/arm/cpu/arm926ejs/davinci/libdavinci.o: In function `board_init_f':
/home/sjg/trunk/src/third_party/u-boot/files/arch/arm/cpu/arm926ejs/davinci/spl.c:75:
undefined reference to `relocate_code'
make[1]: *** [/home/sjg/trunk/src/third_party/u-boot/files/spl/u-boot-spl]
Error 1
make: *** [spl/u-boot-spl.bin] Error 2
make: *** Waiting for unfinished jobs
Regards,
Simon
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 2/3 v3] sandbox: new SPI flash driver
On Thursday 15 March 2012 00:09:59 Simon Glass wrote:
On Mon, Mar 12, 2012 at 8:22 AM, Mike Frysinger wrote:
+/* Used to quickly bulk erase backing store */
+static u8 sb_sf_0xff[0x1];
Ick, Does it really need to be so large?
in order to do a single write() for a single sector, yes. it also simplifies
the code as i don't have to loop over some smaller size and keep track of how
many bytes i've written until a sector is cleared.
this is in the bss and it's 64KiB. i'm really not worried about your
development system running Chrome getting low on RAM :).
+ sbsf-fd = os_open(file, 02);
+ if (sbsf-fd == -1) {
+ free(sbsf);
+ goto error;
Prints incorrect error if the file couldn't be found/open. I wonder if
we should have os_perror() ?
probably would be useful. we prob have to document that while os_perror()
would work, strerror(errno) would not. the os_* funcs update the errno that
the C library knows about (or *__errno_location() in glibc), but u-boot
declares a local errno variable. so attempting to reference errno in u-
boot code will always resolve to the local definition rather than the glibc
one. os_perror() would work because it calls __errno_location() internally
just like the other os_* funcs.
+ pos += os_read(sbsf-fd, tx + pos, cnt);
This can fail (return -1)
the ways in which read/write could fail aren't really possible for us, but i
guess it won't hurt to assert() the values.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Don't use printf() in SPL builds
Hello Simon, Simon Glass wrote: Hi Heiko, On Wed, Mar 14, 2012 at 10:13 PM, Heiko Schocher h...@denx.de wrote: Hello Simon, Simon Glass wrote: Hi Sughosh, On Sat, Mar 10, 2012 at 12:33 AM, Sughosh Ganu urwithsugh...@gmail.com wrote: hi Simon, On Sat Mar 03, 2012 at 12:33:15PM -0800, Simon Glass wrote: [...] Can you please check if libcommon support is needed for the cam_enc_4xx board -- your relocation patch series did not add CONFIG_SPL_LIBCOMMON_SUPPORT to this board. This will affect my patch to initialise gd and bd objects for hawkboard. Please let me know, and i will spin a patch accordingly. Yes I think this board needs both of these: #define CONFIG_SPL_LIBCOMMON_SUPPORT #define CONFIG_SPL_LIBGENERIC_SUPPORT I posted a patch, which adds CONFIG_SPL_LIBGENERIC_SUPPORT, see http://patchwork.ozlabs.org/patch/145280/ for this board. Build/works fine without CONFIG_SPL_LIBCOMMON_SUPPORT maybe I miss something? Builded with ELDK-4.2 and ELDK-5.1 based on commit: commit e37ae40e9dec9af417c19de72f76becebf160730 Author: Stephen Warren swar...@nvidia.com Date: Tue Nov 1 06:28:21 2011 + image: Support FDTs already loaded at their load address Yes I am talking about building with the generic relocation series included, so a slightly different point. With that I get: $ make -j8 -s Generating include/generated/asm-offsets.h arch/arm/cpu/arm926ejs/davinci/libdavinci.o: In function `board_init_f': /home/sjg/trunk/src/third_party/u-boot/files/arch/arm/cpu/arm926ejs/davinci/spl.c:75: undefined reference to `relocate_code' make[1]: *** [/home/sjg/trunk/src/third_party/u-boot/files/spl/u-boot-spl] Error 1 make: *** [spl/u-boot-spl.bin] Error 2 make: *** Waiting for unfinished jobs Ah, Ok. Currently I have no access to the hw, so I could not test this :-( 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
