[U-Boot] [PATCH] powerpc/p1022ds: nand: introduce the TPL based on the SPL
From: Ying Zhang b40...@freescale.com
Due to the nand SPL on the board P1022DS has a size limit, it can not be
more than 4K. So, the SPL cannot initialize the DDR with the SPD code.
This patch introduces TPL to enable a loader stub that runs in the L2 SRAM,
after being loaded by the code from the SPL. It initializes the DDR with
the SPD.
The TPL's size is sizeable, the maximum size must not exceed the size of L2
SRAM. It initializes the DDR through SPD code, and copys final uboot image
to DDR. So there are three stage uboot images:
* spl_boot, 4KB size, pad to 128K byte.
* tpl_boot, 88K size, pad to 128K size. The env variables are
copied to L2 SRAM, so that ddr SPD code can get the interleaving
mode setting in env. It loads final uboot image from offset 256KB.
* final uboot image, size is variable depends on the functions
enabled.
This patch is on top of the patch:
powerpc/p1022ds: boot from SD Card with SPL
Signed-off-by: Ying Zhang b40...@freescale.com
---
Makefile | 25 +++-
README | 55 ++-
arch/powerpc/config.mk |2 +
arch/powerpc/cpu/mpc85xx/spl_minimal.c | 16 ++
arch/powerpc/cpu/mpc85xx/u-boot-tpl.lds| 80 +
.../cpu/mpc8xxx/ddr/lc_common_dimm_params.c|4 +-
arch/powerpc/lib/Makefile |2 +
board/freescale/p1022ds/Makefile |3 +
board/freescale/p1022ds/spl_minimal.c | 56 +--
board/freescale/p1022ds/tlb.c |4 +-
board/freescale/p1022ds/tpl.c | 101
common/Makefile|9 +
common/cmd_nvedit.c|8 +-
config.mk | 32
doc/README.TPL | 93 +++
drivers/mtd/nand/Makefile |8 +
drivers/mtd/nand/fsl_elbc_tpl.c| 168
drivers/serial/serial.c|2 +-
include/bootstage.h|3 +-
include/configs/P1022DS.h | 75 +++--
tpl/Makefile | 161 +++
21 files changed, 824 insertions(+), 83 deletions(-)
create mode 100644 arch/powerpc/cpu/mpc85xx/u-boot-tpl.lds
create mode 100644 board/freescale/p1022ds/tpl.c
create mode 100644 doc/README.TPL
create mode 100644 drivers/mtd/nand/fsl_elbc_tpl.c
create mode 100644 tpl/Makefile
diff --git a/Makefile b/Makefile
index ef154aa..65849d1 100644
--- a/Makefile
+++ b/Makefile
@@ -118,10 +118,11 @@ endif # ifneq ($(BUILD_DIR),)
OBJTREE:= $(if $(BUILD_DIR),$(BUILD_DIR),$(CURDIR))
SPLTREE:= $(OBJTREE)/spl
+TPLTREE:= $(OBJTREE)/tpl
SRCTREE:= $(CURDIR)
TOPDIR := $(SRCTREE)
LNDIR := $(OBJTREE)
-export TOPDIR SRCTREE OBJTREE SPLTREE
+export TOPDIR SRCTREE OBJTREE SPLTREE TPLTREE
MKCONFIG := $(SRCTREE)/mkconfig
export MKCONFIG
@@ -412,9 +413,14 @@ ALL-y += $(obj)u-boot.srec $(obj)u-boot.bin
$(obj)System.map
ALL-$(CONFIG_NAND_U_BOOT) += $(obj)u-boot-nand.bin
ALL-$(CONFIG_ONENAND_U_BOOT) += $(obj)u-boot-onenand.bin
ALL-$(CONFIG_SPL) += $(obj)spl/u-boot-spl.bin
+ALL-$(CONFIG_TPL) += $(obj)tpl/u-boot-tpl.bin
ALL-$(CONFIG_OF_SEPARATE) += $(obj)u-boot.dtb $(obj)u-boot-dtb.bin
ifneq ($(CONFIG_SPL_TARGET),)
ALL-$(CONFIG_SPL) += $(obj)$(subst ,,$(CONFIG_SPL_TARGET))
+else
+ifneq ($(CONFIG_TPL_TARGET),)
+ALL-$(CONFIG_TPL) += $(obj)$(subst ,,$(CONFIG_TPL_TARGET))
+endif
endif
# enable combined SPL/u-boot/dtb rules for tegra
@@ -498,6 +504,18 @@ $(obj)u-boot-with-spl.bin: $(obj)spl/u-boot-spl.bin
$(obj)u-boot.bin
cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin $@
rm $(obj)spl/u-boot-spl-pad.bin
+$(obj)u-boot-with-tpl.bin: $(obj)spl/u-boot-spl.bin $(obj)tpl/u-boot-tpl.bin \
+ $(obj)u-boot.bin
+ $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SPL_PAD_TO) \
+ -I binary -O binary \
+ $(obj)spl/u-boot-spl.bin $(obj)spl/u-boot-spl-pad.bin
+ $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_TPL_PAD_TO) \
+ -I binary -O binary \
+ $(obj)tpl/u-boot-tpl.bin $(obj)tpl/u-boot-tpl-pad.bin
+ cat $(obj)spl/u-boot-spl-pad.bin $(obj)tpl/u-boot-tpl-pad.bin \
+ $(obj)u-boot.bin $@
+ rm $(obj)spl/u-boot-spl-pad.bin $(obj)tpl/u-boot-tpl-pad.bin
+
$(obj)u-boot-with-spl.imx: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
$(MAKE) -C $(SRCTREE)/arch/arm/imx-common \
$(OBJTREE)/u-boot-with-spl.imx
@@ -622,6 +640,9 @@ $(obj)u-boot-nand.bin:
Re: [U-Boot] [PATCH] video:lcd:cfb_console: cm_t35: Add CONFIG_SPLASH_SCREEN_PREPARE support to CONFIG_VIDEO
On 06/06/13 22:06, Robert Winkler wrote:
Hi All,
On Wed, Jun 5, 2013 at 1:31 AM, Igor Grinberg grinb...@compulab.co.il wrote:
Hi Robert,
On 06/04/13 21:11, Robert Winkler wrote:
Adding Anatolij to the CC list.
On Tue, Jun 4, 2013 at 8:10 AM, Robert Winkler
robert.wink...@boundarydevices.com wrote:
Hi Igor,
On Mon, Jun 3, 2013 at 11:10 PM, Igor Grinberg grinb...@compulab.co.il
wrote:
Hi Robert,
On 06/03/13 20:20, Robert Winkler wrote:
Also change splash_screen_prepare to a weak function.
You should be able to make a commit message a bit better.
Also, personally, I see here two functional changes and it would be better
to separate them into two patches:
1) Make the splash_screen_prepare() weak (I don't like this approach,
explanation below)
2) Add CONFIG_SPLASH_SCREEN_PREPARE support to CONFIG_VIDEO
We have considered making the splash_screen_prepare() function weak
in the past, but decided to make it a config option instead.
This way it is documented in the README and is selectable in the
board config.
Once you change it to be weak, there is no point in the config option
anymore... Personally, I don't like this approach.
Wolfgang said as long as I was fixing the bug of SPLASH_SCREEN_PREPARE
not working
for CONFIG_VIDEO I should change it to a weak function so that's what I
did.
See the email here:
http://lists.denx.de/pipermail/u-boot/2013-May/155478.html
Ok.
The major benefit of the construct (which Wolfgang wants to remove) is
clear code with no #ifdefs inside functions.
I don't have any special feelings for that construct, but I'd like to
keep #ifdefs out of any functions (the benefit).
I agree with you about the pointlessness of the CONFIG option and I
too like having
it documented in the README. That's the only reason I left the
#ifdefs in at all because
I didn't want to/didn't think I should remove the CONFIG altogether.
I'm not sure what the solution is.
...
some thoughts below...
Signed-off-by: Robert Winkler robert.wink...@boundarydevices.com
---
board/compulab/cm_t35/cm_t35.c | 2 +-
common/lcd.c | 10 --
drivers/video/cfb_console.c| 14 ++
3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/board/compulab/cm_t35/cm_t35.c
b/board/compulab/cm_t35/cm_t35.c
index b0b80e5..95098af 100644
--- a/board/compulab/cm_t35/cm_t35.c
+++ b/board/compulab/cm_t35/cm_t35.c
@@ -120,7 +120,7 @@ static inline int splash_load_from_nand(void)
}
#endif /* CONFIG_CMD_NAND */
-int board_splash_screen_prepare(void)
+int splash_screen_prepare(void)
{
char *env_splashimage_value;
u32 bmp_load_addr;
diff --git a/common/lcd.c b/common/lcd.c
index edae835..90f1143 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -1069,15 +1069,13 @@ int lcd_display_bitmap(ulong bmp_image, int x,
int y)
#endif
#ifdef CONFIG_SPLASH_SCREEN_PREPARE
-static inline int splash_screen_prepare(void)
-{
- return board_splash_screen_prepare();
-}
-#else
-static inline int splash_screen_prepare(void)
+int __splash_screen_prepare(void)
{
return 0;
}
+
+int splash_screen_prepare(void)
+ __attribute__ ((weak, alias(__splash_screen_prepare)));
#endif
You remove the #else statement, apparently you break the compilation for
!CONFIG_SPLASH_SCREEN_PREPARE, as the below lcd_logo() function references
the splash_screen_prepare() function.
Also, this means you force the code to have the ugly #ifdefs inside
functions - that is not really nice.
static void *lcd_logo(void)
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 0793f07..9180998 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -1966,6 +1966,16 @@ static void plot_logo_or_black(void *screen, int
width, int x, int y, int black)
#endif
}
+#ifdef CONFIG_SPLASH_SCREEN_PREPARE
+int __splash_screen_prepare(void)
+{
+ return 0;
+}
+
+int splash_screen_prepare(void)
+ __attribute__ ((weak, alias(__splash_screen_prepare)));
+#endif
Why duplicate the above?
Probably, just place it in a common location?
I asked Wolfgang about this in the original thread but haven't heard
back so I just submitted it
like this with the thought that CONFIG_VIDEO and CONFIG_LCD are never
used simultaneously and are
designed not to be (I could easily be wrong about that).
+
static void *video_logo(void)
{
char info[128];
@@ -1996,6 +2006,10 @@ static void *video_logo(void)
s = getenv(splashimage);
if (s != NULL) {
+#ifdef CONFIG_SPLASH_SCREEN_PREPARE
+ splash_screen_prepare();
+#endif
These are the ugly #ifdefs, I was talking about...
Agreed
I would recommend to just move the splash_screen_prepare() function
definition
to a common location and add the above function call (with no #ifdef
around).
And keep the meaningless CONFIG?
While I was writing the above, I meant to keep the #ifdef
Re: [U-Boot] [PATCH] cmd_bootm: Add command line arguments to Plan 9
Dear Steven Stallion, In message CAGGHmKH3W6SQSwG3qKJHQmRaxS7ZRVJmbLw_anvgNA61=pc...@mail.gmail.com you wrote: bootm has a well-known an documented API: it takes up to three arguments: kernel address, ramdisk address, and device tree address. Nothing else. Is there a reason that this should only be used by Linux? The changes I have submitted follow the same behavior as NetBSD. VxWorks and QNX also have their own quirks that don't follow the same path/usage as Linux. Agreed. But this should be documented, then. The usage seems to indicate this is a valid approach: Usage: bootm [addr [arg ...]] If this is such a contentious change, I'm happy to drop it. I was following the NetBSD approach since it was the most similar. It would be a shame to let it go - it's useful. Please do not misunderstand me - all I'm asking is to document the exact behaviour. Personally, I consider the interface a bad design, especially the different handling (or ignorance) of the bootargs setting depending on the number of arguments. But I agree that this has already crept in. It's a pity yo want to use exactly this interface, but it's you who has to use (and suffer from) it, so I won;t really block it. I've raised my concerns, that's all. Some ports (such as OMAP) will stop once it encounters the first non-ASCII character. In general, the parsing for the configuration is fairly strict and is only a small risk if a user configures the system incorrectly. Hm. This is just a subterfuge for there is no security at all, and you are invoking undefined behaviour ... This would only happen if a user did not configure the loader appropriately. ...which is just a typo away. There is also something subtle in not specifying confaddr (or bootargs for that matter). Many ports support loading configuration from a FAT file system. U-Boot would be no different. I don't see what this has to do with it? Plan 9 was traditionally loaded from FAT on PC architectures. Much of that support still exists today. Typically, a small FAT partition exists, which houses the kernel and the configuration (plan9.ini). With U-Boot, to emulate this behavior a fatload would be issued to copy the file to the proper location. This allows users to modify their configuration and reboot without having to drop into the U-Boot shell. You can still do this with U-Boot. I see no problems here. If do_plan9_bootm writes a NUL byte if no bootargs are defined, this would break the fatload method. Oops? I cannot parse this. You have no way to check for valid data, and you have no way to know the correct address, because it is neither fixed nor known to both the producer and the consumer? I'm sorry, but this is crap. It's known to both the producer and consumer, but can change during development. Having it compiled in also means that you do not have quick access to the value to use for a fatload, though this is a minor annoyance. I disagree. It appears that when you load a kernel image, there is no way to find out what the required confaddr would be. You have to know it. If you have several images with different settings, you always have to know exactly what is what. That's not exactly a robust (nor intelligent) setup. I'm sorry, but it appears this design is completely borked, so how should I answer this? If you have no way to know the correct adddress, and the consumer has no way to verify the data it recives, it's all just trial and error. Not exactly a robust design, that is. It's a known address for known kernels but needs to have the flexibility to change without a recompile. Personal feelings aside, this is how the kernel handles configuration at boot - I can only do so much. I don't know about Plan 9, but is there no way to pass this information to the boot loader? For example, if you were using a device tree, you could ncode it there, so UBoot could pick it up. Alternatively, you could use FIT images and include an extra blob with information (and if it's just the confaddr environment setting) for use in U-Boot, etc. ... I very much want these changes (or an acceptable version of them) to go upstream. Most users tend to just hack up U-Boot for the boards they use and maintain private forks, but I would like to see better support in both directions. I'm happy to keep a fork, but these changes do not seem onerous, especially given that other operating systems that are already supported follow this exact behavior. I do not intend to block this - I'm just pointing out issues I'm anticipating. 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 It may be that our role on this planet is not to worship God but to create him. -
Re: [U-Boot] [PATCH] cmd_bootm: Add command line arguments to Plan 9
Dear Steven Stallion,
In message 1370562103-92148-1-git-send-email-sstall...@gmail.com you wrote:
This patch introduces support for command line arguments to Plan 9.
Plan 9 generally dedicates a small region of kernel memory (known
as CONFADDR) for runtime configuration. A new environment variable
named confaddr was introduced to indicate this location when copying
arguments.
Signed-off-by: Steven Stallion sstall...@gmail.com
---
common/cmd_bootm.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 05130b6..5c62271 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -1533,6 +1533,7 @@ static int do_bootm_plan9(int flag, int argc, char *
const argv[],
bootm_headers_t *images)
{
void (*entry_point)(void);
+ char *s;
if ((flag != 0) (flag != BOOTM_STATE_OS_GO))
return 1;
@@ -1544,6 +1545,24 @@ static int do_bootm_plan9(int flag, int argc, char *
const argv[],
}
#endif
+ if ((s = getenv(confaddr)) != NULL) {
+ char *confaddr = (char *)simple_strtoul(s, NULL, 16);
+
+ if (argc 2) {
+ int i;
+
+ s = confaddr;
+ for (i = 2; i argc; i++) {
+ if (i 2)
+ *s++ = '\n';
+ strcpy(s, argv[i]);
+ s += strlen(argv[i]);
+ }
+ } else if ((s = getenv(bootargs)) != NULL) {
+ strcpy(confaddr, s);
+ }
+ }
+
This is basically the same code (with only irrelevant differences) as
used by do_bootm_netbsd(). Can you please
1) factor out this common code, and
2) documnt the behaviour
?
By the way: this patch still triggers two do not use assignment in if
condition checkpoatch errors. Please fix these, too.
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
Advice is seldom welcome; and those who want it the most always like
it the least. -- Philip Earl of Chesterfield
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/11] MIPS: bootm: refactor initialisation of kernel cmdline
Dear Daniel Schwierzeck,
In message 1370731370-32767-5-git-send-email-daniel.schwierz...@gmail.com you
wrote:
Move initialisation of Linux command line to separate functions.
Also add support for bootm subcommand 'cmdline'.
+static void linux_cmdline_dump(void)
+{
+#ifdef DEBUG
+ int i;
+
+ printf(## cmdline argv at 0x%p, argp at 0x%p\n,
+linux_argv, linux_argp);
+
+ for (i = 1; i linux_argc; i++)
+ printf( arg %03d: %s\n, i, linux_argv[i]);
+#endif
+}
Please remove the #ifdef here, and change printf() into debug()
instead.
+ while (next quote quote next) {
+ /* we found a left quote before the next blank
+ * now we have to find the matching right quote
+ */
Incorrect multiline comment style.
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
IMPORTANT NOTICE TO PURCHASERS: The Entire Physical Universe, Inclu-
ding This Product, May One Day Collapse Back into an Infinitesimally
Small Space. Should Another Universe Subsequently Re-emerge, the
Existence of This Product in That Universe Cannot Be Guaranteed.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Hi Lubomir, On 06/08/13 23:43, Lubomir Popov wrote: Hi Tom, Michael, Hello, The following changes since commit 3da0e5750b24a9491058df6126c7be577a276c09: arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to 80dd596d1b442ff53dbeb33eccdb8efd2283be79: [snip] Michael Trimarchi (1): usb: omap: ulpi: fix ulpi transceiver access [snip] drivers/usb/ulpi/omap-ulpi-viewport.c | 40 +- [snip] I just made a clean clone of u-boot-ti/master, manually applied the changes to the ehci files, added my board files and made a build. Everything seems to work fine, but I see an error message regarding ULPI reset that was not present before, and obviously it is due to Michael's changes: Yes indeed, those are due to Michael's patch. Michael's patch aligns the code with the TRM and seems to reveal an OMAP USB bug might an erratum. SOM5_EVB # usb start (Re)start USB... USB0: ULPI: ulpi_reset: failed writing reset bit USB EHCI 1.00 scanning bus 0 for devices... 6 USB Device(s) found scanning usb for storage devices... 3 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found SOM5_EVB # usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Mass Storage (480 Mb/s, 200mA) |FSC MEMORYBIRD USB2 C157040817120315AA | +-3 Hub (480 Mb/s, 2mA) | | | +-4 Mass Storage (480 Mb/s, 96mA) | |Generic Ultra Fast Media Reader 00264001 | | | +-5 Mass Storage (480 Mb/s, 100mA) | USB Flash Drive 531C43B21928F11F | +-6 Vendor specific (480 Mb/s, 500mA) SOM5_EVB # Otherwise everything is OK, the device on the ULPI port is working (it is #2 above). It is now late and I shall investigate in detail tomorrow, this is just an early warning ;) Best regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] powerpc/85xx: Add P1023RDB board support
P1023RDB Specification:
---
Memory subsystem:
512MB DDR3 (Fixed DDR on board)
64MB NOR flash
128MB NAND flash
Ethernet:
eTSEC1: Connected to Atheros AR8035 GETH PHY
eTSEC2: Connected to Atheros AR8035 GETH PHY
PCIe:
Three mini-PCIe slots
USB: Two USB2.0 Type A ports
I2C:
AT24C08 8K Board EEPROM (8 bit address)
Signed-off-by: Chunhe Lan chunhe@freescale.com
Cc: Scott Wood scottw...@freescale.com
---
arch/powerpc/cpu/mpc85xx/Makefile |1 +
board/freescale/p1023rdb/Makefile | 33 +++
board/freescale/p1023rdb/ddr.c | 105 +
board/freescale/p1023rdb/law.c | 34 +++
board/freescale/p1023rdb/p1023rdb.c | 161 ++
board/freescale/p1023rdb/tlb.c | 115 ++
boards.cfg |1 +
include/configs/P1023RDB.h | 406 +++
8 files changed, 856 insertions(+), 0 deletions(-)
create mode 100644 board/freescale/p1023rdb/Makefile
create mode 100644 board/freescale/p1023rdb/ddr.c
create mode 100644 board/freescale/p1023rdb/law.c
create mode 100644 board/freescale/p1023rdb/p1023rdb.c
create mode 100644 board/freescale/p1023rdb/tlb.c
create mode 100644 include/configs/P1023RDB.h
diff --git a/arch/powerpc/cpu/mpc85xx/Makefile
b/arch/powerpc/cpu/mpc85xx/Makefile
index 2318064..4669883 100644
--- a/arch/powerpc/cpu/mpc85xx/Makefile
+++ b/arch/powerpc/cpu/mpc85xx/Makefile
@@ -73,6 +73,7 @@ COBJS-$(CONFIG_P1014) += ddr-gen3.o
COBJS-$(CONFIG_P1020) += ddr-gen3.o
COBJS-$(CONFIG_P1021) += ddr-gen3.o
COBJS-$(CONFIG_P1022) += ddr-gen3.o
+COBJS-$(CONFIG_P1023) += ddr-gen3.o
COBJS-$(CONFIG_P1024) += ddr-gen3.o
COBJS-$(CONFIG_P1025) += ddr-gen3.o
COBJS-$(CONFIG_P2010) += ddr-gen3.o
diff --git a/board/freescale/p1023rdb/Makefile
b/board/freescale/p1023rdb/Makefile
new file mode 100644
index 000..45c4f8b
--- /dev/null
+++ b/board/freescale/p1023rdb/Makefile
@@ -0,0 +1,33 @@
+#
+# Copyright 2013 Freescale Semiconductor, Inc.
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by the Free
+# Software Foundation; either version 2 of the License, or (at your option)
+# any later version.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS-y+= $(BOARD).o
+COBJS-y+= ddr.o
+COBJS-y+= law.o
+COBJS-y+= tlb.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/freescale/p1023rdb/ddr.c b/board/freescale/p1023rdb/ddr.c
new file mode 100644
index 000..7ed275a
--- /dev/null
+++ b/board/freescale/p1023rdb/ddr.c
@@ -0,0 +1,105 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include asm/mmu.h
+#include asm/immap_85xx.h
+#include asm/processor.h
+#include asm/fsl_ddr_sdram.h
+#include asm/fsl_ddr_dimm_params.h
+#include asm/io.h
+#include asm/fsl_law.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* CONFIG_SYS_DDR_RAW_TIMING */
+/*
+ * Hynix H5TQ1G83TFR-H9C
+ */
+dimm_params_t ddr_raw_timing = {
+ .n_ranks = 1,
+ .rank_density = 536870912u,
+ .capacity = 536870912u,
+ .primary_sdram_width = 32,
+ .ec_sdram_width = 0,
+ .registered_dimm = 0,
+ .mirrored_dimm = 0,
+ .n_row_addr = 14,
+ .n_col_addr = 10,
+ .n_banks_per_sdram_device = 8,
+ .edc_config = 0,
+ .burst_lengths_bitmask = 0x0c,
+
+ .tCKmin_X_ps = 1875,
+ .caslat_X = 0x1e 4, /* 5,6,7,8 */
+ .tAA_ps = 13125,
+ .tWR_ps = 18000,
+ .tRCD_ps = 13125,
+ .tRRD_ps = 7500,
+ .tRP_ps = 13125,
+ .tRAS_ps = 37500,
+ .tRC_ps = 50625,
+ .tRFC_ps = 16,
+ .tWTR_ps = 7500,
+ .tRTP_ps = 7500,
+
Re: [U-Boot] [PATCH 04/11] MIPS: bootm: refactor initialisation of kernel cmdline
2013/6/9 Wolfgang Denk w...@denx.de:
Dear Daniel Schwierzeck,
In message 1370731370-32767-5-git-send-email-daniel.schwierz...@gmail.com
you wrote:
Move initialisation of Linux command line to separate functions.
Also add support for bootm subcommand 'cmdline'.
+static void linux_cmdline_dump(void)
+{
+#ifdef DEBUG
+ int i;
+
+ printf(## cmdline argv at 0x%p, argp at 0x%p\n,
+linux_argv, linux_argp);
+
+ for (i = 1; i linux_argc; i++)
+ printf( arg %03d: %s\n, i, linux_argv[i]);
+#endif
+}
Please remove the #ifdef here, and change printf() into debug()
instead.
I will change it
+ while (next quote quote next) {
+ /* we found a left quote before the next blank
+ * now we have to find the matching right quote
+ */
Incorrect multiline comment style.
a left-over from the original code. I will fix it in patch 01/11.
Thanks,
Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 01/11] MIPS: bootm: fix checkpatch.pl warnings
Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
Changes in v2:
- fix multi-line comment
arch/mips/lib/bootm.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
index a36154a..148c18b 100644
--- a/arch/mips/lib/bootm.c
+++ b/arch/mips/lib/bootm.c
@@ -57,7 +57,7 @@ static void boot_prep_linux(bootm_headers_t *images)
#else
sprintf(env_buf, %lu, (ulong)(gd-ram_size 20));
debug(## Giving linux memsize in MB, %lu\n,
- (ulong)(gd-ram_size 20));
+ (ulong)(gd-ram_size 20));
#endif /* CONFIG_MEMSIZE_IN_BYTES */
linux_env_set(memsize, env_buf);
@@ -130,9 +130,9 @@ static void linux_params_init(ulong start, char *line)
char *next, *quote, *argp;
linux_argc = 1;
- linux_argv = (char **) start;
+ linux_argv = (char **)start;
linux_argv[0] = 0;
- argp = (char *) (linux_argv + LINUX_MAX_ARGS);
+ argp = (char *)(linux_argv + LINUX_MAX_ARGS);
next = line;
@@ -141,7 +141,8 @@ static void linux_params_init(ulong start, char *line)
next = strchr(line, ' ');
while (next quote quote next) {
- /* we found a left quote before the next blank
+ /*
+* we found a left quote before the next blank
* now we have to find the matching right quote
*/
next = strchr(quote + 1, '');
@@ -167,9 +168,9 @@ static void linux_params_init(ulong start, char *line)
line = next;
}
- linux_env = (char **) (((ulong) argp + 15) ~15);
+ linux_env = (char **)(((ulong) argp + 15) ~15);
linux_env[0] = 0;
- linux_env_p = (char *) (linux_env + LINUX_MAX_ENVS);
+ linux_env_p = (char *)(linux_env + LINUX_MAX_ENVS);
linux_env_idx = 0;
}
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 04/11] MIPS: bootm: refactor initialisation of kernel cmdline
Move initialisation of Linux command line to separate functions.
Also add support for bootm subcommand 'cmdline'.
Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
Changes in v2:
- use debug() macro
arch/mips/lib/bootm.c | 130 --
1 file changed, 83 insertions(+), 47 deletions(-)
diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
index 61e7816..3d0786d 100644
--- a/arch/mips/lib/bootm.c
+++ b/arch/mips/lib/bootm.c
@@ -35,12 +35,13 @@ DECLARE_GLOBAL_DATA_PTR;
static int linux_argc;
static char **linux_argv;
+static char *linux_argp;
static char **linux_env;
static char *linux_env_p;
static int linux_env_idx;
-static void linux_params_init(ulong start, char *commandline);
+static void linux_params_init(void);
static void linux_env_set(char *env_name, char *env_val);
static ulong arch_get_sp(void)
@@ -64,13 +65,83 @@ void arch_lmb_reserve(struct lmb *lmb)
lmb_reserve(lmb, sp, CONFIG_SYS_SDRAM_BASE + gd-ram_size - sp);
}
+static void linux_cmdline_init(void)
+{
+ linux_argc = 1;
+ linux_argv = (char **)UNCACHED_SDRAM(gd-bd-bi_boot_params);
+ linux_argv[0] = 0;
+ linux_argp = (char *)(linux_argv + LINUX_MAX_ARGS);
+}
+
+static void linux_cmdline_set(const char *value, size_t len)
+{
+ linux_argv[linux_argc] = linux_argp;
+ memcpy(linux_argp, value, len);
+ linux_argp[len] = 0;
+
+ linux_argp += len + 1;
+ linux_argc++;
+}
+
+static void linux_cmdline_dump(void)
+{
+ int i;
+
+ debug(## cmdline argv at 0x%p, argp at 0x%p\n,
+ linux_argv, linux_argp);
+
+ for (i = 1; i linux_argc; i++)
+ debug( arg %03d: %s\n, i, linux_argv[i]);
+}
+
+static void boot_cmdline_linux(bootm_headers_t *images)
+{
+ const char *bootargs, *next, *quote;
+
+ linux_cmdline_init();
+
+ bootargs = getenv(bootargs);
+ if (!bootargs)
+ return;
+
+ next = bootargs;
+
+ while (bootargs *bootargs linux_argc LINUX_MAX_ARGS) {
+ quote = strchr(bootargs, '');
+ next = strchr(bootargs, ' ');
+
+ while (next quote quote next) {
+ /*
+* we found a left quote before the next blank
+* now we have to find the matching right quote
+*/
+ next = strchr(quote + 1, '');
+ if (next) {
+ quote = strchr(next + 1, '');
+ next = strchr(next + 1, ' ');
+ }
+ }
+
+ if (!next)
+ next = bootargs + strlen(bootargs);
+
+ linux_cmdline_set(bootargs, next - bootargs);
+
+ if (*next)
+ next++;
+
+ bootargs = next;
+ }
+
+ linux_cmdline_dump();
+}
+
static void boot_prep_linux(bootm_headers_t *images)
{
- char *commandline = getenv(bootargs);
char env_buf[12];
char *cp;
- linux_params_init(UNCACHED_SDRAM(gd-bd-bi_boot_params), commandline);
+ linux_params_init();
#ifdef CONFIG_MEMSIZE_IN_BYTES
sprintf(env_buf, %lu, (ulong)gd-ram_size);
@@ -123,9 +194,14 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
bootm_headers_t *images)
{
/* No need for those on MIPS */
- if (flag BOOTM_STATE_OS_BD_T || flag BOOTM_STATE_OS_CMDLINE)
+ if (flag BOOTM_STATE_OS_BD_T)
return -1;
+ if (flag BOOTM_STATE_OS_CMDLINE) {
+ boot_cmdline_linux(images);
+ return 0;
+ }
+
if (flag BOOTM_STATE_OS_PREP) {
boot_prep_linux(images);
return 0;
@@ -136,6 +212,7 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
return 0;
}
+ boot_cmdline_linux(images);
boot_prep_linux(images);
boot_jump_linux(images);
@@ -143,50 +220,9 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
return 1;
}
-static void linux_params_init(ulong start, char *line)
+static void linux_params_init(void)
{
- char *next, *quote, *argp;
-
- linux_argc = 1;
- linux_argv = (char **)start;
- linux_argv[0] = 0;
- argp = (char *)(linux_argv + LINUX_MAX_ARGS);
-
- next = line;
-
- while (line *line linux_argc LINUX_MAX_ARGS) {
- quote = strchr(line, '');
- next = strchr(line, ' ');
-
- while (next quote quote next) {
- /*
-* we found a left quote before the next blank
-* now we have to find the matching right quote
-*/
- next = strchr(quote + 1, '');
- if (next) {
-
Re: [U-Boot] [PATCH v2 16/16] sf: Add Flag status register polling support
Hi Jagan,
On Sat, Jun 8, 2013 at 7:44 AM, Jagan Teki jagannadh.t...@gmail.com wrote:
Hi Simon,
On Sat, Jun 8, 2013 at 8:02 PM, Simon Glass s...@chromium.org wrote:
Hi Jagan,
On Sat, Jun 8, 2013 at 1:32 AM, Jagan Teki jagannadh.t...@gmail.com
wrote:
Hi Simon,
Please let know your comments.
I have changed the logic, but removed spi_flash_cmd_poll_bit() use
poll code on spi_flash_cmd_wait_ready()
as no other call for spi_flash_cmd_poll_bit() this.
And also for read_status the check_status i assigned as 0,earlier it
has direct 0 (w/o check_status variable).
To add the support for flag status on the same code, i define this
check_status.
I don't see any coding functionality change for now, compared to before.
This is not the right patch, but in one of them you remove
spi_flash_cmd_poll_bit(), so that it no longer works the same way. You
will
get lots of individual SPI transactions on the bus instead of a single
one
that reads the status byte continuously.
I couldn't understand you clearly.
Earlier all erase/write they were calling spi_flash_cmd_wait_ready
with flash, timeout values.
spi_flash_cmd_wait_ready() is intern call to spi_flash_cmd_poll_bit()
with CMD_READ_STATUS and STATUS_WIP.
In my changes I have removed spi_flash_cmd_poll_bit() as there is no
other caller except spi_flash_cmd_wait_ready()
so all polling stuff on spi_flash_cmd_wait_ready() means, still
erase/program can call spi_flash_cmd_wait_ready() with
flash, timeout and CMD_READ_STATUS and STAUS_WIP were use directly
used on spi_flash_cmd_wait_ready() instead
of passing through spi_flash_cmd_poll_bit().
Any wrong here, please comment.
You have changed the implementation of spi_flash_cmd_wait_ready() so that
instead of polling for the bit within a single SPI transaction (CS staying
asserted) you are now doing multiple transactions.
The old code for spi_flash_cmd_wait_ready() ended up with an algorithm like
this, when you look inside the nested functions:
spi_claim_bus(spi);
ret = spi_xfer(spi, cmd_len * 8, cmd, NULL, SPI_XFER_BEGIN);
do {
ret = spi_xfer(spi, 8, NULL, status, 0);
...
}
spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
spi_release_bus(spi);
The new code is:
do {
spi_claim_bus(spi);
ret = spi_xfer(spi, cmd_len * 8, cmd, NULL, SPI_XFER_BEGIN);
ret = spi_xfer(spi, data_len * 8, data_out, data_in, SPI_XFER_END);
spi_release_bus(spi);
...
} while (...)
Can you see the difference? The bus clain and SPI_XFER_BEGIN/END is now
inside the loop.
Is there a reason why this change is needed? Does updating the bank address
not work with the old code?
It is find to move the spi_flash_cmd_poll_bit() function into
spi_flash_cmd_wait_ready() - I am not worried about that. I am only worried
about your change of algorithm as above.
Regards,
Simon
Thanks,
Jagan.
Do we need to change this?
--
Thanks,
Jagan.
On Fri, May 31, 2013 at 6:22 PM, Jagannadha Sutradharudu Teki
jagannadha.sutradharudu-t...@xilinx.com wrote:
Flag status register polling is required for micron 512Mb flash
devices onwards, for performing erase/program operations.
Like polling for WIP(Write-In-Progress) bit in read status register,
spi_flash_cmd_wait_ready will poll for PEC(Program-Erase-Control)
bit in flag status register.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/spi_flash.c | 15 ---
drivers/mtd/spi/spi_flash_internal.h | 3 +++
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 527423d..8cd2988 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -195,25 +195,34 @@ int spi_flash_cmd_wait_ready(struct spi_flash
*flash, unsigned long timeout)
unsigned long timebase;
int ret;
u8 status;
+ u8 check_status = 0x0;
u8 poll_bit = STATUS_WIP;
u8 cmd = CMD_READ_STATUS;
+ if ((flash-idcode0 == 0x20)
+ (flash-size = SPI_FLASH_512MB_STMIC)) {
+ poll_bit = STATUS_PEC;
+ check_status = poll_bit;
+ cmd = CMD_FLAG_STATUS;
+ }
+
timebase = get_timer(0);
do {
WATCHDOG_RESET();
ret = spi_flash_read_common(flash, cmd, 1, status,
1);
if (ret 0) {
- debug(SF: fail to read read status
register\n);
+ debug(SF: fail to read %s status register\n,
+ cmd == CMD_READ_STATUS ? read :
flag);
return ret;
}
- if ((status poll_bit) == 0)
+ if ((status poll_bit) == check_status)
[U-Boot] 2013.07-rc1 plans?
Hello, I'd like to know what the plains regarding rc releases? Regards, -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 16/16] sf: Add Flag status register polling support
Hi Simon,
On Sun, Jun 9, 2013 at 7:43 PM, Simon Glass s...@chromium.org wrote:
Hi Jagan,
On Sat, Jun 8, 2013 at 7:44 AM, Jagan Teki jagannadh.t...@gmail.com wrote:
Hi Simon,
On Sat, Jun 8, 2013 at 8:02 PM, Simon Glass s...@chromium.org wrote:
Hi Jagan,
On Sat, Jun 8, 2013 at 1:32 AM, Jagan Teki jagannadh.t...@gmail.com
wrote:
Hi Simon,
Please let know your comments.
I have changed the logic, but removed spi_flash_cmd_poll_bit() use
poll code on spi_flash_cmd_wait_ready()
as no other call for spi_flash_cmd_poll_bit() this.
And also for read_status the check_status i assigned as 0,earlier it
has direct 0 (w/o check_status variable).
To add the support for flag status on the same code, i define this
check_status.
I don't see any coding functionality change for now, compared to
before.
This is not the right patch, but in one of them you remove
spi_flash_cmd_poll_bit(), so that it no longer works the same way. You
will
get lots of individual SPI transactions on the bus instead of a single
one
that reads the status byte continuously.
I couldn't understand you clearly.
Earlier all erase/write they were calling spi_flash_cmd_wait_ready
with flash, timeout values.
spi_flash_cmd_wait_ready() is intern call to spi_flash_cmd_poll_bit()
with CMD_READ_STATUS and STATUS_WIP.
In my changes I have removed spi_flash_cmd_poll_bit() as there is no
other caller except spi_flash_cmd_wait_ready()
so all polling stuff on spi_flash_cmd_wait_ready() means, still
erase/program can call spi_flash_cmd_wait_ready() with
flash, timeout and CMD_READ_STATUS and STAUS_WIP were use directly
used on spi_flash_cmd_wait_ready() instead
of passing through spi_flash_cmd_poll_bit().
Any wrong here, please comment.
You have changed the implementation of spi_flash_cmd_wait_ready() so that
instead of polling for the bit within a single SPI transaction (CS staying
asserted) you are now doing multiple transactions.
The old code for spi_flash_cmd_wait_ready() ended up with an algorithm like
this, when you look inside the nested functions:
spi_claim_bus(spi);
ret = spi_xfer(spi, cmd_len * 8, cmd, NULL, SPI_XFER_BEGIN);
do {
ret = spi_xfer(spi, 8, NULL, status, 0);
...
}
spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
spi_release_bus(spi);
The new code is:
do {
spi_claim_bus(spi);
ret = spi_xfer(spi, cmd_len * 8, cmd, NULL, SPI_XFER_BEGIN);
ret = spi_xfer(spi, data_len * 8, data_out, data_in, SPI_XFER_END);
spi_release_bus(spi);
...
} while (...)
Can you see the difference? The bus clain and SPI_XFER_BEGIN/END is now
inside the loop.
Understand, i thought as we do _END transfer in old code as well.
It could be fine to go with using common function as it will do _BEGIN and _END.
What could be the problem you see if we do _BEGIN and _END on loop...?
Is there a reason why this change is needed? Does updating the bank address
not work with the old code?
It doesn't effect with banking.
Thanks,
Jagan.
It is find to move the spi_flash_cmd_poll_bit() function into
spi_flash_cmd_wait_ready() - I am not worried about that. I am only worried
about your change of algorithm as above.
Regards,
Simon
Thanks,
Jagan.
Do we need to change this?
--
Thanks,
Jagan.
On Fri, May 31, 2013 at 6:22 PM, Jagannadha Sutradharudu Teki
jagannadha.sutradharudu-t...@xilinx.com wrote:
Flag status register polling is required for micron 512Mb flash
devices onwards, for performing erase/program operations.
Like polling for WIP(Write-In-Progress) bit in read status register,
spi_flash_cmd_wait_ready will poll for PEC(Program-Erase-Control)
bit in flag status register.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/spi_flash.c | 15 ---
drivers/mtd/spi/spi_flash_internal.h | 3 +++
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c
b/drivers/mtd/spi/spi_flash.c
index 527423d..8cd2988 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -195,25 +195,34 @@ int spi_flash_cmd_wait_ready(struct spi_flash
*flash, unsigned long timeout)
unsigned long timebase;
int ret;
u8 status;
+ u8 check_status = 0x0;
u8 poll_bit = STATUS_WIP;
u8 cmd = CMD_READ_STATUS;
+ if ((flash-idcode0 == 0x20)
+ (flash-size = SPI_FLASH_512MB_STMIC)) {
+ poll_bit = STATUS_PEC;
+ check_status = poll_bit;
+ cmd = CMD_FLAG_STATUS;
+ }
+
timebase = get_timer(0);
do {
WATCHDOG_RESET();
ret = spi_flash_read_common(flash, cmd, 1, status,
1);
if (ret 0) {
-
Re: [U-Boot] dfu: make data buffer size configurable
Dear Pantelis Antoniou, Heiko, On Jun 4, 2013, at 1:31 PM, Heiko Schocher wrote: Hello Pantelis, Am 04.06.2013 12:08, schrieb Pantelis Antoniou: Hi Heiko, Just thinking out loud here. Can we have an extra option that allocates the buffer dynamically based on an env variable? Hmm.. also a possibility... I have here no preferences ... Name: dfu_data_buf_size if not defined, or env invalid, use default CONFIG_SYS_DFU_DATA_BUF_SIZE size? But this can be done in a second step, right? Yes, only as a second step please. Why not do it like that right away? btw. sorry, I'm playing dead beetle until next week :-( Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] usb: omap: ulpi: fix ulpi transceiver access
Dear Michael Trimarchi, This patch fix the omap access to the transceiver configuration registers using the ulpi bus. As reported by the documentation the bit31 is used only to check if the transaction is done or still running and the reading and writing operation have different offset and have different values. What we need to do at the end of a transaction is leave the bus in done state. Anyway an error using the ulpi omap register is not recoverable so any error give out the usage of this interface. Signed-off-by: Michael Trimarchi mich...@amarulasolutions.com Reviewed-by: Igor Grinberg grinb...@compulab.co.il Tom, can you ACK/NAK this ? I have no omap board. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb, composite: after unregister gadget driver set composite to NULL
Dear Heiko Schocher, Without this, second usb_composite_register() call fails always with -EINVAL. Signed-off-by: Heiko Schocher h...@denx.de Cc: Lukasz Majewski l.majew...@samsung.com Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Marek Vasut ma...@denx.de Applied, thanks. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] usb: omap: ulpi: fix ulpi transceiver access
Dear Michael Trimarchi, Dear Marek On 06/09/2013 10:05 PM, Marek Vasut wrote: Dear Michael Trimarchi, This patch fix the omap access to the transceiver configuration registers using the ulpi bus. As reported by the documentation the bit31 is used only to check if the transaction is done or still running and the reading and writing operation have different offset and have different values. What we need to do at the end of a transaction is leave the bus in done state. Anyway an error using the ulpi omap register is not recoverable so any error give out the usage of this interface. Signed-off-by: Michael Trimarchi mich...@amarulasolutions.com Reviewed-by: Igor Grinberg grinb...@compulab.co.il Tom, can you ACK/NAK this ? I have no omap board. I don't understand the point, the old code was wrong and you can check omap3/omap4 documentation. If you revert it you still have a wrong code so it's better to drop omap3/4 viewport. You can take a look at this patch http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=2a18e1248588c326f 0a63c5bce4a611d709130a8 that is used to fix this errata http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=a0dd0ee69578e32f1 469596b8fd3a6c8ef172d42 I'm using this ulpi code in one of our device. I have fixed the u-boot viewport code because I have seen it wrong. Sorry for the late response but I was busy for a Wedding ;) Fear not! I'm busy having no life, it's really hard task! I will actually be busy with that until sometimes mid-next-week. I can try to test it tomorrow on an omap3 device but I think that is more easy for Stefano because he has already a platform with a recent uboot I don't care who tests it, I'd just like to make sure it's tested on more devices than one ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] usb: omap: ulpi: fix ulpi transceiver access
Hi Marek On 06/09/2013 11:09 PM, Marek Vasut wrote: Dear Michael Trimarchi, Dear Marek On 06/09/2013 10:05 PM, Marek Vasut wrote: Dear Michael Trimarchi, This patch fix the omap access to the transceiver configuration registers using the ulpi bus. As reported by the documentation the bit31 is used only to check if the transaction is done or still running and the reading and writing operation have different offset and have different values. What we need to do at the end of a transaction is leave the bus in done state. Anyway an error using the ulpi omap register is not recoverable so any error give out the usage of this interface. Signed-off-by: Michael Trimarchi mich...@amarulasolutions.com Reviewed-by: Igor Grinberg grinb...@compulab.co.il Tom, can you ACK/NAK this ? I have no omap board. I don't understand the point, the old code was wrong and you can check omap3/omap4 documentation. If you revert it you still have a wrong code so it's better to drop omap3/4 viewport. You can take a look at this patch http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=2a18e1248588c326f 0a63c5bce4a611d709130a8 that is used to fix this errata http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=a0dd0ee69578e32f1 469596b8fd3a6c8ef172d42 I'm using this ulpi code in one of our device. I have fixed the u-boot viewport code because I have seen it wrong. Sorry for the late response but I was busy for a Wedding ;) Fear not! I'm busy having no life, it's really hard task! I will actually be busy with that until sometimes mid-next-week. I can try to test it tomorrow on an omap3 device but I think that is more easy for Stefano because he has already a platform with a recent uboot I don't care who tests it, I'd just like to make sure it's tested on more devices than one ;-) I think that I have already understand the problem. The port_num is used starting from 0 in omap-ehci, so if this is correct my patch need a fix from u32 val = (OMAP_ULPI_START | (ulpi_vp-port_num 0xf) 24) | OMAP_ULPI_WR_OPSEL | ((u32)reg 16) | (value 0xff); to u32 val = (OMAP_ULPI_START | ((ulpi_vp-port_num + 1) 0xf) 24) | OMAP_ULPI_WR_OPSEL | ((u32)reg 16) | (value 0xff); Michael Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] usb: omap: ulpi: fix ulpi transceiver access
Dear Marek On 06/09/2013 10:05 PM, Marek Vasut wrote: Dear Michael Trimarchi, This patch fix the omap access to the transceiver configuration registers using the ulpi bus. As reported by the documentation the bit31 is used only to check if the transaction is done or still running and the reading and writing operation have different offset and have different values. What we need to do at the end of a transaction is leave the bus in done state. Anyway an error using the ulpi omap register is not recoverable so any error give out the usage of this interface. Signed-off-by: Michael Trimarchi mich...@amarulasolutions.com Reviewed-by: Igor Grinberg grinb...@compulab.co.il Tom, can you ACK/NAK this ? I have no omap board. I don't understand the point, the old code was wrong and you can check omap3/omap4 documentation. If you revert it you still have a wrong code so it's better to drop omap3/4 viewport. You can take a look at this patch http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=2a18e1248588c326f0a63c5bce4a611d709130a8 that is used to fix this errata http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=a0dd0ee69578e32f1469596b8fd3a6c8ef172d42 I'm using this ulpi code in one of our device. I have fixed the u-boot viewport code because I have seen it wrong. Sorry for the late response but I was busy for a Wedding ;), I can try to test it tomorrow on an omap3 device but I think that is more easy for Stefano because he has already a platform with a recent uboot Best regards, Marek Vasut Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Hi
On 06/08/2013 10:43 PM, Lubomir Popov wrote:
Hi Tom, Michael,
Hello,
The following changes since commit 3da0e5750b24a9491058df6126c7be577a276c09:
arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-ti.git master
for you to fetch changes up to 80dd596d1b442ff53dbeb33eccdb8efd2283be79:
[snip]
Michael Trimarchi (1):
usb: omap: ulpi: fix ulpi transceiver access
[snip]
drivers/usb/ulpi/omap-ulpi-viewport.c | 40 +-
[snip]
I just made a clean clone of u-boot-ti/master, manually applied the
changes to the ehci files, added my board files and made a build.
Everything seems to work fine, but I see an error message regarding
ULPI reset that was not present before, and obviously it is due to
Michael's changes:
SOM5_EVB # usb start
(Re)start USB...
USB0: ULPI: ulpi_reset: failed writing reset bit
Let me understand. The patch is wrong because you have a problem now.
The old code was not sending any write command so any ulpi_reset and the
test condition was wrong.
USB EHCI 1.00
scanning bus 0 for devices... 6 USB Device(s) found
scanning usb for storage devices... 3 Storage Device(s) found
scanning usb for ethernet devices... 1 Ethernet Device(s) found
SOM5_EVB # usb tree
USB device tree:
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Mass Storage (480 Mb/s, 200mA)
|FSC MEMORYBIRD USB2 C157040817120315AA
|
+-3 Hub (480 Mb/s, 2mA)
| |
| +-4 Mass Storage (480 Mb/s, 96mA)
| |Generic Ultra Fast Media Reader 00264001
| |
| +-5 Mass Storage (480 Mb/s, 100mA)
| USB Flash Drive 531C43B21928F11F
|
+-6 Vendor specific (480 Mb/s, 500mA)
SOM5_EVB #
Otherwise everything is OK, the device on the ULPI port is working
(it is #2 above). It is now late and I shall investigate in detail
tomorrow, this is just an early warning ;)
Can you test the attach patch? Yes I know it is not inline but I will
send inline tomorrow and I have done changing the old one.
I was thinking port number was starting from 1 but I have done a quick check
on soft_reset of omap and it is starting from 0
Michael
Best regards,
Lubo
This patch fix the omap access to the transceiver
configuration registers using the ulpi bus. As reported by
the documentation the bit31 is used only to check if the
transaction is done or still running and the reading and
writing operation have different offset and have different
values. What we need to do at the end of a transaction is
leave the bus in done state. Anyway an error using the ulpi
omap register is not recoverable so any error give out the
usage of this interface.
Signed-off-by: Michael Trimarchi mich...@amarulasolutions.com
---
- changes for V4
port_num start from 0 so we need to take in account when
we use the omap access function
- changes for V3
Fix patch subject
- changes for V2
Fix commit message
---
drivers/usb/ulpi/omap-ulpi-viewport.c | 40 +++--
1 file changed, 8 insertions(+), 32 deletions(-)
diff --git a/drivers/usb/ulpi/omap-ulpi-viewport.c b/drivers/usb/ulpi/omap-ulpi-viewport.c
index 3c1ea1a..2a42033 100644
--- a/drivers/usb/ulpi/omap-ulpi-viewport.c
+++ b/drivers/usb/ulpi/omap-ulpi-viewport.c
@@ -22,18 +22,19 @@
#include asm/io.h
#include usb/ulpi.h
-#define OMAP_ULPI_WR_OPSEL (3 21)
-#define OMAP_ULPI_ACCESS (1 31)
+#define OMAP_ULPI_WR_OPSEL (2 22)
+#define OMAP_ULPI_RD_OPSEL (3 22)
+#define OMAP_ULPI_START (1 31)
/*
- * Wait for the ULPI Access to complete
+ * Wait for having ulpi in done state
*/
static int ulpi_wait(struct ulpi_viewport *ulpi_vp, u32 mask)
{
int timeout = CONFIG_USB_ULPI_TIMEOUT;
while (--timeout) {
- if ((readl(ulpi_vp-viewport_addr) mask))
+ if (!(readl(ulpi_vp-viewport_addr) mask))
return 0;
udelay(1);
@@ -43,40 +44,15 @@ static int ulpi_wait(struct ulpi_viewport *ulpi_vp, u32 mask)
}
/*
- * Wake the ULPI PHY up for communication
- *
- * returns 0 on success.
- */
-static int ulpi_wakeup(struct ulpi_viewport *ulpi_vp)
-{
- int err;
-
- if (readl(ulpi_vp-viewport_addr) OMAP_ULPI_ACCESS)
- return 0; /* already awake */
-
- writel(OMAP_ULPI_ACCESS, ulpi_vp-viewport_addr);
-
- err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS);
- if (err)
- debug(ULPI wakeup timed out\n);
-
- return err;
-}
-
-/*
* Issue a ULPI read/write request
*/
static int ulpi_request(struct ulpi_viewport *ulpi_vp, u32 value)
{
int err;
- err = ulpi_wakeup(ulpi_vp);
- if (err)
- return err;
-
writel(value, ulpi_vp-viewport_addr);
- err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS);
+ err = ulpi_wait(ulpi_vp, OMAP_ULPI_START);
if (err)
debug(ULPI request timed out\n);
@@ -85,7 +61,7 @@ static int ulpi_request(struct ulpi_viewport *ulpi_vp, u32 value)
int ulpi_write(struct ulpi_viewport *ulpi_vp, u8 *reg, u32 value)
{
- u32 val =
Re: [U-Boot] [PATCH v3] usb: omap: ulpi: fix ulpi transceiver access
Dear Michael Trimarchi, Hi Marek On 06/09/2013 11:09 PM, Marek Vasut wrote: Dear Michael Trimarchi, Dear Marek On 06/09/2013 10:05 PM, Marek Vasut wrote: Dear Michael Trimarchi, This patch fix the omap access to the transceiver configuration registers using the ulpi bus. As reported by the documentation the bit31 is used only to check if the transaction is done or still running and the reading and writing operation have different offset and have different values. What we need to do at the end of a transaction is leave the bus in done state. Anyway an error using the ulpi omap register is not recoverable so any error give out the usage of this interface. Signed-off-by: Michael Trimarchi mich...@amarulasolutions.com Reviewed-by: Igor Grinberg grinb...@compulab.co.il Tom, can you ACK/NAK this ? I have no omap board. I don't understand the point, the old code was wrong and you can check omap3/omap4 documentation. If you revert it you still have a wrong code so it's better to drop omap3/4 viewport. You can take a look at this patch http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=2a18e1248588c3 26f 0a63c5bce4a611d709130a8 that is used to fix this errata http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=a0dd0ee69578e3 2f1 469596b8fd3a6c8ef172d42 I'm using this ulpi code in one of our device. I have fixed the u-boot viewport code because I have seen it wrong. Sorry for the late response but I was busy for a Wedding ;) Fear not! I'm busy having no life, it's really hard task! I will actually be busy with that until sometimes mid-next-week. I can try to test it tomorrow on an omap3 device but I think that is more easy for Stefano because he has already a platform with a recent uboot I don't care who tests it, I'd just like to make sure it's tested on more devices than one ;-) I think that I have already understand the problem. The port_num is used starting from 0 in omap-ehci, so if this is correct my patch need a fix from u32 val = (OMAP_ULPI_START | (ulpi_vp-port_num 0xf) 24) | OMAP_ULPI_WR_OPSEL | ((u32)reg 16) | (value 0xff); to u32 val = (OMAP_ULPI_START | ((ulpi_vp-port_num + 1) 0xf) 24) | OMAP_ULPI_WR_OPSEL | ((u32)reg 16) | (value 0xff); Michael Make sure you base this stuff on u-boot-usb/master too. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_bootm: Add command line arguments to Plan 9
On Sun, Jun 9, 2013 at 12:52 AM, Wolfgang Denk w...@denx.de wrote: This is basically the same code (with only irrelevant differences) as used by do_bootm_netbsd(). Can you please 1) factor out this common code, and 2) documnt the behaviour ? Will do. By the way: this patch still triggers two do not use assignment in if condition checkpoatch errors. Please fix these, too. Will do. I'll submit a v2 patch later this evening. Thanks for being patient :-) Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] dfu: make data buffer size configurable
Hello Marek, Am 09.06.2013 22:01, schrieb Marek Vasut: Dear Pantelis Antoniou, Heiko, On Jun 4, 2013, at 1:31 PM, Heiko Schocher wrote: Hello Pantelis, Am 04.06.2013 12:08, schrieb Pantelis Antoniou: Hi Heiko, Just thinking out loud here. Can we have an extra option that allocates the buffer dynamically based on an env variable? Hmm.. also a possibility... I have here no preferences ... Name: dfu_data_buf_size if not defined, or env invalid, use default CONFIG_SYS_DFU_DATA_BUF_SIZE size? But this can be done in a second step, right? Yes, only as a second step please. Why not do it like that right away? Ok, I can change this. Envvar name dfu_data_buf_size is ok? 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] dfu: make data buffer size configurable
Hi Heiko, Hello Marek, Am 09.06.2013 22:01, schrieb Marek Vasut: Dear Pantelis Antoniou, Heiko, On Jun 4, 2013, at 1:31 PM, Heiko Schocher wrote: Hello Pantelis, Am 04.06.2013 12:08, schrieb Pantelis Antoniou: Hi Heiko, Just thinking out loud here. Can we have an extra option that allocates the buffer dynamically based on an env variable? Hmm.. also a possibility... I have here no preferences ... Name: dfu_data_buf_size if not defined, or env invalid, use default CONFIG_SYS_DFU_DATA_BUF_SIZE size? But this can be done in a second step, right? Yes, only as a second step please. Why not do it like that right away? Ok, I can change this. Envvar name dfu_data_buf_size is ok? For me it's fine. bye, Heiko -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
