Re: [U-Boot] [PATCH v3 0/6] Introduce generic relocation feature
Hi Simon, Le 26/12/2011 19:24, Simon Glass a écrit : (I am resending this rebased so I can continue with this board-unification work and allow people to review patches. There were some comments on the v2 series but my questions have been sitting on the list for 2 weeks so it is probably time for a new series.) This is the second patch series aiming to unify the various board.c files in each architecture into a single one. This series implements a generic relocation feature, which is the bridge between board_init_f() and board_init_r(). It then moves ARM over to use this framework, as an example. On ARM the relocation code is duplicated for each CPU yet it is the same. We can bring this up to the arch level. But since (I believe) Elf relocation is basically the same process for all archs, there is no reason not to bring it up to the generic level. Each architecture which uses this framework needs to provide a function called arch_elf_relocate_entry() which processes a single relocation entry. This is a static inline function to reduce code size overhead. Agreed. For ARM, a new arch/arm/lib/proc.S file is created, which holds generic ARM assembler code (things that cannot be written in C and are common functions used by all ARM CPUs). This helps reduce duplication. Interrupt handling code and perhaps even some startup code can move there later. It may be useful for other architectures with a lot of different CPUs to have a similar file. NAK for several reasons: 1. The code that goes on proc.S is already in start.S, which already contains "things which cannot be written in C and are common functions used by all ARM CPUs". Granted, right now start.S is duplicated in multiple CPU directories; so the thing to do is to merge all ARM start.S files into a single one, rather than merging only one of its parts. 2. There is no interest in moving this segment of code from all start.S files into a new proc.S file: there is no gain is code size obviously, and there is an increase in source file count. 3. I consider that files should contain 'things' based on their common /functionality/, not on their similar /nature/, and "going about starting up U-Boot" is a functionality. Note that eventually, having a single start.S will achieve the same effect as this 'proc.S' patch. Note also that this start.S commonalization should be a completely different patch set. Code size on my ARMv7 system increases by 54 bytes with generic relocation. This overhead is mostly just literal pool access and setting up to call the relocated U-Boot at the end. On my system, execution time increases from 10.8ms to 15.6ms due to the less efficient C implementations of the copy and zero loops. If execution time is of concern, you can define CONFIG_USE_ARCH_MEMSET and CONFIG_USE_ARCH_MEMCPY to reduce it. For met this reduces relocation time to 5.4ms, i.e. twice as fast as the old system. Side question: is there any reason not to define these CONFIG options systematically? One problem remains which causes mx31pdk to fail to build. It doesn't have string.c in its SPL code and the architecture-specific versions of memset()/memcpy() are too large. I propose to add a local change to reloc.c that uses inline code for boards that use the old legacy SPL framework. We can remove it later. This is not included in v2 but I am interested in comments on this approach. An alternative would be just to add simple memset()/memcpy() functions just for this board (and one other affected MX31 board). I am not too fond of the "later removal" approach. In my experience, this invariably tends to the "old bloat in the code no one knows the reason of" situations. Changes in v2: - Use CONFIG_SYS_SKIP_RELOC instead of CONFIG_SYS_LEGACY_BOARD - Import asm-generic/sections.h from Linux and add U-Boot extras - Squash generic link symbols patch into generic relocation patch - Move reloc.c into common/ - Add function comments - Use memset, memcpy instead of inline code - Add README file for relocation - Invalidate I-cache when we jump to relocated code - Use an inline relocation function to reduce code size - Make relocation symbols global so we can use them outside start.S Changes in v3: - Remove the 'reloc' tag from each commit - Rebase to master Simon Glass (6): Create reloc.h and include it where needed define CONFIG_SYS_SKIP_RELOC for all archs Add generic relocation feature arm: Add processor function library arm: Move over to generic relocation arm: Remove unused code in start.S README|4 + arch/arm/cpu/arm1136/start.S | 133 ++ arch/arm/cpu/arm1176/start.S | 214 ++--- arch/arm/cpu/arm720t/start.S | 127 ++--- arch/arm/cpu/arm920t/start.S | 135 ++ arch/arm/cpu/arm925t/start.S | 135 ++---
Re: [U-Boot] [PATCH v5 0/3] ARMV7: Exynos4: Add support for TRATS board
Dear HeungJun, Kim On 17 January 2012 16:13, HeungJun, Kim wrote: > This patch series support for Samsung TRATS board, and add the headers of > watchdog and power, and current version is 4. > > I missed logs of v2 on this thread, so I'm going to add this: > http://lists.denx.de/pipermail/u-boot/2012-January/114857.html > > Also, this patch is tested on Samsung TRATS board. > > Thank you. > > Best Regards, > Heungjun Kim > > HeungJun, Kim (3): > ARMV7: Exynos4: Add watchdog.h for Exynos4 > ARMV7: Exynos4: Add supoort power for Exynos4 > ARMV7: Exynos4: Add support for TRATS board > > MAINTAINERS | 4 + > arch/arm/include/asm/arch-exynos/cpu.h | 1 + > arch/arm/include/asm/arch-exynos/power.h | 230 ++ > arch/arm/include/asm/arch-exynos/watchdog.h | 53 +++ > board/samsung/trats/Makefile | 43 ++ > board/samsung/trats/setup.h | 637 > +++ > board/samsung/trats/trats.c | 379 > boards.cfg | 1 + > include/configs/trats.h | 216 + > 9 files changed, 1564 insertions(+), 0 deletions(-) > create mode 100644 arch/arm/include/asm/arch-exynos/power.h > create mode 100644 arch/arm/include/asm/arch-exynos/watchdog.h > create mode 100644 board/samsung/trats/Makefile > create mode 100644 board/samsung/trats/setup.h > create mode 100644 board/samsung/trats/trats.c > create mode 100644 include/configs/trats.h > applied to u-boot-samsung. Chander Kashyap, Please refer to this patch for converting C codes. 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] nand_util: correct YAFFS image write function
In function nand_write_skip_bad(),for YAFFS filesystem part, write_oob() will return 0 when success, so when rval equals 0, it should continue to write the next page, and no break. Signed-off-by: Wentao, Liu diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c index 60c778e..7ed8b18 100644 --- a/drivers/mtd/nand/nand_util.c +++ b/drivers/mtd/nand/nand_util.c @@ -564,7 +564,7 @@ int nand_write_skip_bad(nand_info_t *nand, loff_t offset, size_t *length, ops.oobbuf = ops.datbuf + pagesize; rval = nand->write_oob(nand, offset, &ops); - if (!rval) + if (rval != 0) break; offset += pagesize; -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] common, menu: do not timeout again if an item was selected but not found
Signed-off-by: Heiko Schocher
Acked-by: Jason Hobbs
Cc: Mike Frysinger
---
- changes for v2:
- add Acked-by from Jason Hobbs
- add comment from Mike Frysinger:
- respell summary text
---
common/menu.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/common/menu.c b/common/menu.c
index 754a9f9..aa16c9a 100644
--- a/common/menu.c
+++ b/common/menu.c
@@ -236,8 +236,10 @@ static inline int menu_interactive_choice(struct menu *m,
void **choice)
if (readret >= 0) {
choice_item = menu_item_by_key(m, cbuf);
- if (!choice_item)
+ if (!choice_item) {
printf("%s not found\n", cbuf);
+ m->timeout = 0;
+ }
} else {
puts("^C\n");
return -EINTR;
--
1.7.7.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common, menu: do not trigger timeout again, if a line is read
Hello Mike,
Mike Frysinger wrote:
> On Tuesday 17 January 2012 03:24:29 Heiko Schocher wrote:
>> --- a/common/menu.c
>> +++ b/common/menu.c
>> choice_item = menu_item_by_key(m, cbuf);
>>
>> -if (!choice_item)
>> +if (!choice_item) {
>> printf("%s not found\n", cbuf);
>> +m->timeout = 0;
>> +}
>> } else {
>> puts("^C\n");
>> return -EINTR;
>
> the summary says "do not timeout again if a line is read", but this C code
> seems like "do not timeout again if an item was selected but not found". but
> maybe i'm reading the menu code incorrectly ?
No, you are reading C code right, fix this, thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3 v3] common, menu: show menu on startup if CONFIG_MENU_SHOW is defined
show a menu on startup instead running the shell.
Signed-off-by: Heiko Schocher
Acked-by: Jason Hobbs
Cc: Mike Frysinger
---
- changes for v2:
- add comments from Mike Frysinger
- pass current bootdelay to menu_show
- changes for v3:
- add Acked-by: Jason Hobbs
- add comment from Jason Hobbs
- spelling fixes in README
---
common/main.c |4
doc/README.menu |5 +
include/menu.h |3 +++
3 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/common/main.c b/common/main.c
index 248744b..91e888f 100644
--- a/common/main.c
+++ b/common/main.c
@@ -41,6 +41,7 @@
#include
#include
+#include
#if defined(CONFIG_SILENT_CONSOLE) || defined(CONFIG_POST) ||
defined(CONFIG_CMDLINE_EDITING)
DECLARE_GLOBAL_DATA_PTR;
@@ -372,6 +373,9 @@ void main_loop (void)
debug ("### main_loop entered: bootdelay=%d\n\n", bootdelay);
+#if defined(CONFIG_MENU_SHOW)
+ bootdelay = menu_show(bootdelay);
+#endif
# ifdef CONFIG_BOOT_RETRY_TIME
init_cmd_timeout ();
# endif/* CONFIG_BOOT_RETRY_TIME */
diff --git a/doc/README.menu b/doc/README.menu
index 4ddf914..bc33012 100644
--- a/doc/README.menu
+++ b/doc/README.menu
@@ -25,6 +25,11 @@ the interfaces should be available.
Menus are composed of items. Each item has a key used to identify it in
the menu, and an opaque pointer to data controlled by the consumer.
+If you want to show a menu, instead of starting the shell, define
+CONFIG_MENU_SHOW. You have to code the int menu_show(int bootdelay)
+function, which handles your menu. This function returns the remaining
+bootdelay.
+
Interfaces
--
#include "menu.h"
diff --git a/include/menu.h b/include/menu.h
index b806a02..7af5fdb 100644
--- a/include/menu.h
+++ b/include/menu.h
@@ -28,4 +28,7 @@ int menu_item_add(struct menu *m, char *item_key, void
*item_data);
int menu_destroy(struct menu *m);
void menu_display_statusline(struct menu *m);
+#if defined(CONFIG_MENU_SHOW)
+int menu_show(int bootdelay);
+#endif
#endif /* __MENU_H__ */
--
1.7.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot not auto booting
the autobooting function of uboot is not functioning properly on my sheevaplug with debian. I have set the bootcmd and bootdelay variables, but I still can't get it to work. I can watch the countdown hit zero, and I do not hit any buttons and then the whole process just stops at the prompt. If I disconnect the serial cable from the computer, it still fails to proceed with the boot process. Below is the dump of 'printenv' any suggestions? Marvell>> printenv autostart=yes baudrate=115200 bootargs=console=ttyS0,115200 bootargs_console=console=ttyS0,115200 bootcmd=setenv bootargs $(bootargs_console); run bootcmd_mmc; bootm 0x0080 0x0110 bootcmd_mmc=mmc init; ext2load mmc 0:1 0x0080 /uImage; ext2load mmc 0:1 0x0110 /uInitrd bootcmd_usb=usb start; ext2load usb 0:1 0x0080 /uImage; ext2load usb 0:1 0x0110 /uInitrd bootdelay=3 ethact=egiga0 ethaddr=02:50:43:8f:c8:4b filesize=55EB7D machid=a76 stderr=serial stdin=serial stdout=serial x_bootargs=console=ttyS0,115200 mtdparts=orion_nand:512k(uboot),4m@1m (kernel),507m@5m(rootfs) rw x_bootargs_root=ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs x_bootcmd_kernel=nand read 0x640 0x10 0x40 x_bootcmd_sata=ide reset; x_bootcmd_usb=usb start; Environment size: 805/131068 bytes ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] imx6: mx6qarm2: updated board_mmc_getcd() to the new prototype
On Tue, Jan 17, 2012 at 9:15 PM, Stefano Babic wrote:
> Commit 314284b1567f1ce29c19060641e7f213146f7ab8 has
> changed board_mmc_getcd() function prototype, while
> mx6qarm2 has still the old one.
>
> Signed-off-by: Stefano Babic
> CC: Jason Liu
> Acked-by: Dirk Behme
>
> ---
> board/freescale/mx6qarm2/mx6qarm2.c | 9 +
> 1 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/board/freescale/mx6qarm2/mx6qarm2.c
> b/board/freescale/mx6qarm2/mx6qarm2.c
> index 9894245..9724c16 100644
> --- a/board/freescale/mx6qarm2/mx6qarm2.c
> +++ b/board/freescale/mx6qarm2/mx6qarm2.c
> @@ -120,17 +120,18 @@ struct fsl_esdhc_cfg usdhc_cfg[2] = {
> {USDHC4_BASE_ADDR, 1},
> };
>
> -int board_mmc_getcd(u8 *cd, struct mmc *mmc)
> +int board_mmc_getcd(struct mmc *mmc)
> {
> struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
> + int ret;
>
> if (cfg->esdhc_base == USDHC3_BASE_ADDR) {
> gpio_direction_input(171); /*GPIO6_11*/
> - *cd = gpio_get_value(171);
> + ret = !gpio_get_value(171);
> } else /* Don't have the CD GPIO pin on board */
> - *cd = 0;
> + ret = 0;
^^1
Apparently, this is wrong for the else statement, since there is no CD
for the SD4 on the board,
so, we have to tell MMC system that the card is always there,
otherwise, we can't use the MMC
plug-in that slot. After change to new prototype, we also need convert
the ret value for the SD4,
and return 1 not 0 to MMC.
>
> - return 0;
> + return ret;
> }
>
> int board_mmc_init(bd_t *bis)
> --
> 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 2/6] mx6q: Add support for ECSPI through mxc_spi driver
On 01/17/2012 06:47 PM, Marek Vasut wrote: On 01/17/2012 06:27 PM, Marek Vasut wrote: I'll defer to Stefano on this one, since I did this in response to his request: >> Right - and we already discussed in the past how to avoid to put specific SOC code inside the driver. In fact, the cspi_regs structure was already moved into the specific SOC header (imx-regs.h) - but the definitions of the single bits of the registers are still inside the driver, as well as the base address of the (e)cspi controllers. They should also be moved - take into acoount by implementing your changes for i.mx6 The struct cspi_regs is already present in mx31, mx35, and mx51 headers, so I'm not breaking new ground here, only in the bitfield declarations. >> My interpretation of Stefano's intent is to clean up the driver at the expense of extra defines in the arch-specific headers. But they're all the same, right? So we have now the same structure defined thrice? Almost, but not quite: mx31 and mx35 both use the CSPI peripheral and have one layout. mx5 and mx6 have the ECSPI peripheral, which has an extra register "cfg" to control the polarity and phase of the signals. Actually, that comment is wrong. The MX51 and MX53 have **both** CSPI and ECSPI peripherals, but the existing code in mxc_spi only supports ECSPI. The bitfields that my patches move into the imx-regs.h files are also almost identical. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] mx6q: Add support for ECSPI through mxc_spi driver
> On 01/17/2012 06:27 PM, Marek Vasut wrote:
> >> On 01/17/2012 04:19 PM, Marek Vasut wrote:
> Signed-off-by: Eric Nelson
> +/* ECSPI registers */
> +struct cspi_regs {
> +u32 rxdata;
> +u32 txdata;
> +u32 ctrl;
> +u32 cfg;
> +u32 intr;
> +u32 dma;
> +u32 stat;
> +u32 period;
> +};
> >>>
> >>> Sigh ... it's no fun I can have only one remark :-)
> >>>
> >>> Is this part common for all imx-es ?
> >>
> >> All i.MX6's
> >>
> >> This is a cut& paste from MX51.
> >>
> >> I was tempted to introduce an 'mxc_ecspi.h' to merge the declaration
> >> for i.MX5x and i.MX6 which share the ECSPI peripheral and 'mxc_cspi.h'
> >> for i.MX31 and i.MX35 that share the CSPI peripheral.
> >
> > But you don't even need this outside of the spi driver so just put it
> > into the spi driver and be done with it. That'll solve your duplication
> > issue.
> >
> > M
>
> I'll defer to Stefano on this one, since I did this in response
>
> to his request:
> > Right - and we already discussed in the past how to avoid to put
> > specific SOC code inside the driver. In fact, the cspi_regs structure
> > was already moved into the specific SOC header (imx-regs.h) - but the
> > definitions of the single bits of the registers are still inside the
> > driver, as well as the base address of the (e)cspi controllers.
> >
> > They should also be moved - take into acoount by implementing your
> > changes for i.mx6
>
> The struct cspi_regs is already present in mx31, mx35, and mx51 headers,
> so I'm not breaking new ground here, only in the bitfield declarations.
>
> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-
mx31/i
> mx-regs.h;h=6a517ddd931ca0d1e598bd7456c4c611741602eb;hb=HEAD#l60
> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-mx35/i
> mx-regs.h;h=df74508a93ee87ae986f7c2f48f6c5fb36626070;hb=HEAD#l279
> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-mx5/im
> x-regs.h;h=0ee88d25b7800ae9e6aed809d02dd19d9cac9c82;hb=HEAD#l423
>
> My interpretation of Stefano's intent is to clean up the driver at the
> expense of extra defines in the arch-specific headers.
But they're all the same, right? So we have now the same structure defined
thrice?
M
>
> Regards,
>
>
> Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] mx6q: Add support for ECSPI through mxc_spi driver
On 01/17/2012 06:27 PM, Marek Vasut wrote:
On 01/17/2012 04:19 PM, Marek Vasut wrote:
Signed-off-by: Eric Nelson
+/* ECSPI registers */
+struct cspi_regs {
+ u32 rxdata;
+ u32 txdata;
+ u32 ctrl;
+ u32 cfg;
+ u32 intr;
+ u32 dma;
+ u32 stat;
+ u32 period;
+};
Sigh ... it's no fun I can have only one remark :-)
Is this part common for all imx-es ?
All i.MX6's
This is a cut& paste from MX51.
I was tempted to introduce an 'mxc_ecspi.h' to merge the declaration
for i.MX5x and i.MX6 which share the ECSPI peripheral and 'mxc_cspi.h'
for i.MX31 and i.MX35 that share the CSPI peripheral.
But you don't even need this outside of the spi driver so just put it into the
spi driver and be done with it. That'll solve your duplication issue.
M
I'll defer to Stefano on this one, since I did this in response
to his request:
Right - and we already discussed in the past how to avoid to put
specific SOC code inside the driver. In fact, the cspi_regs structure
was already moved into the specific SOC header (imx-regs.h) - but the
definitions of the single bits of the registers are still inside the
driver, as well as the base address of the (e)cspi controllers.
They should also be moved - take into acoount by implementing your
changes for i.mx6
The struct cspi_regs is already present in mx31, mx35, and mx51 headers,
so I'm not breaking new ground here, only in the bitfield declarations.
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-mx31/imx-regs.h;h=6a517ddd931ca0d1e598bd7456c4c611741602eb;hb=HEAD#l60
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-mx35/imx-regs.h;h=df74508a93ee87ae986f7c2f48f6c5fb36626070;hb=HEAD#l279
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-mx5/imx-regs.h;h=0ee88d25b7800ae9e6aed809d02dd19d9cac9c82;hb=HEAD#l423
My interpretation of Stefano's intent is to clean up the driver at the expense
of extra defines in the arch-specific headers.
Regards,
Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] mx6q: Add support for ECSPI through mxc_spi driver
> On 01/17/2012 04:19 PM, Marek Vasut wrote:
> >> Signed-off-by: Eric Nelson
> >> ---
> >>
> >> arch/arm/include/asm/arch-mx6/imx-regs.h | 44
> >>
> >> ++ 1 files changed, 44 insertions(+), 0
> >> deletions(-)
> >>
> >> diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
> >> b/arch/arm/include/asm/arch-mx6/imx-regs.h index 7650cb9..00040c4 100644
> >> --- a/arch/arm/include/asm/arch-mx6/imx-regs.h
> >> +++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
> >> @@ -190,6 +190,50 @@ struct src {
> >>
> >>u32 gpr10;
> >>
> >> };
> >>
> >> +/* ECSPI registers */
> >> +struct cspi_regs {
> >> + u32 rxdata;
> >> + u32 txdata;
> >> + u32 ctrl;
> >> + u32 cfg;
> >> + u32 intr;
> >> + u32 dma;
> >> + u32 stat;
> >> + u32 period;
> >> +};
> >
> > Sigh ... it's no fun I can have only one remark :-)
> >
> > Is this part common for all imx-es ?
>
> All i.MX6's
>
> This is a cut & paste from MX51.
>
> I was tempted to introduce an 'mxc_ecspi.h' to merge the declaration
> for i.MX5x and i.MX6 which share the ECSPI peripheral and 'mxc_cspi.h'
> for i.MX31 and i.MX35 that share the CSPI peripheral.
But you don't even need this outside of the spi driver so just put it into the
spi driver and be done with it. That'll solve your duplication issue.
M
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] mx6q: Add support for ECSPI through mxc_spi driver
On 01/17/2012 04:19 PM, Marek Vasut wrote:
Signed-off-by: Eric Nelson
---
arch/arm/include/asm/arch-mx6/imx-regs.h | 44
++ 1 files changed, 44 insertions(+), 0
deletions(-)
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/imx-regs.h index 7650cb9..00040c4 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -190,6 +190,50 @@ struct src {
u32 gpr10;
};
+/* ECSPI registers */
+struct cspi_regs {
+ u32 rxdata;
+ u32 txdata;
+ u32 ctrl;
+ u32 cfg;
+ u32 intr;
+ u32 dma;
+ u32 stat;
+ u32 period;
+};
Sigh ... it's no fun I can have only one remark :-)
Is this part common for all imx-es ?
All i.MX6's
This is a cut & paste from MX51.
I was tempted to introduce an 'mxc_ecspi.h' to merge the declaration
for i.MX5x and i.MX6 which share the ECSPI peripheral and 'mxc_cspi.h'
for i.MX31 and i.MX35 that share the CSPI peripheral.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] mx6q: Add support for ECSPI through mxc_spi driver
> Signed-off-by: Eric Nelson
> ---
> arch/arm/include/asm/arch-mx6/imx-regs.h | 44
> ++ 1 files changed, 44 insertions(+), 0
> deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
> b/arch/arm/include/asm/arch-mx6/imx-regs.h index 7650cb9..00040c4 100644
> --- a/arch/arm/include/asm/arch-mx6/imx-regs.h
> +++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
> @@ -190,6 +190,50 @@ struct src {
> u32 gpr10;
> };
>
> +/* ECSPI registers */
> +struct cspi_regs {
> + u32 rxdata;
> + u32 txdata;
> + u32 ctrl;
> + u32 cfg;
> + u32 intr;
> + u32 dma;
> + u32 stat;
> + u32 period;
> +};
Sigh ... it's no fun I can have only one remark :-)
Is this part common for all imx-es ?
> +
> +/*
> + * CSPI register definitions
> + */
> +#define MXC_ECSPI
> +#define MXC_CSPICTRL_EN (1 << 0)
> +#define MXC_CSPICTRL_MODE(1 << 1)
> +#define MXC_CSPICTRL_XCH (1 << 2)
> +#define MXC_CSPICTRL_CHIPSELECT(x) (((x) & 0x3) << 12)
> +#define MXC_CSPICTRL_BITCOUNT(x) (((x) & 0xfff) << 20)
> +#define MXC_CSPICTRL_PREDIV(x) (((x) & 0xF) << 12)
> +#define MXC_CSPICTRL_POSTDIV(x) (((x) & 0xF) << 8)
> +#define MXC_CSPICTRL_SELCHAN(x) (((x) & 0x3) << 18)
> +#define MXC_CSPICTRL_MAXBITS 0xfff
> +#define MXC_CSPICTRL_TC (1 << 7)
> +#define MXC_CSPICTRL_RXOVF (1 << 6)
> +#define MXC_CSPIPERIOD_32KHZ (1 << 15)
> +#define MAX_SPI_BYTES32
> +
> +/* Bit position inside CTRL register to be associated with SS */
> +#define MXC_CSPICTRL_CHAN18
> +
> +/* Bit position inside CON register to be associated with SS */
> +#define MXC_CSPICON_POL 4
> +#define MXC_CSPICON_PHA 0
> +#define MXC_CSPICON_SSPOL12
> +#define MXC_SPI_BASE_ADDRESSES \
> + ECSPI1_BASE_ADDR, \
> + ECSPI2_BASE_ADDR, \
> + ECSPI3_BASE_ADDR, \
> + ECSPI4_BASE_ADDR, \
> + ECSPI5_BASE_ADDR
> +
> struct iim_regs {
> u32 ctrl;
> u32 ctrl_set;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mxc_spi refactoring (for mx6q)
> This patch set refactors mxc_spi as described in > http://lists.denx.de/pipermail/u-boot/2010-March/068791.html > and requested in > http://lists.denx.de/pipermail/u-boot/2012-January/116023.html > in order to add support for the MX6Q in general and the mx6qsabrelite > specifically. > > Patch 1 simply moves the conditional parts of mxc_spi.c into the > respective CPU-specific imx-regs.h files. > > Patch 2 adds general support for SPI to the i.MX6. > > Patch 3 adds support to the mx6qsabrelite board > > Patch 4 modifies the 'sf' command to allow a default chip-select > to be specified by board headers as is done on efika et al. This allows > a bare 'sf' probe command: > U-Boot> sf probe > instead of the more cumbersome usage when a GPIO is tacked onto > the chip-select. Otherwise, this command-line would be needed > to specify GP3:19 on SabreLite: > U-Boot> sf probe 0x5300 > > Patch 5 adds default chip-select values for mx6qsabrelite platform. > > Patch 6 adds reference macros for use in storing the environment > in serial flash to match the use on Freescale's U-Boot release > > This patch set has been compiled against the following configurations, > but only tested on mx6qsabrelite: > mx6qsabrelite > mx51evk > mx31pdk > mx35pdk Muhehehe ... time for a little review-torture :-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm, davinci: add PLL0 prediv to da850 lowlevel setup
On Mon, Jan 16, 2012 at 10:43 AM, Ben Gardiner wrote: > The OMAP-L138 has a pre-divider available on PLL0. > > Add support to da850_lowlevel.c for configuring PLL0's pre-divider. This is > to achieve certain OPP's -- e.g. the 372MHz OPP used also by Linux. > > Signed-off-by: Ben Gardiner > Cc: Christian Riesch > CC: Heiko Schocher > Cc: Sandeep Paulraj > Cc: Tom Rini > Cc: Albert ARIBAUD Applied to u-boot-ti/master, thanks! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6] mx6q: mx6qsabrelite: Provide default chip-select for serial flash
Signed-off-by: Eric Nelson --- include/configs/mx6qsabrelite.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h index 8dd6e39..44b028a 100644 --- a/include/configs/mx6qsabrelite.h +++ b/include/configs/mx6qsabrelite.h @@ -46,6 +46,7 @@ #define CONFIG_CMD_SF #ifdef CONFIG_CMD_SF +#define CONFIG_SPI_FLASH_CS 0x5300 #define CONFIG_SPI_FLASH #define CONFIG_SPI_FLASH_SST #define CONFIG_MXC_SPI -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/6] mx6q: mx6qsabrelite: Provide defaults for placing environment in serial flash
Signed-off-by: Eric Nelson --- include/configs/mx6qsabrelite.h | 12 +++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h index 44b028a..160894c 100644 --- a/include/configs/mx6qsabrelite.h +++ b/include/configs/mx6qsabrelite.h @@ -174,10 +174,20 @@ /* FLASH and environment organization */ #define CONFIG_SYS_NO_FLASH -#define CONFIG_ENV_OFFSET (6 * 64 * 1024) #define CONFIG_ENV_SIZE(8 * 1024) + #define CONFIG_ENV_IS_IN_MMC +/* #define CONFIG_ENV_IS_IN_SPI_FLASH */ + +#if defined(CONFIG_ENV_IS_IN_MMC) +#define CONFIG_ENV_OFFSET (6 * 64 * 1024) #define CONFIG_SYS_MMC_ENV_DEV 0 +#elif defined(CONFIG_ENV_IS_IN_SPI_FLASH) +#define CONFIG_ENV_OFFSET (768 * 1024) +#define CONFIG_ENV_SECT_SIZE (8 * 1024) +#define CONFIG_ENV_SPI_CS 0x5300 +#define CONFIG_ENV_SPI_MODESPI_MODE_0 +#endif #define CONFIG_OF_LIBFDT -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] mxc_spi refactoring (for mx6q)
This patch set refactors mxc_spi as described in http://lists.denx.de/pipermail/u-boot/2010-March/068791.html and requested in http://lists.denx.de/pipermail/u-boot/2012-January/116023.html in order to add support for the MX6Q in general and the mx6qsabrelite specifically. Patch 1 simply moves the conditional parts of mxc_spi.c into the respective CPU-specific imx-regs.h files. Patch 2 adds general support for SPI to the i.MX6. Patch 3 adds support to the mx6qsabrelite board Patch 4 modifies the 'sf' command to allow a default chip-select to be specified by board headers as is done on efika et al. This allows a bare 'sf' probe command: U-Boot> sf probe instead of the more cumbersome usage when a GPIO is tacked onto the chip-select. Otherwise, this command-line would be needed to specify GP3:19 on SabreLite: U-Boot> sf probe 0x5300 Patch 5 adds default chip-select values for mx6qsabrelite platform. Patch 6 adds reference macros for use in storing the environment in serial flash to match the use on Freescale's U-Boot release This patch set has been compiled against the following configurations, but only tested on mx6qsabrelite: mx6qsabrelite mx51evk mx31pdk mx35pdk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/6] mx6q: Add support for ECSPI through mxc_spi driver
Signed-off-by: Eric Nelson
---
arch/arm/include/asm/arch-mx6/imx-regs.h | 44 ++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 7650cb9..00040c4 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -190,6 +190,50 @@ struct src {
u32 gpr10;
};
+/* ECSPI registers */
+struct cspi_regs {
+ u32 rxdata;
+ u32 txdata;
+ u32 ctrl;
+ u32 cfg;
+ u32 intr;
+ u32 dma;
+ u32 stat;
+ u32 period;
+};
+
+/*
+ * CSPI register definitions
+ */
+#define MXC_ECSPI
+#define MXC_CSPICTRL_EN(1 << 0)
+#define MXC_CSPICTRL_MODE (1 << 1)
+#define MXC_CSPICTRL_XCH (1 << 2)
+#define MXC_CSPICTRL_CHIPSELECT(x) (((x) & 0x3) << 12)
+#define MXC_CSPICTRL_BITCOUNT(x) (((x) & 0xfff) << 20)
+#define MXC_CSPICTRL_PREDIV(x) (((x) & 0xF) << 12)
+#define MXC_CSPICTRL_POSTDIV(x)(((x) & 0xF) << 8)
+#define MXC_CSPICTRL_SELCHAN(x)(((x) & 0x3) << 18)
+#define MXC_CSPICTRL_MAXBITS 0xfff
+#define MXC_CSPICTRL_TC(1 << 7)
+#define MXC_CSPICTRL_RXOVF (1 << 6)
+#define MXC_CSPIPERIOD_32KHZ (1 << 15)
+#define MAX_SPI_BYTES 32
+
+/* Bit position inside CTRL register to be associated with SS */
+#define MXC_CSPICTRL_CHAN 18
+
+/* Bit position inside CON register to be associated with SS */
+#define MXC_CSPICON_POL4
+#define MXC_CSPICON_PHA0
+#define MXC_CSPICON_SSPOL 12
+#define MXC_SPI_BASE_ADDRESSES \
+ ECSPI1_BASE_ADDR, \
+ ECSPI2_BASE_ADDR, \
+ ECSPI3_BASE_ADDR, \
+ ECSPI4_BASE_ADDR, \
+ ECSPI5_BASE_ADDR
+
struct iim_regs {
u32 ctrl;
u32 ctrl_set;
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/6] mx6q: mx6qsabrelite: Add ECSPI support to the Sabrelite platform
Signed-off-by: Eric Nelson
---
board/freescale/mx6qsabrelite/imximage.cfg|2 +-
board/freescale/mx6qsabrelite/mx6qsabrelite.c | 25 +
include/configs/mx6qsabrelite.h |9 +
3 files changed, 35 insertions(+), 1 deletions(-)
diff --git a/board/freescale/mx6qsabrelite/imximage.cfg
b/board/freescale/mx6qsabrelite/imximage.cfg
index b4ff010..fa40bff 100644
--- a/board/freescale/mx6qsabrelite/imximage.cfg
+++ b/board/freescale/mx6qsabrelite/imximage.cfg
@@ -156,7 +156,7 @@ DATA 4 0x021b0404 0x00011006
# set the default clock gate to save power
DATA 4 0x020c4068 0x00C03F3F
-DATA 4 0x020c406c 0x0030FC00
+DATA 4 0x020c406c 0x0030FC03
DATA 4 0x020c4070 0x0FFFC000
DATA 4 0x020c4074 0x3FF0
DATA 4 0x020c4078 0x00FFF300
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index a0b648f..56c54d6 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -46,6 +46,10 @@ DECLARE_GLOBAL_DATA_PTR;
PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
+#define SPI_PAD_CTRL (PAD_CTL_HYS |\
+ PAD_CTL_PUS_100K_DOWN | PAD_CTL_SPEED_MED | \
+ PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
+
int dram_init(void)
{
gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
@@ -193,6 +197,23 @@ int board_mmc_init(bd_t *bis)
}
#endif
+#ifdef CONFIG_MXC_SPI
+iomux_v3_cfg_t ecspi1_pads[] = {
+ /* SS1 */
+ MX6Q_PAD_EIM_D19__GPIO_3_19 | MUX_PAD_CTRL(SPI_PAD_CTRL),
+ MX6Q_PAD_EIM_D17__ECSPI1_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL),
+ MX6Q_PAD_EIM_D18__ECSPI1_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL),
+ MX6Q_PAD_EIM_D16__ECSPI1_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL),
+};
+
+void setup_spi(void)
+{
+ gpio_direction_output(IMX_GPIO_NR(3, 19), 1);
+ imx_iomux_v3_setup_multiple_pads(ecspi1_pads,
+ARRAY_SIZE(ecspi1_pads));
+}
+#endif
+
#define MII_1000BASET_CTRL 0x9
#define MII_EXTENDED_CTRL 0xb
#define MII_EXTENDED_DATAW 0xc
@@ -250,6 +271,10 @@ int board_early_init_f(void)
{
setup_iomux_uart();
+#ifdef CONFIG_MXC_SPI
+ setup_spi();
+#endif
+
return 0;
}
diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h
index 034fc40..8dd6e39 100644
--- a/include/configs/mx6qsabrelite.h
+++ b/include/configs/mx6qsabrelite.h
@@ -44,6 +44,15 @@
#define CONFIG_MXC_UART
#define CONFIG_MXC_UART_BASE UART2_BASE
+#define CONFIG_CMD_SF
+#ifdef CONFIG_CMD_SF
+#define CONFIG_SPI_FLASH
+#define CONFIG_SPI_FLASH_SST
+#define CONFIG_MXC_SPI
+#define CONFIG_SF_DEFAULT_SPEED 2500
+#define CONFIG_SF_DEFAULT_MODE (SPI_MODE_0)
+#endif
+
/* MMC Configs */
#define CONFIG_FSL_ESDHC
#define CONFIG_FSL_USDHC
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/6] sf command: allow default chip select through CONFIG_SPI_FLASH_CS
Signed-off-by: Eric Nelson
---
common/cmd_sf.c | 34 +++---
1 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/common/cmd_sf.c b/common/cmd_sf.c
index 7225656..97fce16 100644
--- a/common/cmd_sf.c
+++ b/common/cmd_sf.c
@@ -70,20 +70,28 @@ static int do_spi_flash_probe(int argc, char * const argv[])
char *endp;
struct spi_flash *new;
- if (argc < 2)
- return -1;
-
- cs = simple_strtoul(argv[1], &endp, 0);
- if (*argv[1] == 0 || (*endp != 0 && *endp != ':'))
+#ifndef CONFIG_SPI_FLASH_CS
+ if (argc < 2) {
+ printf("%s: missing arguments\n", __func__);
return -1;
- if (*endp == ':') {
- if (endp[1] == 0)
- return -1;
+ }
+#else
+ cs = CONFIG_SPI_FLASH_CS ;
+#endif
- bus = cs;
- cs = simple_strtoul(endp + 1, &endp, 0);
- if (*endp != 0)
+ if (argc >= 2) {
+ cs = simple_strtoul(argv[1], &endp, 0);
+ if (*argv[1] == 0 || (*endp != 0 && *endp != ':'))
return -1;
+ if (*endp == ':') {
+ if (endp[1] == 0)
+ return -1;
+
+ bus = cs;
+ cs = simple_strtoul(endp + 1, &endp, 0);
+ if (*endp != 0)
+ return -1;
+ }
}
if (argc >= 3) {
@@ -299,7 +307,11 @@ usage:
U_BOOT_CMD(
sf, 5, 1, do_spi_flash,
"SPI flash sub-system",
+#ifndef CONFIG_SPI_FLASH_CS
"probe [bus:]cs [hz] [mode] - init flash device on given SPI bus\n"
+#else
+ "probe [[bus:]cs] [hz] [mode] - init flash device on given SPI bus\n"
+#endif
" and chip select\n"
"sf read addr offset len- read `len' bytes starting at\n"
" `offset' to memory at `addr'\n"
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/6] mxc_spi: move machine specifics into CPU headers
Move (E)CSPI register declarations into the imx-regs.h files for each supported
CPU
Introduce two new macros to control conditional setup
MXC_CSPI - Used for processors with the Configurable Serial Peripheral
Interface (MX3x)
MXC_ECSPI - For processors with Enhanced Configurable... (MX5x, MX6x)
Signed-off-by: Eric Nelson
---
arch/arm/include/asm/arch-mx31/imx-regs.h | 27
arch/arm/include/asm/arch-mx35/imx-regs.h | 25
arch/arm/include/asm/arch-mx5/imx-regs.h | 30 +
drivers/spi/mxc_spi.c | 93 ++---
4 files changed, 88 insertions(+), 87 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx31/imx-regs.h
b/arch/arm/include/asm/arch-mx31/imx-regs.h
index 6a517dd..70e3338 100644
--- a/arch/arm/include/asm/arch-mx31/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx31/imx-regs.h
@@ -890,4 +890,31 @@ struct esdc_regs {
#define MXC_EHCI_IPPUE_DOWN(1 << 8)
#define MXC_EHCI_IPPUE_UP (1 << 9)
+/*
+ * CSPI register definitions
+ */
+#define MXC_CSPI
+#define MXC_CSPICTRL_EN(1 << 0)
+#define MXC_CSPICTRL_MODE (1 << 1)
+#define MXC_CSPICTRL_XCH (1 << 2)
+#define MXC_CSPICTRL_SMC (1 << 3)
+#define MXC_CSPICTRL_POL (1 << 4)
+#define MXC_CSPICTRL_PHA (1 << 5)
+#define MXC_CSPICTRL_SSCTL (1 << 6)
+#define MXC_CSPICTRL_SSPOL (1 << 7)
+#define MXC_CSPICTRL_CHIPSELECT(x) (((x) & 0x3) << 24)
+#define MXC_CSPICTRL_BITCOUNT(x) (((x) & 0x1f) << 8)
+#define MXC_CSPICTRL_DATARATE(x) (((x) & 0x7) << 16)
+#define MXC_CSPICTRL_TC(1 << 8)
+#define MXC_CSPICTRL_RXOVF (1 << 6)
+#define MXC_CSPICTRL_MAXBITS 0x1f
+
+#define MXC_CSPIPERIOD_32KHZ (1 << 15)
+#define MAX_SPI_BYTES 4
+
+#define MXC_SPI_BASE_ADDRESSES \
+ 0x43fa4000, \
+ 0x5001, \
+ 0x53f84000,
+
#endif /* __ASM_ARCH_MX31_IMX_REGS_H */
diff --git a/arch/arm/include/asm/arch-mx35/imx-regs.h
b/arch/arm/include/asm/arch-mx35/imx-regs.h
index df74508..e570ad1 100644
--- a/arch/arm/include/asm/arch-mx35/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx35/imx-regs.h
@@ -179,6 +179,31 @@
#define IPU_CONF_IC_EN (1<<1)
#define IPU_CONF_SCI_EN(1<<0)
+/*
+ * CSPI register definitions
+ */
+#define MXC_CSPI
+#define MXC_CSPICTRL_EN(1 << 0)
+#define MXC_CSPICTRL_MODE (1 << 1)
+#define MXC_CSPICTRL_XCH (1 << 2)
+#define MXC_CSPICTRL_SMC (1 << 3)
+#define MXC_CSPICTRL_POL (1 << 4)
+#define MXC_CSPICTRL_PHA (1 << 5)
+#define MXC_CSPICTRL_SSCTL (1 << 6)
+#define MXC_CSPICTRL_SSPOL (1 << 7)
+#define MXC_CSPICTRL_CHIPSELECT(x) (((x) & 0x3) << 12)
+#define MXC_CSPICTRL_BITCOUNT(x) (((x) & 0xfff) << 20)
+#define MXC_CSPICTRL_DATARATE(x) (((x) & 0x7) << 16)
+#define MXC_CSPICTRL_TC(1 << 7)
+#define MXC_CSPICTRL_RXOVF (1 << 6)
+#define MXC_CSPICTRL_MAXBITS 0xfff
+#define MXC_CSPIPERIOD_32KHZ (1 << 15)
+#define MAX_SPI_BYTES 4
+
+#define MXC_SPI_BASE_ADDRESSES \
+ 0x43fa4000, \
+ 0x5001,
+
#define GPIO_PORT_NUM 3
#define GPIO_NUM_PIN 32
diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h
b/arch/arm/include/asm/arch-mx5/imx-regs.h
index 0ee88d2..4fa6658 100644
--- a/arch/arm/include/asm/arch-mx5/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
@@ -223,6 +223,36 @@
#define CS0_32M_CS1_32M_CS2_32M_CS3_32M3
/*
+ * CSPI register definitions
+ */
+#define MXC_ECSPI
+#define MXC_CSPICTRL_EN(1 << 0)
+#define MXC_CSPICTRL_MODE (1 << 1)
+#define MXC_CSPICTRL_XCH (1 << 2)
+#define MXC_CSPICTRL_CHIPSELECT(x) (((x) & 0x3) << 12)
+#define MXC_CSPICTRL_BITCOUNT(x) (((x) & 0xfff) << 20)
+#define MXC_CSPICTRL_PREDIV(x) (((x) & 0xF) << 12)
+#define MXC_CSPICTRL_POSTDIV(x)(((x) & 0xF) << 8)
+#define MXC_CSPICTRL_SELCHAN(x)(((x) & 0x3) << 18)
+#define MXC_CSPICTRL_MAXBITS 0xfff
+#define MXC_CSPICTRL_TC(1 << 7)
+#define MXC_CSPICTRL_RXOVF (1 << 6)
+#define MXC_CSPIPERIOD_32KHZ (1 << 15)
+#define MAX_SPI_BYTES 32
+
+/* Bit position inside CTRL register to be associated with SS */
+#define MXC_CSPICTRL_CHAN 18
+
+/* Bit position inside CON register to be associated with SS */
+#define MXC_CSPICON_POL4
+#define MXC_CSPICON_PHA0
+#define MXC_CSPICON_SSPOL 12
+#define MXC_SPI_BASE_ADDRESSES \
+ CSPI1_BASE_ADDR, \
+ CSPI2_BASE_ADDR, \
+ CSPI3_BASE_ADDR,
+
+/*
* Number of GPIO pins per port
*/
#define GPIO_NUM_PIN32
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 2fa7486..2e15318 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -33,93 +33,12 @@
#error "i.MX27 CSPI not supported due to drastic differences in register
definitions" \
"See linux mxc_spi driver from Freescale for details."
-
-#elif defined(CONFIG_MX31)
-
-
Re: [U-Boot] Pull request: u-boot-arm/master
Dear Albert ARIBAUD, In message <4f13dcef.1070...@aribaud.net> you wrote: > Hi Wolfgang, > > The following changes since commit f1f441afc41083e54775e6efe21b2c059e80b8f7: > >openrisc: Add MAINTAINERS entry (2012-01-13 21:17:08 +0100) > > are available in the git repository at: >git://git.denx.de/u-boot-arm.git master > > Andreas M�ller (7): >drivers/i2c/omap24xx_i2c.c: replace printf with one argument by puts >board/overo/overo.c: replace printf with one argument by puts >include/configs/omap3_overo.h: several cleanups >drivers/i2c/omap24xx_i2c.c: move all local variables to SRAM >OMAP SPL: call timer_init in s_init to make udelay work earlier >omap_rev_string: output to stdout >overo: add SPL support > > Aneesh V (1): >omap4: fix boot issue on ES2.0 Panda > > Chandan Nath (5): >ARM:AM33XX: Replace CONFIG_AM335X with CONFIG_AM33XX >ARM:AM33XX: Fix ddr and timer register offset >ARM:AM33XX: Fixing AM335X config parameters >ARM:AM33XX: Add mmc/sd support >ARM:AM33XX: Add SPL support for AM335X EVM > > Christian Riesch (3): >arm, davinci: Use a common configuration file for da850evm and > da850_am18xxevm >da850evm: Remove CONFIG_SYS_xxCACHE_OFF defines >arm, davinci: Change byte order of RTC kick register values > > Eric Nelson (1): >i.mx6q: mx6qarm2: Enable the usboh3 clock > > Fabio Estevam (7): >net: imx: Add multi-FEC support for imx_get_mac_from_fuse >mx28: Let imx_get_mac_from_fuse be common for mx28 >mx28: Let dram_init be common for mx28 >mx28evk: Add initial support for MX28EVK board >mx28evk: Remove 'all' target from Makefile >m28evk: Use GENERATED_GBL_DATA_SIZE >m28evk: Remove 'all' target from Makefile > > Jason Liu (6): >i.mx: i.mx6q: Add the enet clock function >fec: add the i.mx6q enet driver support >i.mx6q: arm2: Add the enet function support >i.mx6:imx6q: allign MAC address with burned-in ordering >imx: mx6q: add aipstz init for off platform periph >i.mx: i.mx6q: add the initial support for i.mx6q Sabre Lite board > > Marek Vasut (2): >MX28: Fix MXSBOOT segfault if no params specified >M28EVK: Fix build if CONFIG_CMD_NAND not selected > > Nikita Kiryanov (6): >cm-t35: cleanup the config file >cm-t35: various cleanups >cm-t35: add EEPROM module and pass Linux a serial number >omap3: make get_board_rev() function weak >cm-t35: pass correct revision information to Linux >cm-t35: use the new EEPROM module to read the MAC address > > Peter Barada (1): >ARMV7: Add support For Logic OMAP35x/DM37x modules > > Peter Meerwald (1): >beagle: add eeprom expansion board info for bct brettl3 > > Thomas Weber (1): >OMAP3: Remove unused define CONFIG_OMAP3_*_DDR > > Veli-Pekka Peltola (1): >mx28: remove omap specific config options > > Zach Sadecki (1): >mx28: fix clearing of IRQs in power init > > MAINTAINERS|6 + > Makefile |2 +- > arch/arm/cpu/arm1136/mx35/generic.c|2 +- > arch/arm/cpu/arm926ejs/mx25/generic.c |2 +- > arch/arm/cpu/arm926ejs/mx27/generic.c |2 +- > arch/arm/cpu/arm926ejs/mx28/mx28.c | 67 > arch/arm/cpu/arm926ejs/mx28/spl_power_init.c |8 +- > arch/arm/cpu/arm926ejs/mx28/start.S|6 - > arch/arm/cpu/armv7/am33xx/Makefile |2 - > arch/arm/cpu/armv7/am33xx/board.c | 66 - > arch/arm/cpu/armv7/am33xx/clock.c |8 + > arch/arm/cpu/armv7/am33xx/config.mk| 18 + > arch/arm/cpu/armv7/am33xx/emif4.c |2 +- > arch/arm/cpu/armv7/am33xx/lowlevel_init.S | 72 > arch/arm/cpu/armv7/mx6/clock.c |5 + > arch/arm/cpu/armv7/mx6/soc.c | 45 ++- > arch/arm/cpu/armv7/omap-common/Makefile|4 + > arch/arm/cpu/armv7/omap-common/boot-common.c | 49 +++ > arch/arm/cpu/armv7/omap-common/hwinit-common.c | 38 +-- > arch/arm/cpu/armv7/omap-common/spl.c | 14 +- > arch/arm/cpu/armv7/omap3/board.c |2 + > arch/arm/cpu/armv7/omap3/sys_info.c|3 +- > arch/arm/cpu/armv7/omap4/hwinit.c |4 +- > .../arm/include/asm/arch-am33xx}/common_def.h |4 +- > arch/arm/include/asm/arch-am33xx/cpu.h | 44 ++-- > arch/arm/include/asm/arch-am33xx/ddr_defs.h|6 +- > arch/arm/include/asm/arch-am33xx/mmc_host_def.h| 164 + > arch/arm/include/asm/arch-am33xx/omap.h| 59 > arch/arm/include/asm/arch-am33xx/sys_proto.h
Re: [U-Boot] [PATCH 1/5] net: ll_temac: Add LL TEMAC driver to u-boot
Am Sonntag, den 15.01.2012, 13:47 -0500 schrieb Mike Frysinger: > On Sunday 15 January 2012 13:29:26 Stephan Linz wrote: > > Am Sonntag, den 15.01.2012, 12:28 -0500 schrieb Mike Frysinger: > > > On Sunday 15 January 2012 10:46:02 Stephan Linz wrote: > > > > +/* Data buffer for LL TEMAC Rx and Tx direction */ > > > > +static unsigned char rx_buffer[PKTSIZE_ALIGN] > > > > __attribute((aligned(DMAALIGN))); > > > > +static unsigned char tx_buffer[PKTSIZE_ALIGN] > > > > __attribute((aligned(DMAALIGN))); > > > > > > come code already declares PktBuf ... can't you use that ? > > > > Hm, what do you mean exactly here? > > > > These are the two DMA transfer buffers. I have no idea if there are > > buffers in the upper layer (NET) and how I can use it for DMA transfers. > > Therfore I create my own rx/tx buffers and copy data. That reduce the > > performance a little bit, but it's OK. Furthermore I have to use DMA > > safe buffers here (no cache, 32 byte alignment). > > from doc/README.drivers.eth: > The recv function should process packets as long as the hardware has them > readily available before returning. i.e. you should drain the hardware fifo. > For each packet you receive, you should call the NetReceive() function on it > along with the packet length. The common code sets up packet buffers for you > already in the .bss (NetRxPackets), so there should be no need to allocate > your own. > > so you already have an array of packet buffers declared for you. the first > one > is &NetRxPackets[0], etc... since you're just DMA-ing to random external > memory, i don't think the address matters. Hello Mike and all others, is there already a simple ETH driver that use these kind of buffer handling? Up to now I've learned from the Freescale TSEC driver, especially the MDIO bus implementation. It seems this driver implement this packet buffer, or not? > > the core code atm however doesn't align things at all, so we'll have to fix > that before this driver could use it. Is the TSEC driver DMA alignment safe (especially the DMA buffer data, not the DMA buffer descriptor)? What do I need to make the internal array of packet buffer DMA secure (cache, alignment)? -- Best regards, Stephan Linz __ MB-Ref: http://www.li-pro.de/xilinx_mb:mbref:start OpenDCC: http://www.li-pro.net/opendcc.phtml PC/M: http://www.li-pro.net/pcm.phtml Sourceforge: http://sourceforge.net/users/slz Gitorious: https://gitorious.org/~slz ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] bootm: Avoid 256-byte overflow in fixup_silent_linux()
Acked-by: Mike Frysinger -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 v4] bootm: Avoid 256-byte overflow in fixup_silent_linux()
This makes fixup_silent_linux() use malloc() to allocate its
working space, meaning that our maximum kernel command line
should only be limited by malloc(). Previously it was silently
overflowing the stack.
Note that nothing about this change increases the kernel's maximum
command line length. If you have a command line that is >256
bytes it's up to you to make sure that kernel can handle it.
Signed-off-by: Doug Anderson
---
Changes in v2:
- Tried to trim down to just the minimum changes needed with
no extra helper code.
Changes in v3:
- Took Mike Frysinger's suggestion of removing strdup()
Changes in v4:
- Added in const
common/cmd_bootm.c | 41 +
1 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index d5745b1..0a5ac81 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -1229,9 +1229,14 @@ U_BOOT_CMD(
/* helper routines */
/***/
#ifdef CONFIG_SILENT_CONSOLE
+
+#define CONSOLE_ARG "console="
+#define CONSOLE_ARG_LEN (sizeof(CONSOLE_ARG) - 1)
+
static void fixup_silent_linux(void)
{
- char buf[256], *start, *end;
+ char *buf;
+ const char *env_val;
char *cmdline = getenv("bootargs");
/* Only fix cmdline when requested */
@@ -1239,25 +1244,37 @@ static void fixup_silent_linux(void)
return;
debug("before silent fix-up: %s\n", cmdline);
- if (cmdline) {
- start = strstr(cmdline, "console=");
+ if (cmdline && (cmdline[0] != '\0')) {
+ char *start = strstr(cmdline, CONSOLE_ARG);
+
+ /* Allocate space for maximum possible new command line */
+ buf = malloc(strlen(cmdline) + 1 + CONSOLE_ARG_LEN + 1);
+ if (!buf) {
+ debug("%s: out of memory\n", __func__);
+ return;
+ }
+
if (start) {
- end = strchr(start, ' ');
- strncpy(buf, cmdline, (start - cmdline + 8));
+ char *end = strchr(start, ' ');
+ int num_start_bytes = start - cmdline + CONSOLE_ARG_LEN;
+
+ strncpy(buf, cmdline, num_start_bytes);
if (end)
- strcpy(buf + (start - cmdline + 8), end);
+ strcpy(buf + num_start_bytes, end);
else
- buf[start - cmdline + 8] = '\0';
+ buf[num_start_bytes] = '\0';
} else {
- strcpy(buf, cmdline);
- strcat(buf, " console=");
+ sprintf(buf, "%s %s", cmdline, CONSOLE_ARG);
}
+ env_val = buf;
} else {
- strcpy(buf, "console=");
+ buf = NULL;
+ env_val = CONSOLE_ARG;
}
- setenv("bootargs", buf);
- debug("after silent fix-up: %s\n", buf);
+ setenv("bootargs", env_val);
+ debug("after silent fix-up: %s\n", env_val);
+ free(buf);
}
#endif /* CONFIG_SILENT_CONSOLE */
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx28: fix i.MX28 spi driver
On 1/16/12, Alexander Keller wrote: > I just want to confirm and thanks to Matthias for this patch. I already > stated my problems by writing the SPI flash ... > > So, I use the IMX28EVK with a Winbond W25Q64CV SPI flash chip and it's > working great now. > > Thanks for the great work. Ok, great. Can you or Matthias post a patch adding SPI flash support to mx28evk? I have just soldered one SPI flash on my board and would be glad to try it. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] bootm: Avoid 256-byte overflow in fixup_silent_linux()
Mike, On Tue, Jan 17, 2012 at 11:27 AM, Mike Frysinger wrote: > On Tuesday 17 January 2012 14:16:53 Doug Anderson wrote: >> --- a/common/cmd_bootm.c >> +++ b/common/cmd_bootm.c >> >> + char *env_val; > > did marking this const not work out ? I coded the patch an old "-v2011.06" branch then tested on ToT. On "-v2011.06" setenv wasn't const. I'll resubmit with the "const". Thanks! -Doug ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] bootm: Avoid 256-byte overflow in fixup_silent_linux()
On Tuesday 17 January 2012 14:16:53 Doug Anderson wrote: > --- a/common/cmd_bootm.c > +++ b/common/cmd_bootm.c > > + char *env_val; did marking this const not work out ? otherwise, seems to look OK ... -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 1/3] i2c: add i2c_core and prepare for new multibus support
On Tuesday 17 January 2012 02:12:23 Simon Glass wrote: > +#if defined(CONFIG_SYS_I2C) > + void*cur_adap; /* current used i2c adapter */ > +#endif let's have "i2c" in the variable name somewhere. "curr_i2c" ? > --- /dev/null > +++ b/drivers/i2c/i2c_core.c > > +#ifdef CONFIG_TEGRA2_I2C > +extern struct i2c_adapter tegra_i2c_adap[]; > +#endif i feel like if your initial run includes i2c bus specific defines, the end result is a failure > +struct i2c_adapter *i2c_adap[CONFIG_SYS_NUM_I2C_ADAPTERS] = > + CONFIG_SYS_I2C_ADAPTERS; > +#ifndef CONFIG_SYS_I2C_DIRECT_BUS > +struct i2c_bus i2c_bus[CONFIG_SYS_NUM_I2C_BUSSES] = > CONFIG_SYS_I2C_BUSSES; > +#endif the nand layer is moving away from this style ... > + * mux_id is the multiplexer chip type from defined in i2c.h. So far only > + * NXP (Philips) PCA954x multiplexers are supported. Switches are NOT > + * supported (anybody uses them?) does part-specific stuff belong in the core ? seems like it should be in a part-specific driver ... > +int i2c_probe(u_int8_t chip) use uintx_t types. the u_intx_t types are deprecated. -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 v3] bootm: Avoid 256-byte overflow in fixup_silent_linux()
This makes fixup_silent_linux() use malloc() to allocate its
working space, meaning that our maximum kernel command line
should only be limited by malloc(). Previously it was silently
overflowing the stack.
Note that nothing about this change increases the kernel's maximum
command line length. If you have a command line that is >256
bytes it's up to you to make sure that kernel can handle it.
Signed-off-by: Doug Anderson
---
Changes in v2:
- Tried to trim down to just the minimum changes needed with
no extra helper code.
Changes in v3:
- Took Mike Frysinger's suggestion of removing strdup()
common/cmd_bootm.c | 41 +
1 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index d5745b1..95ac2d9 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -1229,9 +1229,14 @@ U_BOOT_CMD(
/* helper routines */
/***/
#ifdef CONFIG_SILENT_CONSOLE
+
+#define CONSOLE_ARG "console="
+#define CONSOLE_ARG_LEN (sizeof(CONSOLE_ARG) - 1)
+
static void fixup_silent_linux(void)
{
- char buf[256], *start, *end;
+ char *buf;
+ char *env_val;
char *cmdline = getenv("bootargs");
/* Only fix cmdline when requested */
@@ -1239,25 +1244,37 @@ static void fixup_silent_linux(void)
return;
debug("before silent fix-up: %s\n", cmdline);
- if (cmdline) {
- start = strstr(cmdline, "console=");
+ if (cmdline && (cmdline[0] != '\0')) {
+ char *start = strstr(cmdline, CONSOLE_ARG);
+
+ /* Allocate space for maximum possible new command line */
+ buf = malloc(strlen(cmdline) + 1 + CONSOLE_ARG_LEN + 1);
+ if (!buf) {
+ debug("%s: out of memory\n", __func__);
+ return;
+ }
+
if (start) {
- end = strchr(start, ' ');
- strncpy(buf, cmdline, (start - cmdline + 8));
+ char *end = strchr(start, ' ');
+ int num_start_bytes = start - cmdline + CONSOLE_ARG_LEN;
+
+ strncpy(buf, cmdline, num_start_bytes);
if (end)
- strcpy(buf + (start - cmdline + 8), end);
+ strcpy(buf + num_start_bytes, end);
else
- buf[start - cmdline + 8] = '\0';
+ buf[num_start_bytes] = '\0';
} else {
- strcpy(buf, cmdline);
- strcat(buf, " console=");
+ sprintf(buf, "%s %s", cmdline, CONSOLE_ARG);
}
+ env_val = buf;
} else {
- strcpy(buf, "console=");
+ buf = NULL;
+ env_val = CONSOLE_ARG;
}
- setenv("bootargs", buf);
- debug("after silent fix-up: %s\n", buf);
+ setenv("bootargs", env_val);
+ debug("after silent fix-up: %s\n", env_val);
+ free(buf);
}
#endif /* CONFIG_SILENT_CONSOLE */
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common, menu: do not trigger timeout again, if a line is read
On Tuesday 17 January 2012 03:24:29 Heiko Schocher wrote:
> --- a/common/menu.c
> +++ b/common/menu.c
> choice_item = menu_item_by_key(m, cbuf);
>
> - if (!choice_item)
> + if (!choice_item) {
> printf("%s not found\n", cbuf);
> + m->timeout = 0;
> + }
> } else {
> puts("^C\n");
> return -EINTR;
the summary says "do not timeout again if a line is read", but this C code
seems like "do not timeout again if an item was selected but not found". but
maybe i'm reading the menu code incorrectly ?
-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 2/3 v2] common, menu: add statusline support
Acked-by: Mike Frysinger -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 1/3 v2] common: add possibility for readline_into_buffer timeout
Acked-by: Mike Frysinger -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 v3 2/2] fdt: Add tests for fdtdec
The fdtdec_find_aliases_for_id() function is complicated enough that
it really should have some tests. This does not necessarily need to be
committed to U-Boot, but it might be useful.
(note there are a few minor inconsistencies with this patch which will be
cleaned up when the USB series is applied)
Signed-off-by: Simon Glass
---
Changes in v2:
- Add test_fdtdec command to test fdtdec_find_aliases_for_id()
Changes in v3:
- Change fdtdec-test.c to fdtdec_test.c to fit better with U-Boot conventions
- Remove varargs declaration (hang-over from previous implementation)
- Use COMPAT_UNKNOWN instead of COMPAT_NVIDIA_TEGRA20_I2C for test
lib/Makefile |1 +
lib/fdtdec_test.c | 226 +
2 files changed, 227 insertions(+), 0 deletions(-)
create mode 100644 lib/fdtdec_test.c
diff --git a/lib/Makefile b/lib/Makefile
index 35ba7ff..b938549 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -39,6 +39,7 @@ COBJS-y += crc32.o
COBJS-y += display_options.o
COBJS-y += errno.o
COBJS-$(CONFIG_OF_CONTROL) += fdtdec.o
+COBJS-$(CONFIG_TEST_FDTDEC) += fdtdec_test.o
COBJS-$(CONFIG_GZIP) += gunzip.o
COBJS-y += hashtable.o
COBJS-$(CONFIG_LMB) += lmb.o
diff --git a/lib/fdtdec_test.c b/lib/fdtdec_test.c
new file mode 100644
index 000..497be8e
--- /dev/null
+++ b/lib/fdtdec_test.c
@@ -0,0 +1,226 @@
+/*
+ * Some very basic tests for fdtdec, accessed through test_fdtdec command.
+ * They are easiest to use with sandbox.
+ *
+ * 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
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/* The size of our test fdt blob */
+#define FDT_SIZE (16 * 1024)
+
+/**
+ * Check if an operation failed, and if so, print an error
+ *
+ * @param oper_nameName of operation
+ * @param err Error code to check
+ *
+ * @return 0 if ok, -1 if there was an error
+ */
+static int fdt_checkerr(const char *oper_name, int err)
+{
+ if (err) {
+ printf("%s: %s: %s\n", __func__, oper_name, fdt_strerror(err));
+ return -1;
+ }
+
+ return 0;
+}
+
+/**
+ * Check the result of an operation and if incorrect, print an error
+ *
+ * @param oper_nameName of operation
+ * @param expected Expected value
+ * @param valueActual value
+ *
+ * @return 0 if ok, -1 if there was an error
+ */
+static int checkval(const char *oper_name, int expected, int value)
+{
+ if (expected != value) {
+ printf("%s: %s: expected %d, but returned %d\n", __func__,
+ oper_name, expected, value);
+ return -1;
+ }
+
+ return 0;
+}
+
+#define CHECK(op) if (fdt_checkerr(#op, op)) return -1
+#define CHECKVAL(op, expected) \
+ if (checkval(#op, expected, op)) \
+ return -1
+#define CHECKOK(op)CHECKVAL(op, 0)
+
+/* maximum number of nodes / aliases to generate */
+#define MAX_NODES 20
+
+/*
+ * Make a test fdt
+ *
+ * @param fdt Device tree pointer
+ * @param size Size of device tree blob
+ * @param aliases Specifies alias assignments. Format is a list of items
+ * separated by space. Items are #a where
+ * # is the alias number
+ * a is the node to point to
+ * @param nodesSpecifies nodes to generate (a=0, b=1), upper
case
+ * means to create a disabled node
+ */
+static int make_fdt(void *fdt, int size, const char *aliases,
+ const char *nodes)
+{
+ char name[20], value[20];
+ const char *s;
+ int fd;
+
+ CHECK(fdt_create(fdt, size));
+ CHECK(fdt_finish_reservemap(fdt));
+ CHECK(fdt_begin_node(fdt, ""));
+
+ CHECK(fdt_begin_node(fdt, "aliases"));
+ for (s = aliases; *s;) {
+ sprintf(name, "i2c%c", *s);
+ sprintf(value, "/i2c%d@0", s[1] - 'a');
+ CHECK(fdt_property_string(fdt, name, value));
+ s += 2 + (s[2] != '\0');
+ }
+ CHECK(fdt_end_node(fdt));
+
+ for (s = nodes; *s; s++) {
+ sprintf(value, "i2c%d@0", (*s & 0xd
[U-Boot] [PATCH v3 1/2] fdt: Add fdtdec_find_aliases() to deal with alias nodes
Stephen Warren pointed out that we should use nodes whether or not they
have an alias in the /aliases section. The aliases section specifies the
order so far as it can, but is not essential. Operating without alisses
is useful when the enumerated order of nodes does not matter (admittedly
rare in U-Boot).
This is considerably more complex, and it is important to keep this
complexity out of driver code. This patch creates a function
fdtdec_find_aliases() which returns an ordered list of node offsets
for a particular compatible ID, taking account of alias nodes.
Signed-off-by: Simon Glass
---
Changes in v2:
- Allow gaps in the list returned to the caller
- Improve alias checking algorithm to reduce run time
- Rename function to fdtdec_find_aliases_for_id()
- Skip nodes marked as disabled
Changes in v3:
- Change 'continue' to 'break' in last loop, since we are done anyway
- Fix typos and add two assert() checks
include/fdtdec.h | 47 ++
lib/fdtdec.c | 116 ++
2 files changed, 163 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index d871cdd..492431c 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -126,3 +126,50 @@ int fdtdec_get_is_enabled(const void *blob, int node, int
default_val);
* if not.
*/
int fdtdec_check_fdt(void);
+
+/**
+ * Find the nodes for a peripheral and return a list of them in the correct
+ * order. This is used to enumerate all the peripherals of a certain type.
+ *
+ * To use this, optionally set up a /aliases node with alias properties for
+ * a peripheral. For example, for usb you could have:
+ *
+ * aliases {
+ * usb0 = "/ehci@c5008000";
+ * usb1 = "/ehci@c500";
+ * };
+ *
+ * Pass "usb" as the name to this function and will return a list of two
+ * nodes offsets: /ehci@c5008000 and ehci@c500.
+ *
+ * All nodes returned will match the compatible ID, as it is assumed that
+ * all peripherals use the same driver.
+ *
+ * If no alias node is found, then the node list will be returned in the
+ * order found in the fdt. If the aliases mention a node which doesn't
+ * exist, then this will be ignored. If nodes are found with no aliases,
+ * they will be added in any order.
+ *
+ * If there is a gap in the aliases, then this function return a 0 node at
+ * that position. The return value will also count these gaps.
+ *
+ * This function checks node properties and will not return nodes which are
+ * marked disabled (status = "disabled").
+ *
+ * @param blob FDT blob to use
+ * @param name Root name of alias to search for
+ * @param id Compatible ID to look for
+ * @param node_listPlace to put list of found nodes
+ * @param maxcount Maximum number of nodes to find
+ * @return number of nodes found on success, FTD_ERR_... on error
+ */
+int fdtdec_find_aliases_for_id(const void *blob, const char *name,
+ enum fdt_compat_id id, int *node_list, int maxcount);
+
+/*
+ * Get the name for a compatible ID
+ *
+ * @param id Compatible ID to look for
+ * @return compatible string for that id
+ */
+const char *fdtdec_get_compatible(enum fdt_compat_id id);
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 0f87163..55d5bdf 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -35,6 +35,13 @@ DECLARE_GLOBAL_DATA_PTR;
static const char * const compat_names[COMPAT_COUNT] = {
};
+const char *fdtdec_get_compatible(enum fdt_compat_id id)
+{
+ /* We allow reading of the 'unknown' ID for testing purposes */
+ assert(id >= 0 && id < COMPAT_COUNT);
+ return compat_names[id];
+}
+
/**
* Look in the FDT for an alias with the given name and return its node.
*
@@ -132,6 +139,115 @@ int fdtdec_next_alias(const void *blob, const char *name,
return err ? -FDT_ERR_NOTFOUND : node;
}
+/* TODO: Can we tighten this code up a little? */
+int fdtdec_find_aliases_for_id(const void *blob, const char *name,
+ enum fdt_compat_id id, int *node_list, int maxcount)
+{
+ int name_len = strlen(name);
+ int nodes[maxcount];
+ int num_found = 0;
+ int offset, node;
+ int alias_node;
+ int count;
+ int i, j;
+
+ /* find the alias node if present */
+ alias_node = fdt_path_offset(blob, "/aliases");
+
+ /*
+* start with nothing, and we can assume that the root node can't
+* match
+*/
+ memset(nodes, '\0', sizeof(nodes));
+
+ /* First find all the compatible nodes */
+ for (node = count = 0; node >= 0 && count < maxcount;) {
+ node = fdtdec_next_compatible(blob, node, id);
+ if (node >= 0)
+ nodes[count++] = node;
+ }
+ if (node >= 0)
+ debug("%s: warning: maxcount exceeded with alias '%s'\n",
+ __func__, name);
+
+ /* Now find all the aliases */
+ memset(node_l
[U-Boot] [PATCH v3 0/2] fdt: Deal correctly with alias nodes
This series proposes a new way to deal with alias nodes and introduces a function to take care of it. Drivers can now request an ordered list of compatible nodes in a single step. This simplifies node discovery for drivers (and keeps this nasty code in a common place). If DEBUG is defined the alias function will print messages in the event of a warning/error. Changes in v2: - Add test_fdtdec command to test fdtdec_find_aliases_for_id() - Allow gaps in the list returned to the caller - Improve alias checking algorithm to reduce run time - Rename function to fdtdec_find_aliases_for_id() - Skip nodes marked as disabled Changes in v3: - Change 'continue' to 'break' in last loop, since we are done anyway - Change fdtdec-test.c to fdtdec_test.c to fit better with U-Boot conventions - Fix typos and add two assert() checks - Remove varargs declaration (hang-over from previous implementation) - Use COMPAT_UNKNOWN instead of COMPAT_NVIDIA_TEGRA20_I2C for test Simon Glass (2): fdt: Add fdtdec_find_aliases() to deal with alias nodes fdt: Add tests for fdtdec include/fdtdec.h | 47 +++ lib/Makefile |1 + lib/fdtdec.c | 116 +++ lib/fdtdec_test.c | 226 + 4 files changed, 390 insertions(+), 0 deletions(-) create mode 100644 lib/fdtdec_test.c -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] fdt: Add fdtdec_find_aliases() to deal with alias nodes
Hi Stephen,
On Fri, Jan 13, 2012 at 1:41 PM, Stephen Warren wrote:
> On 01/11/2012 04:08 PM, Simon Glass wrote:
>> Stephen Warren pointed out that we should use nodes whether or not they
>> have an alias in the /aliases section. The aliases section specifies the
>> order so far as it can, but is not essential. Operating without alisses
>> is useful when the enumerated order of nodes does not matter (admittedly
>> rare in U-Boot).
>>
>> This is considerably more complex, and it is important to keep this
>> complexity out of driver code. This patch creates a function
>> fdtdec_find_aliases() which returns an ordered list of node offsets
>> for a particular compatible ID, taking account of alias nodes.
>
> Overall, this looks basically OK. Just a few minor comments below, but
> once those are fixed,
>
> Acked-by: Stephen Warren
>
>> diff --git a/include/fdtdec.h b/include/fdtdec.h
>
>> +/**
>> + * Find the nodes for a peripheral and return a list of them in the correct
> ...
>> + * This function checks node properties and will not return node which are
>
> s/node/nodes/
>
>> + * marked disabled (status = "disabled").
>> + *
>> + * @param blob FDT blob to use
>> + * @param name Root name of alias to search for
>> + * @param id Compatible ID to look for
>> + * @param node Place to put list of found nodes
>
> s/node/node_list/
>
>> + * @param maxcount Maximum number of nodes to find
>> + * @return number of nodes found on success, FTD_ERR_... on error
>> + */
>> +int fdtdec_find_aliases_for_id(const void *blob, const char *name,
>> + enum fdt_compat_id id, int *node_list, int maxcount);
>> +
>
>> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
>
>> @@ -35,6 +35,11 @@ DECLARE_GLOBAL_DATA_PTR;
>> static const char * const compat_names[COMPAT_COUNT] = {
>> };
>>
>> +const char *fdtdec_get_compatible(enum fdt_compat_id id)
>> +{
>> + return compat_names[id];
>
> Range-check?
These and other changes made - but see one comment below.
>
>> +/* TODO: Can we tighten this code up a little? */
>> +int fdtdec_find_aliases_for_id(const void *blob, const char *name,
>> + enum fdt_compat_id id, int *node_list, int maxcount)
>> +{
>> + int name_len = strlen(name);
>> + int nodes[maxcount];
>> + int num_found = 0;
>> + int offset, node;
>> + int alias_node;
>> + int count;
>> + int i, j;
>> +
>> + /* find the alias node if present */
>> + alias_node = fdt_path_offset(blob, "/aliases");
>> +
>> + /*
>> + * start with nothing, and we can assume that the root node can't
>> + * match
>> + */
>> + memset(nodes, '\0', sizeof(nodes));
>> +
>> + /* First find all the compatible nodes */
>> + node = 0;
>> + for (node = count = 0; node >= 0 && count < maxcount;) {
>
> node = 0 is duplicated on those two lines.
>
>> + node = fdtdec_next_compatible(blob, node, id);
>> + if (node >= 0)
>> + nodes[count++] = node;
>> + }
>> + if (node >= 0)
>> + debug("%s: warning: maxcount exceeded with alias '%s'\n",
>> + __func__, name);
>> +
>> + /* Now find all the aliases */
>> + memset(node_list, '\0', sizeof(*node_list) * maxcount);
>> +
>> + for (offset = fdt_first_property_offset(blob, alias_node);
>> + offset > 0;
>> + offset = fdt_next_property_offset(blob, offset)) {
>> + const struct fdt_property *prop;
>> + const char *path;
>> + int number;
>> + int found;
>> +
>> + node = 0;
>> + prop = fdt_get_property_by_offset(blob, offset, NULL);
>> + path = fdt_string(blob, fdt32_to_cpu(prop->nameoff));
>> + if (prop->len && 0 == strncmp(path, name, name_len))
>> + node = fdt_path_offset(blob, prop->data);
>> + if (node <= 0)
>> + continue;
>> +
>> + /* Get the alias number */
>> + number = simple_strtoul(path + name_len, NULL, 10);
>> + if (number < 0 || number >= maxcount) {
>> + debug("%s: warning: alias '%s' is out of range\n",
>> + __func__, path);
>> + continue;
>> + }
>> +
>> + /* Make sure the node we found is actually in our list! */
>> + found = -1;
>> + for (j = 0; j < count; j++)
>> + if (nodes[j] == node) {
>> + found = j;
>> + break;
>> + }
>> +
>> + if (found == -1) {
>> + debug("%s: warning: alias '%s' points to a node "
>> + "'%s' that is missing or is not compatible "
>> + " with '%s'\n", __func__, path,
>> + fdt_get_name(blob, node, NULL)
Re: [U-Boot] [PATCH v2 2/2] fdt: Add tests for fdtdec
Hi Stephen, On Fri, Jan 13, 2012 at 1:49 PM, Stephen Warren wrote: > On 01/11/2012 04:08 PM, Simon Glass wrote: >> The fdtdec_find_aliases_for_id() function is complicated enough that >> it really should have some tests. This does not necessarily need to be >> committed to U-Boot, but it might be useful. >> >> Signed-off-by: Simon Glass > >> +static int run_test(const char *aliases, const char *nodes, const char >> *expect) > ... >> + va_list ptr; > ... >> + va_end(ptr); > > ptr doesn't seem to be used, and this isn't a varargs function. Yes, it's a hangover from my previous non-string implementation. I will send a new series as there are a couple of changes. Regards, Simon > > Otherwise, > > Acked-by: Stephen Warren > > -- > nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c
Hi Govindraj,
I'm sorry it took me so much time, I just was very busy these days...
I've looked in the TRMs of both OMAP3 and OMAP4, please see below.
On 01/12/12 12:52, Govindraj wrote:
> On Thu, Jan 12, 2012 at 2:53 PM, Igor Grinberg
> wrote:
>> Hi Govindraj,
>>
>> On 01/12/12 07:45, Govindraj wrote:
>>> Hi Igor,
>>>
>>> On Wed, Jan 11, 2012 at 8:33 PM, Igor Grinberg
>>> wrote:
Hi Guys,
On 01/11/12 16:34, Marek Vasut wrote:
>> On Wed, Jan 11, 2012 at 6:58 PM, Marek Vasut
>> wrote:
On Wed, Jan 11, 2012 at 6:16 PM, Marek Vasut
wrote:
>> On Wed, Jan 11, 2012 at 4:22 PM, Marek Vasut
> wrote:
Hi Marek,
Thanks for you review.
On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut
>>>
>>> wrote:
>> From: "Govindraj.R"
>>
>> Clean up added ehci-omap.c and make it generic for re-use
>> across soc having same ehci ip block. Also pass the modes to
>> be configured and configure the ports accordingly. All usb
>> layers are not cache aligned till then keep cache off for usb
>> ops as ehci will use internally dma for all usb ops.
>>
>> * Add a generic common header ehci-omap.h having common ip
>> block data and reg shifts.
>> * Rename and modify ehci-omap3 to ehci.h retain only
>> conflicting sysc reg shifts remove others and move to common
>> header file.
>
> Don't reimplement the ulpi stuff ... there's already some ulpi
> stuff in uboot that needs fixing, so fix it and use it.
Why do you keep saying that it needs fixing?
Can you point to a specific problem?
I am not implementing any ulpi stuff I am just configuring OMAP on
soc usb host controller (ehci). All the configuration stuff
is OMAP specific things which are done in ehci-omap.c file
Yes, it is OMAP specific, but only the INSNREG05_ULPI register part...
stuffs done are like soft-reset, port mode to be used and putting
port in no -idle mode(omap specific pm implementation) etc.
Well, the soft-reset, does not fit here...
The soft reset is defined by the ULPI spec and there is already an
implementation for this (as defined by the ULPI spec.)
>>>
>>> This stuff:
>>>
>>> +/* ULPI */
>>> +#define ULPI_SET(a)(a + 1)
>>> +#define ULPI_CLR(a)(a + 2)
>>> +#define ULPI_FUNC_CTRL 0x04
>>> +#define ULPI_FUNC_CTRL_RESET (1 << 5)
>>>
>>> is just accidentally conforming to ULPI spec?
>>
>> These are for configuring INSNREG05_ULPI reg in EHCI reg map
>> of omap while configuring in ulpi-phy mode.
By writing to the INSNREG05_ULPI register, you do not configure it,
but rather initiate the ULPI transaction to the ULPI PHY.
>>
>> looking into struct ulpi_regs {..}
>> then it doesn't map this configuration.
ulpi_regs {...} provides a kind of virtual mapping (to conform to U-Boot
way of accessing the registers) for the ULPI registers inside the ULPI PHY,
which are accessible in a platform specific manner which is sometimes called
a ULPI viewport.
In case of OMAP, the ULPI viewport is the INSNREG05_ULPI register.
>
> Can you point me to some documentation about this please? It's not
> that I don't trust you, I'd rather prefer to avoid unnecessary
> duplication.
Yes that would be fine.
You can download the omap4460 public trm from here:
http://www.ti.com/pdfs/wtbu/OMAP4460_ES.1x_PUBLIC_TRM_vM.zip
Go to chapter 23.11.6.6.1 EHCI Register Summary
(page number 5171 and 5186/87)
>>>
>>> Sure, but the macro above looks more like 23.11.6.3, doesn't it ? And
>>> for
>>> that purpose, the struct ulpi_regs is fitting ok.
No, Marek, there is another thing inside OMAP, which is called TLL.
It provides a kind of virtual ULPI interface and can be used instead of ULPI
PHY for the on-board connected devices.
TLL is not related to this discussion.
>>>
>>> Actually ... can you check the ulpi_read and ulpi_write stuff that's
>>> already in u-boot and explain why they can not be used with this port?
Marek, OMAP has a different ULPI viewport register structure, so
to reuse the ULPI layer, the omap-ulpi-viewport.c should be implemented
with its own ULPI accessors (e.g. ulpi_{read|write}()).
>>
>> echi-omap.c is no where writing to those registers
>> and the macro was used only to configure INSNREG05_ULPI reg in EHCI reg
>> map
This is not exactly true...
Indeed, the
Re: [U-Boot] [PATCH v2 0/9] Unified command execution in one place
Hi Stefan, On Wed, Jan 11, 2012 at 11:43 PM, Stefan Roese wrote: > On Saturday 10 December 2011 19:43:52 Simon Glass wrote: >> At present two parsers have similar code to execute commands. Also >> cmd_usage() is called all over the place. This series adds a single >> function which processes commands called cmd_process(). >> >> This new function understands return codes, and in particular >> CMD_RET_USAGE to indicate a usage error. So rather than calling >> cmd_usage() themselves, the command handlers can just return this >> error. >> >> There appears to be a run_command2() which is used to run commands >> with the selected parser. This series changes this in two separate >> steps to just run_command(), and renames the old run_command() to >> builtin_run_command(). No one should call this outside main.c since >> if the hush parser is being used it is wrong to call it. The >> built-in parser code could move into a separate file perhaps in a >> future patch. >> >> The overall series reduces code size on ARM by about 1KB on >> my ~160KB U-Boot text region when the hush parser is used, and around >> 60 bytes when it isn't. >> >> As an aside the only user of parse_line() is fsl_ddr_interactive() >> which seems to have its own command line interface which operates >> before DRAM is set up. Do I have this right? Is there no way this >> could be done later from a normal U-Boot command? > > Whole series: > > Applied to u-boot-staging/s...@denx.de. Thanks. Thanks for your efforts with this, sorry about the return code problem. I have re-done the series keeping the original return code behaviour - let's wait and see what people think of that. Regards, Simon > > Best regards, > Stefan > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net/eth.c: fix eth_write_hwaddr() to use dev->enetaddr as fall back
Dear Wolfgang and all,
On 17.01.2012 10:52, Wolfgang Denk wrote:
Dear Zach Sadecki,
In message <4f149ccb.6070...@itwatchdogs.com> you wrote:
This patch will also fix a problem with mx28 boards that are depending
on the OCOTP bits to set the MAC address (like the Denx m28 board). Now
it simply fails with a "Warning: failed to set MAC address" if there's
no environment variable instead of using the OCOTP bits like it should.
This patch will fix that.
But there _should_ always be a warning message if the environment
variable is missing.
Let's see if I can summarize the issue:
If I understood correctly, we are talking about
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=7616e7850804c7c69e0a22c179dfcba9e8f3f587
and there
int eth_initialize(bd_t *bis)
{
...
- eth_getenv_enetaddr_by_index(eth_number, env_enetaddr);
versus
+int eth_write_hwaddr(...)
+{
...
+ if (!eth_getenv_enetaddr_by_index(base_name, eth_number, env_enetaddr))
+ return -1;
I.e. the unconditional call of eth_getenv_enetaddr_by_index() was
replaced by a return -1 if the environment variable is missing
(resulting in "Warning: failed to set MAC address"? Btw: That's wrong?
It should be "Warning: failed to get MAC address from the environment"?)
Now, Eric's patch [1] (which needs an update of the commit message,
sure, but was acked by the author of the original patch [2]) tries to
re-introduce the original behavior:
+ eth_getenv_enetaddr_by_index(base_name, eth_number, env_enetaddr);
So, what I understand for i.MXxx, Zach and Eric are talking about:
If the environment variable is missing, the system can use the OCOTP
bits to set the MAC address. If the return -1 is removed by using Eric's
patch.
And for overo:
From Philip's mail, on an overo based product that uses the SMSC911x
ethernet chip, if the environment variable is missing, the MAC address
is set via EEPROM connected to the SMSC911x chip.
I.e. on these systems, with Eric's patch, we get a correct MAC address,
even if the environment variable is missing. This sounds like a good
option (?).
The question is then: Do we want a "Warning: failed to set MAC address"
message, even if the MAC is set correctly? But not from the environment
variable, but somehow read from the HW?
I know you will correct what I missed in this summary ;)
Best regards
Dirk
[1] http://lists.denx.de/pipermail/u-boot/2011-August/098686.html
[2] http://lists.denx.de/pipermail/u-boot/2011-August/098690.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3 performance regression in 2011.12
Aneesh V writes: > Hi Joe, > > On Monday 09 January 2012 09:18 PM, Joe Woodward wrote: > >> If I take the 2011.12 uBoot release the kernel takes about twice the >> time to boot (compared to 2011.09), and the device is noticably >> slower. >> >> Then if I comment out the v7_out_cache_disable() line in cpu.c and >> rebuild uBoot then everything speeds up again. >> >> I thought the kernel would turn on the cache again too... >> [...] >> I did a bit of Googling and found: >> http://www.spinics.net/lists/arm-kernel/msg50064.html >> http://www.spinics.net/lists/arm-kernel/msg50083.html >> >> It may be that the kernel is re-enabling the L1 cache, but expecting >> L2 to be on? > > Ideally kernel should be enabling L2 too. But looks like L2 was enabled > by ROM code itself in OMAP3, but D-cache disabled globally. So, it gets > enabled as soon as the D-cache is enabled globally. > > L2$ in OMAP3 is a bit tricky. The cache is known to ARM but > enabling/disabling it and affecting secure entries needs ROM > assistance. So, while ARMv7 generic code can flush L2, we need OMAP > specific code to enable/disable it. On OMAP3 ES2 and later, the L2EN bit in the auxiliary control register is banked between secure and non-secure modes, so there is no need for ROM calls to enable/disable the L2$ on these chips. -- Måns Rullgård m...@mansr.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/9] fdt: Add fdtdec functions to read byte array
On Tuesday 17 January 2012 02:11:58 Simon Glass wrote: > On Mon, Jan 16, 2012 at 10:30 PM, Mike Frysinger wrote: > > On Tuesday 17 January 2012 01:11:14 Simon Glass wrote: > >> From: Anton Staff > >> > >> Sometimes we don't need a full cell for each value. This provides > >> a simple function to read a byte array, both with and without > >> copying it. > >> > >> Signed-off-by: Simon Glass > > > > seems like getting s-o-b from Anton should be fairly easy ;) > > I have the jellybeans ready. I will make a list of those I need - it > is a pretty long list now. Does patchwork pick it up automatically if > they reply to the list? i believe it does if they reply to the patch in question. at least, it should be easy to check (have him reply and then d/l it via patchwork). -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 1/2 V2] arm926: Flush the data cache before disabling it.
On Mon, Jan 16, 2012 at 11:46 PM, Sughosh Ganu wrote: > On Mon Jan 16, 2012 at 10:57:05AM -0700, Tom Rini wrote: >> On Fri, Jan 13, 2012 at 10:38 AM, Sughosh Ganu >> wrote: >> > hi Heiko, >> > >> > On Fri Jan 13, 2012 at 04:29:29PM +0100, Heiko Schocher wrote: >> >> Hello Sugosh, >> >> >> >> Sughosh Ganu wrote: >> >> > hi Christian, >> >> > >> >> > On Fri Jan 13, 2012 at 09:06:26AM +0100, Christian Riesch wrote: >> >> >> Hi Sughosh, >> >> >> I had a look at the patch and I tried to understand what's going on >> >> >> here (I must confess that I didn't know anything about this cache >> >> >> stuff). >> >> > >> >> > Ok, thanks for taking time off to understand this issue. >> >> > >> >> >> On Tue, Jan 10, 2012 at 7:12 PM, Sughosh Ganu >> >> >> wrote: >> >> >>> The current implementation invalidates the cache instead of flushing >> >> >>> it. This causes problems on platforms where the spl/u-boot is already >> >> >>> loaded to the RAM, with caches enabled by a first stage bootloader. >> >> >> >> Hmm.. how did u-boot work on such boards? How can u-boot work with D-Cache >> >> enabled, if u-boot is not initializing it? (And I think, on davinci SoC >> >> we have a none working uboot ethernet driver if d-cache is enabled too). >> >> There must be a page_table in DRAM for using D-Cache in U-Boot, if u-boot >> >> don't initialize it, it maybe overrides it ... or miss I something? >> > >> > Well, there is some data in the cache, which if not flushed creates >> > problems on my board. I get the board to boot just by commenting out >> > cpu_init_crit call. My hypothesis that the D-cache is enabled is >> > simply because cache invalidation followed by cache disabling breaks >> > the board, while flushing it prior to disabling gets it to boot >> > fine. This(invalidation) would not have been a problem if the cache >> > was in the disabled state. >> >> Putting my TI hat on, I've confirmed with the RBL folks that they >> aren't turning on ICACHE/DCACHE. > > Well, i'm not sure then why does the cache invalidation cause a > problem on my platform. Btw, will this patch be > accepted. Irrespective of the cache state on my board, it is not a > wrong fix, and moreover results in the booting of my board. > > I haven't yet tried out reading the cache bit state in the spl. Will > try out this experiment in a day or two, and share the results. I think someone needs to look over this init code very carefully. If I can summarize from memory quickly, when we enable the CP_CRITICAL_INITS code for everyone that exposed a problem on the hawkboard that _looks_like_ DCACHE is enabled by RBL as changing the code from doing an invalidate to a flush+invalidate fixes a problem. But the manual says we should be doing flush+invalidate anyhow and the RBL code is not turning on DCACHE. Maybe we've got something else being done not as the manual says and that's tickling another issue? -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3 performance regression in 2011.12
On Tuesday 17 January 2012 08:21 PM, Måns Rullgård wrote: Aneesh V writes: Hi Joe, On Monday 09 January 2012 09:18 PM, Joe Woodward wrote: If I take the 2011.12 uBoot release the kernel takes about twice the time to boot (compared to 2011.09), and the device is noticably slower. Then if I comment out the v7_out_cache_disable() line in cpu.c and rebuild uBoot then everything speeds up again. I thought the kernel would turn on the cache again too... [...] I did a bit of Googling and found: http://www.spinics.net/lists/arm-kernel/msg50064.html http://www.spinics.net/lists/arm-kernel/msg50083.html It may be that the kernel is re-enabling the L1 cache, but expecting L2 to be on? Ideally kernel should be enabling L2 too. But looks like L2 was enabled by ROM code itself in OMAP3, but D-cache disabled globally. So, it gets enabled as soon as the D-cache is enabled globally. L2$ in OMAP3 is a bit tricky. The cache is known to ARM but enabling/disabling it and affecting secure entries needs ROM assistance. So, while ARMv7 generic code can flush L2, we need OMAP specific code to enable/disable it. On OMAP3 ES2 and later, the L2EN bit in the auxiliary control register is banked between secure and non-secure modes, so there is no need for ROM calls to enable/disable the L2$ on these chips. Yes, but IIRC, there was an erratum around it in some ARM revisions (I think 3430 ES2 was affected) and the workaround was to keep both the banked bits at the same value always. So, to keep things simple and working for all revisions, I try to change both together. In the U-Boot code where this is done I have added a comment on this. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3 performance regression in 2011.12
Hi Joe, On Monday 09 January 2012 09:18 PM, Joe Woodward wrote: (apologies for previous top posting, wasn't paying attention to what I was doing!) I'm fairly certain... If I take the 2011.12 uBoot release the kernel takes about twice the time to boot (compared to 2011.09), and the device is noticably slower. Then if I comment out the v7_out_cache_disable() line in cpu.c and rebuild uBoot then everything speeds up again. I thought the kernel would turn on the cache again too... Is there any easy way from userspace to determine if the cache is on? It won't be easy I believe, unless you have a debugger that allows you to see CP15 registers. I did a bit of Googling and found: http://www.spinics.net/lists/arm-kernel/msg50064.html http://www.spinics.net/lists/arm-kernel/msg50083.html It may be that the kernel is re-enabling the L1 cache, but expecting L2 to be on? Ideally kernel should be enabling L2 too. But looks like L2 was enabled by ROM code itself in OMAP3, but D-cache disabled globally. So, it gets enabled as soon as the D-cache is enabled globally. L2$ in OMAP3 is a bit tricky. The cache is known to ARM but enabling/disabling it and affecting secure entries needs ROM assistance. So, while ARMv7 generic code can flush L2, we need OMAP specific code to enable/disable it. So, before my patch and before cache-support came to U-boot L2$ always remained enabled. Since de-compressor's flush indeed flushed L2$ we didn't get into any coherency problems. Let the discussion in l-o conclude. I think fixing it in kernel is the right thing to do. But if that's not possible, we can have a patch in U-boot to work around it. br, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] imx6: mx6qarm2: updated board_mmc_getcd() to the new prototype
Commit 314284b1567f1ce29c19060641e7f213146f7ab8 has
changed board_mmc_getcd() function prototype, while
mx6qarm2 has still the old one.
Signed-off-by: Stefano Babic
CC: Jason Liu
Acked-by: Dirk Behme
---
board/freescale/mx6qarm2/mx6qarm2.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/board/freescale/mx6qarm2/mx6qarm2.c
b/board/freescale/mx6qarm2/mx6qarm2.c
index 9894245..9724c16 100644
--- a/board/freescale/mx6qarm2/mx6qarm2.c
+++ b/board/freescale/mx6qarm2/mx6qarm2.c
@@ -120,17 +120,18 @@ struct fsl_esdhc_cfg usdhc_cfg[2] = {
{USDHC4_BASE_ADDR, 1},
};
-int board_mmc_getcd(u8 *cd, struct mmc *mmc)
+int board_mmc_getcd(struct mmc *mmc)
{
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
+ int ret;
if (cfg->esdhc_base == USDHC3_BASE_ADDR) {
gpio_direction_input(171); /*GPIO6_11*/
- *cd = gpio_get_value(171);
+ ret = !gpio_get_value(171);
} else /* Don't have the CD GPIO pin on board */
- *cd = 0;
+ ret = 0;
- return 0;
+ return ret;
}
int board_mmc_init(bd_t *bis)
--
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] imx6: mx6qarm2: updated
On 17/01/2012 13:03, Fabio Estevam wrote: > Hi Stefano, > > On Tue, Jan 17, 2012 at 9:18 AM, Stefano Babic wrote: >> Commit 314284b1567f1ce29c19060641e7f213146f7ab8 has >> changed board_mmc_getcd() function prototype, while >> mx6qarm2 has still the old one. >> >> Signed-off-by: Stefano Babic >> CC: Jason Liu > > I think the subject of the patch could be improved. ...one part was lost editing the commit message - I will send V2. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v2] common, menu: show menu on startup if CONFIG_MENU_SHOW is defined
Dear Heiko, On Tue, Jan 17, 2012 at 02:13:35AM -0500, Heiko Schocher wrote: > show a menu on startup instead running the shell. > > Signed-off-by: Heiko Schocher > Cc: Jason Hobbs > Cc: Mike Frysinger A couple of minor fixes in your README addition below, otherwise: Acked-by: Jason Hobbs > --- > - changes for v2: > - add comments from Mike Frysinger > - pass current bootdelay to menu_show > > common/main.c |4 > doc/README.menu |5 + > include/menu.h |3 +++ > 3 files changed, 12 insertions(+), 0 deletions(-) > ... > diff --git a/doc/README.menu b/doc/README.menu > index 4ddf914..6ce6bba 100644 > --- a/doc/README.menu > +++ b/doc/README.menu > @@ -25,6 +25,11 @@ the interfaces should be available. > Menus are composed of items. Each item has a key used to identify it in > the menu, and an opaque pointer to data controlled by the consumer. > > +If you want to show a menu, instead starting the shell, define "instead of starting the shell" > +CONFIG_MENU_SHOW. You have to code the int menu_show(int bootdelay) > +function, which handle your menu. This function returns the remaining "which handles" > +bootdelay. > + > Interfaces > -- > #include "menu.h" > diff --git a/include/menu.h b/include/menu.h > index b806a02..7af5fdb 100644 > --- a/include/menu.h > +++ b/include/menu.h > @@ -28,4 +28,7 @@ int menu_item_add(struct menu *m, char *item_key, void > *item_data); > int menu_destroy(struct menu *m); > void menu_display_statusline(struct menu *m); > > +#if defined(CONFIG_MENU_SHOW) > +int menu_show(int bootdelay); > +#endif > #endif /* __MENU_H__ */ > -- > 1.7.7.4 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common, menu: do not trigger timeout again, if a line is read
Dear Heiko,
On Tue, Jan 17, 2012 at 03:24:29AM -0500, Heiko Schocher wrote:
> Signed-off-by: Heiko Schocher
> Cc: Jason Hobbs
Acked-by: Jason Hobbs
> ---
> common/menu.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/common/menu.c b/common/menu.c
> index 754a9f9..aa16c9a 100644
> --- a/common/menu.c
> +++ b/common/menu.c
> @@ -236,8 +236,10 @@ static inline int menu_interactive_choice(struct menu
> *m, void **choice)
> if (readret >= 0) {
> choice_item = menu_item_by_key(m, cbuf);
>
> - if (!choice_item)
> + if (!choice_item) {
> printf("%s not found\n", cbuf);
> + m->timeout = 0;
> + }
> } else {
> puts("^C\n");
> return -EINTR;
> --
> 1.7.7.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx6: mx6qarm2: updated
Hi Stefano, On Tue, Jan 17, 2012 at 9:18 AM, Stefano Babic wrote: > Commit 314284b1567f1ce29c19060641e7f213146f7ab8 has > changed board_mmc_getcd() function prototype, while > mx6qarm2 has still the old one. > > Signed-off-by: Stefano Babic > CC: Jason Liu I think the subject of the patch could be improved. Writing only "updated" in the subject is too vague. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx6: mx6qarm2: updated
On 17.01.2012 12:18, Stefano Babic wrote: Commit 314284b1567f1ce29c19060641e7f213146f7ab8 has changed board_mmc_getcd() function prototype, while mx6qarm2 has still the old one. Signed-off-by: Stefano Babic CC: Jason Liu Acked-by: Dirk Behme Thanks Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] imx6: mx6qarm2: updated
Commit 314284b1567f1ce29c19060641e7f213146f7ab8 has
changed board_mmc_getcd() function prototype, while
mx6qarm2 has still the old one.
Signed-off-by: Stefano Babic
CC: Jason Liu
---
board/freescale/mx6qarm2/mx6qarm2.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/board/freescale/mx6qarm2/mx6qarm2.c
b/board/freescale/mx6qarm2/mx6qarm2.c
index 9894245..9724c16 100644
--- a/board/freescale/mx6qarm2/mx6qarm2.c
+++ b/board/freescale/mx6qarm2/mx6qarm2.c
@@ -120,17 +120,18 @@ struct fsl_esdhc_cfg usdhc_cfg[2] = {
{USDHC4_BASE_ADDR, 1},
};
-int board_mmc_getcd(u8 *cd, struct mmc *mmc)
+int board_mmc_getcd(struct mmc *mmc)
{
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
+ int ret;
if (cfg->esdhc_base == USDHC3_BASE_ADDR) {
gpio_direction_input(171); /*GPIO6_11*/
- *cd = gpio_get_value(171);
+ ret = !gpio_get_value(171);
} else /* Don't have the CD GPIO pin on board */
- *cd = 0;
+ ret = 0;
- return 0;
+ return ret;
}
int board_mmc_init(bd_t *bis)
--
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] arm, davinci: add PLL0 prediv to da850 lowlevel setup
Hello Ben, On Mon, Jan 16, 2012 at 6:43 PM, Ben Gardiner wrote: > The OMAP-L138 has a pre-divider available on PLL0. > > Add support to da850_lowlevel.c for configuring PLL0's pre-divider. This is > to achieve certain OPP's -- e.g. the 372MHz OPP used also by Linux. I noticed that that pre-divider configuration was missing while working on the lowlevel setup, but then I forgot to add it (and I was fine with the default)... Thank you for adding it! Acked-by: Christian Riesch Regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Add Prep subcommand support to bootm
On 16/01/2012 09:12, Simon Schwarz wrote: > From: Simon Schwarz > > Adds prep subcommand to bootm implementation of ARM. When bootm is called > with the subcommand prep the function stops right after ATAGS creation and > before announce_and_cleanup. > > This is used in command "cmd_spl export" > > Signed-off-by: Simon Schwarz > Acked-by: Stefano Babic Tested-by: Stefano Babic Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] configs: Remove CONFIG_NET_MULTI from board files
On 15/01/2012 16:03, Fabio Estevam wrote: > CONFIG_NET_MULTI is not used anymore, so remove it from board files. > > Cc: Marek Vasut > Cc: Stefano Babic > Cc: Kumar Gala > Cc: Sandeep Paulraj > Signed-off-by: Fabio Estevam > --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] fsl_pmic.h: add regulator mode 0 and 1 bits
On 16/01/2012 12:10, Helmut Raiger wrote:
> Add bit definitions for register 32 and 33 of Freescale PMIC.
>
> Signed-off-by: Helmut Raiger
> ---
> include/fsl_pmic.h | 52
>
> 1 files changed, 52 insertions(+), 0 deletions(-)
>
Hi Helmut,
> diff --git a/include/fsl_pmic.h b/include/fsl_pmic.h
> index 742f2e1..17e7b82 100644
> --- a/include/fsl_pmic.h
> +++ b/include/fsl_pmic.h
> @@ -102,6 +102,58 @@ enum {
> PMIC_NUM_OF_REGS,
> };
>
> +/* REG_MODE_0 */
> +#define VAUDIOEN (1 << 0)
> +#define VAUDIOSTBY (1 << 1)
No, this is not correct. I explain it better. Freescale's PMIC that we
currently support have the same register names, but their layout
differs. What you are defining here is valid for the MC13783, but
conflicts with the mc13892.
See the comments inside fsl_pmic.h:
/*
* The registers of different PMIC has the same meaning
* but the bit positions of the fields can differ or
* some fields has a meaning only on some devices.
* You have to check with the internal SPI bitmap
* (see Freescale Documentation) to set the registers
* for the device you are using
*/
I checked the REG_0 registers in both PMIC and they differ. The way to
do is to have a pmic specific header file with the bit definitions. We
have already include/mc13892.h, and you can add include/mc13783.h with
the constants you need.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mmc: access mxcmmc from mx31 boards
On 11/01/2012 14:59, Helmut Raiger wrote: > This patch modifies mxcmmc.c to be used > not only by i.MX27 but also by i.MX31 boards. > Both use the same SD controller, but have different > clock set-ups. > The i.MX27 imx_get_XXXclock functions are made static to > generic.c and a public mxc_get_clock() function > is provided. Pins, base address and prototypes for > an i.MX31 specific board_init_mmc() are provided. > Some of the i.MX27 clock getters are unused and marked > as such to avoid warnings (./MAKEALL -s mx27), but > the code was left in for future use. > > Signed-off-by: Helmut Raiger > --- > Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net/eth.c: fix eth_write_hwaddr() to use dev->enetaddr as fall back
Dear Zach Sadecki, In message <4f149ccb.6070...@itwatchdogs.com> you wrote: > This patch will also fix a problem with mx28 boards that are depending > on the OCOTP bits to set the MAC address (like the Denx m28 board). Now > it simply fails with a "Warning: failed to set MAC address" if there's > no environment variable instead of using the OCOTP bits like it should. > This patch will fix that. But there _should_ always be a warning message if the environment variable is missing. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Heavier than air flying machines are impossible. -- Lord Kelvin, President, Royal Society, c. 1895 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.mx6q: mx6qsabrelite: Add the ethernet function support
On 13/01/2012 09:56, Dirk Behme wrote: > From: Jason Liu > > Signed-off-by: Jason Liu > Signed-off-by: Eric Miao > CC: Jason Liu > CC: Stefano Babic > --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.mx6q: mx6qsabrelite: Setup uart1 pinmux
On 13/01/2012 10:49, Dirk Behme wrote: > From: Troy Kisky > > This allows the Linux kernel to use UART1 before pinmux > support is added for UART1 > > Signed-off-by: Troy Kisky > CC: Troy Kisky > CC: Jason Liu > CC: Stefano Babic > --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.mx6q: configs: Add fdt_high and initrd_high variables
On 13/01/2012 10:49, Dirk Behme wrote: > To be able to load the device tree and initrd correctly, set > the fdt_high and initrd_high environment variables. > > Using 0x implies that the device tree and the initrd > are initially copied to working addresses. This will avoid an > additional copy. > > Loading the device tree to 0x3000 and the initrd to 0x3c00 > should work for both boards, the ARM2 and SabreLite. > > Example (SabreLite): > > fatload mmc 0:2 0x1000 uImage > fatload mmc 0:2 0x3c00 uInitrd > fatload mmc 0:2 0x3000 board.dtb > bootm 0x1000 0x3c00 0x3000 > > Note: This requires that the kernel has CONFIG_HIGHMEM enabled. > > Signed-off-by: Dirk Behme > CC: Jason Liu > CC: Stefano Babic > --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] imximage: Add support for i.MX6
On 12/01/2012 10:28, Dirk Behme wrote: > The i.MX6 processor can boot from NOR flash and SATA disks, > additionally. Add the flash offsets for these additional > boot modes. > > Signed-off-by: Dirk Behme > Signed-off-by: Fabio Estevam > CC: Stefano Babic > CC: Jason Liu > --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] imximage: Add MX53 to the documentation
On 12/01/2012 10:28, Dirk Behme wrote: > i.MX53 is supported, too. Add this to the introduction of the > documentation. > > Signed-off-by: Dirk Behme > CC: Fabio Estevam > CC: Stefano Babic > CC: Jason Liu > --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] imximage: Sort bootops alphabetically
On 12/01/2012 10:28, Dirk Behme wrote: > Signed-off-by: Dirk Behme > CC: Fabio Estevam > CC: Stefano Babic > CC: Jason Liu > --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/8 v2] powerpc/corenet_ds: Slave core in holdoff when boot from SRIO
When boot from SRIO, slave's core can be in holdoff after powered on for
some specific requirements. Master can release the slave's core at the
right time by SRIO interface.
Master needs to:
1. Set outbound SRIO windows in order to configure slave's registers
for the core's releasing.
2. Check the SRIO port status when release slave core, if no errors,
will implement the process of the slave core's releasing.
Slave needs to:
1. Set all the cores in holdoff by RCW.
2. Be powered on before master's boot.
Signed-off-by: Liu Gang
Signed-off-by: Shaohui Xie
---
Changes in v2:
- Subject changed to "powerpc/corenet_ds".
- Use "(void *)" instead of "(u32)" when calling "out_be32()".
- Use "NOR flash" instead of "Nor flash".
- Get rid of the base address + offset notation. Use C structs
instead.
- Get rid of hard coded magic numbers. Use macro instead.
- Use "debug()" instead of "printf()".
arch/powerpc/cpu/mpc85xx/cpu_init.c |3 +
arch/powerpc/cpu/mpc8xxx/srio.c | 126 +++
arch/powerpc/include/asm/fsl_srio.h |3 +
include/configs/corenet_ds.h|4 +
4 files changed, 136 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 97a7fe1..2cd5db7 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -444,6 +444,9 @@ skip_l2:
srio_init();
#ifdef CONFIG_SRIOBOOT_MASTER
srio_boot_master();
+#ifdef CONFIG_SRIOBOOT_SLAVE_HOLDOFF
+ srio_boot_master_release_slave();
+#endif
#endif
#endif
diff --git a/arch/powerpc/cpu/mpc8xxx/srio.c b/arch/powerpc/cpu/mpc8xxx/srio.c
index 5694561..e132c69 100644
--- a/arch/powerpc/cpu/mpc8xxx/srio.c
+++ b/arch/powerpc/cpu/mpc8xxx/srio.c
@@ -25,6 +25,12 @@
#define SRIO_PORT_ACCEPT_ALL 0x1001
#define SRIO_IB_ATMU_AR 0x80f55000
+#define SRIO_OB_ATMU_AR_MAINT 0x80077000
+#define SRIO_OB_ATMU_AR_RW 0x80045000
+#define SRIO_LCSBA1CSR_OFFSET 0x5c
+#define SRIO_MAINT_WIN_SIZE 0x100 /* 16M */
+#define SRIO_RW_WIN_SIZE 0x10 /* 1M */
+#define SRIO_LCSBA1CSR 0x6000
#if defined(CONFIG_FSL_CORENET)
#define _DEVDISR_SRIO1 FSL_CORENET_DEVDISR_SRIO1
@@ -168,4 +174,124 @@ void srio_boot_master(void)
SRIO_IB_ATMU_AR
| atmu_size_mask(CONFIG_SRIOBOOT_SLAVE_ENV_SIZE));
}
+
+#ifdef CONFIG_SRIOBOOT_SLAVE_HOLDOFF
+void srio_boot_master_release_slave(void)
+{
+ struct ccsr_rio *srio = (void *)CONFIG_SYS_FSL_SRIO_ADDR;
+ u32 escsr;
+ u32 addr;
+ debug("SRIOBOOT - MASTER: "
+ "Check the port status and release slave core ...\n");
+
+ escsr = in_be32((void *)&srio->lp_serial
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].pescsr);
+ if (escsr & 0x2) {
+ if (escsr & 0x10100) {
+ debug("SRIOBOOT - MASTER: Port [ %d ] is error.\n",
+ CONFIG_SRIOBOOT_MASTER_PORT);
+ } else {
+ debug("SRIOBOOT - MASTER: "
+ "Port [ %d ] is ready, now release
slave's core ...\n",
+ CONFIG_SRIOBOOT_MASTER_PORT);
+ /*
+* configure outbound window
+* with maintenance attribute to set slave's LCSBA1CSR
+*/
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT]
+ .outbw[1].rowtar, 0);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT]
+ .outbw[1].rowtear, 0);
+ if (CONFIG_SRIOBOOT_MASTER_PORT)
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT]
+ .outbw[1].rowbar,
+ CONFIG_SYS_SRIO2_MEM_PHYS >> 12);
+ else
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT]
+ .outbw[1].rowbar,
+ CONFIG_SYS_SRIO1_MEM_PHYS >> 12);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT]
+ .outbw[1].rowar,
+ SRIO_OB_ATMU_AR_MAINT
+ | atmu_size_mask(SRIO_MAINT_WIN_SIZE));
+
+ /*
+* configure outbound window
+* with R/W attribute to set slave's BRR
+*/
+
[U-Boot] [PATCH 7/8 v2] powerpc/corenet_ds: Slave reads ENV from master when boot from SRIO
When boot from SRIO, slave's ENV can be stored in master's memory space,
then slave can fetch the ENV through SRIO interface.
NOTE: Because the slave can not erase, write master's NOR flash by SRIO
interface, so it can not modify the ENV parameters stored in
master's NOR flash using "saveenv" or other commands.
Master needs to:
1. Put the slave's ENV into it's own memory space.
2. Set an inbound SRIO window covered slave's ENV stored in master's
memory space.
Slave needs to:
1. Set a specific TLB entry in order to fetch ucode and ENV from master.
2. Set a LAW entry with the TargetID SRIO1 or SRIO2 for ucode and ENV.
Signed-off-by: Liu Gang
Signed-off-by: Shaohui Xie
---
Changes in v2:
- Subject changed to "powerpc/corenet_ds".
- Update the README for "CONFIG_ENV_IS_IN_REMOTE".
- Use "(void *)" instead of "(u32)" when calling "out_be32()".
- Use "NOR flash" instead of "Nor flash".
- Get rid of the base address + offset notation. Use C structs
instead.
- Get rid of hard coded magic numbers. Use macro instead.
- Use "debug()" instead of "printf()".
- Some code styles changed.
README | 18 +
arch/powerpc/cpu/mpc8xxx/srio.c | 17
common/Makefile |1 +
common/cmd_nvedit.c |3 +-
common/env_remote.c | 79 +++
include/configs/corenet_ds.h| 13 ++
6 files changed, 130 insertions(+), 1 deletions(-)
create mode 100644 common/env_remote.c
diff --git a/README b/README
index f4f0d64..1b699c9 100644
--- a/README
+++ b/README
@@ -2917,6 +2917,24 @@ to save the current settings.
environment area within the total memory of your DataFlash placed
at the specified address.
+- CONFIG_ENV_IS_IN_REMOTE:
+
+ Define this if you have a remote memory space which you
+ want to use for the local device's environment.
+
+ - CONFIG_ENV_ADDR:
+ - CONFIG_ENV_SIZE:
+
+ These two #defines specify the address and size of the
+ environment area within the remote memory space. The
+ local device can get the environment from remote memory
+ space by SRIO or other links.
+
+BE CAREFUL! For some special cases, the local device can not use
+"saveenv" command. For example, the local device will get the
+environment stored in a remote NOR flash by SRIO link, but it can
+not erase, write this NOR flash by SRIO interface.
+
- CONFIG_ENV_IS_IN_NAND:
Define this if you have a NAND device which you want to use
diff --git a/arch/powerpc/cpu/mpc8xxx/srio.c b/arch/powerpc/cpu/mpc8xxx/srio.c
index e593f22..5694561 100644
--- a/arch/powerpc/cpu/mpc8xxx/srio.c
+++ b/arch/powerpc/cpu/mpc8xxx/srio.c
@@ -150,5 +150,22 @@ void srio_boot_master(void)
.port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[2].riwar,
SRIO_IB_ATMU_AR
| atmu_size_mask(CONFIG_SRIOBOOT_SLAVE_UCODE_SIZE));
+
+ /* configure inbound window for slave's ENV */
+ debug("SRIOBOOT - MASTER: Inbound window for slave's ENV; "
+ "Local = 0x%llx, Siro = 0x%llx, Size = 0x%x\n",
+ CONFIG_SRIOBOOT_SLAVE_ENV_LAW_PHYS,
+ CONFIG_SRIOBOOT_SLAVE_ENV_SRIO_PHYS,
+ CONFIG_SRIOBOOT_SLAVE_ENV_SIZE);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[3].riwtar,
+ CONFIG_SRIOBOOT_SLAVE_ENV_LAW_PHYS >> 12);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[3].riwbar,
+ CONFIG_SRIOBOOT_SLAVE_ENV_SRIO_PHYS >> 12);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[3].riwar,
+ SRIO_IB_ATMU_AR
+ | atmu_size_mask(CONFIG_SRIOBOOT_SLAVE_ENV_SIZE));
}
#endif
diff --git a/common/Makefile b/common/Makefile
index 2d9ae8c..bd9e8a3 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -58,6 +58,7 @@ COBJS-$(CONFIG_ENV_IS_IN_NAND) += env_nand.o
COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_nvram.o
COBJS-$(CONFIG_ENV_IS_IN_ONENAND) += env_onenand.o
COBJS-$(CONFIG_ENV_IS_IN_SPI_FLASH) += env_sf.o
+COBJS-$(CONFIG_ENV_IS_IN_REMOTE) += env_remote.o
COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o
# command
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 63afc82..c2fd8fa 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -65,9 +65,10 @@ DECLARE_GLOBAL_DATA_PTR;
!defined(CONFIG_ENV_IS_IN_NVRAM)&& \
!defined(CONFIG_ENV_IS_IN_ONENAND) && \
!defined(CONFIG_ENV_IS_IN_SPI_FLASH)&& \
+ !defined(CONFIG_ENV_IS_IN_REMOTE) && \
!defined(CONFIG_ENV_IS_NOWHERE)
# error Define one of CONFIG_ENV_IS_IN_{EEPROM|FLASH|DATAFLASH|ONENAND|\
-SPI_FLASH|MG_DISK|NVRAM|MMC} or CO
[U-Boot] [PATCH 5/8 v2] powerpc/corenet_ds: Slave module for boot from SRIO
For the powerpc processors with SRIO interface, boot location can be configured
from SRIO1 or SRIO2 by RCW. The processor booting from SRIO can do without flash
for u-boot image. The image can be fetched from another processor's memory
space by SRIO link connected between them.
The processor boots from SRIO is slave, the processor boots from normal flash
memory space and can help slave to boot from its memory space is master.
They are different environments and requirements:
master:
1. NOR flash for its own u-boot image, ucode and ENV space.
2. Slave's u-boot image in master NOR flash.
3. Normally boot from local NOR flash.
4. Configure SRIO switch system if needed.
slave:
1. Just has EEPROM for RCW. No flash for u-boot image, ucode and ENV.
2. Boot location should be set to SRIO1 or SRIO2 by RCW.
3. RCW should configure the SerDes, SRIO interfaces correctly.
4. Slave must be powered on after master's boot.
5. Must define CONFIG_SYS_QE_FMAN_FW_IN_REMOTE because of no ucode
locally.
For the slave module, need to finish these processes:
1. Set the boot location to SRIO1 or SRIO2 by RCW.
2. Set a specific TLB entry for the boot process.
3. Set a LAW entry with the TargetID SRIO1 or SRIO2 for the boot.
4. Slave's u-boot image should be generated specifically by
make _SRIOBOOT_SLAVE_config.
This will set SYS_TEXT_BASE=0xFFF8 and other configurations.
Signed-off-by: Liu Gang
Signed-off-by: Shaohui Xie
---
Changes in v2:
- Subject changed to "powerpc/corenet_ds".
- Use "(void *)" instead of "(u32)" when calling "out_be32()".
- Use "NOR flash" instead of "Nor flash".
- Get rid of the base address + offset notation. Use C structs
instead.
- Get rid of hard coded magic numbers. Use macro instead.
- Use "debug()" instead of "printf()".
- Add the description for CONFIG_SYS_QE_FMAN_FW_IN_REMOTE and also
update the README for this.
README |6 ++
board/freescale/common/p_corenet/law.c |9 +
board/freescale/common/p_corenet/tlb.c |9 +
boards.cfg |3 +++
drivers/net/fm/fm.c|2 ++
include/configs/corenet_ds.h | 28
6 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 9d713e8..f4f0d64 100644
--- a/README
+++ b/README
@@ -3358,6 +3358,12 @@ within that device.
Specifies that QE/FMAN firmware is located on the primary SPI
device. CONFIG_SYS_FMAN_FW_ADDR is the byte offset on that device.
+- CONFIG_SYS_QE_FMAN_FW_IN_REMOTE
+ Specifies that QE/FMAN firmware is located in the remote (master)
+ memory space. CONFIG_SYS_FMAN_FW_ADDR is a virtual address which
+ can be mapped from slave TLB->slave LAW->slave SRIO outbound window
+ ->master inbound window->master LAW->the ucode address in master's
+ NOR flash.
Building the Software:
==
diff --git a/board/freescale/common/p_corenet/law.c
b/board/freescale/common/p_corenet/law.c
index 09ef561..1fbab4d 100644
--- a/board/freescale/common/p_corenet/law.c
+++ b/board/freescale/common/p_corenet/law.c
@@ -48,6 +48,15 @@ struct law_entry law_table[] = {
#ifdef CONFIG_SYS_NAND_BASE_PHYS
SET_LAW(CONFIG_SYS_NAND_BASE_PHYS, LAW_SIZE_1M, LAW_TRGT_IF_LBC),
#endif
+#ifdef CONFIG_SRIOBOOT_SLAVE
+#if defined(CONFIG_SRIOBOOT_SLAVE_PORT0)
+ SET_LAW(CONFIG_SYS_SRIOBOOT_SLAVE_ADDR_PHYS,
+ LAW_SIZE_1M, LAW_TRGT_IF_RIO_1),
+#elif defined(CONFIG_SRIOBOOT_SLAVE_PORT1)
+ SET_LAW(CONFIG_SYS_SRIOBOOT_SLAVE_ADDR_PHYS,
+ LAW_SIZE_1M, LAW_TRGT_IF_RIO_2),
+#endif
+#endif
};
int num_law_entries = ARRAY_SIZE(law_table);
diff --git a/board/freescale/common/p_corenet/tlb.c
b/board/freescale/common/p_corenet/tlb.c
index 6a0026a..a8c8b3c 100644
--- a/board/freescale/common/p_corenet/tlb.c
+++ b/board/freescale/common/p_corenet/tlb.c
@@ -66,6 +66,15 @@ struct fsl_e_tlb_entry tlb_table[] = {
SET_TLB_ENTRY(1, CONFIG_SYS_INIT_L3_ADDR, CONFIG_SYS_INIT_L3_ADDR,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 0, BOOKE_PAGESZ_1M, 1),
+#elif defined(CONFIG_SRIOBOOT_SLAVE)
+ /*
+* SRIOBOOT-SLAVE. When slave boot, the address of the
+* space is at 0xfff0, it covered the 0xf000.
+*/
+ SET_TLB_ENTRY(1, CONFIG_SYS_SRIOBOOT_SLAVE_ADDR,
+ CONFIG_SYS_SRIOBOOT_SLAVE_ADDR_PHYS,
+ MAS3_SX|MAS3_SW|MAS3_SR, MAS2_W|MAS2_G,
+ 0, 0, BOOKE_PAGESZ_1M, 1),
#else
SET_TLB_ENTRY(1, 0xf000, 0xf000,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
diff --git a/boards.cfg b/boards.cfg
index 446f0eb..798466e 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -741,6
[U-Boot] [PATCH 4/8 v2] powerpc/corenet_ds: Master module for boot from SRIO
For the powerpc processors with SRIO interface, boot location can be configured
from SRIO1 or SRIO2 by RCW. The processor booting from SRIO can do without flash
for u-boot image. The image can be fetched from another processor's memory
space by SRIO link connected between them.
The processor boots from SRIO is slave, the processor boots from normal flash
memory space and can help slave to boot from its memory space is master.
They are different environments and requirements:
master:
1. NOR flash for its own u-boot image, ucode and ENV space.
2. Slave's u-boot image in master NOR flash.
3. Normally boot from local NOR flash.
4. Configure SRIO switch system if needed.
slave:
1. Just has EEPROM for RCW. No flash for u-boot image, ucode and ENV.
2. Boot location should be set to SRIO1 or SRIO2 by RCW.
3. RCW should configure the SerDes, SRIO interfaces correctly.
4. Slave must be powered on after master's boot.
For the master module, need to finish these processes:
1. Initialize the SRIO port and address space.
2. Set inbound SRIO windows covered slave's u-boot image stored in
master's NOR flash.
3. Master's u-boot image should be generated specifically by
make _SRIOBOOT_MASTER_config
4. Master must boot first, and then slave can be powered on.
Signed-off-by: Liu Gang
Signed-off-by: Shaohui Xie
---
Changes in v2:
- Subject changed to "powerpc/corenet_ds".
- Use "(void *)" instead of "(u32)" when calling "out_be32()".
- Use "NOR flash" instead of "Nor flash".
- Get rid of the base address + offset notation. Use C structs
instead.
- Get rid of hard coded magic numbers. Use macro instead.
- Use "debug()" instead of "printf()".
arch/powerpc/cpu/mpc85xx/cpu_init.c |6 ++-
arch/powerpc/cpu/mpc8xxx/srio.c | 51 +++
arch/powerpc/include/asm/fsl_srio.h | 61 +
arch/powerpc/include/asm/immap_85xx.h |3 ++
boards.cfg|3 ++
include/configs/corenet_ds.h | 18 ++
6 files changed, 140 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/include/asm/fsl_srio.h
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 2e4a06c..97a7fe1 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include "mp.h"
#ifdef CONFIG_SYS_QE_FMAN_FW_IN_NAND
@@ -48,8 +49,6 @@
DECLARE_GLOBAL_DATA_PTR;
-extern void srio_init(void);
-
#ifdef CONFIG_QE
extern qe_iop_conf_t qe_iop_conf_tab[];
extern void qe_config_iopin(u8 port, u8 pin, int dir,
@@ -443,6 +442,9 @@ skip_l2:
#ifdef CONFIG_SYS_SRIO
srio_init();
+#ifdef CONFIG_SRIOBOOT_MASTER
+ srio_boot_master();
+#endif
#endif
#if defined(CONFIG_MP)
diff --git a/arch/powerpc/cpu/mpc8xxx/srio.c b/arch/powerpc/cpu/mpc8xxx/srio.c
index e46d328..77fa32f 100644
--- a/arch/powerpc/cpu/mpc8xxx/srio.c
+++ b/arch/powerpc/cpu/mpc8xxx/srio.c
@@ -21,6 +21,10 @@
#include
#include
#include
+#include
+
+#define SRIO_PORT_ACCEPT_ALL 0x1001
+#define SRIO_IB_ATMU_AR 0x80f55000
#if defined(CONFIG_FSL_CORENET)
#define _DEVDISR_SRIO1 FSL_CORENET_DEVDISR_SRIO1
@@ -84,3 +88,50 @@ void srio_init(void)
setbits_be32(&gur->devdisr, _DEVDISR_RMU);
}
}
+
+#ifdef CONFIG_SRIOBOOT_MASTER
+void srio_boot_master(void)
+{
+ struct ccsr_rio *srio = (void *)CONFIG_SYS_FSL_SRIO_ADDR;
+
+ /* set port accept-all */
+ out_be32((void *)&srio->impl.port[CONFIG_SRIOBOOT_MASTER_PORT].ptaacr,
+ SRIO_PORT_ACCEPT_ALL);
+
+ debug("SRIOBOOT - MASTER: Master port [ %d ] for srio boot.\n",
+ CONFIG_SRIOBOOT_MASTER_PORT);
+ /* configure inbound window5 for slave's u-boot image */
+ debug("SRIOBOOT - MASTER: Inbound window 5 for slave's image; "
+ "Local = 0x%llx, Srio = 0x%llx, Size = 0x%x\n",
+ (u64)CONFIG_SRIOBOOT_SLAVE_IMAGE_LAW_PHYS1,
+ (u64)CONFIG_SRIOBOOT_SLAVE_IMAGE_SRIO_PHYS1,
+ CONFIG_SRIOBOOT_SLAVE_IMAGE_SIZE);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[0].riwtar,
+ CONFIG_SRIOBOOT_SLAVE_IMAGE_LAW_PHYS1 >> 12);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[0].riwbar,
+ CONFIG_SRIOBOOT_SLAVE_IMAGE_SRIO_PHYS1 >> 12);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[0].riwar,
+ SRIO_IB_ATMU_AR
+ | atmu_size_mask(CONFIG_SRIOBOOT_SLAVE_IMAGE_SIZE));
+
+ /* configure inbound window4 for slave's u-boot image */
+ debug("SRIO
[U-Boot] [PATCH 3/8 v2] powerpc/corenet_ds: Document for the boot from SRIO
This document describes the implementation of the boot from SRIO, includes the introduction of envionment, an example based on P4080DS platform, an example of the slave's RCW, and the description about how to use this feature. Signed-off-by: Liu Gang --- Changes in v2: - Subject changed to "powerpc/corenet_ds". - Change the name of the document for "corenet" platform. doc/README.srio-boot-corenet | 103 ++ 1 files changed, 103 insertions(+), 0 deletions(-) create mode 100644 doc/README.srio-boot-corenet diff --git a/doc/README.srio-boot-corenet b/doc/README.srio-boot-corenet new file mode 100644 index 000..56b094c --- /dev/null +++ b/doc/README.srio-boot-corenet @@ -0,0 +1,103 @@ +-- +SRIO Boot on Corenet Platforms +-- + +For some PowerPC processors with SRIO interface, boot location can be configured +to SRIO by RCW. The processor booting from SRIO can do without flash for u-boot +image, ucode and ENV. All the images can be fetched from another processor's +memory space by SRIO link connected between them. + +This document describes the processes based on an example implemented on P4080DS +platforms and a RCW example with boot from SRIO configuration. + +Environment of the SRIO boot: + a) Master and slave can be SOCs in one board or SOCs in separate boards. + b) They are connected with SRIO links, whether 1x or 4x, and directly or + through switch system. + c) Only Master has NorFlash for booting, and all the Master's and Slave's + U-Boot images, UCodes will be stored in this flash. + d) Slave has its own EEPROM for RCW and PBI. + e) Slave's RCW should configure the SerDes for SRIO boot port, set the boot + location to SRIO, and holdoff all the cores if needed. + + ----- --- + | | | | | | + | | | | | | + | NorFlash|<->| Master |SRIO | Slave |<>[EEPROM] + | | | |<===>| | + | | | | | | + ----- --- + +The example based on P4080DS platform: + Two P4080DS platforms can be used to implement the boot from SRIO. Their SRIO + ports 0 will be connected directly and will be used for the boot from SRIO. + + 1. Slave's RCW example for boot from SRIO port 0 and core 0 not in holdoff. + : aa55 aa55 010e 0100 0c58 + 0010: 1818 1818 7440 4000 2000 + 0020: f400 0100 + 0030: 0083 + 0040: 0813 8040 698b 93fe + + 2. Slave's RCW example for boot from SRIO port 0 and all cores in holdoff. + : aa55 aa55 010e 0100 0c58 + 0010: 1818 1818 7440 4000 2000 + 0020: f440 0100 + 0030: 0083 + 0040: 0813 8040 063c 778f + + 3. Sequence in Step by Step. + a) Update RCW for slave with boot from SRIO port 0 configuration. + b) Program slave's U-Boot image, UCode, and ENV parameters into master's + NorFlash. + c) Start up master and it will boot up normally from its NorFlash. + Then, it will finish necessary configurations for slave's boot from + SRIO port 0. + d) Master will set inbound SRIO windows covered slave's U-Boot image stored + in master's NorFlash. + e) Master will set an inbound SRIO window covered slave's UCode stored in + master's NorFlash. + f) Master will set an inbound SRIO window covered slave's ENV stored in + master's NorFlash. + g) If need to release slave's core, master will set outbound SRIO windows + in order to configure slave's registers for the core's releasing. + h) If all cores of slave in holdoff, slave should be powered on before all + the above master's steps, and wait to be released by master. If not all + cores in holdoff, that means core 0 will start up normally, slave should + be powered on after all the above master's steps. In the startup phase + of the slave from SRIO, it will finish some necessary configurations. + i) Slave will set a specific TLB entry for the boot process. + j) Slave will set a LAW entry with the TargetI
[U-Boot] [PATCH 2/8 v2] powerpc/corenet_ds: Correct the compilation errors about ENV
When defined CONFIG_ENV_IS_NOWHERE, there will be some compilation errors: ./common/env_nowhere.o: In function `env_relocate_spec': ./common/env_nowhere.c:38: multiple definition of `env_relocate_spec' ./common/env_flash.o: ./common/env_flash.c:326: first defined here ./common/env_nowhere.o: In function `env_get_char_spec': ./common/env_nowhere.c:42: multiple definition of `env_get_char_spec' ./common/env_flash.o:./common/env_flash.c:78: first defined here ./common/env_nowhere.o: In function `env_init': ./common/env_nowhere.c:51: multiple definition of `env_init' ./common/env_flash.o:./common/env_flash.c:237: first defined here make[1]: *** [./common/libcommon.o] Error 1 make[1]: Leaving directory `./common' make: *** [./common/libcommon.o] Error 2 Remove the CONFIG_ENV_IS_IN_FLASH if defined CONFIG_ENV_IS_NOWHERE. Signed-off-by: Liu Gang --- Changes in v2: - Subject changed to "powerpc/corenet_ds". - Change the commit message more clearly. include/configs/corenet_ds.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/corenet_ds.h b/include/configs/corenet_ds.h index 7925b95..e38f69d 100644 --- a/include/configs/corenet_ds.h +++ b/include/configs/corenet_ds.h @@ -96,6 +96,8 @@ #define CONFIG_ENV_IS_IN_NAND #define CONFIG_ENV_SIZECONFIG_SYS_NAND_BLOCK_SIZE #define CONFIG_ENV_OFFSET (5 * CONFIG_SYS_NAND_BLOCK_SIZE) +#elif defined(CONFIG_ENV_IS_NOWHERE) +#define CONFIG_ENV_SIZE0x2000 #else #define CONFIG_ENV_IS_IN_FLASH #define CONFIG_ENV_ADDR(CONFIG_SYS_MONITOR_BASE - CONFIG_ENV_SECT_SIZE) -- 1.7.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/8 v2] powerpc/srio: Rewrite the struct ccsr_rio
Rewrite this struct for the support of two ports and two message
units registers.
Signed-off-by: Liu Gang
---
Changes in v2:
- Change the subject and commit message.
- Remove the offsets in the comments.
- Rewrite the struct for the support of two ports
and two message units registers.
arch/powerpc/include/asm/immap_85xx.h | 383 +++--
1 files changed, 223 insertions(+), 160 deletions(-)
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index 9b08cb8..a65fc1c 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1353,171 +1353,234 @@ typedef struct ccsr_cpm {
} ccsr_cpm_t;
#endif
-/* RapidIO Registers */
-typedef struct ccsr_rio {
- u32 didcar; /* Device Identity Capability */
- u32 dicar; /* Device Information Capability */
- u32 aidcar; /* Assembly Identity Capability */
- u32 aicar; /* Assembly Information Capability */
- u32 pefcar; /* Processing Element Features Capability */
- u32 spicar; /* Switch Port Information Capability */
- u32 socar; /* Source Operations Capability */
- u32 docar; /* Destination Operations Capability */
+#define SRIO_PORT_MAX_NUM 2 /* SRIO port max number */
+#define SRIO_OB_WIN_NUM9 /* SRIO outbound window number */
+#define SRIO_IB_WIN_NUM5 /* SRIO inbound window number */
+#define SRIO_MSG_UNIT_NUM 2 /* SRIO message unit number */
+
+/* Architectural regsiters */
+struct rio_arch {
+ u32 didcar; /* Device Identity CAR */
+ u32 dicar; /* Device Information CAR */
+ u32 aidcar; /* Assembly Identity CAR */
+ u32 aicar; /* Assembly Information CAR */
+ u32 pefcar; /* Processing Element Features CAR */
+ u8 res0[4];
+ u32 socar; /* Source Operations CAR */
+ u32 docar; /* Destination Operations CAR */
u8 res1[32];
- u32 msr;/* Mailbox Cmd And Status */
- u32 pwdcsr; /* Port-Write & Doorbell Cmd And Status */
+ u32 mcsr; /* Mailbox CSR */
+ u32 pwdcsr; /* Port-Write and Doorbell CSR */
u8 res2[4];
u32 pellccsr; /* Processing Element Logic Layer CCSR */
u8 res3[12];
- u32 lcsbacsr; /* Local Cfg Space Base Addr Cmd & Status */
- u32 bdidcsr;/* Base Device ID Cmd & Status */
+ u32 lcsbacsr; /* Local Configuration Space BACSR */
+ u32 bdidcsr;/* Base Device ID CSR */
u8 res4[4];
- u32 hbdidlcsr; /* Host Base Device ID Lock Cmd & Status */
- u32 ctcsr; /* Component Tag Cmd & Status */
- u8 res5[144];
- u32 pmbh0csr; /* Port Maint. Block Hdr 0 Cmd & Status */
- u8 res6[28];
- u32 pltoccsr; /* Port Link Time-out Ctrl Cmd & Status */
- u32 prtoccsr; /* Port Response Time-out Ctrl Cmd & Status */
- u8 res7[20];
- u32 pgccsr; /* Port General Cmd & Status */
- u32 plmreqcsr; /* Port Link Maint. Request Cmd & Status */
- u32 plmrespcsr; /* Port Link Maint. Response Cmd & Status */
- u32 plascsr;/* Port Local Ackid Status Cmd & Status */
- u8 res8[12];
- u32 pescsr; /* Port Error & Status Cmd & Status */
- u32 pccsr; /* Port Control Cmd & Status */
- u8 res9[65184];
- u32 cr; /* Port Control Cmd & Status */
- u8 res10[12];
- u32 pcr;/* Port Configuration */
- u32 peir; /* Port Error Injection */
- u8 res11[3048];
- u32 rowtar0;/* RIO Outbound Window Translation Addr 0 */
- u8 res12[12];
- u32 rowar0; /* RIO Outbound Attrs 0 */
- u8 res13[12];
- u32 rowtar1;/* RIO Outbound Window Translation Addr 1 */
- u8 res14[4];
- u32 rowbar1;/* RIO Outbound Window Base Addr 1 */
- u8 res15[4];
- u32 rowar1; /* RIO Outbound Attrs 1 */
- u8 res16[12];
- u32 rowtar2;/* RIO Outbound Window Translation Addr 2 */
- u8 res17[4];
- u32 rowbar2;/* RIO Outbound Window Base Addr 2 */
- u8 res18[4];
- u32 rowar2; /* RIO Outbound Attrs 2 */
- u8 res19[12];
- u32 rowtar3;/* RIO Outbound Window Translation Addr 3 */
- u8 res20[4];
- u32 rowbar3;/* RIO Outbound Window Base Addr 3 */
- u8 res21[4];
- u32 rowar3; /* RIO Outbound Attrs 3 */
- u8 res22[12];
- u32 rowtar4;
Re: [U-Boot] [PATCH 1/2] image: add support for Android's boot image format
Dear Wolfgang, On Wednesday 23 November 2011 03:33 PM, Sebastian Andrzej Siewior wrote: * Wolfgang Denk | 2011-11-22 20:04:47 [+0100]: Dear Sebastian Andrzej Siewior, In message<2022123007.ga5...@linutronix.de> you wrote: + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * * Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in + *the documentation and/or other materials provided with the + *distribution. Sorry, but this is not GPL compatible. Ehm. Is this the All rights reserved issue? If so then I assumed that I cleared up things in No, it's the "Redistributions in binary form must reproduce..." clause. How so? If you distribute it as source nothing changes. I don't see much difference in binary form either: section 1 of the GPL says |.. keep intact all the notices that refer to this License and to the |absence of any warranty; and give any other recipients of the Program a |copy of this License along with the Program. and this is no different. It does not mention whether the software has to be passed in source or binary form. The BSD part does not push any restrictions on the GPL, it "wants" the same thing. Section 6 of the GPL says that by redistributing the receiptient should receive a copy of this license. The section you mentioed is no different. If you distribute GPL in binary code you have let the receiptient know, that he is using GPL code. A note in the documentation is enough as far as I know [if remeber correctly Harald went after a few companies which were using Linux and were not letting the customers know about it]. If you look at the fresh released Quake3 source [0] you see that there is a readme file which points out that it is GPL code and enumerates various other licenses. So right now, I don't see why those two should not be compatible. Plus the FSF claims that they are [1]. [0] https://github.com/TTimo/doom3.gpl [1] http://www.gnu.org/licenses/license-list.html#FreeBSD What is your final call on this? The above arguments sound convincing to me, but I have to admit that I am no legal expert. Either way, it will be great to have a closure on this. Lack of fastboot support was the greatest impediment to adoption of mainline U-Boot in our previous platforms. It will be really unfortunate if the same happens to OMAP5 that has just arrived. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/8 v2] powerpc/corenet_ds: Slave uploads ucode when boot from SRIO
When boot from SRIO, slave's ucode can be stored in master's memory space,
then slave can fetch the ucode image through SRIO interface. For the
corenet platform, ucode is for Fman.
Master needs to:
1. Put the slave's ucode image into it's own memory space.
2. Set an inbound SRIO window covered slave's ucode stored in master's
memory space.
Slave needs to:
1. Set a specific TLB entry in order to fetch ucode from master.
2. Set a LAW entry with the TargetID SRIO1 or SRIO2 for ucode.
Signed-off-by: Liu Gang
Signed-off-by: Shaohui Xie
---
Changes in v2:
- Subject changed to "powerpc/corenet_ds".
- Use "(void *)" instead of "(u32)" when calling "out_be32()".
- Use "NOR flash" instead of "Nor flash".
- Get rid of the base address + offset notation. Use C structs
instead.
- Get rid of hard coded magic numbers. Use macro instead.
- Use "debug()" instead of "printf()".
- Correct some comment style errors.
arch/powerpc/cpu/mpc8xxx/srio.c| 25 +
board/freescale/common/p_corenet/law.c |4
board/freescale/common/p_corenet/tlb.c | 10 ++
include/configs/corenet_ds.h | 12 +++-
4 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/srio.c b/arch/powerpc/cpu/mpc8xxx/srio.c
index 77fa32f..e593f22 100644
--- a/arch/powerpc/cpu/mpc8xxx/srio.c
+++ b/arch/powerpc/cpu/mpc8xxx/srio.c
@@ -100,8 +100,8 @@ void srio_boot_master(void)
debug("SRIOBOOT - MASTER: Master port [ %d ] for srio boot.\n",
CONFIG_SRIOBOOT_MASTER_PORT);
- /* configure inbound window5 for slave's u-boot image */
- debug("SRIOBOOT - MASTER: Inbound window 5 for slave's image; "
+ /* configure inbound window for slave's u-boot image */
+ debug("SRIOBOOT - MASTER: Inbound window for slave's image; "
"Local = 0x%llx, Srio = 0x%llx, Size = 0x%x\n",
(u64)CONFIG_SRIOBOOT_SLAVE_IMAGE_LAW_PHYS1,
(u64)CONFIG_SRIOBOOT_SLAVE_IMAGE_SRIO_PHYS1,
@@ -117,8 +117,8 @@ void srio_boot_master(void)
SRIO_IB_ATMU_AR
| atmu_size_mask(CONFIG_SRIOBOOT_SLAVE_IMAGE_SIZE));
- /* configure inbound window4 for slave's u-boot image */
- debug("SRIOBOOT - MASTER: Inbound window 4 for slave's image; "
+ /* configure inbound window for slave's u-boot image */
+ debug("SRIOBOOT - MASTER: Inbound window for slave's image; "
"Local = 0x%llx, Srio = 0x%llx, Size = 0x%x\n",
(u64)CONFIG_SRIOBOOT_SLAVE_IMAGE_LAW_PHYS2,
(u64)CONFIG_SRIOBOOT_SLAVE_IMAGE_SRIO_PHYS2,
@@ -133,5 +133,22 @@ void srio_boot_master(void)
.port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[1].riwar,
SRIO_IB_ATMU_AR
| atmu_size_mask(CONFIG_SRIOBOOT_SLAVE_IMAGE_SIZE));
+
+ /* configure inbound window for slave's ucode */
+ debug("SRIOBOOT - MASTER: Inbound window for slave's ucode; "
+ "Local = 0x%llx, Srio = 0x%llx, Size = 0x%x\n",
+ (u64)CONFIG_SRIOBOOT_SLAVE_UCODE_LAW_PHYS,
+ (u64)CONFIG_SRIOBOOT_SLAVE_UCODE_SRIO_PHYS,
+ CONFIG_SRIOBOOT_SLAVE_UCODE_SIZE);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[2].riwtar,
+ CONFIG_SRIOBOOT_SLAVE_UCODE_LAW_PHYS >> 12);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[2].riwbar,
+ CONFIG_SRIOBOOT_SLAVE_UCODE_SRIO_PHYS >> 12);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[2].riwar,
+ SRIO_IB_ATMU_AR
+ | atmu_size_mask(CONFIG_SRIOBOOT_SLAVE_UCODE_SIZE));
}
#endif
diff --git a/board/freescale/common/p_corenet/law.c
b/board/freescale/common/p_corenet/law.c
index 1fbab4d..c4566dd 100644
--- a/board/freescale/common/p_corenet/law.c
+++ b/board/freescale/common/p_corenet/law.c
@@ -52,9 +52,13 @@ struct law_entry law_table[] = {
#if defined(CONFIG_SRIOBOOT_SLAVE_PORT0)
SET_LAW(CONFIG_SYS_SRIOBOOT_SLAVE_ADDR_PHYS,
LAW_SIZE_1M, LAW_TRGT_IF_RIO_1),
+ SET_LAW(CONFIG_SYS_SRIOBOOT_UCODE_ENV_ADDR_PHYS,
+ LAW_SIZE_1M, LAW_TRGT_IF_RIO_1),
#elif defined(CONFIG_SRIOBOOT_SLAVE_PORT1)
SET_LAW(CONFIG_SYS_SRIOBOOT_SLAVE_ADDR_PHYS,
LAW_SIZE_1M, LAW_TRGT_IF_RIO_2),
+ SET_LAW(CONFIG_SYS_SRIOBOOT_UCODE_ENV_ADDR_PHYS,
+ LAW_SIZE_1M, LAW_TRGT_IF_RIO_2),
#endif
#endif
};
diff --git a/board/freescale/common/p_corenet/tlb.c
b/board/freescale/common/p_corenet/tlb.c
index a8c8b3c..6bb4c3f 100644
--- a/board/freescale/common/p_core
Re: [U-Boot] [PATCH 3/3] WIP: tegra: i2c: Enable new I2C framework
Hello Simon,
Simon Glass wrote:
> This is just a rough patch to show how this might be done.
>
> Not to be applied, please.
>
> Signed-off-by: Simon Glass
> ---
> drivers/i2c/tegra2_i2c.c | 53 +++
> include/configs/seaboard.h |2 +
> 2 files changed, 25 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/i2c/tegra2_i2c.c b/drivers/i2c/tegra2_i2c.c
> index b42d9ac..93f3269 100644
> --- a/drivers/i2c/tegra2_i2c.c
> +++ b/drivers/i2c/tegra2_i2c.c
> @@ -30,7 +30,9 @@
> #include
> #include
> #include
> +
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -296,12 +298,7 @@ static int tegra2_i2c_read_data(u32 addr, u8 *data, u32
> len)
> #error "Please enable device tree support to use this driver"
> #endif
>
> -unsigned int i2c_get_bus_speed(void)
> -{
> - return i2c_controllers[i2c_bus_num].speed;
> -}
> -
> -int i2c_set_bus_speed(unsigned int speed)
> +uint tegra_i2c_set_bus_speed(unsigned int speed)
static
> {
> struct i2c_bus *i2c_bus;
>
> @@ -309,7 +306,7 @@ int i2c_set_bus_speed(unsigned int speed)
> i2c_bus->speed = speed;
> i2c_init_controller(i2c_bus);
>
> - return 0;
> + return 0; /* TODO: return actual speed */
> }
>
> static int i2c_get_config(const void *blob, int node, struct i2c_bus
> *i2c_bus)
> @@ -404,7 +401,7 @@ int i2c_init_board(void)
> return 0;
> }
>
> -void i2c_init(int speed, int slaveaddr)
> +void tegra_i2c_init(int speed, int slaveaddr)
static, add this for all functions
[...]
> diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h
> index d2d0115..64c804a 100644
> --- a/include/configs/seaboard.h
> +++ b/include/configs/seaboard.h
> @@ -79,6 +79,8 @@
> #define CONFIG_SYS_MAX_I2C_BUS 4
This define is no longer valid if using the new framework.
Do you have really 4 busses with only one i2c adapter?
This works only, if you have i2c muxes! In this case you have to
define
/*
* how many muxes are maximal consecutively connected on
* one i2c bus
*/
#define CONFIG_SYS_I2C_MAX_HOPS 1
and for example using a PCA9547 mux:
#define CONFIG_SYS_I2C_BUSSES { {0, {I2C_NULL_HOP}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 1}}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 2}}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 3}}},
}
or you use other i2c adapters like soft_i2c, but I could not see
this in your patch ... and in this case you must define
CONFIG_SYS_NUM_I2C_ADAPTERS ...
> #define CONFIG_SYS_I2C_SPEED 10
should not longer be defined, instead you should make a option to define
a i2c speed for your i2c driver ... for example
#define CONFIG_SYS_I2C_TEGRA2_SPEED 10
> #define CONFIG_CMD_I2C
> +#define CONFIG_SYS_I2C
> +#define CONFIG_SYS_I2C_ADAPTERS {&tegra_i2c_adap}
You must have a define in drivers/i2c/Makefile which "activates" your
drivers/i2c/tegra2_i2c.c ... this must defined in your board config
file too (maybe a CONFIG_SYS_I2C_TEGRA2 ?)!
Also you must have a change in drivers/i2c/i2c_core.c
#ifdef CONFIG_SYS_I2C_TEGRA2
extern struct i2c_adap tegra_i2c_adap[];
#endif
or?
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 0/3] Bring in new I2C framework
Hello Simon, Simon Glass wrote: > This series provides Heiko's upgraded I2C framework from a few years ago. > I hope that we can bring this in and move boards over to it as time > permits, rather than switching everything in one fell swoop which never > happens. Ok, lets try it! > To show it working I have enabled it for Tegra in a very rough way. It > seems fine with my limited testing. Great! Thanks! Patches for other i2c drivers can be found here: http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=shortlog;h=refs/heads/multibus_v2_2012 They just need a rebase and an update to your changes (and of course some tests) > In terms of changes, I have just fixed some checkpatch errors and fiddled > with a couple of function signatures. > > I will start a thread on the list with a few thoughts on this series > at some point. Ok, thanks. Here some thoughts comming in my mind: - Why a "cur_adap" added in gd_t: - This points allways to the current used i2c adapter. - because gd_t is writeable when running in flash, complete multiadapter/multibus functionality is usable, when running in flash, which is needed for some SoCs. - using a pointer brings faster accesses to the i2c_adapter_t struct and saves some bytes here and there. - init from a i2c controller: In current code all i2c controllers, as a precaution, getting initialized. In the new code, a i2c controller gets only initialized if it is used. This is done in i2c_set_bus_num(). Also, with this approach, we can easy add in a second step, a i2c_deinit() function, called from i2c_set_bus_num(), so we can easy deactivate a no longer used controller. - added "hw_adapnr" in i2c_adapter_t struct: when for example a CPU has more then one i2c controller we can use this variable to differentiate which controller the actual i2c adapter uses. - Maybe we should add a base_addr field in struct i2c_adapter? This would help for SoCs, who have more then one identical controller, just differ in their base_addr... (Currently I made a function, or an array which returns the base_addr, dependend on "hw_adapnr"). We should drop this, and introduce a "base_addr" field. [...] bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] common, menu: do not trigger timeout again, if a line is read
Signed-off-by: Heiko Schocher
Cc: Jason Hobbs
---
common/menu.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/common/menu.c b/common/menu.c
index 754a9f9..aa16c9a 100644
--- a/common/menu.c
+++ b/common/menu.c
@@ -236,8 +236,10 @@ static inline int menu_interactive_choice(struct menu *m,
void **choice)
if (readret >= 0) {
choice_item = menu_item_by_key(m, cbuf);
- if (!choice_item)
+ if (!choice_item) {
printf("%s not found\n", cbuf);
+ m->timeout = 0;
+ }
} else {
puts("^C\n");
return -EINTR;
--
1.7.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
