Re: [U-Boot] [PATCH v3] at91sam9x5ek: Pass serial and revision tags to Linux
Dear Julius Hemanth P,
first of all, please address Bo's comment about checkpatch:
---8---
andreas@andreas-mbp % ./tools/checkpatch.pl ~/Downloads/\[PATCH\ v3\]\
at91sam9x5ek_\ Pass\ serial\ and\ revision\ tags\ to\ Linux.eml
ERROR: DOS line endings
#70: FILE: board/atmel/at91sam9x5ek/at91sam9x5ek.c:30:
+#include asm/arch/at91_gpbr.h^M$
ERROR: patch seems to be corrupt (line wrapped?)
#75: FILE: board/atmel/at91sam9x5ek/at91sam9x5ek.c:48:
total: 38 errors, 7 warnings, 1 checks, 66 lines checked
NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
scripts/cleanfile
NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX
MULTISTATEMENT_MACRO_USE_DO_WHILE USLEEP_RANGE
/Users/andreas/Downloads/[PATCH v3] at91sam9x5ek_ Pass serial and
revision tags to Linux.eml has style problems, please review.
If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
---8---
On 09.05.13 19:07, Julius Hemanth P wrote:
This code is small snippet from patch
ftp://ftp.linux4sam.org/pub/uboot/u-boot-v2010.06/u-boot-5series_1.0.patch
Linux 2.6.39 (released on www.at91.com/linux4sam) requires serial and
revision ATAGs to detect NAND device.
This patch provides backward compatibility for old Linux 2.6.39 by
passing serial and revision ATAGs to Linux kernel.
Signed-off-by: Julius Hemanth juliushema...@gmail.com
---
Changes for v3:
- corrected GPBR register access
- updated commit message
Changes for v2:
- access GPBR using c structure
- removed tailing 1 for #define
- s/Miscelaneous/Miscellaneous
- s/initialisations/initializations
board/atmel/at91sam9x5ek/at91sam9x5ek.c | 33
-
include/configs/at91sam9x5ek.h | 5 +
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/board/atmel/at91sam9x5ek/at91sam9x5ek.c
b/board/atmel/at91sam9x5ek/at91sam9x5ek.c
index 8773e6f..116bd83 100644
--- a/board/atmel/at91sam9x5ek/at91sam9x5ek.c
+++ b/board/atmel/at91sam9x5ek/at91sam9x5ek.c
@@ -27,6 +27,7 @@
#include asm/arch/at91_common.h
#include asm/arch/at91_pmc.h
#include asm/arch/at91_rstc.h
+#include asm/arch/at91_gpbr.h
#include asm/arch/gpio.h
#include asm/arch/clk.h
#include lcd.h
@@ -48,8 +49,34 @@ DECLARE_GLOBAL_DATA_PTR;
/* -
*/
/*
- * Miscelaneous platform dependent initialisations
+ * Miscellaneous platform dependent initializations
*/
+
+#ifdef CONFIG_LOAD_ONE_WIRE_INFO
What the hell has this one wire thing to do with reading internal GPBR's?
This is a new config parameter (which lacks documentation in this patch)
is not required at all cause it is enabled in any case, or do I miss
something?
+static u32 system_rev;
+static u32 system_serial_low;
Can we please omit these global variables? We could just read the GPBR's
in respective get-functions. This will reduce the .bss and .text size
and is therefore reasonable.
+
+u32 get_board_rev(void)
+{
+ return system_rev;
+}
+
+void get_board_serial(struct tag_serialnr *serialnr)
+{
+ serialnr-high = 0; /* Not used */
+ serialnr-low = system_serial_low;
+}
+
+void load_1wire_info(void)
+{
+ at91_gpbr_t *gpbr = (at91_gpbr_t *) ATMEL_BASE_GPBR;
+
+ /* serial is in GPBR #2 and revision is in GPBR #3 */
Why is that so? Which code places the serial and revision version into
the GPBR's?
Please add documentation and mark the usage in at91_gpbr.h.
As at91_gpbr.h states GPBR[3] is already used for bootcount ... so I
tend to completely NAK this patch.
As I understand Bo's comment in a prior mail this patch is only required
for one specific kernel which is outdated. Can't you just patch the
kernel to get the whole thing working?
Best regards
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] No status update errors in OMAP mmc_send_cmd()
Michael Cashwell mboards at prograde.net writes: Greetings, I've been fighting an odd problem with a custom OMAP4 board throwing MMC errors. It seems that a 4-bit-wide uSD card on MMC1 works but an 8-bit-wide eMMC part on MMC2 has problems. As sometimes happens, in trying to track down the problem the presence of a debugging printf() masked the error. Just now I've finally gotten a good trace on this. In drivers/mmc/omap_hsmmc.c near line 380, if I have: writel(cmd-cmdarg, mmc_base-arg); writel((cmd-cmdidx 24) | flags, mmc_base-cmd); printf(%s : at %p cmd 0x%08x arg 0x%08x\n, __func__, mmc_base, cmd-cmdidx, cmd-cmdarg); With or without that printf() the code fails when I select MMC2 (eMMC): snip If I instead put the printf() or a udelay(20) (anything less than 20 still failed) *between* the two writel() calls it works: I had a similar problem with recent u-boot on OMAP 4430SDP board. With my rather old MMC, I was unable to boot at all: U-Boot SPL 2013.04 (May 10 2013 - 08:20:30) OMAP4430 ES2.1 OMAP SD/MMC: 0 mmc_send_cmd : timeout: No status update Card did not respond to voltage select! spl: mmc init failed: err - -17 ### ERROR ### Please RESET the board ### With newer MMC, I can boot, but I see an error from u-boot: mmc_send_cmd : timeout: No status update Adding udelay to the place you mention fixes both problems. Tomi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Uboot question from Newbee
Dear Casper Floppy, On 10.05.13 00:53, Casper Floppy wrote: Hi All, I come from PC side and familiar with UEFI BIOS. I am very new to uboot so please help ( be kind :). Is this the right forum to ask Uboot specific question? yes, it is. I will just pick up some of your concrete questions. 3) Do every uboot bootloader based system support FastBoot or only some platforms; is this vendor choice? Do you mean the 'Falcon Boot Mode' [1]? It is vendor choice, the basics are there but currently only two mainline boards utilizes that feature. 4) Where can I get a good documentation on how the uboot build process work? For ex. I saw a call to drv_video_init but not sure how this is linked to the code or invoked. Is the entre uboot files compiled and conditional macro drop unused code? How are various files pulled into the build? Each sub directory builds archives (sometimes empty archives if nothing in the directory is compiled) and the linker picks required parts into the final ELF. We utilize functions-sections/data-sections in compile stage and gc-sections in link stage. We try to minimize the compile time decisions via if-differy. Some parts utilize the weak functions to put arch/board specific functions into generic code. Each arch has its initialization code in some assembler code, mostly start.S and later on some c-code in $ARCH/lib/board.c. We try to migrate that to a generic board initialization in common/board_f.c (code that runs before relocation) and common/board_r.c, this is ongoing and just a few arches where migrated. I think Simon is on it to migrate x86. I can't answer your question regarding drv_video_init exactly, I guess this is the interface for cfb_console to initialize the video hardware. It will be called by the stdio code when the stdio-device is set to the cfb_console. 5) I am not sure how GPL licensing work. If I use uboot code in some form do I need to send all code just the customization changes back? For example if I am interested in just fastboot aspect of uboot and execute it over other proprietary firmware what changes I need to provide back. If you provide a product containing GPL'ed code you _must_ point this out in some way. Additionally you _must_ provide the GPL'ed code plus your changes to it to your customers, at least if they ask for them. This are just two rules of thumb, but in general this should meet the needs, at least for GPLv2. Please let some legal expert check this in depth. Nevertheless, you _should_ provide your changes to the community to find the best solution for your needs and to spare you future efforts of porting your proprietary changes to the GPL'ed code when that code changes. Best regards Andreas Bießmann [1] http://schedule2012.rmll.info/IMG/pdf/LSM2012_UbootFalconMode_Babic.pdf ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ARM] [STATUS] Resuming activity
Hello all, I've been away for a few days, and back to U-Boot duties today. As usual, I will handle merge requests first, then patches (oldest first), but before this I'll be finishing and submitting a patch series for factoring the ARM relocation routine. As usual too, anything you want to point me to, please post or mail and make sure I am a To: recipient (rather than Cc: or not at tall), that'll ensure these messages are brought to my attention. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request - zynq
Hi Michal, On Wed, 01 May 2013 09:45:47 +0200, Michal Simek mon...@monstr.eu wrote: Unless Albert really doesn't want this, I'm fine going through his tree as it's all ARM related. Albert: any comment? I'm fine with pulling it, and starting now. Thanks, Michal Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: fix a comment
I sent this mail by operation mistake of git send-email. The mail address y...@epochmail.jp.panasonic.com written in From: field of the email is incorrect. I posted again with the same subject. The Message-ID of the correct mail is 1368159848-3964-1-git-send-email-yamad...@jp.panasonic.com Very sorry for noise. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request - fpga
Hi Michal, On Mon, 06 May 2013 10:50:44 +0200, Michal Simek mon...@monstr.eu wrote: Hi Tom and Albert, I have created fpga branch. It is based on zynq patches(and request) I sent last week. The reason why it is based on it is that new zynq fpga driver and changes in zynq I have done. Just talk to each other and be aware that this fpga patchset is based on zynq one. Thanks, Michal As this is related to the Zynq series and Tom has reviewed it too, I'll pull it in the ARM tree right after I pull the Zynq patches. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] avr32: fix relocation address calculation
Hi Andreas, On Wed, 8 May 2013 11:25:17 +0200, Andreas Bießmann andreas.de...@googlemail.com wrote: Commit 1865286466a5d0c7f2e3c37632da56556c838e9e (Introduce generic link section.h symbol files) changed the __bss_end symbol type from char[] to ulong. This led to wrong relocation parameters which ended up in a not working u-boot. Unfortunately this is not clear to see cause due to RAM aliasing we may get a 'half-working' u-boot then. Fix this by dereferencing the __bss_end symbol where needed. (cc:ing Simon and Tom) The dereferencing is correct, so this patch seems good per se (it could actually have applied when __bss_end was still a char[]). But the definition of __bss_end to being an ulong, as introduced by 18652864, is plain wrong. Just because it is a linker defined symbol does not mean the object it represents is a 32-bit quantity -- it is not. It still is a non-object, a pure address. Ditto for __data_end, __rel_dyn_start, __rel_dyn_end and pretty much any symbol in sections.h which is not an offset. Sorry for not spotting this before it was merged in; but now this must be fixed. I'm ok with the wrongly-ulong symbols being changed back to char[], though I would prefer their type to be char[0] if possible, as this is (admittedly marginally) more likely to help the compiler catch accidental dereferencings. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request - zynq
Hi Michal, On Tue, 30 Apr 2013 11:49:33 +0200, Michal Simek mon...@monstr.eu wrote: Hi Tom and Albert, please pull this patchset related to arm zynq to your tree. I haven't got any ACK for gem and platform changes but the whole patchset was reviewed by Tom. Also not all patches are ARM core specific but they are affecting zynq platform that's why I think it can go directly to Tom tree. Please let me know if you have any problem with it. I can create more branches with specific patches which should go through specific trees. I have removed fpga related patch because I have some others pending fpga patches and I will group them together. Thanks, Michal The following changes since commit d10f68ae47b67acab8b110b5c605dde4197a1820: Prepare v2013.04 (2013-04-19 10:25:43 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git zynq for you to fetch changes up to 8934f7846501070a5b01c1fab5db27559e9d70d1: i2c: zynq: Add support for Xilinx Zynq (2013-04-30 11:39:28 +0200) David Andrey (3): arm: zynq: U-Boot udelay 1000 FIX net: gem: Pass phy address to init net: gem: Preserve clk on emio interface Michal Simek (11): arm: zynq: Rename XPSS_ prefix to ZYNQ_ for hardcoded SoC addresses zynq: Move scutimer baseaddr to hardware.h net: phy: Define Marvell 88e1518 phy net: gem: Remove WRAP bit from TX buffer description net: gem: Simplify return path in zynq_gem_recv net: gem: Do not initialize BDs again net: gem: Fix gem driver on 1Gbps LAN zynq: Move macros to hardware.h net: gem: Add support for phy autodetection mmc: Add support for Xilinx Zynq sdhci controller i2c: zynq: Add support for Xilinx Zynq arch/arm/cpu/armv7/zynq/slcr.c | 26 arch/arm/cpu/armv7/zynq/timer.c| 49 --- arch/arm/include/asm/arch-zynq/hardware.h | 26 +--- arch/arm/include/asm/arch-zynq/sys_proto.h | 4 ++ board/xilinx/zynq/board.c | 29 - drivers/i2c/Makefile | 1 + drivers/i2c/zynq_i2c.c | 306 + drivers/mmc/Makefile | 1 + drivers/mmc/zynq_sdhci.c | 40 drivers/net/phy/marvell.c | 11 drivers/net/zynq_gem.c | 199 +- include/configs/zynq.h | 33 -- include/netdev.h | 2 +- 13 files changed, 644 insertions(+), 83 deletions(-) create mode 100644 drivers/i2c/zynq_i2c.c create mode 100644 drivers/mmc/zynq_sdhci.c Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/p1022ds: boot from SD card/SPI flash with SPL
This patch needs to be broken into several patches that each take care of one
logical problem; it's too hard to properly review (and have the right people
pay attention to certain parts) in its current state.
[Zhang Ying]
It only can be broken to two patches, one for SD boot, another for SPI boot.
diff --git a/arch/powerpc/cpu/mpc85xx/tlb.c
b/arch/powerpc/cpu/mpc85xx/tlb.c index 0dff37f..d21b324 100644
--- a/arch/powerpc/cpu/mpc85xx/tlb.c
+++ b/arch/powerpc/cpu/mpc85xx/tlb.c
@@ -55,7 +55,7 @@ void init_tlbs(void)
return ;
}
-#if !defined(CONFIG_NAND_SPL) !defined(CONFIG_SPL_BUILD)
+#if !defined(CONFIG_NAND_SPL) !defined(CONFIG_SPL_BUILD_MINIMAL)
void read_tlbcam_entry(int idx, u32 *valid, u32 *tsize, unsigned long
*epn,
phys_addr_t *rpn)
{
Aren't you breaking the existing minimal targets?
CONFIG_SPL_BUILD_MINIMAL does not currently exist, and you add it only for
P1022DS.
[Zhang Ying]
Yes, it needs to be added for other existing boards that defines
CONFIG_SPL_INIT_MINIMAL. It should include p1_p2_rdb_pc.
@@ -83,5 +107,6 @@ SECTIONS
*(.sbss*)
*(.bss*)
}
+ . = ALIGN(4);
__bss_end = .;
}
This seems unrelated.
[Zhang Ying]
It is necessary. In the function clear_bss(), the address of bss is on the
basis of the __bss_start, and then to four bytes of incremental growth, finally
the last stop is based on the address and __bss_end is equal or not.
diff --git a/board/freescale/common/sdhc_boot.c
b/board/freescale/common/sdhc_boot.c
index e432318..96b0680 100644
--- a/board/freescale/common/sdhc_boot.c
+++ b/board/freescale/common/sdhc_boot.c
+ val = *(u16 *)(tmp_buf + ESDHC_BOOT_IMAGE_SIGN_ADDR);
+ if ((u16)ESDHC_BOOT_IMAGE_SIGN != val) {
+ free(tmp_buf);
+ return;
+ }
Why do you need this cast?
[Zhang Ying]
The offset 0x1FE of the config data sector should contain the value 0x55AA. If
the value in this location doesn't match 0x55AA, it means that the SD/MMC card
doesn't contain a valid user code.
+ offset = *(u32 *)(tmp_buf + ESDHC_BOOT_IMAGE_ADDR);
+ offset += CONFIG_SYS_MMC_U_BOOT_OFFS;
+ /* Get the code size from offset 0x48 */
+ code_len = *(u32 *)(tmp_buf + ESDHC_BOOT_IMAGE_SIZE);
+ code_len -= CONFIG_SYS_MMC_U_BOOT_OFFS;
+ /*
+ * Load U-Boot image from mmc into RAM
+ */
+ /*
+ SDHC card: code offset and length is stored in block units
rather
+ * than a single byte
+ */
/*
* U-Boot multiline
* comment style is
* like this.
*/
+ blk_start = ALIGN(offset, mmc-read_bl_len) / mmc-read_bl_len;
+ blk_cnt = ALIGN(code_len, mmc-read_bl_len) / mmc-read_bl_len;
+
+ err = mmc-block_dev.block_read(0, blk_start, blk_cnt,
+ (uchar
*)CONFIG_SYS_MMC_U_BOOT_DST);
+ if (err != blk_cnt) {
+ free(tmp_buf);
+ return ;
+ }
+}
+void mmc_boot(void)
No space before ;
That return is pointless since you're at the end of the function anyway.
[Zhang Ying]
Ok, I can hang the cpu and print the error information.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __SDHC_BOOT_H_
+#define __SDHC_BOOT_H_1
+
+
+int mmc_get_env_addr(struct mmc *mmc, u32 *env_addr); void
+mmc_get_env(void); void mmc_boot(void);
+
+#endif /* __SDHC_BOOT_H_ */
Does this stuff really belong in board/freescale? Should probably at least be
in arch/powerpc/cpu/mpc85xx, if not more generic.
[Zhang Ying]
Ok, whether we can handle like this: sdhc_boot.c and spi_boot.c will be
deleted. All this stuff in the sdhc_boot.c will be moved to
drivers/mmc/fsl_esdhc.c, and the functions in the spi_boot.c will be moved to
drivers/mmc/fsl_espi.c.
+void hang(void)
+{
+ puts(### ERROR ### Please RESET the board ###\n);
+ for (;;)
+ ;
+}
Whitespace
[Zhang Ying]
?
diff --git a/common/Makefile b/common/Makefile index 0e0fff1..bc80414
100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -225,6 +225,11 @@ COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_common.o
COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_flags.o
COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_nowhere.o
COBJS-$(CONFIG_SPL_NET_SUPPORT) += miiphyutil.o
+COBJS-$(CONFIG_SPL_HWCONFIG_SUPPORT) += hwconfig.o
+COBJS-$(CONFIG_SPL_INIT_DDR_SUPPORT) += ddr_spd.o
+COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_attr.o
+COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_flags.o
+COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_callback.o
CONFIG_SPL_ENV_SUPPORT should replace CONFIG_SPL_NET_SUPPORT here (and add it
to the boards that already have CONFIG_SPL_NET_SUPPORT). This sort of
refactoring needs to be a separate patch, BTW.
Can ddr_spd.o and hwconfig just use
[U-Boot] [PATCH] drivers/mmc: move spl_mmc.c to common/spl
From: Ying Zhang b40...@freescale.com
The mpc85xx repuires a special layout on the memory device that is
connected to the eSDHC controller interface. But the file spl_mmc.c
didn't handle this specfic case, there needs a special treatmen, in
the powerpc drictory. So, there is no longer to keep spl_mmc.c on
mpc85xx, CONFIG_SPL_FRAMEWORK is not set.
When CONFIG_SPL_MMC_SUPPORT is set and CONFIG_SPL_FRAMEWORK is not
set, there was an error in drivers/mmc/spl_mmc.c:
drivers/mmc/libmmc.o:(.got2+0x8): undefined reference to `spl_image'.
Now, the solution is to move the file spl_mmc.c to directory common/spl.
Signed-off-by: Ying Zhang b40...@freescale.com
---
common/spl/Makefile |1 +
common/spl/spl_mmc.c | 137 +
drivers/mmc/Makefile |3 -
drivers/mmc/spl_mmc.c | 137 -
4 files changed, 138 insertions(+), 140 deletions(-)
create mode 100644 common/spl/spl_mmc.c
delete mode 100644 drivers/mmc/spl_mmc.c
diff --git a/common/spl/Makefile b/common/spl/Makefile
index da2afc1..a74563c 100644
--- a/common/spl/Makefile
+++ b/common/spl/Makefile
@@ -20,6 +20,7 @@ COBJS-$(CONFIG_SPL_YMODEM_SUPPORT) += spl_ymodem.o
COBJS-$(CONFIG_SPL_NAND_SUPPORT) += spl_nand.o
COBJS-$(CONFIG_SPL_ONENAND_SUPPORT) += spl_onenand.o
COBJS-$(CONFIG_SPL_NET_SUPPORT) += spl_net.o
+COBJS-$(CONFIG_SPL_MMC_SUPPORT) += spl_mmc.o
endif
COBJS := $(sort $(COBJS-y))
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
new file mode 100644
index 000..7efdcb8
--- /dev/null
+++ b/common/spl/spl_mmc.c
@@ -0,0 +1,137 @@
+/*
+ * (C) Copyright 2010
+ * Texas Instruments, www.ti.com
+ *
+ * Aneesh V ane...@ti.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#include common.h
+#include spl.h
+#include asm/u-boot.h
+#include asm/utils.h
+#include mmc.h
+#include fat.h
+#include version.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static void mmc_load_image_raw(struct mmc *mmc)
+{
+ unsigned long err;
+ u32 image_size_sectors;
+ struct image_header *header;
+
+ header = (struct image_header *)(CONFIG_SYS_TEXT_BASE -
+ sizeof(struct image_header));
+
+ /* read image header to find the image size load address */
+ err = mmc-block_dev.block_read(0,
+ CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR, 1,
+ header);
+
+ if (err == 0)
+ goto end;
+
+ spl_parse_image_header(header);
+
+ /* convert size to sectors - round up */
+ image_size_sectors = (spl_image.size + mmc-read_bl_len - 1) /
+ mmc-read_bl_len;
+
+ /* Read the header too to avoid extra memcpy */
+ err = mmc-block_dev.block_read(0,
+ CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR,
+ image_size_sectors, (void *)spl_image.load_addr);
+
+end:
+ if (err == 0) {
+ printf(spl: mmc blk read err - %lu\n, err);
+ hang();
+ }
+}
+
+#ifdef CONFIG_SPL_FAT_SUPPORT
+static void mmc_load_image_fat(struct mmc *mmc)
+{
+ int err;
+ struct image_header *header;
+
+ header = (struct image_header *)(CONFIG_SYS_TEXT_BASE -
+ sizeof(struct image_header));
+
+ err = fat_register_device(mmc-block_dev,
+ CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION);
+ if (err) {
+ printf(spl: fat register err - %d\n, err);
+ hang();
+ }
+
+ err = file_fat_read(CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME,
+ header, sizeof(struct image_header));
+ if (err = 0)
+ goto end;
+
+ spl_parse_image_header(header);
+
+ err = file_fat_read(CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME,
+ (u8 *)spl_image.load_addr, 0);
+
+end:
+ if (err = 0) {
+ printf(spl: error reading image %s, err - %d\n,
+ CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME, err);
+ hang();
+ }
+}
+#endif
+
+void spl_mmc_load_image(void)
+{
+ struct mmc *mmc;
+ int err;
+ u32
Re: [U-Boot] ARM: cfi_flash: Fix unaligned accesses to cfi_qry structure
Dear Andrew Gabbasov, Your patch seems to newly generate the following warning and error, because your patch is changing the type of 'qry-max_buf_write_size' from u16 to u8[2]. cfi_flash.c:2038:33: warning: comparison between pointer and integer [enabled by default] cfi_flash.c:2046:27: error: incompatible types when assigning to type 'u8[2]' from type 'int' By the way, I also had this unalignment access problem for my board. Before finding your patch, I was thinking another way to fix this problem. My idea is to just use 'get_unaligned' and 'put_unaligned' functions instead of introducing special macros. With this way, we don't need to change the fields of struct cfi_qry. If you fix the above problem, I think your patch will be fine. But I am wondering which way is more smart. Best regards, Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Displaying characters on the display in u-boot
Hi Why are you using 0xA500 address here as the frame buffer base address? Yeah this is a very much a valid frame buffer address. I 'used' to use this for splash screen also and it worked fine. Can you see changes on the display if you write data to this address by U-Boot mw command (i.e. mw a500 100) ? No.. but the memory will have all f's contained in it until I reboot. Probably the frame buffer or display controller configuration is wrong then. Is the display backlight enabled? Frame buffer configuration has to be right.. it worked for the splash screen Is it any different for text displaying ? Yeah, backlight is enabled. lcd_drawchars() will not help since you do not use the lcd driver. I displayed the bmp images on the LCD, which I had been asking u in the 'u-boot.10912.n7.nabble.com' forum. The method I used goes like this, - I created a gzip of the bmp - used the xxd -i to create a HEX dump of it. - made it part of the u-boot compilation process, that was a requirement imposed. - gunzip it runtime, just use a portion of lcd_display_bitmap, which does the conversion to RGB888. The portion of the code where bmp_bpix=32, in the switch case. - its just too good, the u-boot.bin is 330 KB with more that 15 images inside it :D - my u-boot just became awesome after that. On the same lines, I tried using lcd_drawchars(). Please correct me if I'm wrong. But the bigger problem here is I'm not able to figure out where the mistake is. I'm pretty conversant with using the Lauterbach to debug. I have JTAG pins drawn out on my board. Please give me Ur suggestions. Regards Bhargav From: Anatolij Gustschin [ag...@denx.de] Sent: Sunday, April 28, 2013 7:52 PM To: Bhargav A K Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Displaying characters on the display in u-boot Hi, On Fri, 19 Apr 2013 21:29:33 +0530 Bhargav A K bhargav...@sasken.com wrote: Hi All, I have enabled the following configurations. in my board's config header #define CONFIG_VGA_AS_SINGLE_DEVICE #define CONFIG_VIDEO #define CONFIG_CFB_CONSOLE video_hw_init() returns a pointer to GraphicsDevice structure. It does the following - omap4_GD.winSizeX = 480; //__raw_readl() omap4_GD.winSizeY = 800; omap4_GD.gdfBytesPP = 4; omap4_GD.gdfIndex = GDF_32BIT_X888RGB; __raw_writel(0xA500, DISPC_GFX_BA0); omap4_GD.frameAdrs = __raw_readl(DISPC_GFX_BA0); Why are you using 0xA500 address here as the frame buffer base address? Are you sure that this is a valid memory address? Can you see changes on the display if you write data to this address by U-Boot mw command (i.e. mw a500 100) ? Which frame buffer base address did you use before for working splashscreen? initDisplay(); // Do all other clocks, GPIOs, OMAP4 registers specific for LCD(DSI, DISPC, DSS). -- board_video_init() is just a dummy call. I did a console_assign() to redirect stderr and stdout to vga. All the printf's doesn't come on the serial console or the LCD. I tried using the video_drawstring(10, 20, hello world), after resetting the stdout to serial. I see all the printf's on the serial console, but the string from video_drawstring()(hello world) won't come on the LCD even after syncing LCD pipelines (GO_LCD in OMAP4470). Probably the frame buffer or display controller configuration is wrong then. Is the display backlight enabled? Then I just exported the lcd_drawchars() function into my LCD code, tried to write characters to the LCD, nothing came onto the screen. lcd_drawchars() will not help since you do not use the lcd driver. Thanks, Anatolij SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited (Sasken) unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] avr32: fix relocation address calculation
Hi Albert, On 05/10/2013 11:24 AM, Albert ARIBAUD wrote: Hi Andreas, On Wed, 8 May 2013 11:25:17 +0200, Andreas Bießmann andreas.de...@googlemail.com wrote: Commit 1865286466a5d0c7f2e3c37632da56556c838e9e (Introduce generic link section.h symbol files) changed the __bss_end symbol type from char[] to ulong. This led to wrong relocation parameters which ended up in a not working u-boot. Unfortunately this is not clear to see cause due to RAM aliasing we may get a 'half-working' u-boot then. Fix this by dereferencing the __bss_end symbol where needed. (cc:ing Simon and Tom) The dereferencing is correct, so this patch seems good per se (it could actually have applied when __bss_end was still a char[]). well, as I understood this the __bss_end being a char[] did implicitly take the address when accessing __bss_end (as we do when we have a definition of char foo[2] and we take just 'foo'). But you say here we should reference the address of __bss_end while it was still of type char[]. Sorry, I do not understand that, can you please clarify? Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Displaying characters on the display in u-boot
Hi, On Fri, 10 May 2013 16:00:31 +0530 Bhargav A K bhargav...@sasken.com wrote: Hi Why are you using 0xA500 address here as the frame buffer base address? Yeah this is a very much a valid frame buffer address. I 'used' to use this for splash screen also and it worked fine. Can you see changes on the display if you write data to this address by U-Boot mw command (i.e. mw a500 100) ? No.. but the memory will have all f's contained in it until I reboot. Well, if you do not see changes on the display, that means your OMAP display controller doesn't fetch data starting from this frame buffer base address. Otherwise you would see some white lines on the display. Best regards, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] at91sam9x5ek: Pass serial and revision tags to Linux
Hi Andreas,
On Fri, May 10, 2013 at 12:21 PM, Andreas Bießmann
andreas.de...@googlemail.com wrote:
Dear Julius Hemanth P,
first of all, please address Bo's comment about checkpatch:
I am sorry, Its my fault, will address them in next patch.
---8---
andreas@andreas-mbp % ./tools/checkpatch.pl ~/Downloads/\[PATCH\ v3\]\
at91sam9x5ek_\ Pass\ serial\ and\ revision\ tags\ to\ Linux.eml
ERROR: DOS line endings
#70: FILE: board/atmel/at91sam9x5ek/at91sam9x5ek.c:30:
+#include asm/arch/at91_gpbr.h^M$
ERROR: patch seems to be corrupt (line wrapped?)
#75: FILE: board/atmel/at91sam9x5ek/at91sam9x5ek.c:48:
total: 38 errors, 7 warnings, 1 checks, 66 lines checked
NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
scripts/cleanfile
NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX
MULTISTATEMENT_MACRO_USE_DO_WHILE USLEEP_RANGE
/Users/andreas/Downloads/[PATCH v3] at91sam9x5ek_ Pass serial and
revision tags to Linux.eml has style problems, please review.
If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
---8---
On 09.05.13 19:07, Julius Hemanth P wrote:
This code is small snippet from patch
ftp://ftp.linux4sam.org/pub/uboot/u-boot-v2010.06/u-boot-5series_1.0.patch
Linux 2.6.39 (released on www.at91.com/linux4sam) requires serial and
revision ATAGs to detect NAND device.
This patch provides backward compatibility for old Linux 2.6.39 by
passing serial and revision ATAGs to Linux kernel.
Signed-off-by: Julius Hemanth juliushema...@gmail.com
---
Changes for v3:
- corrected GPBR register access
- updated commit message
Changes for v2:
- access GPBR using c structure
- removed tailing 1 for #define
- s/Miscelaneous/Miscellaneous
- s/initialisations/initializations
board/atmel/at91sam9x5ek/at91sam9x5ek.c | 33
-
include/configs/at91sam9x5ek.h | 5 +
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/board/atmel/at91sam9x5ek/at91sam9x5ek.c
b/board/atmel/at91sam9x5ek/at91sam9x5ek.c
index 8773e6f..116bd83 100644
--- a/board/atmel/at91sam9x5ek/at91sam9x5ek.c
+++ b/board/atmel/at91sam9x5ek/at91sam9x5ek.c
@@ -27,6 +27,7 @@
#include asm/arch/at91_common.h
#include asm/arch/at91_pmc.h
#include asm/arch/at91_rstc.h
+#include asm/arch/at91_gpbr.h
#include asm/arch/gpio.h
#include asm/arch/clk.h
#include lcd.h
@@ -48,8 +49,34 @@ DECLARE_GLOBAL_DATA_PTR;
/*
- */
/*
- * Miscelaneous platform dependent initialisations
+ * Miscellaneous platform dependent initializations
*/
+
+#ifdef CONFIG_LOAD_ONE_WIRE_INFO
What the hell has this one wire thing to do with reading internal GPBR's?
This is a new config parameter (which lacks documentation in this patch)
is not required at all cause it is enabled in any case, or do I miss
something?
AT91Bootstrap reads board revision and serial info from 1 wire chip
and writes it to GPBR registers. U-boot, in board_init(), reads that
info from GPBR and places it in global variables in order to pass it
to Linux. At the time of boot_prep_linux(), these info will be read
from global variables and passed to linux kernel as ATAGs.
The board at91sam9x5ek I came across has this 1 wire chip connected,
But I am really not sure if this is true with all at91sam9x5ek boards,
hence I made a config parameter so that others can just enable or
disable reading rev and serial info from 1 wire chip(in this case from
GPBR registers).
+static u32 system_rev;
+static u32 system_serial_low;
Can we please omit these global variables? We could just read the GPBR's
in respective get-functions. This will reduce the .bss and .text size
and is therefore reasonable.
May be yes, if we have some place to preserve these info for
processing at later stage, As of now I am really not aware of any such
struct. If you have any suggestion of one such place, please suggest
me so that I can omit these global variables. I too dislike the idea
of using global variables.
+
+u32 get_board_rev(void)
+{
+ return system_rev;
+}
+
+void get_board_serial(struct tag_serialnr *serialnr)
+{
+ serialnr-high = 0; /* Not used */
+ serialnr-low = system_serial_low;
+}
+
+void load_1wire_info(void)
+{
+ at91_gpbr_t *gpbr = (at91_gpbr_t *) ATMEL_BASE_GPBR;
+
+ /* serial is in GPBR #2 and revision is in GPBR #3 */
Why is that so? Which code places the serial and revision version into
the GPBR's?
Please add documentation and mark the usage in at91_gpbr.h.
As at91_gpbr.h states GPBR[3] is already used for bootcount ... so I
tend to completely NAK this patch.
In early stage of U-boot, at the time of board_init(), we read serial
and revision info from GPBR registers, which making GPBR registers
free and available for other
Re: [U-Boot] [PATCH v5 1/4] usb: hub: make minimum power-on delay configurable
Dear Kuo-Jung Su, From: Kuo-Jung Su dant...@faraday-tech.com This patch makes the minimum power-on delay for USB HUB become configurable. The original design waits at least 100 msec here, but some EHCI controlers(e.g. Faraday EHCI) are known to require much longer delay interval. NOTE: The minimal delay is still 100 msec, a small value defined in CONFIG_USB_HUB_MIN_POWER_ON_DELAY would be automatically justified in common/usb_hub.c. Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com CC: Marek Vasut ma...@denx.de --- Changes for v5: - Split up from Faraday EHCI patch - Replace the Faraday EHCI ifdef for the long delay in usb_hub_configure() with the new configuration option: USB_HUB_MIN_POWER_ON_DELAY, which is used in usb_hub_power_on() to control the minimum usb hub power-on delay. Changes for v2 - v4: - See 'usb: ehci: add Faraday USB 2.0 EHCI support' README |3 +++ common/usb_hub.c |8 +++- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/README b/README index 0d37d56..c70a59b 100644 --- a/README +++ b/README @@ -1244,6 +1244,9 @@ The following options need to be configured: CONFIG_USB_EHCI_TXFIFO_THRESH enables setting of the txfilltuning field in the EHCI controller on reset. + CONFIG_USB_HUB_MIN_POWER_ON_DELAY defines the minimum + interval for usb hub power-on delay.(minimum 100msec) + - USB Device: Define the below if you wish to use the USB console. Once firmware is rebuilt from a serial console issue the diff --git a/common/usb_hub.c b/common/usb_hub.c index b5eeb62..0db3530 100644 --- a/common/usb_hub.c +++ b/common/usb_hub.c @@ -61,6 +61,12 @@ #define USB_HUB_DEBUG0 #endif +#if CONFIG_USB_HUB_MIN_POWER_ON_DELAY 100 +# define USB_HUB_MIN_POWER_ON_DELAY CONFIG_USB_HUB_MIN_POWER_ON_DELAY +#else +# define USB_HUB_MIN_POWER_ON_DELAY 100 +#endif Even better (and easier) solution here would be: ifndef CONFIG_USB_HUB_MIN_POWER_ON_DELAY #define CONFIG_USB_HUB_MIN_POWER_ON_DELAY 100 #endif no ? ;-) #define USB_PRINTF(fmt, args...) debug_cond(USB_DEBUG, fmt, ##args) #define USB_HUB_PRINTF(fmt, args...) debug_cond(USB_HUB_DEBUG, fmt, ##args) @@ -121,7 +127,7 @@ static void usb_hub_power_on(struct usb_hub_device *hub) } /* Wait at least 100 msec for power to become stable */ - mdelay(max(pgood_delay, (unsigned)100)); + mdelay(max(pgood_delay, USB_HUB_MIN_POWER_ON_DELAY)); } void usb_hub_reset(void) -- 1.7.9.5 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 v5 2/4] usb: ehci: add weak-aliased functions to portsc tdi
Dear Kuo-Jung Su,
From: Kuo-Jung Su dant...@faraday-tech.com
There is at least one non-EHCI compliant controller (i.e. Faraday EHCI)
known to implement a non-standard TDI stuff.
Futhermore, it not only leave reserved and CONFIGFLAG registers
un-implemented but also has their address spaces removed.
And thus, we need weak-aliased functions to both TDI stuff
and PORTSC registers for interface abstraction.
Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
CC: Marek Vasut ma...@denx.de
---
Changes for v5:
- Split up from Faraday EHCI patch
Changes for v2 - v4:
- See 'usb: ehci: add Faraday USB 2.0 EHCI support'
drivers/usb/host/ehci-hcd.c | 100
+++ 1 file changed, 64
insertions(+), 36 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index c816878..b334173 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -117,10 +117,50 @@ static struct descriptor {
};
#if defined(CONFIG_EHCI_IS_TDI)
-#define ehci_is_TDI()(1)
-#else
-#define ehci_is_TDI()(0)
+# define ehci_is_TDI() (1)
+
+/* put TDI/ARC silicon into EHCI mode */
+void __ehci_tdi_reset(struct ehci_hcor *hcor)
+{
+ uint32_t tmp, *reg_ptr;
+
+ reg_ptr = (uint32_t *)((uint8_t *) + USBMODE);
+ tmp = ehci_readl(reg_ptr);
+ tmp |= USBMODE_CM_HC;
+#if defined(CONFIG_EHCI_MMIO_BIG_ENDIAN)
+ tmp |= USBMODE_BE;
#endif
+ ehci_writel(reg_ptr, tmp);
+}
+
+void ehci_tdi_reset(struct ehci_hcor *hcor)
+ __attribute__((weak, alias(__ehci_tdi_reset)));
Just wrap this into simple
__weak void ehci_tdi_reset(struct ehci_hcor *hcor)
{
...body of __ehci_tdi_reset() above ...
}
it's the same thing as those two functions above, but without so much code ;-)
if it doesn't work, include linux/compiler.h, same below.
+int __ehci_port_speed(struct ehci_hcor *hcor, unsigned int portsc)
+{
+ int ret = 0;
+
+ switch (PORTSC_PSPD(portsc)) {
+ case PORTSC_PSPD_FS:
+ break;
+ case PORTSC_PSPD_LS:
+ ret = USB_PORT_STAT_LOW_SPEED;
+ break;
+ case PORTSC_PSPD_HS:
+ default:
+ ret = USB_PORT_STAT_HIGH_SPEED;
+ break;
+ }
+
+ return ret;
+}
+
+int ehci_port_speed(struct ehci_hcor *hcor, unsigned int portsc)
+ __attribute__((weak, alias(__ehci_port_speed)));
+
+#else /* CONFIG_EHCI_IS_TDI */
+# define ehci_is_TDI() (0)
+#endif /* CONFIG_EHCI_IS_TDI */
void __ehci_powerup_fixup(uint32_t *status_reg, uint32_t *reg)
{
@@ -149,8 +189,6 @@ static int handshake(uint32_t *ptr, uint32_t mask,
uint32_t done, int usec) static int ehci_reset(int index)
{
uint32_t cmd;
- uint32_t tmp;
- uint32_t *reg_ptr;
int ret = 0;
cmd = ehci_readl(ehcic[index].hcor-or_usbcmd);
@@ -163,15 +201,8 @@ static int ehci_reset(int index)
goto out;
}
- if (ehci_is_TDI()) {
- reg_ptr = (uint32_t *)((u8 *)ehcic[index].hcor + USBMODE);
- tmp = ehci_readl(reg_ptr);
- tmp |= USBMODE_CM_HC;
-#if defined(CONFIG_EHCI_MMIO_BIG_ENDIAN)
- tmp |= USBMODE_BE;
-#endif
- ehci_writel(reg_ptr, tmp);
- }
+ if (ehci_is_TDI())
+ ehci_tdi_reset(ehcic[index].hcor);
#ifdef CONFIG_USB_EHCI_TXFIFO_THRESH
cmd = ehci_readl(ehcic[index].hcor-or_txfilltuning);
@@ -597,6 +628,18 @@ static inline int min3(int a, int b, int c)
return a;
}
+uint32_t *__ehci_get_portsc_register(struct ehci_hcor *hcor, int port)
+{
+ if (port = CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS) {
+ printf(The request port(%d) is not configured\n, port);
+ return NULL;
+ }
+
+ return (uint32_t *)hcor-or_portsc[port];
+}
+uint32_t *ehci_get_portsc_register(struct ehci_hcor *hcor, int port)
+ __attribute__((weak, alias(__ehci_get_portsc_register)));
+
int
ehci_submit_root(struct usb_device *dev, unsigned long pipe, void *buffer,
int length, struct devrequest *req)
@@ -609,13 +652,10 @@ ehci_submit_root(struct usb_device *dev, unsigned
long pipe, void *buffer, uint32_t *status_reg;
struct ehci_ctrl *ctrl = dev-controller;
- if (le16_to_cpu(req-index) CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS) {
- printf(The request port(%d) is not configured\n,
- le16_to_cpu(req-index) - 1);
+ status_reg = ehci_get_portsc_register(ctrl-hcor,
+ le16_to_cpu(req-index) - 1);
+ if (!status_reg)
return -1;
- }
- status_reg = (uint32_t *)ctrl-hcor-or_portsc[
- le16_to_cpu(req-index) - 1];
srclen = 0;
debug(req=%u (%#x), type=%u (%#x), value=%u, index=%u\n,
@@ -709,23 +749,10 @@ ehci_submit_root(struct usb_device *dev, unsigned
long pipe, void *buffer, tmpbuf[0]
Re: [U-Boot] [U-Boot,v2] cmd_boot: cleanup for 'go' command
On Sun, Apr 28, 2013 at 04:53:08PM -, Kuo-Jung Su wrote: From: Kuo-Jung Su dant...@faraday-tech.com With MMU/D-Cache enabled, data might be retained at d-cache rather than at DRAM when we execute 'go' command, and some of the bare-metal softwares would always invalidate the entire data cache at start-up, and then leads to a data lost issue. Furthermore, the U-Boot not only relocates itself but also updates symbol table at start-up, which means the i-cache might also be dirty, so it would be better to invalidates the i-cache alone with d-cache flush. This patch is designed to fix the issues above. It has been verified at ARM based systems, and should also work at other platforms. This patch has a few not trivially solvable problems. First, the only weak version of invalidate_icache_all is in common/cmd_cache.c. The only defined version of the function is for ARMv7 CPUs. So, everyone that is not ARMv7 and does not have CONFIG_CMD_CACHE will not build now. And I'm not seeing a globally defined CONFIG to say Yes, we are ARMv7 or Yes, we have icache to invalidate. This actually seems related to the cache flush issue that Freescale folks brought up a few weeks ago. Or maybe that's my pre-coffee brain talking. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: cfi_flash: Fix unaligned accesses to cfi_qry structure
Hello Masahiro-san, Dear Andrew Gabbasov, This way of starting emails seems to be dangerously widely adopted ;-D Your patch seems to newly generate the following warning and error, because your patch is changing the type of 'qry-max_buf_write_size' from u16 to u8[2]. cfi_flash.c:2038:33: warning: comparison between pointer and integer [enabled by default] cfi_flash.c:2046:27: error: incompatible types when assigning to type 'u8[2]' from type 'int' Good find. By the way, I also had this unalignment access problem for my board. Before finding your patch, I was thinking another way to fix this problem. My idea is to just use 'get_unaligned' and 'put_unaligned' functions instead of introducing special macros. With this way, we don't need to change the fields of struct cfi_qry. I think we should make sure to use natural alignment as much as possible, really. I'm keeping Albert in CC because this is his turf. If you fix the above problem, I think your patch will be fine. But I am wondering which way is more smart. Best regards, Masahiro Yamada [...] Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ti/master
Hello,
The following changes since commit 8934f7846501070a5b01c1fab5db27559e9d70d1:
i2c: zynq: Add support for Xilinx Zynq (2013-04-30 11:39:28 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-ti.git master
for you to fetch changes up to 47c6ea076eb51e624f8744d93db5cd70b97dc25d:
ARM: OMAP: Add arch_cpu_init function (2013-05-10 08:25:56 -0400)
Dan Murphy (2):
ARM:Panda:Fix device tree loading for the panda-es
ARM: Panda: Add flag to allow runtime enviroment varibale mods
Enric Balletbo i Serra (2):
Add DDR3 support for IGEP COM AQUILA/CYGNUS.
ARM: Add support for IGEP COM AQUILA/CYGNUS
Eric Benard (2):
da850: provide davinci_enable_uart0
davinci: handle CONFIG_SYS_CLE_MASK and CONFIG_SYS_ALE_MASK
Igor Grinberg (3):
cm-t35: move cm-t35 to live in compulab directory
MAINTAINERS: fix the cm-t35 board name
cm-t35: update config file
Lokesh Vutla (2):
arm: omap: emif: Fix DDR3 init after warm reset
ARM: OMAP5: Fix warm reset with USB cable connected
Lubomir Popov (4):
OMAP5: I2C: Enable i2c5 clocks
OMAP5: I2C: Add I2C4 and I2C5 bases
OMAP5: I2C: Set I2C_BUS_MAX to 5 to enable I2C4 and I2C5
OMAP5: USB: hsusbtll_clkctrl has to be in hw_auto for USB to work
Mark Jackson (1):
Remove duplicate / unused #defines on AM335x boards
Matt Porter (4):
am33xx: add pll and clock support for TI814x CPSW
cpsw: add support for TI814x slave_regs differences
phy: add support for ET1011C phys
ti814x_evm: enable CPSW support
Nishanth Menon (10):
twl4030: make twl4030_i2c_write_u8 prototype consistent
twl4030: make twl4030_i2c_read_u8 prototype consistent
twl6030: twl6030_i2c_[read|write]_u8 prototype consistent
twl6030: move twl6030 register access functions to common header file
twl6030: add header guard
twl6035: rename to palmas
palmas: rename init_settings to an generic palmas init
palmas: rename twl6035_mmc1_poweron_ldo with an palmas generic function
palmas: use palmas_i2c_[read|write]_u8
palmas: add header guard
SRICHARAN R (5):
ARM: OMAP: Make omap_boot_parameters common across socs
ARM: OMAP4/5: Make OMAPx_SRAM_SCRATCH_ defines common
ARM: OMAP: Correct save_boot_params and replace with 'C' function
ARM: OMAP: Cleanup boot parameters usage
ARM: OMAP: Add arch_cpu_init function
Tom Rini (3):
beagleboard: Update comment in get_board_rev()
omap5_common: Add optargs variable for kernel command line args
am33xx: Fix warning with CONFIG_DISPLAY_CPUINFO
MAINTAINERS|3 +-
README |4 +
arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c|8 +
arch/arm/cpu/armv7/am33xx/clock_ti814x.c | 103 ++-
arch/arm/cpu/armv7/am33xx/sys_info.c |6 +-
arch/arm/cpu/armv7/lowlevel_init.S |8 +-
arch/arm/cpu/armv7/omap-common/boot-common.c | 31 +--
arch/arm/cpu/armv7/omap-common/clocks-common.c |1 +
arch/arm/cpu/armv7/omap-common/emif-common.c | 11 +-
arch/arm/cpu/armv7/omap-common/hwinit-common.c | 61 -
arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 50 +---
arch/arm/cpu/armv7/omap-common/reset.c |4 +
arch/arm/cpu/armv7/omap4/emif.c|4 +-
arch/arm/cpu/armv7/omap4/hw_data.c |2 +-
arch/arm/cpu/armv7/omap4/hwinit.c |3 +-
arch/arm/cpu/armv7/omap5/emif.c|4 +-
arch/arm/cpu/armv7/omap5/hw_data.c |5 +-
arch/arm/cpu/armv7/omap5/hwinit.c | 22 +-
arch/arm/cpu/armv7/omap5/prcm-regs.c |2 +
arch/arm/include/asm/arch-am33xx/ddr_defs.h| 17 ++
arch/arm/include/asm/arch-am33xx/hardware_ti814x.h |1 +
arch/arm/include/asm/arch-am33xx/omap.h| 25 --
arch/arm/include/asm/arch-davinci/hardware.h |2 +
arch/arm/include/asm/arch-davinci/nand_defs.h |9 +
arch/arm/include/asm/arch-omap4/omap.h | 36 ---
arch/arm/include/asm/arch-omap4/sys_proto.h| 12 +-
arch/arm/include/asm/arch-omap5/clocks.h | 10 +
arch/arm/include/asm/arch-omap5/cpu.h |2 +
arch/arm/include/asm/arch-omap5/i2c.h |2 +-
arch/arm/include/asm/arch-omap5/omap.h | 36 ---
arch/arm/include/asm/arch-omap5/sys_proto.h| 22 +-
arch/arm/include/asm/global_data.h |8 +
arch/arm/include/asm/omap_boot.h | 50
arch/arm/include/asm/omap_common.h | 20 ++
board/{ = compulab}/cm_t35/Makefile | 12 +-
board/{ = compulab}/cm_t35/cm_t35.c | 26 +-
board/{ = compulab}/cm_t35/display.c |
Re: [U-Boot] [PATCH v3] at91sam9x5ek: Pass serial and revision tags to Linux
Hi Julius,
On 05/10/2013 01:40 PM, Julius Hemanth P wrote:
Hi Andreas,
On Fri, May 10, 2013 at 12:21 PM, Andreas Bießmann
andreas.de...@googlemail.com wrote:
Dear Julius Hemanth P,
On 09.05.13 19:07, Julius Hemanth P wrote:
snip
diff --git a/board/atmel/at91sam9x5ek/at91sam9x5ek.c
b/board/atmel/at91sam9x5ek/at91sam9x5ek.c
index 8773e6f..116bd83 100644
--- a/board/atmel/at91sam9x5ek/at91sam9x5ek.c
+++ b/board/atmel/at91sam9x5ek/at91sam9x5ek.c
@@ -27,6 +27,7 @@
#include asm/arch/at91_common.h
#include asm/arch/at91_pmc.h
#include asm/arch/at91_rstc.h
+#include asm/arch/at91_gpbr.h
#include asm/arch/gpio.h
#include asm/arch/clk.h
#include lcd.h
@@ -48,8 +49,34 @@ DECLARE_GLOBAL_DATA_PTR;
/*
- */
/*
- * Miscelaneous platform dependent initialisations
+ * Miscellaneous platform dependent initializations
*/
+
+#ifdef CONFIG_LOAD_ONE_WIRE_INFO
What the hell has this one wire thing to do with reading internal GPBR's?
This is a new config parameter (which lacks documentation in this patch)
is not required at all cause it is enabled in any case, or do I miss
something?
AT91Bootstrap reads board revision and serial info from 1 wire chip
and writes it to GPBR registers. U-boot, in board_init(), reads that
info from GPBR and places it in global variables in order to pass it
to Linux. At the time of boot_prep_linux(), these info will be read
from global variables and passed to linux kernel as ATAGs.
there are a lot of outdated stuff involved ;)
* ATAGs will be replaced by FDT
* AT91bootstrap should be replaced with u-boot SPL
The board at91sam9x5ek I came across has this 1 wire chip connected,
But I am really not sure if this is true with all at91sam9x5ek boards,
hence I made a config parameter so that others can just enable or
disable reading rev and serial info from 1 wire chip(in this case from
GPBR registers).
We have a single definition for all at91sam9x5ek variants. If there are
some which do not provide such an 1wire id chip we need to address this
here (or in at91bootstrap). I think we shouldn't force the user to
change the board config header to enable different variants. We could
introduce a new 'board name' (in boards.cfg) to address this, but as
long as we do not know that we break other boards which do _not_ have
such an 1wire id chip I think it is ok to not introduce a new config.
If we decide to introduce the config parameter we should document it
somewhere.
+static u32 system_rev;
+static u32 system_serial_low;
Can we please omit these global variables? We could just read the GPBR's
in respective get-functions. This will reduce the .bss and .text size
and is therefore reasonable.
May be yes, if we have some place to preserve these info for
processing at later stage, As of now I am really not aware of any such
struct. If you have any suggestion of one such place, please suggest
me so that I can omit these global variables. I too dislike the idea
of using global variables.
Well, my first idea was to define these places in GPBR to be
'system_rev' and 'system_serial_low', but the provided location does not
fit current definition of GPBR ...
+
+u32 get_board_rev(void)
+{
+ return system_rev;
+}
+
+void get_board_serial(struct tag_serialnr *serialnr)
+{
+ serialnr-high = 0; /* Not used */
+ serialnr-low = system_serial_low;
+}
+
+void load_1wire_info(void)
+{
+ at91_gpbr_t *gpbr = (at91_gpbr_t *) ATMEL_BASE_GPBR;
+
+ /* serial is in GPBR #2 and revision is in GPBR #3 */
Why is that so? Which code places the serial and revision version into
the GPBR's?
Please add documentation and mark the usage in at91_gpbr.h.
As at91_gpbr.h states GPBR[3] is already used for bootcount ... so I
tend to completely NAK this patch.
In early stage of U-boot, at the time of board_init(), we read serial
and revision info from GPBR registers, which making GPBR registers
free and available for other purpose (like bootcount). Hence, this
patch will not conflict with any part of code which plays with GPBR.
board_init() runs in board_init_r(), this is way to late cause a lot of
stuff runs before, board_early_init_f() is a better place, but I dunno
if we can use .bss while in the board_init_f() phase.
Currently GPBR[3] is reserved for bootcount (in some at91 boards), the
aim of bootcount is to read the bootcount store, increment it and write
the new value. The value in the store must not be changed during power
cycle/reset of the system.
So this change breaks the current GPBR layout for this feature.
As I understand Bo's comment in a prior mail this patch is only required
for one specific kernel which is outdated. Can't you just patch the
kernel to get the whole thing working?
Typically Linux reads serial and revision info from ATAGs, and since
U-boot was not passing serial and revision info to Linux, I thought
patch should
[U-Boot] [PATCH v2] at91sam9260ek: move board id setup to config header
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
Acked-by: Bo Shen voice.s...@atmel.com
---
Changes in v2:
* use only one ifdef for sam9G variants
board/atmel/at91sam9260ek/at91sam9260ek.c | 12
include/configs/at91sam9260ek.h | 18 ++
2 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/board/atmel/at91sam9260ek/at91sam9260ek.c
b/board/atmel/at91sam9260ek/at91sam9260ek.c
index 3aa394a..049b3d7 100644
--- a/board/atmel/at91sam9260ek/at91sam9260ek.c
+++ b/board/atmel/at91sam9260ek/at91sam9260ek.c
@@ -157,18 +157,6 @@ int board_early_init_f(void)
int board_init(void)
{
-#ifdef CONFIG_AT91SAM9G20EK_2MMC
- /* arch number of AT91SAM9G20EK_2MMC-Board */
- gd-bd-bi_arch_number = MACH_TYPE_AT91SAM9G20EK_2MMC;
-#else
-#ifdef CONFIG_AT91SAM9G20EK
- /* arch number of AT91SAM9G20EK-Board */
- gd-bd-bi_arch_number = MACH_TYPE_AT91SAM9G20EK;
-#else
- /* arch number of AT91SAM9260EK-Board */
- gd-bd-bi_arch_number = MACH_TYPE_AT91SAM9260EK;
-#endif
-#endif
/* adress of boot parameters */
gd-bd-bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
diff --git a/include/configs/at91sam9260ek.h b/include/configs/at91sam9260ek.h
index ebcc69a..39a8fc2 100644
--- a/include/configs/at91sam9260ek.h
+++ b/include/configs/at91sam9260ek.h
@@ -128,6 +128,24 @@
(ATMEL_BASE_SRAM1 + 0x1000 - GENERATED_GBL_DATA_SIZE)
#endif
+/*
+ * The (arm)linux board id set by generic code depending on configured board
+ * (see boards.cfg for different boards)
+ */
+#ifdef CONFIG_AT91SAM9G20
+ /* the sam9g20 variants have two different board ids */
+# ifdef CONFIG_AT91SAM9G20EK_2MMC
+ /* we may be setup for the 2MMC variant of at91sam9g20ek */
+# define CONFIG_MACH_TYPE MACH_TYPE_AT91SAM9G20EK_2MMC
+# else
+ /* or the normal at91sam9g20ek */
+# define CONFIG_MACH_TYPE MACH_TYPE_AT91SAM9G20EK
+# endif
+#else
+ /* otherwise default to good old at91sam9260ek */
+# define CONFIG_MACH_TYPE MACH_TYPE_AT91SAM9260EK
+#endif
+
/* DataFlash */
#ifndef CONFIG_AT91SAM9G20EK_2MMC
#define CONFIG_ATMEL_DATAFLASH_SPI
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] avr32: fix relocation address calculation
Hi Andreas, On Fri, 10 May 2013 12:57:21 +0200, Andreas Bießmann andreas.de...@googlemail.com wrote: Hi Albert, On 05/10/2013 11:24 AM, Albert ARIBAUD wrote: Hi Andreas, On Wed, 8 May 2013 11:25:17 +0200, Andreas Bießmann andreas.de...@googlemail.com wrote: Commit 1865286466a5d0c7f2e3c37632da56556c838e9e (Introduce generic link section.h symbol files) changed the __bss_end symbol type from char[] to ulong. This led to wrong relocation parameters which ended up in a not working u-boot. Unfortunately this is not clear to see cause due to RAM aliasing we may get a 'half-working' u-boot then. Fix this by dereferencing the __bss_end symbol where needed. (cc:ing Simon and Tom) The dereferencing is correct, so this patch seems good per se (it could actually have applied when __bss_end was still a char[]). well, as I understood this the __bss_end being a char[] did implicitly take the address when accessing __bss_end (as we do when we have a definition of char foo[2] and we take just 'foo'). But you say here we should reference the address of __bss_end while it was still of type char[]. Sorry, I do not understand that, can you please clarify? There are several concepts here, some pertaining to the compiler, some to the linker. From the linker viewpoint, a symbol is *always* and *only* an address, the first address of the object corresponding to the symbol, and an object is just some area in the addressable space. From the compiler viewpoint, an object has a C type, possibly with an initial value, and a name, which is the symbol. The compiler considers the name/symbol to be value, not the address of the corresponding object... at least most of the time: as you indicate, when the symbol denotes a C array, then the C compiler understand the symbol as the address of the array. The __bss_end symbol does not actually correspond to an object in the usual sense, since the BSS contains all sorts of data: any C global, either uninitialized or initialized with zeroes, whatever its type, ends up in BSS. The most general way one can assign a type to BSS itself is by considering it as a shapeless array of bytes -- hence the char[] definition. Thus, the C compiler considered the name __bss_end to denote the address of the BSS object, and the C code for AVR32 was correct as it was actually referring to the BSS object's address. When the __bss_end symbol's C type was changed to 'ulong', this changed the way the compiler understood the symbol: it now thinks __bss_end is the BSS' value, which has no true sense, and certainly does not mean 'the first 4 bytes of BSS considered as a 32-bit value'. To compensate this, the AVR32 code has to add an to find the address of __bss_end, but the original error is to have changed the type of the BSS. IOW, we should *always* take the address of __bss_end, since this is the only thing it was defined for. We should never give it a chance to even *have* a value at the C level, because we don't want to read, or worse, write, the BSS itself; we only want to access C globals in the BSS. HTH, Best regards Andreas Bießmann Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx.git
On Thu, May 09, 2013 at 05:20:32PM -0500, Andy Fleming wrote: The following changes since commit 4e779ad2e54e39d5343c8c83b4fc686a7bb16859: gpio: Add support for microblaze xilinx GPIO (2013-05-09 11:20:08 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-mpc85xx.git master for you to fetch changes up to a9c81eaa54f6ef0976cf15065cd3efc9430fdca8: powerpc: Add T4160QDS (2013-05-09 17:07:39 -0500) [snip] Roy ZANG (1): powerpc/pcie: add PCIe version 3.x support This change breaks a handful of platforms thusly: Configuring for MPC8315ERDB_NAND - Board: MPC8315ERDB, Options: NAND_U_BOOT pcie.c:315:34: error: 'PCI_LTSSM' undeclared (first use in this function) pcie.c:316:15: error: 'PCI_LTSSM_L0' undeclared (first use in this function) And from MAKEALL: Boards compiled: 637 Boards with errors: 7 ( mpc8308_p1m MPC8315ERDB_NAND MPC8315ERDB MPC837XERDB MPC837XEMDS_HOST MERGERBOX MPC8308RDB ) Please fix, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH] ARM: byteorder: add optimized swab16 and swab32
Use the specialized ARM instructions for swapping 16 and 32 bit values
instead of using the generic ones from include/linux/byteorder/swab.h.
The x86 version in arch/x86/include/asm/byteorder.h was taken as an
example for this.
E.g. for the mx6qsabrelite target this results in ~4k less code.
Signed-off-by: Dirk Behme dirk.be...@gmail.com
---
This patch is marked as RFC due to two questions:
1) These ARM instructions are available in ARMv6 and above. Do we have to limit
this code somehow to = ARMv6? I couldn't find any #define to do this in
U-Boot (?)
2) I'm not sure about the rev16. The rev16 instruction swaps *both* half words,
the lower _and_ the upper one:
REV16 Rd, Rm = Rd[15:8] := Rm[7:0], Rd[7:0] := Rm[15:8], Rd[31:24] :=
Rm[23:16], Rd[23:16] := Rm[31:24]
I'm not sure if we want this? Most probably we only want to swap the lower
half word with swap16()?
arch/arm/include/asm/byteorder.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/include/asm/byteorder.h b/arch/arm/include/asm/byteorder.h
index c3489f1..f21baf0 100644
--- a/arch/arm/include/asm/byteorder.h
+++ b/arch/arm/include/asm/byteorder.h
@@ -15,6 +15,23 @@
#ifndef __ASM_ARM_BYTEORDER_H
#define __ASM_ARM_BYTEORDER_H
+static __inline__ __u32 ___arch__swab32(__u32 x)
+{
+ __asm__(rev %0,%1 /* swap bytes */ \
+ : =r (x) \
+ : 0 (x)); \
+ return x;
+}
+#define __arch__swab32(x) ___arch__swab32(x)
+
+static __inline__ __u16 ___arch__swab16(__u16 x)
+{
+ __asm__(rev16 %0,%1 /* swap bytes */ \
+ : =r (x) \
+ : 0 (x)); \
+ return x;
+}
+#define __arch__swab16(x) ___arch__swab16(x)
#include asm/types.h
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx.git
On May 10, 2013, at 10:23 AM, Tom Rini wrote: On Thu, May 09, 2013 at 05:20:32PM -0500, Andy Fleming wrote: The following changes since commit 4e779ad2e54e39d5343c8c83b4fc686a7bb16859: gpio: Add support for microblaze xilinx GPIO (2013-05-09 11:20:08 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-mpc85xx.git master for you to fetch changes up to a9c81eaa54f6ef0976cf15065cd3efc9430fdca8: powerpc: Add T4160QDS (2013-05-09 17:07:39 -0500) [snip] Roy ZANG (1): powerpc/pcie: add PCIe version 3.x support This change breaks a handful of platforms thusly: Configuring for MPC8315ERDB_NAND - Board: MPC8315ERDB, Options: NAND_U_BOOT pcie.c:315:34: error: 'PCI_LTSSM' undeclared (first use in this function) pcie.c:316:15: error: 'PCI_LTSSM_L0' undeclared (first use in this function) And from MAKEALL: Boards compiled: 637 Boards with errors: 7 ( mpc8308_p1m MPC8315ERDB_NAND MPC8315ERDB MPC837XERDB MPC837XEMDS_HOST MERGERBOX MPC8308RDB ) Please fix, thanks! Ugh, sorry. I even looked very skeptically at that, and decided to trust the change despite my misgivings. I will fix. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request - fpga
Hi Michal, On Mon, 06 May 2013 10:50:44 +0200, Michal Simek mon...@monstr.eu wrote: Hi Tom and Albert, I have created fpga branch. It is based on zynq patches(and request) I sent last week. The reason why it is based on it is that new zynq fpga driver and changes in zynq I have done. Just talk to each other and be aware that this fpga patchset is based on zynq one. Thanks, Michal The following changes since commit 8934f7846501070a5b01c1fab5db27559e9d70d1: i2c: zynq: Add support for Xilinx Zynq (2013-04-30 11:39:28 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git fpga for you to fetch changes up to b03b25caea1ff3a501161f5bc1ad5e5b5b124e0c: fpga: Remove all CONFIG_SYS_* fpga related options (2013-05-06 10:41:30 +0200) Michal Simek (9): fpga: Clean coding style fpga: Fix debug message compilation error cmd: fpga: Clean coding style cmd: fpga: Move fpga_loadbitstream to fpga.c fpga: Change the first parameter in fpga_loadbitstream cmd: fpga: Do not include net.h fpga: zynq: Add support for loading bitstream fpga: Check device name against bitstream name fpga: Remove all CONFIG_SYS_* fpga related options arch/arm/cpu/armv7/zynq/slcr.c | 35 arch/arm/include/asm/arch-zynq/hardware.h | 10 +++- arch/arm/include/asm/arch-zynq/sys_proto.h | 3 + board/xilinx/zynq/board.c | 37 common/cmd_fpga.c | 254 ++--- drivers/fpga/Makefile | 1 + drivers/fpga/fpga.c| 225 +++- drivers/fpga/xilinx.c | 146 +++ drivers/fpga/zynqpl.c | 355 ++ include/altera.h | 17 -- include/configs/M54455EVB.h| 2 +- include/configs/MERGERBOX.h| 2 +- include/configs/MVBC_P.h | 2 +- include/configs/MVBLM7.h | 2 +- include/configs/MVSMR.h| 2 +- include/configs/omap3_mvblx.h | 2 +- include/configs/zynq.h | 6 ++ include/fpga.h | 13 + include/lattice.h | 3 - include/xilinx.h | 25 +--- include/zynqpl.h | 59 +++ 21 files changed, 848 insertions(+), 353 deletions(-) create mode 100644 drivers/fpga/zynqpl.c create mode 100644 include/zynqpl.h Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] avr32: fix relocation address calculation
On May 10, 2013, at 11:09 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: The compiler considers the name/symbol to be value, not the address of the corresponding object... at least most of the time: as you indicate, when the symbol denotes a C array, then the C compiler understand the symbol as the address of the array. I ran into a case one on Codewarrior Mac PPC tools where there was a subtle different here. In an existing body of code there was originally a global char[] defined with a matching extern char[] declared in a header. At some point the definition was changed to char* because the size of the array grew and we wanted it out of the global section. I traced an obscure crash to some assembly code that had worked when the definition was char[] but needed an extra level of indirection when it was char *. During that debugging I found that the declaration had not been changed to char * but the C compiler hadn't cared. It handled the mixed forms just fine despite the clear difference in the code. I surmised it was some subtle issue around PPC's handling of global data (or the Codewarrior PPC ABI) but still don't really know. -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] avr32: fix relocation address calculation
Hi Michael, On Fri, 10 May 2013 13:02:57 -0400, Michael Cashwell mboa...@prograde.net wrote: On May 10, 2013, at 11:09 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: The compiler considers the name/symbol to be value, not the address of the corresponding object... at least most of the time: as you indicate, when the symbol denotes a C array, then the C compiler understand the symbol as the address of the array. I ran into a case one on Codewarrior Mac PPC tools where there was a subtle different here. In an existing body of code there was originally a global char[] defined with a matching extern char[] declared in a header. At some point the definition was changed to char* because the size of the array grew and we wanted it out of the global section. I traced an obscure crash to some assembly code that had worked when the definition was char[] but needed an extra level of indirection when it was char *. Well, of course it did! char* is a pointer to char, with syntactic facilities to use it as a pointer to char array, but char* is not an array. The value of a pointer to char is a (probably 32-bit) address, and you need to dereferenc it to get a char. During that debugging I found that the declaration had not been changed to char * but the C compiler hadn't cared. It handled the mixed forms just fine despite the clear difference in the code. Well, the compiler would not care that one C module would know the symbol as char* and another one would know it as char[], since the compiler treats compilation units completely independently. You would end up using the same address space area for two different objects: an array of chars, overlapped with a (probably 32-bit) pointer to char. Where I worked up until recently, we had a 'coding rule' that required us to always #include a module's .h file (its public interface) from within its .c file (its implementation) if only to make sure the compiler saw both the declarations and the definitions in a single compilation unit, and would thus bark at us for screwing up between declaration and definition. I surmised it was some subtle issue around PPC's handling of global data (or the Codewarrior PPC ABI) but still don't really know. This has nothing to do with PPC or CW; this is just C working as designed. -Mike Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/mpc85xx: support application without resetvec segment in the linker script
From: Ying Zhang b40...@freescale.com
For SD/SPI 2-stage bootloader, the On-Chip Rom code loads the SPL into L2 SRAM,
then jump to it to begin execution. After that, the SPL loads the final uboot
image into DDR, then jump to it to begin execution. The segment .resetvec in
the SPL and in final U-boot is useless.
So, add new symbols CONFIG_SYS_MPC85XX_NO_RESETVEC for this application.
If CONFIG_SYS_MPC85XX_NO_RESETVEC is set, the segment .resetvec is excluded
and the segment .bootpg is placed in the previous 4K of the segment .text.
Signed-off-by: Ying Zhang b40...@freescale.com
---
README |5 +
arch/powerpc/cpu/mpc85xx/u-boot-spl.lds | 15 +++
arch/powerpc/cpu/mpc85xx/u-boot.lds |8
3 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 0d37d56..d8a1198 100644
--- a/README
+++ b/README
@@ -3972,6 +3972,11 @@ Low Level (hardware related) configuration options:
that is executed before the actual U-Boot. E.g. when
compiling a NAND SPL.
+- CONFIG_SYS_MPC85XX_NO_RESETVEC
+ Only for 85xx systems. If this variable is specified, the
section
+ .resetvec is not kept and the section .bootpg is placed in the
+ previous 4k of the .text section.
+
- CONFIG_ARCH_MAP_SYSMEM
Generally U-Boot (and in particular the md command) uses
effective address. It is therefore not necessary to regard
diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
index f2b7bff..dff2398 100644
--- a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
+++ b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
@@ -26,6 +26,13 @@
#include config.h/* CONFIG_BOARDDIR */
OUTPUT_ARCH(powerpc)
+#ifdef CONFIG_SYS_MPC85XX_NO_RESETVEC
+PHDRS
+{
+ text PT_LOAD;
+ bss PT_LOAD;
+}
+#endif
SECTIONS
{
. = CONFIG_SPL_TEXT_BASE;
@@ -68,9 +75,17 @@ SECTIONS
#else
#error unknown NAND controller
#endif
+
+#ifdef CONFIG_SYS_MPC85XX_NO_RESETVEC
+ .bootpg ADDR(.text) - 0x1000 :
+ {
+ KEEP(*(.bootpg))
+ } :text = 0x
+#else
.resetvec ADDR(.text) + RESET_VECTOR_OFFSET : {
KEEP(*(.resetvec))
} = 0x
+#endif
/*
* Make sure that the bss segment isn't linked at 0x0, otherwise its
diff --git a/arch/powerpc/cpu/mpc85xx/u-boot.lds
b/arch/powerpc/cpu/mpc85xx/u-boot.lds
index 0503dce..2643563 100644
--- a/arch/powerpc/cpu/mpc85xx/u-boot.lds
+++ b/arch/powerpc/cpu/mpc85xx/u-boot.lds
@@ -95,6 +95,13 @@ SECTIONS
. = ALIGN(256);
__init_end = .;
+#ifdef CONFIG_SYS_MPC85XX_NO_RESETVEC
+ .bootpg ADDR(.text) - 0x1000 :
+ {
+KEEP(arch/powerpc/cpu/mpc85xx/start.o (.bootpg))
+ } :text = 0x
+ . = ADDR(.text) + 0x8;
+#else
.bootpg RESET_VECTOR_ADDRESS - 0xffc :
{
arch/powerpc/cpu/mpc85xx/start.o (.bootpg)
@@ -117,6 +124,7 @@ SECTIONS
#if (RESET_VECTOR_ADDRESS == 0xfffc)
. |= 0x10;
#endif
+#endif
__bss_start = .;
.bss (NOLOAD) :
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT to replace CONFIG_SPL_NET_SUPPORT
From: Ying Zhang b40...@freescale.com Add a new symbol CONFIG_SPL_ENV_SUPPORT to replace CONFIG_SPL_NET_SUPPORT. In common/Makefile, the environment-related files in SPL is difined by CONFIG_SPL_NET_SUPPORT, it is wrong. Signed-off-by: Ying Zhang b40...@freescale.com --- common/Makefile | 12 +--- include/configs/am335x_evm.h |1 + include/configs/pcm051.h |1 + 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/common/Makefile b/common/Makefile index 0e0fff1..1bd742a 100644 --- a/common/Makefile +++ b/common/Makefile @@ -215,15 +215,13 @@ endif ifdef CONFIG_SPL_BUILD COBJS-y += cmd_nvedit.o -COBJS-y += env_common.o COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o COBJS-$(CONFIG_SPL_YMODEM_SUPPORT) += xyzModem.o -COBJS-$(CONFIG_SPL_NET_SUPPORT) += cmd_nvedit.o -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_attr.o -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_callback.o -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_common.o -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_flags.o -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_nowhere.o +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_common.o +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_attr.o +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_flags.o +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_callback.o +COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o COBJS-$(CONFIG_SPL_NET_SUPPORT) += miiphyutil.o endif COBJS-$(CONFIG_BOUNCE_BUFFER) += bouncebuf.o diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index ef00306..f47d3d1 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -325,6 +325,7 @@ #define CONFIG_SPL_GPIO_SUPPORT #define CONFIG_SPL_YMODEM_SUPPORT #define CONFIG_SPL_NET_SUPPORT +#define CONFIG_SPL_ENV_SUPPORT #define CONFIG_SPL_NET_VCI_STRING AM335x U-Boot SPL #define CONFIG_SPL_ETH_SUPPORT #define CONFIG_SPL_SPI_SUPPORT diff --git a/include/configs/pcm051.h b/include/configs/pcm051.h index d0ea74e..926842f 100644 --- a/include/configs/pcm051.h +++ b/include/configs/pcm051.h @@ -224,6 +224,7 @@ #define CONFIG_SPL_GPIO_SUPPORT #define CONFIG_SPL_YMODEM_SUPPORT #define CONFIG_SPL_NET_SUPPORT +#define CONFIG_SPL_ENV_SUPPORT #define CONFIG_SPL_NET_VCI_STRING pcm051 U-Boot SPL #define CONFIG_SPL_ETH_SUPPORT #define CONFIG_SPL_SPI_SUPPORT -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] ARM: byteorder: add optimized swab16 and swab32
Dirk Behme dirk.be...@gmail.com writes: Use the specialized ARM instructions for swapping 16 and 32 bit values instead of using the generic ones from include/linux/byteorder/swab.h. The x86 version in arch/x86/include/asm/byteorder.h was taken as an example for this. E.g. for the mx6qsabrelite target this results in ~4k less code. Which compiler are you using? GCC 4.5 and later recognises the byteswap pattern and emits these instructions automatically. This gives better code than the inline asm since it allows the compiler to do proper instruction scheduling, and in the 16-bit case it avoids extraneous masking. -- 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] [RFC PATCH] ARM: byteorder: add optimized swab16 and swab32
Am 10.05.2013 18:56, schrieb Måns Rullgård: Dirk Behme dirk.be...@gmail.com writes: Use the specialized ARM instructions for swapping 16 and 32 bit values instead of using the generic ones from include/linux/byteorder/swab.h. The x86 version in arch/x86/include/asm/byteorder.h was taken as an example for this. E.g. for the mx6qsabrelite target this results in ~4k less code. Which compiler are you using? An older gcc 4.4.4 version. GCC 4.5 and later recognises the byteswap pattern and emits these instructions automatically. This gives better code than the inline asm since it allows the compiler to do proper instruction scheduling, and in the 16-bit case it avoids extraneous masking. Thanks, Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] spi: mxc_spi: Update pre and post divider algorithm
On 5/9/2013 10:34 PM, Dirk Behme wrote:
Am 09.05.2013 20:00, schrieb Troy Kisky:
On 5/8/2013 10:19 PM, Dirk Behme wrote:
The spi clock divisor is of the form x * (2**y), or x y, where
x is
1 to 16, and y is 0 to 15. Note the similarity with floating point
numbers.
Convert the desired divisor to the smallest number which is =
desired divisor,
and can be represented in this form. The previous algorithm chose a
divisor
which could be almost twice as large as needed.
Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
Signed-off-by: Dirk Behme dirk.be...@gmail.com
---
drivers/spi/mxc_spi.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 3e903b3..66c2ad8 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -128,7 +128,7 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave
*mxcs, unsigned int cs,
unsigned int max_hz, unsigned int mode)
{
u32 clk_src = mxc_get_clock(MXC_CSPI_CLK);
-s32 pre_div = 1, post_div = 0, i, reg_ctrl, reg_config;
+s32 pre_div = 1, post_div = 0, reg_ctrl, reg_config;
First, I'm totally fine with the patch as it is. I'm just going to
point out things you may want to change, or
send a follow-up patch.
Here, no need to initialize pre_div, post_div, if you delete the if
(clk_src max_hz) below which is not needed.
Hmm, why is it not needed?
If you remove the if, you *always* do at least the computation
pre_div = DIV_ROUND_UP(clk_src, max_hz);
post_div = fls(pre_div - 1);
if (post_div 4) {
I would think that doing the initialization and the if is much cheaper
than always doing above computation, even if its not needed? I would
keep the if.
u32 ss_pol = 0, sclkpol = 0, sclkpha = 0;
struct cspi_regs *regs = (struct cspi_regs *)mxcs-base;
@@ -147,27 +147,24 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave
*mxcs, unsigned int cs,
reg_ctrl |= MXC_CSPICTRL_EN;
reg_write(regs-ctrl, reg_ctrl);
-/*
- * The following computation is taken directly from Freescale's
code.
- */
if (clk_src max_hz) {
This if can be removed.
pre_div = DIV_ROUND_UP(clk_src, max_hz);
If you subtract -1 here instead of when you set the divisor register,
the logic becomes simpler
pre_div = DIV_ROUND_UP(clk_src, max_hz) - 1;
or just
pre_div = (clk_src - 1) / max_hz;
-if (pre_div 16) {
-post_div = pre_div / 16;
-pre_div = 16;
-}
-if (post_div != 0) {
-for (i = 0; i 16; i++) {
-if ((1 i) = post_div)
-break;
-}
-if (i == 16) {
+/* fls(1) = 1, fls(0x8000) = 32, fls(16) = 5 */
+post_div = fls(pre_div - 1);
+if (post_div 4) {
+post_div -= 4;
+
+if (post_div = 16) {
printf(Error: no divider for the freq: %d\n,
max_hz);
return -1;
}
-post_div = i;
+pre_div = (pre_div + (1 post_div) - 1) post_div;
This would become
pre_div = post_div;
+
+} else {
+post_div = 0;
}
+
}
debug(pre_div = %d, post_div=%d\n, pre_div, post_div);
And
MXC_CSPICTRL_PREDIV(pre_div - 1);
would return to
MXC_CSPICTRL_PREDIV(pre_div);
Well, where to do the -1 mainly depends on how we want to interpret
the output of
debug(pre_div = %d, post_div=%d\n, pre_div, post_div);
I'd change to
debug(actual div = %d, pre_div = %d, post_div=%d\n, (pre_div + 1)
post_div, pre_div, post_div);
to eliminate confusion.
There are two options how to understand this, at least the pre_div =
%d part:
a) print the pre_div as the real divider used in a human readable
format. I.e. if we divide by /15 then print 15
or
b) print the pre_div value we write to the register. I.e. if we divide
by /15 then print 14
Up to now we are doing (a) and calculate the register value after the
debug print. Your proposal would switch this to (b). Anyway, if it
makes the algorithm simpler I'd agree that it's fine to switch to (b).
To summarize, this would become then:
s32 pre_div = 1, post_div = 0, reg_ctrl, reg_config;
...
If you keep the if, pre_div = 0
Also, I'd change s32 to unsigned or u32.
But usually the if will be true, so why keep it?
It is just code bloat and prone to errors like yours above.
The only logic difference between keeping/killing the if is when
clk_src == 0. Keeping will give a divide by 1. Killing will give an error.
I'd argue that an error is more appropriate.
if (clk_src max_hz) {
pre_div = (clk_src - 1) / max_hz;
/* fls(1) = 1, fls(0x8000) = 32, fls(16) = 5 */
post_div = fls(pre_div);
if (post_div 4) {
post_div -= 4;
if (post_div = 16) {
printf(Error: no divider for the freq: %d\n, max_hz);
return -1;
}
pre_div = post_div;
}
Re: [U-Boot] Beagle-XM: u-boot SPL fat support (was Re: [opensuse-arm] Beagleboard Xm CPU speed)
On 19.03.2013, at 23:12, Tom Rini wrote: On 03/19/2013 03:53 PM, Alexander Graf wrote: On 19.03.2013, at 18:01, Nishanth Menon wrote: Change in subject. Original thread start: http://lists.opensuse.org/opensuse-arm/2013-03/msg00076.html On 17:15-20130319, Guillaume Gardet wrote: Le 19/03/2013 17:04, Nishanth Menon a йcrit : On 08:47-20130319, gary wrote: Just a FYI, here is the the boot text dumped to the serial port. It indicates a 1GHz max clock rate, but maybe that is just a capability of the board (as in a designation) and not a parameter that has been set. I see in the boot text there is a way to interrupt the automatic boot, which I presume is a way to set parameters. Could someone give me what such a line would look like for forcing the mpurate? --- Texas Instruments X-Loader 1.5.0 (Sep 8 2012 - 02:21:18) Beagle xM Reading boot sector Error: reading boot sector fat load failed, trying ext2 Loading u-boot.bin from mmc Why are we still using old x-loader - we should be using SPL MLO from u-boot master - it works straight on beagleXM. Our last tests with SPL and latest u-boot were unsuccessful! And we have to port ext2 support to it because we have no FAT partition. Quote from an internal query I just did: There shouldn't be a case where xM has memory that X-Loader works for that SPL did not. The issue was that with SPL and proper upstream u-boot from ~fall last year, my beagleboard xm was unstable. It constantly crashed. So I reverted back to the old x-loader booting, as that kept things stable. If you can try current U-Boot or provide more details about the instability I'd appreciate it. Alrighty, we switched all images to upstream SPL now. Let's see what happens :). There _may_ be a UART issue that needs work-arounding however. And of course if they used mainline they could pretty easily do RAW for SPL/U-Boot.img and then do everything else with ext2/3/4 and ignore FAT. The default that we stuck with so far (though we can certainly change that) is to keep u-boot as a file in ext2, so that it can easily be updated. That maybe wasn't the most clever decision and going with raw is the way to go, but it's what we do today. That's fine and a decent idea. I'd be happy to review patches to make this a clean option in SPL, even. A plus of moving to mainline would be that ext4 is supported now too. Oh, with recent u-boot and the SPL approach for OMAP this already is a pretty clean option. You only need to enable the CMD defines and change the default bootcmd :). Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Beagle-XM: u-boot SPL fat support (was Re: [opensuse-arm] Beagleboard Xm CPU speed)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/10/2013 02:31 PM, Alexander Graf wrote: On 19.03.2013, at 23:12, Tom Rini wrote: On 03/19/2013 03:53 PM, Alexander Graf wrote: On 19.03.2013, at 18:01, Nishanth Menon wrote: Change in subject. Original thread start: http://lists.opensuse.org/opensuse-arm/2013-03/msg00076.html On 17:15-20130319, Guillaume Gardet wrote: Le 19/03/2013 17:04, Nishanth Menon a йcrit : On 08:47-20130319, gary wrote: Just a FYI, here is the the boot text dumped to the serial port. It indicates a 1GHz max clock rate, but maybe that is just a capability of the board (as in a designation) and not a parameter that has been set. I see in the boot text there is a way to interrupt the automatic boot, which I presume is a way to set parameters. Could someone give me what such a line would look like for forcing the mpurate? --- Texas Instruments X-Loader 1.5.0 (Sep 8 2012 - 02:21:18) Beagle xM Reading boot sector Error: reading boot sector fat load failed, trying ext2 Loading u-boot.bin from mmc Why are we still using old x-loader - we should be using SPL MLO from u-boot master - it works straight on beagleXM. Our last tests with SPL and latest u-boot were unsuccessful! And we have to port ext2 support to it because we have no FAT partition. Quote from an internal query I just did: There shouldn't be a case where xM has memory that X-Loader works for that SPL did not. The issue was that with SPL and proper upstream u-boot from ~fall last year, my beagleboard xm was unstable. It constantly crashed. So I reverted back to the old x-loader booting, as that kept things stable. If you can try current U-Boot or provide more details about the instability I'd appreciate it. Alrighty, we switched all images to upstream SPL now. Let's see what happens :). Yay! There _may_ be a UART issue that needs work-arounding however. And of course if they used mainline they could pretty easily do RAW for SPL/U-Boot.img and then do everything else with ext2/3/4 and ignore FAT. The default that we stuck with so far (though we can certainly change that) is to keep u-boot as a file in ext2, so that it can easily be updated. That maybe wasn't the most clever decision and going with raw is the way to go, but it's what we do today. That's fine and a decent idea. I'd be happy to review patches to make this a clean option in SPL, even. A plus of moving to mainline would be that ext4 is supported now too. Oh, with recent u-boot and the SPL approach for OMAP this already is a pretty clean option. You only need to enable the CMD defines and change the default bootcmd :). You should just be able to provide a uEnv.txt with your custom actual-boot command as uenvcmd. What CMD defines do you need? I'm quite open to enabling more as needed for real world cases. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRjUGdAAoJENk4IS6UOR1W8nYP+gPArBP31donUe0TZfPsC0ef aHwe7shOJp6ZGWMeRii9wzkByYXo2MlFvNyYALEm7cl9PYmngCILuLpQDerhKTFZ G6CQbUSyYhENj5eWQJWZJwFfO58nfVdDTXYT6yFjLGMeZI7bE+khGFsAtounR5Ag XtNUfVbRh9KxS0SJ+kE2uYjfi/BmW2eru8L+Z4Em0jb+Od1HsOVqIlNUOKkb/XEo ZLNuAqRr20ysu3EwF9j0VLBjFNNuR+cGceWJZGRY8u+Xkd/3eCzIRs8m4Gge/ePn XqDEmQZpCeFxosYCfSvmLvp26rTUVZm8oCBTMfCWXOn1Mx9AMmbbg1jnPNENY3Xk ck8+Wy8AmZ+JVAi33v8otdmHeeXoTW4QGpL2ZnG45rOkGoRAxEgL75ARCAYFSEax nk+nvIu6+xnPm8af0UzW1FkO3qkYuId0Wr+WGIPkkGQJu2PthEFgTIY4+aIv+/x8 31pvXFXgVIFubCue47OzR6vBkqvoeK9ZSU0XmGgsEPgOksZ1xI4xs4/5pmDW94yF rmNlhG3mFRv1kiNkUCObXfNuhvSFQNhe/E56cquoHRzuE61rRtWn0dL5rBhKmruB e5QQG8PDuLcUuUqfrFA009qW0cqDFw38Aqobrm+R6LygPeWSpIBQarhCrpkkjKxO AyXKj8GUHAHJH0Kqu/HY =GpkC -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Beagle-XM: u-boot SPL fat support (was Re: [opensuse-arm] Beagleboard Xm CPU speed)
Am 10.05.2013 um 20:51 schrieb Tom Rini tr...@ti.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/10/2013 02:31 PM, Alexander Graf wrote: On 19.03.2013, at 23:12, Tom Rini wrote: On 03/19/2013 03:53 PM, Alexander Graf wrote: On 19.03.2013, at 18:01, Nishanth Menon wrote: Change in subject. Original thread start: http://lists.opensuse.org/opensuse-arm/2013-03/msg00076.html On 17:15-20130319, Guillaume Gardet wrote: Le 19/03/2013 17:04, Nishanth Menon a йcrit : On 08:47-20130319, gary wrote: Just a FYI, here is the the boot text dumped to the serial port. It indicates a 1GHz max clock rate, but maybe that is just a capability of the board (as in a designation) and not a parameter that has been set. I see in the boot text there is a way to interrupt the automatic boot, which I presume is a way to set parameters. Could someone give me what such a line would look like for forcing the mpurate? --- Texas Instruments X-Loader 1.5.0 (Sep 8 2012 - 02:21:18) Beagle xM Reading boot sector Error: reading boot sector fat load failed, trying ext2 Loading u-boot.bin from mmc Why are we still using old x-loader - we should be using SPL MLO from u-boot master - it works straight on beagleXM. Our last tests with SPL and latest u-boot were unsuccessful! And we have to port ext2 support to it because we have no FAT partition. Quote from an internal query I just did: There shouldn't be a case where xM has memory that X-Loader works for that SPL did not. The issue was that with SPL and proper upstream u-boot from ~fall last year, my beagleboard xm was unstable. It constantly crashed. So I reverted back to the old x-loader booting, as that kept things stable. If you can try current U-Boot or provide more details about the instability I'd appreciate it. Alrighty, we switched all images to upstream SPL now. Let's see what happens :). Yay! There _may_ be a UART issue that needs work-arounding however. And of course if they used mainline they could pretty easily do RAW for SPL/U-Boot.img and then do everything else with ext2/3/4 and ignore FAT. The default that we stuck with so far (though we can certainly change that) is to keep u-boot as a file in ext2, so that it can easily be updated. That maybe wasn't the most clever decision and going with raw is the way to go, but it's what we do today. That's fine and a decent idea. I'd be happy to review patches to make this a clean option in SPL, even. A plus of moving to mainline would be that ext4 is supported now too. Oh, with recent u-boot and the SPL approach for OMAP this already is a pretty clean option. You only need to enable the CMD defines and change the default bootcmd :). You should just be able to provide a uEnv.txt with your custom actual-boot command as uenvcmd. What CMD defines do you need? I'm quite open to enabling more as needed for real world cases. Well, that would make the situation on OMAP slightly better, but wouldn't help on other SoCs. I think we should rather try and get a reasonably unified boot environment up across the board first :). Worst case I would only have to s/fat/ext2/g at a single spot then. Or enable dynamic fs detection and use the respective helpers at that one spot. Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] arm: lds: Remove libgcc eabi exception handling tables
Hi Michal, On Thu, 9 May 2013 11:35:33 +0200, Michal Simek michal.si...@xilinx.com wrote: Remove ARM eabi exception handling tables (for frame unwinding). AFAICT, u-boot stubs away the frame unwiding routines, so the tables will more or less just consume space. It should be OK to remove them. Signed-off-by: Edgar E. Iglesias edgar.igles...@xilinx.com Signed-off-by: Michal Simek michal.si...@xilinx.com --- Other options could be to complete u-boot/arch/arm/lib/* so that libgcc routines with exception handling dont get pulled in. Or to avoid user code (like the mentioned patch) which causes external libgcc functions to get pulled in... Er... which mentioned patch? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] spi: mxc_spi: Update pre and post divider algorithm
Am 10.05.2013 20:44, schrieb Troy Kisky:
On 5/9/2013 10:34 PM, Dirk Behme wrote:
Am 09.05.2013 20:00, schrieb Troy Kisky:
On 5/8/2013 10:19 PM, Dirk Behme wrote:
The spi clock divisor is of the form x * (2**y), or x y, where
x is
1 to 16, and y is 0 to 15. Note the similarity with floating point
numbers.
Convert the desired divisor to the smallest number which is =
desired divisor,
and can be represented in this form. The previous algorithm chose a
divisor
which could be almost twice as large as needed.
Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
Signed-off-by: Dirk Behme dirk.be...@gmail.com
---
drivers/spi/mxc_spi.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 3e903b3..66c2ad8 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -128,7 +128,7 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave
*mxcs, unsigned int cs,
unsigned int max_hz, unsigned int mode)
{
u32 clk_src = mxc_get_clock(MXC_CSPI_CLK);
-s32 pre_div = 1, post_div = 0, i, reg_ctrl, reg_config;
+s32 pre_div = 1, post_div = 0, reg_ctrl, reg_config;
First, I'm totally fine with the patch as it is. I'm just going to
point out things you may want to change, or
send a follow-up patch.
Here, no need to initialize pre_div, post_div, if you delete the if
(clk_src max_hz) below which is not needed.
Hmm, why is it not needed?
If you remove the if, you *always* do at least the computation
pre_div = DIV_ROUND_UP(clk_src, max_hz);
post_div = fls(pre_div - 1);
if (post_div 4) {
I would think that doing the initialization and the if is much
cheaper than always doing above computation, even if its not needed?
I would keep the if.
u32 ss_pol = 0, sclkpol = 0, sclkpha = 0;
struct cspi_regs *regs = (struct cspi_regs *)mxcs-base;
@@ -147,27 +147,24 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave
*mxcs, unsigned int cs,
reg_ctrl |= MXC_CSPICTRL_EN;
reg_write(regs-ctrl, reg_ctrl);
-/*
- * The following computation is taken directly from Freescale's
code.
- */
if (clk_src max_hz) {
This if can be removed.
pre_div = DIV_ROUND_UP(clk_src, max_hz);
If you subtract -1 here instead of when you set the divisor register,
the logic becomes simpler
pre_div = DIV_ROUND_UP(clk_src, max_hz) - 1;
or just
pre_div = (clk_src - 1) / max_hz;
-if (pre_div 16) {
-post_div = pre_div / 16;
-pre_div = 16;
-}
-if (post_div != 0) {
-for (i = 0; i 16; i++) {
-if ((1 i) = post_div)
-break;
-}
-if (i == 16) {
+/* fls(1) = 1, fls(0x8000) = 32, fls(16) = 5 */
+post_div = fls(pre_div - 1);
+if (post_div 4) {
+post_div -= 4;
+
+if (post_div = 16) {
printf(Error: no divider for the freq: %d\n,
max_hz);
return -1;
}
-post_div = i;
+pre_div = (pre_div + (1 post_div) - 1) post_div;
This would become
pre_div = post_div;
+
+} else {
+post_div = 0;
}
+
}
debug(pre_div = %d, post_div=%d\n, pre_div, post_div);
And
MXC_CSPICTRL_PREDIV(pre_div - 1);
would return to
MXC_CSPICTRL_PREDIV(pre_div);
Well, where to do the -1 mainly depends on how we want to interpret
the output of
debug(pre_div = %d, post_div=%d\n, pre_div, post_div);
I'd change to
debug(actual div = %d, pre_div = %d, post_div=%d\n, (pre_div + 1)
post_div, pre_div, post_div);
to eliminate confusion.
There are two options how to understand this, at least the pre_div =
%d part:
a) print the pre_div as the real divider used in a human readable
format. I.e. if we divide by /15 then print 15
or
b) print the pre_div value we write to the register. I.e. if we
divide by /15 then print 14
Up to now we are doing (a) and calculate the register value after
the debug print. Your proposal would switch this to (b). Anyway, if
it makes the algorithm simpler I'd agree that it's fine to switch to
(b).
To summarize, this would become then:
s32 pre_div = 1, post_div = 0, reg_ctrl, reg_config;
...
If you keep the if, pre_div = 0
Ah, yes, thanks.
Also, I'd change s32 to unsigned or u32.
But usually the if will be true, so why keep it?
For cases where clk_src = max_hz. Then don't do the calculation
because it's unnecessary.
It is just code bloat and prone to errors like yours above.
The only logic difference between keeping/killing the if is when
clk_src == 0. Keeping will give a divide by 1. Killing will give an
error.
I'd argue that an error is more appropriate.
if (clk_src max_hz) {
pre_div = (clk_src - 1) / max_hz;
/* fls(1) = 1, fls(0x8000) = 32, fls(16) = 5 */
post_div = fls(pre_div);
if (post_div 4) {
post_div -= 4;
if (post_div =
[U-Boot] [PATCH 1/3] mx28evk: Add splash screen support
From: Fabio Estevam fabio.este...@freescale.com
Enable display support.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/mx28evk/iomux.c | 33 +
board/freescale/mx28evk/mx28evk.c |6 ++
include/configs/mx28evk.h | 17 +
3 files changed, 56 insertions(+)
diff --git a/board/freescale/mx28evk/iomux.c b/board/freescale/mx28evk/iomux.c
index ae6eda3..beae0e6 100644
--- a/board/freescale/mx28evk/iomux.c
+++ b/board/freescale/mx28evk/iomux.c
@@ -30,6 +30,7 @@
#defineMUX_CONFIG_ENET (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL)
#defineMUX_CONFIG_SSP2 (MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_PULLUP)
+#defineMUX_CONFIG_LCD (MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_NOPULL)
const iomux_cfg_t iomux_setup[] = {
/* DUART */
@@ -162,6 +163,38 @@ const iomux_cfg_t iomux_setup[] = {
/* I2C */
MX28_PAD_I2C0_SCL__I2C0_SCL,
MX28_PAD_I2C0_SDA__I2C0_SDA,
+
+ /* LCD */
+ MX28_PAD_LCD_D00__LCD_D0 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D01__LCD_D1 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D02__LCD_D2 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D03__LCD_D3 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D04__LCD_D4 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D05__LCD_D5 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D06__LCD_D6 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D07__LCD_D7 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D08__LCD_D8 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D09__LCD_D9 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D10__LCD_D10 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D11__LCD_D11 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D12__LCD_D12 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D13__LCD_D13 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D14__LCD_D14 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D15__LCD_D15 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D16__LCD_D16 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D17__LCD_D17 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D18__LCD_D18 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D19__LCD_D19 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D20__LCD_D20 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D21__LCD_D21 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D22__LCD_D22 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_D23__LCD_D23 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_RD_E__LCD_VSYNC | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_WR_RWN__LCD_HSYNC | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_RS__LCD_DOTCLK | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_CS__LCD_ENABLE | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_RESET__GPIO_3_30 | MUX_CONFIG_LCD, /* LCD power */
+ MX28_PAD_PWM2__GPIO_3_18 | MUX_CONFIG_LCD, /* LCD contrast */
};
#define HW_DRAM_CTL29 (0x74 2)
diff --git a/board/freescale/mx28evk/mx28evk.c
b/board/freescale/mx28evk/mx28evk.c
index de7231b..8f6c281 100644
--- a/board/freescale/mx28evk/mx28evk.c
+++ b/board/freescale/mx28evk/mx28evk.c
@@ -59,6 +59,12 @@ int board_early_init_f(void)
gpio_direction_output(MX28_PAD_AUART2_RX__GPIO_3_8, 1);
#endif
+ /* Power on LCD */
+ gpio_direction_output(MX28_PAD_LCD_RESET__GPIO_3_30, 1);
+
+ /* Set contrast to maximum */
+ gpio_direction_output(MX28_PAD_PWM2__GPIO_3_18, 1);
+
return 0;
}
diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index b22a20b..d6de83f 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -64,6 +64,7 @@
#define CONFIG_CMD_BOOTZ
#define CONFIG_CMD_NAND
#define CONFIG_CMD_NAND_TRIMFFS
+#define CONFIG_VIDEO
/* Memory configurations */
#define CONFIG_NR_DRAM_BANKS 1 /* 1 bank of DRAM */
@@ -235,6 +236,22 @@
#endif
#endif
+/* Framebuffer support */
+#ifdef CONFIG_VIDEO
+#define CONFIG_CFB_CONSOLE
+#define CONFIG_VIDEO_MXS
+#define CONFIG_VIDEO_LOGO
+#define CONFIG_VIDEO_SW_CURSOR
+#define CONFIG_VGA_AS_SINGLE_DEVICE
+#define CONFIG_SYS_CONSOLE_IS_IN_ENV
+#define CONFIG_SPLASH_SCREEN
+#define CONFIG_CMD_BMP
+#define CONFIG_BMP_16BPP
+#define CONFIG_VIDEO_BMP_RLE8
+#define CONFIG_VIDEO_BMP_GZIP
+#define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE (512 10)
+#endif
+
/* Boot Linux */
#define CONFIG_CMDLINE_TAG
#define CONFIG_SETUP_MEMORY_TAGS
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] mx23evk: Add splash screen support
From: Fabio Estevam fabio.este...@freescale.com
Enable display support.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/mx23evk/mx23evk.c |6 ++
board/freescale/mx23evk/spl_boot.c | 32
include/configs/mx23evk.h | 17 +
3 files changed, 55 insertions(+)
diff --git a/board/freescale/mx23evk/mx23evk.c
b/board/freescale/mx23evk/mx23evk.c
index 41ba303..19a631e 100644
--- a/board/freescale/mx23evk/mx23evk.c
+++ b/board/freescale/mx23evk/mx23evk.c
@@ -43,6 +43,12 @@ int board_early_init_f(void)
/* SSP0 clock at 96MHz */
mxs_set_sspclk(MXC_SSPCLK0, 96000, 0);
+ /* Power on LCD */
+ gpio_direction_output(MX23_PAD_LCD_RESET__GPIO_1_18, 1);
+
+ /* Set contrast to maximum */
+ gpio_direction_output(MX23_PAD_PWM2__GPIO_1_28, 1);
+
return 0;
}
diff --git a/board/freescale/mx23evk/spl_boot.c
b/board/freescale/mx23evk/spl_boot.c
index 6be8c8d..4d2ce85 100644
--- a/board/freescale/mx23evk/spl_boot.c
+++ b/board/freescale/mx23evk/spl_boot.c
@@ -27,6 +27,7 @@
#defineMUX_CONFIG_SSP1 (MXS_PAD_8MA | MXS_PAD_PULLUP)
#defineMUX_CONFIG_EMI (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_PULLUP)
+#defineMUX_CONFIG_LCD (MXS_PAD_4MA | MXS_PAD_NOPULL)
const iomux_cfg_t iomux_setup[] = {
/* DUART */
@@ -96,6 +97,37 @@ const iomux_cfg_t iomux_setup[] = {
/* Slot Power Enable */
MX23_PAD_PWM3__GPIO_1_29 |
(MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
+ /* LCD */
+ MX23_PAD_LCD_D00__LCD_D00 | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_D01__LCD_D01 | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_D02__LCD_D02 | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_D03__LCD_D03 | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_D04__LCD_D04 | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_D05__LCD_D05 | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_D06__LCD_D06 | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_D07__LCD_D07 | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_D08__LCD_D08 | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_D09__LCD_D09 | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_D10__LCD_D10 | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_D11__LCD_D11 | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_D12__LCD_D12 | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_D13__LCD_D13 | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_D14__LCD_D14 | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_D15__LCD_D15 | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_D16__LCD_D16 | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_D17__LCD_D17 | MUX_CONFIG_LCD,
+ MX23_PAD_GPMI_D08__LCD_D18 | MUX_CONFIG_LCD,
+ MX23_PAD_GPMI_D09__LCD_D19 | MUX_CONFIG_LCD,
+ MX23_PAD_GPMI_D10__LCD_D20 | MUX_CONFIG_LCD,
+ MX23_PAD_GPMI_D11__LCD_D21 | MUX_CONFIG_LCD,
+ MX23_PAD_GPMI_D12__LCD_D22 | MUX_CONFIG_LCD,
+ MX23_PAD_GPMI_D13__LCD_D23 | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_DOTCK__LCD_DOTCK | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_ENABLE__LCD_ENABLE | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_HSYNC__LCD_HSYNC | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_VSYNC__LCD_VSYNC | MUX_CONFIG_LCD,
+ MX23_PAD_LCD_RESET__GPIO_1_18 | MUX_CONFIG_LCD, /* LCD power */
+ MX23_PAD_PWM2__GPIO_1_28 | MUX_CONFIG_LCD, /* LCD contrast */
};
#define HW_DRAM_CTL14 (0x38 2)
diff --git a/include/configs/mx23evk.h b/include/configs/mx23evk.h
index e5a15a4..3a58afe 100644
--- a/include/configs/mx23evk.h
+++ b/include/configs/mx23evk.h
@@ -60,6 +60,7 @@
#define CONFIG_CMD_MMC
#define CONFIG_CMD_USB
#define CONFIG_CMD_BOOTZ
+#define CONFIG_VIDEO
/* Memory configurations */
#define CONFIG_NR_DRAM_BANKS 1 /* 1 bank of DRAM */
@@ -133,6 +134,22 @@
#define CONFIG_USB_STORAGE
#endif
+/* Framebuffer support */
+#ifdef CONFIG_VIDEO
+#define CONFIG_CFB_CONSOLE
+#define CONFIG_VIDEO_MXS
+#define CONFIG_VIDEO_LOGO
+#define CONFIG_VIDEO_SW_CURSOR
+#define CONFIG_VGA_AS_SINGLE_DEVICE
+#define CONFIG_SYS_CONSOLE_IS_IN_ENV
+#define CONFIG_SPLASH_SCREEN
+#define CONFIG_CMD_BMP
+#define CONFIG_BMP_16BPP
+#define CONFIG_VIDEO_BMP_RLE8
+#define CONFIG_VIDEO_BMP_GZIP
+#define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE (512 10)
+#endif
+
/* Boot Linux */
#define CONFIG_CMDLINE_TAG
#define CONFIG_SETUP_MEMORY_TAGS
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] video: mxsfb: Add an entry for mx23evk/mx28vk video modes
From: Fabio Estevam fabio.este...@freescale.com Currently the mxsfb driver takes the display timings from the 'videomode' environment variable. Provide an example on how to set 'videomode' for using splash screen on mx23evk and mx28vk boards. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- drivers/video/mxsfb.c |5 + 1 file changed, 5 insertions(+) diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c index 461ff6e..b189419 100644 --- a/drivers/video/mxsfb.c +++ b/drivers/video/mxsfb.c @@ -39,6 +39,11 @@ static GraphicDevice panel; * setenv videomode * video=ctfb:x:800,y:480,depth:18,mode:0,pclk:30066, * le:0,ri:256,up:0,lo:45,hs:1,vs:1,sync:100663296,vmode:0 + * + * Freescale mx23evk/mx28evk with a Seiko 4.3'' WVGA panel: + * setenv videomode + * video=ctfb:x:800,y:480,depth:24,mode:0,pclk:29851, + * le:89,ri:164,up:23,lo:10,hs:10,vs:10,sync:0,vmode:0 */ static void mxs_lcd_init(GraphicDevice *panel, -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [v2] Please pull u-boot-mpc85xx.git
The following changes since commit 4e779ad2e54e39d5343c8c83b4fc686a7bb16859: gpio: Add support for microblaze xilinx GPIO (2013-05-09 11:20:08 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-mpc85xx.git master for you to fetch changes up to 65744debd1763f7499b11f7566615926adcae53b: powerpc: Add T4160QDS (2013-05-10 14:14:08 -0500) Andy Fleming (2): powerpc/mpc85xx: Add definitions for HDBCR registers e6500: Move L1 enablement after L2 enablement Roy ZANG (1): powerpc/pcie: add PCIe version 3.x support [fixed this by adding #include asm/fsl_pci.h to 83xx pcie.c file] Roy Zang (3): T4/serdes: fix the serdes clock frequency T4/SerDes: correct the SATA index T4/USB: Add USB 2.0 UTMI dual phy support Sandeep Singh (1): powerpc/B4860: Corrected FMAN1 operating frequency print at u-boot Shaohui Xie (3): powerpc/t4240qds: Fix SPI flash type powerpc/t4240qds: fix XAUI card PHY address Fman/t4240: some fix for 10G XAUI York Sun (11): powerpc/mpc85xx: Update corenet global utility block registers powerpc/t4240qds: Update DDR timing table powerpc/mpc8xxx: Fix DDR 3-way interleaving powerpc/mpc85xx: Fix portal setup powerpc/t4240qds: Add voltage ID support powerpc/corenet2: Print SerDes protocol in decimal powerpc/mpc85xx: Fix PIR parsing for chassis2 powerpc/t4240: Fix SerDes protocol arrays with const prefix powerpc/mpc85xx: Add T4160 SoC powerpc/t4240qds: Move SoC define into boards.cfg powerpc: Add T4160QDS arch/powerpc/cpu/mpc83xx/pcie.c|1 + arch/powerpc/cpu/mpc85xx/Makefile |3 + arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c |2 +- arch/powerpc/cpu/mpc85xx/portals.c | 36 ++-- arch/powerpc/cpu/mpc85xx/release.S | 14 +- arch/powerpc/cpu/mpc85xx/speed.c |8 + arch/powerpc/cpu/mpc85xx/start.S | 102 +-- arch/powerpc/cpu/mpc85xx/t4240_serdes.c| 150 ++- arch/powerpc/cpu/mpc8xxx/cpu.c |1 + arch/powerpc/cpu/mpc8xxx/ddr/main.c| 19 +- arch/powerpc/include/asm/config_mpc85xx.h | 37 +++- arch/powerpc/include/asm/fsl_pci.h | 35 +++- arch/powerpc/include/asm/immap_85xx.h | 66 +-- arch/powerpc/include/asm/processor.h | 11 ++ board/freescale/t4qds/ddr.c| 56 +++--- board/freescale/t4qds/t4qds.c | 233 +++- boards.cfg |9 +- drivers/net/fm/Makefile|1 + drivers/net/fm/eth.c |2 + drivers/net/fm/init.c |6 + drivers/net/fm/t4240.c | 14 +- drivers/pci/fsl_pci_init.c | 20 +- drivers/usb/host/ehci-fsl.c| 21 +++ include/configs/T4240QDS.h |1 - include/configs/t4qds.h| 37 +++- include/fm_eth.h |4 +- include/pci.h |7 - 27 files changed, 734 insertions(+), 162 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Loader script updates for OpenRISC
On Wed, May 01, 2013 at 10:32:44PM +0300, Stefan Kristiansson wrote: This set of patches does: Fix a bug in the openrisc-generic u-boot.lds linker script that would cause an error due to that no memory region was specified for u_boot_lists. And then move the above mentioned file into arch/openrisc/cpu/ to unify the linker script for all openrisc boards (we only have one board). Stefan Kristiansson (2): openrisc: specify a memory region for u_boot_lists openrisc: move board linker script(s) to a common in cpu/ Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86.git
On Thu, May 09, 2013 at 02:30:22PM -0700, Simon Glass wrote: Hi Tom, I left out the one that is not yet reviewed. The following changes since commit 4e779ad2e54e39d5343c8c83b4fc686a7bb16859: gpio: Add support for microblaze xilinx GPIO (2013-05-09 11:20:08 +0200) are available in the git repository at: git://git.denx.de/u-boot-x86.git patman for you to fetch changes up to e85707570cf44f7b2d1da5ae92af3684c72c28f2: patman: Do not hardcode python path (2013-05-09 14:27:41 -0700) Michal Simek (1): patman: Do not hardcode python path Simon Glass (1): buildman: Allow conflicting tags to avoid spurious errors tools/buildman/control.py | 5 + tools/patman/patman.py| 2 +- tools/patman/series.py| 4 +++- 3 files changed, 9 insertions(+), 2 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] build: Pull -DBUILD_TAG into separate ifdef
On Sat, Apr 27, 2013 at 07:50:11AM -, Marek Vasut wrote: Currently the base setting for CFLAGS is split in two possibilities, one with -DBUILD_TAG appended at the end and one without, the rest of CFLAGS is the same in both cases. Change this so CFLAGS are always set and the -DBUILD_TAG is appended in separate ifdef. Signed-off-by: Marek Vasut ma...@denx.de Cc: Wolfgang Denk w...@denx.de Cc: Tom Rini tr...@ti.com Reviewed-by: Otavio Salvador ota...@ossystems.com.br Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] env: throw an error when an empty key is used
On Sun, Apr 28, 2013 at 11:31:57AM -, Lucian Cojocar wrote: If the environment contains an entry like =value \0 we should throw an error when parsing the environment. Otherwise, U-Boot will enter in an infinite loop. Signed-off-by: Lucian Cojocar cojo...@gmail.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Fix references to the documentation files
On Tue, Apr 30, 2013 at 11:15:33AM -, Anatolij Gustschin wrote: Many boot image configuration files refer to the appropriate documentation file, but these references contain typos in the directory and file name. Fix them. Also fix reference to doc/README.SPL file. Signed-off-by: Anatolij Gustschin ag...@denx.de Cc: Prafulla Wadaskar prafu...@marvell.com Cc: Stefano Babic sba...@denx.de Acked-by: Stefano Babic sba...@denx.de Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3] fs/ext4: Support device block sizes != 512 bytes
On Wed, May 01, 2013 at 01:13:19AM -, egbert.e...@gmail.com wrote: From: Egbert Eich e...@suse.com The 512 byte block size was hard coded in the ext4 file systems. Large harddisks today support bigger block sizes typically 4096 bytes. This patch removes this limitation. Signed-off-by: Egbert Eich e...@suse.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2, batch 3 01/17] common: Update cmd_bdinfo for PPC
On Mon, Mar 25, 2013 at 12:39 PM, York Sun york...@freescale.com wrote:
Add board detail function to print more individual board information.
Signed-off-by: York Sun york...@freescale.com
CC: Wolfgang Denk w...@denx.de
CC: Tom Rini tr...@ti.com
Tom, Wolfgang, I can take this in through my tree, but I'd like an ACK
before I do so.
---
common/cmd_bdinfo.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c
index 85279d5..3bf8cf2 100644
--- a/common/cmd_bdinfo.c
+++ b/common/cmd_bdinfo.c
@@ -84,6 +84,12 @@ static void print_mhz(const char *name, unsigned long
hz)
}
#if defined(CONFIG_PPC)
+static void __board_detail(void)
+{
+ /* Please define boot_detail() for your platform */
+}
+
+void board_detail(void) __attribute__((weak, alias(__board_detail)));
int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
@@ -169,6 +175,7 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
printf(IP addr = %s\n, getenv(ipaddr));
printf(baudrate= %6u bps\n, bd-bi_baudrate);
print_num(relocaddr, gd-relocaddr);
+ board_detail();
return 0;
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2, batch 3 01/17] common: Update cmd_bdinfo for PPC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/10/2013 04:16 PM, Andy Fleming wrote:
On Mon, Mar 25, 2013 at 12:39 PM, York Sun york...@freescale.com
mailto:york...@freescale.com wrote:
Add board detail function to print more individual board
information.
Signed-off-by: York Sun york...@freescale.com
mailto:york...@freescale.com CC: Wolfgang Denk w...@denx.de
mailto:w...@denx.de CC: Tom Rini tr...@ti.com
mailto:tr...@ti.com
Tom, Wolfgang, I can take this in through my tree, but I'd like an
ACK before I do so.
--- common/cmd_bdinfo.c |7 +++ 1 file changed, 7
insertions(+)
diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c index
85279d5..3bf8cf2 100644 --- a/common/cmd_bdinfo.c +++
b/common/cmd_bdinfo.c @@ -84,6 +84,12 @@ static void
print_mhz(const char *name, unsigned long hz) }
#if defined(CONFIG_PPC) +static void __board_detail(void) +{ +
/* Please define boot_detail() for your platform */ +} + +void
board_detail(void) __attribute__((weak, alias(__board_detail)));
This should be using __weak from linux/compiler.h
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRjVjbAAoJENk4IS6UOR1WU24P/janPXULTG3dl3JelXRN1622
OoiwxD0QhDUecfp66qa3Tc8uvrk3a20ZIiZon7hdbbFpP6caqp+mBuyRGkyFHrgE
dLCZeRPNhQqS4XONDzW21DbsKEJuxzmfZSxajFRGUaACdQnFh1qJL5vmchCp1D9c
Wrx8uGevkMuLhUE8yjog6VOXEJ4NkWQ8ZQHVrVuPwbdNo7lpVAZau0u+bKdVWKei
jOukn4VJOMTgjPIE5ZWumoQ62y9/GVQih563ZbdXAQzoYWybms38am9FvO064GZN
5zMpVnmWLn/XegOpx1O/ia4FiGhgufRRjsbQETsBLwTiAFTU7PVmgyPfzlTYnqFN
WNmvedXr2y39w5BhTnCBCuJ6YvV/E23G1RxT4c4E6kGd6PJEqTiD9FlXJgedM72W
fD9ODMllcQDhpTtTObeTbgQ9Bp7E04BGMrlXxqzQH1gabi7D+YyB7HsV/F8EXpIH
iqFoq3Zn7TB+SSRvt+JUJcK3xW/36zcxRCKlg7iPtUZ69EICI9GkNog2aX0vyHsT
0Qkk41SWPkIr3VrQojF4ni/l7vx6aekbmuYWs7duK1z8oM8ba7lv0uqdOYJm3uDS
Xd/CoUQIbwDolhZGr/ZQYf8rwK02umvWDsvPxV70yngQ1kBGMETGHcMvb87F7cR/
716aouDllgeSYAFpeVKw
=PUux
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] spi: mxc_spi: Update pre and post divider algorithm
On 5/10/2013 12:08 PM, Dirk Behme wrote:
Am 10.05.2013 20:44, schrieb Troy Kisky:
On 5/9/2013 10:34 PM, Dirk Behme wrote:
Am 09.05.2013 20:00, schrieb Troy Kisky:
On 5/8/2013 10:19 PM, Dirk Behme wrote:
The spi clock divisor is of the form x * (2**y), or x y, where
x is
1 to 16, and y is 0 to 15. Note the similarity with floating point
numbers.
Convert the desired divisor to the smallest number which is =
desired divisor,
and can be represented in this form. The previous algorithm chose a
divisor
which could be almost twice as large as needed.
Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
Signed-off-by: Dirk Behme dirk.be...@gmail.com
---
drivers/spi/mxc_spi.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 3e903b3..66c2ad8 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -128,7 +128,7 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave
*mxcs, unsigned int cs,
unsigned int max_hz, unsigned int mode)
{
u32 clk_src = mxc_get_clock(MXC_CSPI_CLK);
-s32 pre_div = 1, post_div = 0, i, reg_ctrl, reg_config;
+s32 pre_div = 1, post_div = 0, reg_ctrl, reg_config;
First, I'm totally fine with the patch as it is. I'm just going to
point out things you may want to change, or
send a follow-up patch.
Here, no need to initialize pre_div, post_div, if you delete the if
(clk_src max_hz) below which is not needed.
Hmm, why is it not needed?
If you remove the if, you *always* do at least the computation
pre_div = DIV_ROUND_UP(clk_src, max_hz);
post_div = fls(pre_div - 1);
if (post_div 4) {
I would think that doing the initialization and the if is much
cheaper than always doing above computation, even if its not needed?
I would keep the if.
u32 ss_pol = 0, sclkpol = 0, sclkpha = 0;
struct cspi_regs *regs = (struct cspi_regs *)mxcs-base;
@@ -147,27 +147,24 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave
*mxcs, unsigned int cs,
reg_ctrl |= MXC_CSPICTRL_EN;
reg_write(regs-ctrl, reg_ctrl);
-/*
- * The following computation is taken directly from Freescale's
code.
- */
if (clk_src max_hz) {
This if can be removed.
pre_div = DIV_ROUND_UP(clk_src, max_hz);
If you subtract -1 here instead of when you set the divisor register,
the logic becomes simpler
pre_div = DIV_ROUND_UP(clk_src, max_hz) - 1;
or just
pre_div = (clk_src - 1) / max_hz;
-if (pre_div 16) {
-post_div = pre_div / 16;
-pre_div = 16;
-}
-if (post_div != 0) {
-for (i = 0; i 16; i++) {
-if ((1 i) = post_div)
-break;
-}
-if (i == 16) {
+/* fls(1) = 1, fls(0x8000) = 32, fls(16) = 5 */
+post_div = fls(pre_div - 1);
+if (post_div 4) {
+post_div -= 4;
+
+if (post_div = 16) {
printf(Error: no divider for the freq: %d\n,
max_hz);
return -1;
}
-post_div = i;
+pre_div = (pre_div + (1 post_div) - 1) post_div;
This would become
pre_div = post_div;
+
+} else {
+post_div = 0;
}
+
}
debug(pre_div = %d, post_div=%d\n, pre_div, post_div);
And
MXC_CSPICTRL_PREDIV(pre_div - 1);
would return to
MXC_CSPICTRL_PREDIV(pre_div);
Well, where to do the -1 mainly depends on how we want to interpret
the output of
debug(pre_div = %d, post_div=%d\n, pre_div, post_div);
I'd change to
debug(actual div = %d, pre_div = %d, post_div=%d\n, (pre_div + 1)
post_div, pre_div, post_div);
to eliminate confusion.
There are two options how to understand this, at least the pre_div =
%d part:
a) print the pre_div as the real divider used in a human readable
format. I.e. if we divide by /15 then print 15
or
b) print the pre_div value we write to the register. I.e. if we
divide by /15 then print 14
Up to now we are doing (a) and calculate the register value after
the debug print. Your proposal would switch this to (b). Anyway, if
it makes the algorithm simpler I'd agree that it's fine to switch to
(b).
To summarize, this would become then:
s32 pre_div = 1, post_div = 0, reg_ctrl, reg_config;
...
If you keep the if, pre_div = 0
Ah, yes, thanks.
Also, I'd change s32 to unsigned or u32.
But usually the if will be true, so why keep it?
For cases where clk_src = max_hz. Then don't do the calculation
because it's unnecessary.
__udivsi3 already has this optimization.
fls can be 2 instructions
clzr0,r0
rsbr0,r0,#32
so your savings are a subroutine call and a return
in the unlikely case that (clk_src = max_hz)
But I don't have a real objection to leaving it, so feel free to decide.
It is just code bloat and prone to errors like yours above.
The only logic difference between keeping/killing the if is when
clk_src
Re: [U-Boot] [PATCH 03/21] fsl_ifc: add support for different IFC bank count
On Fri, Mar 22, 2013 at 12:23 PM, York Sun york...@freescale.com wrote:
From: Mingkai Hu mingkai...@freescale.com
Calculate reserved fields according to IFC bank count
1. Move csor_ext register behind csor register and fix res offset
2. move ifc bank count to config_mpc85xx.h to support 8 bank count
There's no IFC controller instead of eLBC controller on some platforms,
such as MPC8536, P2041, P3041, P4080 etc, so there's no macro definition
for the number of IFC chip select(CONFIG_SYS_FSL_IFC_BANK_COUNT) which
is used in the IFC controller header file fsl_ifc.h on these platforms.
This paragraph is pretty confusing. Is this just explaining that
IFC_BANK_COUNT isn't being defined for devices that don't use IFC? Or is it
explaining why you have to guard fsl_ifc.h with a #ifdef?
Signed-off-by: Mingkai Hu mingkai...@freescale.com
---
arch/powerpc/cpu/mpc85xx/cpu.c|2 +-
arch/powerpc/cpu/mpc8xxx/fsl_ifc.c| 58
-
arch/powerpc/include/asm/config_mpc85xx.h |7
arch/powerpc/include/asm/fsl_ifc.h| 42 +++--
4 files changed, 96 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c
b/arch/powerpc/cpu/mpc85xx/cpu.c
index df2ab6d..379a7df 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -34,8 +34,8 @@
#include asm/io.h
#include asm/mmu.h
#include asm/fsl_ifc.h
-#include asm/fsl_law.h
#include asm/fsl_lbc.h
+#include asm/fsl_law.h
#include post.h
#include asm/processor.h
#include asm/fsl_ddr_sdram.h
diff --git a/arch/powerpc/cpu/mpc8xxx/fsl_ifc.c
b/arch/powerpc/cpu/mpc8xxx/fsl_ifc.c
index 56b319f..f0da355 100644
--- a/arch/powerpc/cpu/mpc8xxx/fsl_ifc.c
+++ b/arch/powerpc/cpu/mpc8xxx/fsl_ifc.c
@@ -26,7 +26,7 @@ void print_ifc_regs(void)
int i, j;
printf(IFC Controller Registers\n);
- for (i = 0; i FSL_IFC_BANK_COUNT; i++) {
+ for (i = 0; i CONFIG_SYS_FSL_IFC_BANK_COUNT; i++) {
printf(CSPR%d:0x%08X\tAMASK%d:0x%08X\tCSOR%d:0x%08X\n,
i, get_ifc_cspr(i), i, get_ifc_amask(i),
i, get_ifc_csor(i));
@@ -94,4 +94,60 @@ void init_early_memctl_regs(void)
set_ifc_amask(IFC_CS3, CONFIG_SYS_AMASK3);
set_ifc_csor(IFC_CS3, CONFIG_SYS_CSOR3);
#endif
+
+#ifdef CONFIG_SYS_CSPR4_EXT
+ set_ifc_cspr_ext(IFC_CS4, CONFIG_SYS_CSPR4_EXT);
+#endif
+#if defined(CONFIG_SYS_CSPR4) defined(CONFIG_SYS_CSOR4)
There seem to be a large number of CONFIG options associated with each and
every new bank. It's following the pattern of the existing code, so I'll
accept it, but I can't help but think that some of these config options are
entirely redundant (would we ever have CSPR4, and *not* CSOR4?). This is,
admittedly, based only on a high-level view of the code -- I'm not familiar
with the specifics of the IFC design.
[...]
diff --git a/arch/powerpc/include/asm/fsl_ifc.h
b/arch/powerpc/include/asm/fsl_ifc.h
index ba41b73..debcb6b 100644
--- a/arch/powerpc/include/asm/fsl_ifc.h
+++ b/arch/powerpc/include/asm/fsl_ifc.h
@@ -21,6 +21,7 @@
#ifndef __ASM_PPC_FSL_IFC_H
#define __ASM_PPC_FSL_IFC_H
+#ifdef CONFIG_FSL_IFC
#include config.h
#include common.h
[...]
@@ -907,6 +910,22 @@ struct fsl_ifc_gpcm {
u32 res4[0x1F3];
};
+#ifdef CONFIG_SYS_FSL_IFC_BANK_COUNT
+#if (CONFIG_SYS_FSL_IFC_BANK_COUNT = 8)
+#define CONFIG_SYS_FSL_IFC_CSPR_RES \
+ (0x25 - CONFIG_SYS_FSL_IFC_BANK_COUNT * 3)
+#define CONFIG_SYS_FSL_IFC_AMASK_RES \
+ (0x24 - CONFIG_SYS_FSL_IFC_BANK_COUNT * 3)
+#define CONFIG_SYS_FSL_IFC_CSOR_RES \
+ (0x24 - CONFIG_SYS_FSL_IFC_BANK_COUNT * 3)
+#define CONFIG_SYS_FSL_IFC_FTIM_RES \
+ (0x90 - CONFIG_SYS_FSL_IFC_BANK_COUNT * 0xc)
These aren't really config values. They are values derived from a CONFIG
value, and they only have local scope (so there's no need for the very
global scoping of the names).
Also... Are these correct? 0x25 is a strange amount of gap in register
space.
All that aside, I think we should just define the register offsets to cover
all existing (or even predicted) registers, and make the gap hard-coded as
before. There's no real advantage to specifying only as many as are
implemented, and this method seems ripe for potential bugs in the future.
+#else
+#error IFC BANK count not vaild
+#endif
+#else
+#error IFC BANK count not defined
+#endif
/*
* IFC Controller Registers
@@ -918,24 +937,24 @@ struct fsl_ifc {
u32 cspr_ext;
u32 cspr;
u32 res2;
- } cspr_cs[FSL_IFC_BANK_COUNT];
- u32 res3[0x19];
+ } cspr_cs[CONFIG_SYS_FSL_IFC_BANK_COUNT];
+ u32 res3[CONFIG_SYS_FSL_IFC_CSPR_RES];
struct {
u32 amask;
u32 res4[0x2];
- } amask_cs[FSL_IFC_BANK_COUNT];
- u32 res5[0x17];
+ } amask_cs[CONFIG_SYS_FSL_IFC_BANK_COUNT];
+ u32
[U-Boot] [PATCH 0/4] Factorize ARM relocation code
This is V1 of the ARM relocation code factorization patch series.
Albert ARIBAUD (4):
Rename arch/arm/lib/bss.c to sections.c
arm: make __image_copy_{start,end} compiler-generated
arm: make relocation section symbols compiler-generated
arm: factorize relocate_code routine
arch/arm/cpu/arm1136/start.S | 83
arch/arm/cpu/arm1136/u-boot-spl.lds|3 +-
arch/arm/cpu/arm1176/start.S | 75 --
arch/arm/cpu/arm720t/start.S | 79 ---
arch/arm/cpu/arm920t/ep93xx/u-boot.lds |6 +-
arch/arm/cpu/arm920t/start.S | 75 --
arch/arm/cpu/arm925t/start.S | 75 --
arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds | 15 +++-
arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds| 15 +++-
arch/arm/cpu/arm926ejs/start.S | 83
arch/arm/cpu/arm946es/start.S | 75 --
arch/arm/cpu/arm_intcm/start.S | 75 --
arch/arm/cpu/armv7/am33xx/u-boot-spl.lds |2 -
arch/arm/cpu/armv7/omap-common/u-boot-spl.lds |2 -
arch/arm/cpu/armv7/socfpga/u-boot-spl.lds |1 -
arch/arm/cpu/armv7/start.S | 80 ---
arch/arm/cpu/ixp/start.S | 75 --
arch/arm/cpu/ixp/u-boot.lds| 24 --
arch/arm/cpu/pxa/start.S | 84
arch/arm/cpu/s3c44b0/start.S | 75 --
arch/arm/cpu/sa1100/start.S| 75 --
arch/arm/cpu/u-boot-spl.lds| 21 +++--
arch/arm/cpu/u-boot.lds| 25 --
arch/arm/lib/Makefile |4 +-
arch/arm/lib/relocate.S| 100
arch/arm/lib/{bss.c = sections.c} |7 +-
board/actux1/u-boot.lds| 18 -
board/actux2/u-boot.lds| 18 -
board/actux3/u-boot.lds| 19 -
board/ait/cam_enc_4xx/u-boot-spl.lds | 16 +++-
board/davinci/da8xxevm/u-boot-spl-da850evm.lds | 16 +++-
board/dvlhost/u-boot.lds | 18 -
board/freescale/mx31ads/u-boot.lds | 18 -
board/vpac270/u-boot-spl.lds | 18 -
34 files changed, 303 insertions(+), 1072 deletions(-)
create mode 100644 arch/arm/lib/relocate.S
rename arch/arm/lib/{bss.c = sections.c} (78%)
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] Rename arch/arm/lib/bss.c to sections.c
This file will contain symbols other than the BSS
start and stop, so rename it for better accuracy.
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
arch/arm/lib/Makefile |2 +-
arch/arm/lib/{bss.c = sections.c} |0
2 files changed, 1 insertion(+), 1 deletion(-)
rename arch/arm/lib/{bss.c = sections.c} (100%)
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 6ae161a..ac51cc1 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -42,7 +42,7 @@ ifndef CONFIG_SPL_BUILD
ifndef CONFIG_SYS_GENERIC_BOARD
COBJS-y+= board.o
endif
-COBJS-y += bss.o
+COBJS-y += sections.o
COBJS-y+= bootm.o
COBJS-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
diff --git a/arch/arm/lib/bss.c b/arch/arm/lib/sections.c
similarity index 100%
rename from arch/arm/lib/bss.c
rename to arch/arm/lib/sections.c
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] arm: make __image_copy_{start, end} compiler-generated
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
arch/arm/cpu/arm1136/start.S |7 +++
arch/arm/cpu/arm1136/u-boot-spl.lds |3 ++-
arch/arm/cpu/arm720t/start.S | 11 +++
arch/arm/cpu/arm920t/ep93xx/u-boot.lds|6 +-
arch/arm/cpu/arm926ejs/start.S|7 +++
arch/arm/cpu/armv7/am33xx/u-boot-spl.lds |2 --
arch/arm/cpu/armv7/omap-common/u-boot-spl.lds |2 --
arch/arm/cpu/armv7/socfpga/u-boot-spl.lds |1 -
arch/arm/cpu/armv7/start.S|6 ++
arch/arm/cpu/ixp/u-boot.lds |6 +-
arch/arm/cpu/u-boot-spl.lds |3 +--
arch/arm/cpu/u-boot.lds |7 +--
arch/arm/lib/sections.c |4 +++-
13 files changed, 36 insertions(+), 29 deletions(-)
diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S
index ccea2d5..ab8fd56 100644
--- a/arch/arm/cpu/arm1136/start.S
+++ b/arch/arm/cpu/arm1136/start.S
@@ -104,10 +104,6 @@ _TEXT_BASE:
_bss_start_ofs:
.word __bss_start - _start
-.globl _image_copy_end_ofs
-_image_copy_end_ofs:
- .word __image_copy_end - _start
-
.globl _bss_end_ofs
_bss_end_ofs:
.word __bss_end - _start
@@ -239,6 +235,9 @@ relocate_done:
bx lr
+_image_copy_end_ofs:
+ .word __image_copy_end - _start
+
#ifndef CONFIG_SPL_BUILD
_rel_dyn_start_ofs:
diff --git a/arch/arm/cpu/arm1136/u-boot-spl.lds
b/arch/arm/cpu/arm1136/u-boot-spl.lds
index 8296e5d..04fc881 100644
--- a/arch/arm/cpu/arm1136/u-boot-spl.lds
+++ b/arch/arm/cpu/arm1136/u-boot-spl.lds
@@ -37,7 +37,6 @@ SECTIONS
{
.text :
{
- __start = .;
arch/arm/cpu/arm1136/start.o (.text*)
*(.text*)
} .sram
@@ -48,7 +47,9 @@ SECTIONS
. = ALIGN(4);
.data : { *(SORT_BY_ALIGNMENT(.data*)) } .sram
. = ALIGN(4);
+
__image_copy_end = .;
+
_end = .;
.bss :
diff --git a/arch/arm/cpu/arm720t/start.S b/arch/arm/cpu/arm720t/start.S
index 9facc7e..b85509c 100644
--- a/arch/arm/cpu/arm720t/start.S
+++ b/arch/arm/cpu/arm720t/start.S
@@ -101,10 +101,6 @@ _TEXT_BASE:
_bss_start_ofs:
.word __bss_start - _start
-.globl _image_copy_end_ofs
-_image_copy_end_ofs:
- .word __image_copy_end - _start
-
.globl _bss_end_ofs
_bss_end_ofs:
.word __bss_end - _start
@@ -221,6 +217,11 @@ relocate_done:
mov pc, lr
+_image_copy_end_ofs:
+ .word __image_copy_end - _start
+
+#ifndef CONFIG_SPL_BUILD
+
_rel_dyn_start_ofs:
.word __rel_dyn_start - _start
_rel_dyn_end_ofs:
@@ -228,6 +229,8 @@ _rel_dyn_end_ofs:
_dynsym_start_ofs:
.word __dynsym_start - _start
+#endif
+
.globl c_runtime_cpu_setup
c_runtime_cpu_setup:
diff --git a/arch/arm/cpu/arm920t/ep93xx/u-boot.lds
b/arch/arm/cpu/arm920t/ep93xx/u-boot.lds
index cf55bf7..2b32c0a 100644
--- a/arch/arm/cpu/arm920t/ep93xx/u-boot.lds
+++ b/arch/arm/cpu/arm920t/ep93xx/u-boot.lds
@@ -31,6 +31,7 @@ SECTIONS
. = ALIGN(4);
.text :
{
+ *(.__image_copy_start)
arch/arm/cpu/arm920t/start.o (.text*)
/* the EP93xx expects to find the pattern 'CRUS' at 0x1000 */
. = 0x1000;
@@ -56,7 +57,10 @@ SECTIONS
. = ALIGN(4);
- __image_copy_end = .;
+ .image_copy_end :
+ {
+ *(.__image_copy_end);
+ }
__bss_start = .;
.bss : { *(.bss*) }
diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
index 4c56711..736361a 100644
--- a/arch/arm/cpu/arm926ejs/start.S
+++ b/arch/arm/cpu/arm926ejs/start.S
@@ -136,10 +136,6 @@ _TEXT_BASE:
_bss_start_ofs:
.word __bss_start - _start
-.globl _image_copy_end_ofs
-_image_copy_end_ofs:
- .word __image_copy_end - _start
-
.globl _bss_end_ofs
_bss_end_ofs:
.word __bss_end - _start
@@ -256,6 +252,9 @@ relocate_done:
bx lr
+_image_copy_end_ofs:
+ .word __image_copy_end - _start
+
#ifndef CONFIG_SPL_BUILD
_rel_dyn_start_ofs:
diff --git a/arch/arm/cpu/armv7/am33xx/u-boot-spl.lds
b/arch/arm/cpu/armv7/am33xx/u-boot-spl.lds
index b6a929f..29cefd0 100644
--- a/arch/arm/cpu/armv7/am33xx/u-boot-spl.lds
+++ b/arch/arm/cpu/armv7/am33xx/u-boot-spl.lds
@@ -37,7 +37,6 @@ SECTIONS
{
.text :
{
- __start = .;
arch/arm/cpu/armv7/start.o (.text)
*(.text*)
} .sram
@@ -53,7 +52,6 @@ SECTIONS
} .sram
. = ALIGN(4);
- __image_copy_end = .;
_end = .;
.bss :
diff --git a/arch/arm/cpu/armv7/omap-common/u-boot-spl.lds
b/arch/arm/cpu/armv7/omap-common/u-boot-spl.lds
index bd218c0..81cafe1 100644
--- a/arch/arm/cpu/armv7/omap-common/u-boot-spl.lds
+++ b/arch/arm/cpu/armv7/omap-common/u-boot-spl.lds
@@ -37,7 +37,6 @@ SECTIONS
{
[U-Boot] [PATCH 3/4] arm: make relocation section symbols compiler-generated
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds | 15 ---
arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds| 15 ---
arch/arm/cpu/ixp/u-boot.lds| 18 ++
arch/arm/cpu/u-boot-spl.lds| 18 ++
arch/arm/cpu/u-boot.lds| 18 ++
arch/arm/lib/sections.c|3 +++
board/actux1/u-boot.lds| 18 ++
board/actux2/u-boot.lds| 18 ++
board/actux3/u-boot.lds| 19 +++
board/ait/cam_enc_4xx/u-boot-spl.lds | 16 +---
board/davinci/da8xxevm/u-boot-spl-da850evm.lds | 16 +---
board/dvlhost/u-boot.lds | 18 ++
board/freescale/mx31ads/u-boot.lds | 18 ++
board/vpac270/u-boot-spl.lds | 18 ++
14 files changed, 180 insertions(+), 48 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
b/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
index 673c725..b078387 100644
--- a/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
+++ b/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
@@ -51,14 +51,23 @@ SECTIONS
. = ALIGN(4);
+ .rel_dyn_start : {
+ *(.__rel_dyn_start);
+ }
+
.rel.dyn : {
- __rel_dyn_start = .;
*(.rel*)
- __rel_dyn_end = .;
+ }
+
+ .rel_dyn_end : {
+ *(.__rel_dyn_end);
+ }
+
+ .dynsym_start : {
+ *(.__dynsym_start);
}
.dynsym : {
- __dynsym_start = .;
*(.dynsym)
}
diff --git a/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
b/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
index 967a135..a24879f 100644
--- a/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
+++ b/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
@@ -51,14 +51,23 @@ SECTIONS
. = ALIGN(4);
+ .rel_dyn_start : {
+ *(.__rel_dyn_start);
+ }
+
.rel.dyn : {
- __rel_dyn_start = .;
*(.rel*)
- __rel_dyn_end = .;
+ }
+
+ .rel_dyn_end : {
+ *(.__rel_dyn_end);
+ }
+
+ .dynsym_start : {
+ *(.__dynsym_start);
}
.dynsym : {
- __dynsym_start = .;
*(.dynsym)
}
diff --git a/arch/arm/cpu/ixp/u-boot.lds b/arch/arm/cpu/ixp/u-boot.lds
index 1a0ba17..1315b41 100644
--- a/arch/arm/cpu/ixp/u-boot.lds
+++ b/arch/arm/cpu/ixp/u-boot.lds
@@ -60,14 +60,24 @@ SECTIONS
*(.__image_copy_end);
}
+ .rel_dyn_start : {
+ __rel_dyn_base = .;
+ *(.__rel_dyn_start);
+ }
+
.rel.dyn : {
- __rel_dyn_start = .;
*(.rel*)
- __rel_dyn_end = .;
+ }
+
+ .rel_dyn_end : {
+ *(.__rel_dyn_end);
+ }
+
+ .dynsym_start : {
+ *(.__dynsym_start);
}
.dynsym : {
- __dynsym_start = .;
*(.dynsym)
}
@@ -78,7 +88,7 @@ SECTIONS
* __bss_base and __bss_limit are for linker only (overlay ordering)
*/
- .bss_start __rel_dyn_start (OVERLAY) : {
+ .bss_start __rel_dyn_base (OVERLAY) : {
KEEP(*(.__bss_start));
__bss_base = .;
}
diff --git a/arch/arm/cpu/u-boot-spl.lds b/arch/arm/cpu/u-boot-spl.lds
index 87341c1..87e5655 100644
--- a/arch/arm/cpu/u-boot-spl.lds
+++ b/arch/arm/cpu/u-boot-spl.lds
@@ -51,20 +51,30 @@ SECTIONS
__image_copy_end = .;
+ .rel_dyn_start : {
+ __rel_dyn_base = .;
+ *(.__rel_dyn_start);
+ }
+
.rel.dyn : {
- __rel_dyn_start = .;
*(.rel*)
- __rel_dyn_end = .;
+ }
+
+ .rel_dyn_end : {
+ *(.__rel_dyn_end);
+ }
+
+ .dynsym_start : {
+ *(.__dynsym_start);
}
.dynsym : {
- __dynsym_start = .;
*(.dynsym)
}
_end = .;
- .bss __rel_dyn_start (OVERLAY) : {
+ .bss __rel_dyn_base (OVERLAY) : {
__bss_start = .;
*(.bss*)
. = ALIGN(4);
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 5b43621..fbac4d1 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -62,14 +62,24 @@ SECTIONS
*(.__image_copy_end);
}
+ .rel_dyn_start : {
+ __rel_dyn_base = .;
+ *(.__rel_dyn_start);
+ }
+
.rel.dyn : {
- __rel_dyn_start = .;
*(.rel*)
- __rel_dyn_end = .;
+ }
+
+
[U-Boot] [PATCH 4/4] arm: factorize relocate_code routine
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
arch/arm/cpu/arm1136/start.S | 82
arch/arm/cpu/arm1176/start.S | 75 --
arch/arm/cpu/arm720t/start.S | 82
arch/arm/cpu/arm920t/start.S | 75 --
arch/arm/cpu/arm925t/start.S | 75 --
arch/arm/cpu/arm926ejs/start.S | 82
arch/arm/cpu/arm946es/start.S | 75 --
arch/arm/cpu/arm_intcm/start.S | 75 --
arch/arm/cpu/armv7/start.S | 78 ---
arch/arm/cpu/ixp/start.S | 75 --
arch/arm/cpu/pxa/start.S | 84 -
arch/arm/cpu/s3c44b0/start.S | 75 --
arch/arm/cpu/sa1100/start.S| 75 --
arch/arm/lib/Makefile |2 +-
arch/arm/lib/relocate.S| 100
15 files changed, 101 insertions(+), 1009 deletions(-)
create mode 100644 arch/arm/lib/relocate.S
diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S
index ab8fd56..4b3f828 100644
--- a/arch/arm/cpu/arm1136/start.S
+++ b/arch/arm/cpu/arm1136/start.S
@@ -167,88 +167,6 @@ next:
bl _main
-/*--*/
-
-/*
- * void relocate_code(addr_moni)
- *
- * This function relocates the monitor code.
- */
- .globl relocate_code
-relocate_code:
- mov r6, r0 /* save addr of destination */
-
- adr r0, _start
- subsr9, r6, r0 /* r9 - relocation offset */
- beq relocate_done /* skip relocation */
- mov r1, r6 /* r1 - scratch for copy_loop */
- ldr r3, _image_copy_end_ofs
- add r2, r0, r3 /* r2 - source end address */
-
-copy_loop:
- ldmia r0!, {r10-r11} /* copy from source address [r0]*/
- stmia r1!, {r10-r11} /* copy to target address [r1]*/
- cmp r0, r2 /* until source end address [r2]*/
- blo copy_loop
-
-#ifndef CONFIG_SPL_BUILD
- /*
-* fix .rel.dyn relocations
-*/
- ldr r0, _TEXT_BASE /* r0 - Text base */
- ldr r10, _dynsym_start_ofs /* r10 - sym table ofs */
- add r10, r10, r0/* r10 - sym table in FLASH */
- ldr r2, _rel_dyn_start_ofs /* r2 - rel dyn start ofs */
- add r2, r2, r0 /* r2 - rel dyn start in FLASH */
- ldr r3, _rel_dyn_end_ofs/* r3 - rel dyn end ofs */
- add r3, r3, r0 /* r3 - rel dyn end in FLASH */
-fixloop:
- ldr r0, [r2]/* r0 - location to fix up, IN FLASH!
*/
- add r0, r0, r9 /* r0 - location to fix up in RAM */
- ldr r1, [r2, #4]
- and r7, r1, #0xff
- cmp r7, #23 /* relative fixup? */
- beq fixrel
- cmp r7, #2 /* absolute fixup? */
- beq fixabs
- /* ignore unknown type of fixup */
- b fixnext
-fixabs:
- /* absolute fix: set location to (offset) symbol value */
- mov r1, r1, LSR #4 /* r1 - symbol index in .dynsym */
- add r1, r10, r1 /* r1 - address of symbol in table */
- ldr r1, [r1, #4]/* r1 - symbol value */
- add r1, r1, r9 /* r1 - relocated sym addr */
- b fixnext
-fixrel:
- /* relative fix: increase location by offset */
- ldr r1, [r0]
- add r1, r1, r9
-fixnext:
- str r1, [r0]
- add r2, r2, #8 /* each rel.dyn entry is 8 bytes */
- cmp r2, r3
- blo fixloop
-#endif
-
-relocate_done:
-
- bx lr
-
-_image_copy_end_ofs:
- .word __image_copy_end - _start
-
-#ifndef CONFIG_SPL_BUILD
-
-_rel_dyn_start_ofs:
- .word __rel_dyn_start - _start
-_rel_dyn_end_ofs:
- .word __rel_dyn_end - _start
-_dynsym_start_ofs:
- .word __dynsym_start - _start
-
-#endif
-
.globl c_runtime_cpu_setup
c_runtime_cpu_setup:
diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S
index f20da8e..6929b08 100644
--- a/arch/arm/cpu/arm1176/start.S
+++ b/arch/arm/cpu/arm1176/start.S
@@ -223,81 +223,6 @@ skip_tcmdisable:
bl _main
-/*--*/
-
-/*
- * void relocate_code(addr_moni)
- *
- * This function relocates the monitor code.
- */
- .globl relocate_code
-relocate_code:
- mov r6, r0 /* save addr of destination */
-
- adr r0, _start
- subsr9, r6, r0
Re: [U-Boot] [PATCH 3/3] video: mxsfb: Add an entry for mx23evk/mx28vk video modes
Dear Fabio Estevam, From: Fabio Estevam fabio.este...@freescale.com Currently the mxsfb driver takes the display timings from the 'videomode' environment variable. Provide an example on how to set 'videomode' for using splash screen on mx23evk and mx28vk boards. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- drivers/video/mxsfb.c |5 + 1 file changed, 5 insertions(+) diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c index 461ff6e..b189419 100644 --- a/drivers/video/mxsfb.c +++ b/drivers/video/mxsfb.c @@ -39,6 +39,11 @@ static GraphicDevice panel; * setenv videomode * video=ctfb:x:800,y:480,depth:18,mode:0,pclk:30066, * le:0,ri:256,up:0,lo:45,hs:1,vs:1,sync:100663296,vmode:0 + * + * Freescale mx23evk/mx28evk with a Seiko 4.3'' WVGA panel: + * setenv videomode + * video=ctfb:x:800,y:480,depth:24,mode:0,pclk:29851, + *le:89,ri:164,up:23,lo:10,hs:10,vs:10,sync:0,vmode:0 */ On SCH-26062 Rev B the image is shifted downwards on MX23EVK, but maybe that's not SEIKO LCD ;-) Otherwise for MX23EVK, Tested-by: Marek Vasut ma...@denx.de Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-fdt
Dear Tom, The following changes since commit 2988eac70ead3720f9ec85a239cd06b2f7246683: Merge branch 'patman' of git://git.denx.de/u-boot-x86 (2013-05-10 08:16:34 -0400) are available in the git repository at: git://git.denx.de/u-boot-fdt.git master for you to fetch changes up to bbd0f7e3ba66d288a2f146f1c7797801e04598ae: Move FDT_RAMDISK_OVERHEAD from fdt.h to libfdt_env.h (2013-05-10 19:04:50 -0400) Per my email and consensus, I have *not* included Simon's patch libfdt: Add fdt_next_subnode() to permit easy subnode iteration which Tom has or will apply as part of Simon's full sandbox patchset. Thanks, gvb François Revol (1): Fix typo Gerald Van Baren (1): Move FDT_RAMDISK_OVERHEAD from fdt.h to libfdt_env.h Justin Sobota (1): Added license header to dtc/libfdt/fdt.h and libfdt_env.h Simon Glass (1): Export fdt_stringlist_contains() include/fdt.h| 53 -- include/libfdt.h | 16 ++- include/libfdt_env.h |3 +++ lib/libfdt/fdt_ro.c |5 ++--- 4 files changed, 71 insertions(+), 6 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 4/6] ARM: add SMP support for non-secure switch
On Mon, May 06, 2013 at 03:19:40PM +0200, Andre Przywara wrote: On 04/27/2013 12:13 AM, Christoffer Dall wrote: On Fri, Apr 26, 2013 at 6:14 AM, Andre Przywara andre.przyw...@linaro.org wrote: Currently the non-secure switch is only done for the boot processor. To later allow full SMP support, we have to switch all secondary cores into non-secure state also. So we add an entry point for secondary CPUs coming out of low-power state and make sure we put them into WFI again after having switched to non-secure state. For this we acknowledge and EOI the wake-up IPI, then go into WFI. Once being kicked out of it later, we sanity check that the start address has actually been changed (since another attempt to switch to non-secure would block the core) and jump to the new address. The actual CPU kick is done by sending an inter-processor interrupt via the GIC to all CPU interfaces except the requesting processor. The secondary cores will then setup their respective GIC CPU interface. The address secondary cores jump to is board specific, we provide the value here for the Versatile Express board. Signed-off-by: Andre Przywara andre.przyw...@linaro.org --- arch/arm/cpu/armv7/start.S | 27 ++- arch/arm/lib/virt-v7.c | 10 +- include/configs/vexpress_ca15_tc2.h | 1 + 3 files changed, 36 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 401b0eb..2b47881 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -563,8 +563,19 @@ fiq: #endif /* CONFIG_SPL_BUILD */ /* Routine to initialize GIC CPU interface and switch to nonsecure state. + * Will be executed directly by secondary CPUs after coming out of + * WFI, or can be called directly by C code for CPU 0. + * Those two paths mandate to not use any stack and to only use registers + * r0-r3 to comply with both the C ABI and the requirement of SMP startup + * code. */ .globl _nonsec_gic_switch +.globl _smp_pen +_smp_pen: + mrs r0, cpsr + orr r0, r0, #0xc0 + msr cpsr, r0@ disable interrupts + mov lr, #0 @ clear LR to mark secondary _nonsec_gic_switch: mrc p15, 4, r2, c15, c0, 0 @ r2 = PERIPHBASE add r3, r2, #0x1000 @ GIC dist i/f offset @@ -605,4 +616,18 @@ _nonsec_gic_switch: add r2, r2, #0x1000 @ GIC dist i/f offset str r1, [r2]@ allow private interrupts - mov pc, lr + cmp lr, #0 + movne pc, lr @ CPU 0 to return + @ all others: go to sleep +_ack_int: + ldr r1, [r3, #0x0c] @ read GICD acknowledge + str r1, [r3, #0x10] @ write GICD EOI + + adr r1, _smp_pen +waitloop: + wfi + ldr r0, =CONFIG_SYSFLAGS_ADDR @ load start address + ldr r0, [r0] + cmp r0, r1 @ make sure we dont execute this code + beq waitloop@ again (due to a spurious wakeup) + mov pc, r0 diff --git a/arch/arm/lib/virt-v7.c b/arch/arm/lib/virt-v7.c index 416ca29..5ca093a 100644 --- a/arch/arm/lib/virt-v7.c +++ b/arch/arm/lib/virt-v7.c @@ -29,6 +29,7 @@ /* the assembly routine doing the actual work in start.S */ void _nonsec_gic_switch(void); +void _smp_pen(void); #define GICD_CTLR 0x000 #define GICD_TYPER 0x004 @@ -51,6 +52,7 @@ int armv7_switch_nonsec(void) unsigned int reg; volatile unsigned int *gicdptr; unsigned itlinesnr, i; + unsigned int *sysflags; /* check whether the CPU supports the security extensions */ asm(mrc p15, 0, %0, c0, c1, 1\n : =r(reg)); @@ -109,7 +111,13 @@ int armv7_switch_nonsec(void) for (i = 0; i = itlinesnr; i++) gicdptr[GICD_IGROUPR0 / 4 + i] = (unsigned)-1; - /* call the non-sec switching code on this CPU */ + /* now kick all CPUs (expect this one) by writing to GICD_SIGR */ + sysflags = (void *)CONFIG_SYSFLAGS_ADDR; + sysflags[1] = (unsigned)-1; + sysflags[0] = (uintptr_t)_smp_pen; + gicdptr[GICD_SGIR / 4] = 1U 24; + + /* call the non-sec switching code on this CPU also */ _nonsec_gic_switch(); return 0; diff --git a/include/configs/vexpress_ca15_tc2.h b/include/configs/vexpress_ca15_tc2.h index 9e230ad..210a27c 100644 --- a/include/configs/vexpress_ca15_tc2.h +++ b/include/configs/vexpress_ca15_tc2.h @@ -32,5 +32,6 @@ #define CONFIG_BOOTP_VCI_STRING U-boot.armv7.vexpress_ca15x2_tc2 #define CONFIG_SYS_CLK_FREQ 2400 +#define CONFIG_SYSFLAGS_ADDR 0x1c010030 #endif -- hmm, is all
Re: [U-Boot] [PATCH] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT to replace CONFIG_SPL_NET_SUPPORT
Dear ying.zh...@freescale.com, In message 1368182421-859-1-git-send-email-ying.zh...@freescale.com you wrote: From: Ying Zhang b40...@freescale.com Add a new symbol CONFIG_SPL_ENV_SUPPORT to replace CONFIG_SPL_NET_SUPPORT. Any CONFIG_* stuff must be documented in the README. Please add this documentation. In common/Makefile, the environment-related files in SPL is difined by CONFIG_SPL_NET_SUPPORT, it is wrong. s/difined/defined/ Could you please also explain, what exactly is wrong, and how your new code fixes this? --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -325,6 +325,7 @@ #define CONFIG_SPL_GPIO_SUPPORT #define CONFIG_SPL_YMODEM_SUPPORT #define CONFIG_SPL_NET_SUPPORT +#define CONFIG_SPL_ENV_SUPPORT #define CONFIG_SPL_NET_VCI_STRINGAM335x U-Boot SPL #define CONFIG_SPL_ETH_SUPPORT #define CONFIG_SPL_SPI_SUPPORT diff --git a/include/configs/pcm051.h b/include/configs/pcm051.h index d0ea74e..926842f 100644 --- a/include/configs/pcm051.h +++ b/include/configs/pcm051.h @@ -224,6 +224,7 @@ #define CONFIG_SPL_GPIO_SUPPORT #define CONFIG_SPL_YMODEM_SUPPORT #define CONFIG_SPL_NET_SUPPORT +#define CONFIG_SPL_ENV_SUPPORT #define CONFIG_SPL_NET_VCI_STRINGpcm051 U-Boot SPL #define CONFIG_SPL_ETH_SUPPORT #define CONFIG_SPL_SPI_SUPPORT Are you sure these are the only locations that need this? 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 Speed of a tortoise breaking the sound barrier = 1 Machturtle ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] ARM: byteorder: add optimized swab16 and swab32
Dear Dirk Behme, In message 518d3191.7060...@gmail.com you wrote: Which compiler are you using? An older gcc 4.4.4 version. We should not really care about these. And if so, then onlya fter testing we are really suing such old stuff, i. e. those who are using recent tools (eventually the majority of users) should not suffer from hacst to optimize for ancient code. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Albert Einstein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Beagle-XM: u-boot SPL fat support (was Re: [opensuse-arm] Beagleboard Xm CPU speed)
Dear Alexander, In message 154a1277-6344-4ab8-9d98-58bbcc38c...@suse.de you wrote: Well, that would make the situation on OMAP slightly better, but wouldn't help on other SoCs. I think we should rather try and get a reasonably unified boot environment up across the board first :). Well, this all depends on which resources are available on the SoC in question. If all you have is 4 kB on chip memory, then you will not be able to load the file system code at all. 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 Always try to do things in chronological order; it's less confusing that way. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT to replace CONFIG_SPL_NET_SUPPORT
On 05/10/2013 07:03:07 PM, Wolfgang Denk wrote: Dear ying.zh...@freescale.com, In message 1368182421-859-1-git-send-email-ying.zh...@freescale.com you wrote: From: Ying Zhang b40...@freescale.com Add a new symbol CONFIG_SPL_ENV_SUPPORT to replace CONFIG_SPL_NET_SUPPORT. Any CONFIG_* stuff must be documented in the README. Please add this documentation. In common/Makefile, the environment-related files in SPL is difined by CONFIG_SPL_NET_SUPPORT, it is wrong. s/difined/defined/ Could you please also explain, what exactly is wrong, and how your new code fixes this? We will need the environment in SPL for reasons other than network support (in particular, hwconfig contains info for how to set up DDR). Yes, this information should go in the changelog. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] arm: make __image_copy_{start, end} compiler-generated
Hi Albert,
On Friday, May 10, 2013 11:56:50 PM, Albert ARIBAUD wrote:
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
arch/arm/cpu/arm1136/start.S |7 +++
arch/arm/cpu/arm1136/u-boot-spl.lds |3 ++-
arch/arm/cpu/arm720t/start.S | 11 +++
arch/arm/cpu/arm920t/ep93xx/u-boot.lds|6 +-
arch/arm/cpu/arm926ejs/start.S|7 +++
arch/arm/cpu/armv7/am33xx/u-boot-spl.lds |2 --
arch/arm/cpu/armv7/omap-common/u-boot-spl.lds |2 --
arch/arm/cpu/armv7/socfpga/u-boot-spl.lds |1 -
arch/arm/cpu/armv7/start.S|6 ++
arch/arm/cpu/ixp/u-boot.lds |6 +-
arch/arm/cpu/u-boot-spl.lds |3 +--
arch/arm/cpu/u-boot.lds |7 +--
arch/arm/lib/sections.c |4 +++-
13 files changed, 36 insertions(+), 29 deletions(-)
diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S
index ccea2d5..ab8fd56 100644
--- a/arch/arm/cpu/arm1136/start.S
+++ b/arch/arm/cpu/arm1136/start.S
@@ -104,10 +104,6 @@ _TEXT_BASE:
_bss_start_ofs:
.word __bss_start - _start
-.globl _image_copy_end_ofs
Wasn't _image_copy_end_ofs used outside of start.S? Same question for all the
start.S files.
-_image_copy_end_ofs:
- .word __image_copy_end - _start
-
.globl _bss_end_ofs
_bss_end_ofs:
.word __bss_end - _start
@@ -239,6 +235,9 @@ relocate_done:
bx lr
+_image_copy_end_ofs:
+ .word __image_copy_end - _start
+
#ifndef CONFIG_SPL_BUILD
_rel_dyn_start_ofs:
diff --git a/arch/arm/cpu/arm1136/u-boot-spl.lds
b/arch/arm/cpu/arm1136/u-boot-spl.lds
index 8296e5d..04fc881 100644
--- a/arch/arm/cpu/arm1136/u-boot-spl.lds
+++ b/arch/arm/cpu/arm1136/u-boot-spl.lds
@@ -37,7 +37,6 @@ SECTIONS
{
.text :
{
- __start = .;
arch/arm/cpu/arm1136/start.o (.text*)
*(.text*)
} .sram
@@ -48,7 +47,9 @@ SECTIONS
. = ALIGN(4);
.data : { *(SORT_BY_ALIGNMENT(.data*)) } .sram
. = ALIGN(4);
+
__image_copy_end = .;
Why aren't all linker scripts treated equally?
Here, start.S is still used, so '*(.__image_copy_end)' and the related stuff
should be like what you did for arch/arm/cpu/u-boot.lds below. Or am I missing
something?
Same question for several other linker scripts below.
+
_end = .;
.bss :
[...]
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index d9bbee3..5b43621 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -33,7 +33,7 @@ SECTIONS
. = ALIGN(4);
.text :
{
- __image_copy_start = .;
+ *(.__image_copy_start)
Are there any users of __image_copy_start?
CPUDIR/start.o (.text*)
*(.text*)
}
@@ -57,7 +57,10 @@ SECTIONS
. = ALIGN(4);
- __image_copy_end = .;
+ .image_copy_end :
+ {
+ *(.__image_copy_end);
+ }
.rel.dyn : {
__rel_dyn_start = .;
diff --git a/arch/arm/lib/sections.c b/arch/arm/lib/sections.c
index 99eda59..80a0c38 100644
--- a/arch/arm/lib/sections.c
+++ b/arch/arm/lib/sections.c
@@ -21,7 +21,7 @@
*/
/**
- * These two symbols are declared in a C file so that the linker
+ * The following symbols are declared in a C file so that the linker
* uses R_ARM_RELATIVE relocation, rather than the R_ARM_ABS32 one
* it would use if the symbols were defined in the linker file.
* Using only R_ARM_RELATIVE relocation ensures that references to
@@ -37,3 +37,5 @@
char __bss_start[0] __attribute__((used, section(.__bss_start)));
char __bss_end[0] __attribute__((used, section(.__bss_end)));
+char __image_copy_start[0] __attribute__((used,
section(.__image_copy_start)));
Ditto.
+char __image_copy_end[0] __attribute__((used,
section(.__image_copy_end)));
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/p1022ds: boot from SD card/SPI flash with SPL
On 05/10/2013 03:44:29 AM, Zhang Ying-B40530 wrote:
This patch needs to be broken into several patches that each take
care of one logical problem; it's too hard to properly review (and
have the right people pay attention to certain parts) in its current
state.
[Zhang Ying]
It only can be broken to two patches, one for SD boot, another for
SPI boot.
You can also separate out logical changes in support of your eventual
goal (as it looks like you already started doing with the
CONFIG_SPL_ENV_SUPPORT patch and such).
@@ -83,5 +107,6 @@ SECTIONS
*(.sbss*)
*(.bss*)
}
+ . = ALIGN(4);
__bss_end = .;
}
This seems unrelated.
[Zhang Ying]
It is necessary. In the function clear_bss(), the address of bss is
on the basis of the __bss_start, and then to four bytes of
incremental growth, finally the last stop is based on the address and
__bss_end is equal or not.
It may be necessary, but I don't see what it has to do with SD/SPI boot
other than by chance. Make this a separate patch with a changelog that
explains the problem.
diff --git a/board/freescale/common/sdhc_boot.c
b/board/freescale/common/sdhc_boot.c
index e432318..96b0680 100644
--- a/board/freescale/common/sdhc_boot.c
+++ b/board/freescale/common/sdhc_boot.c
+ val = *(u16 *)(tmp_buf + ESDHC_BOOT_IMAGE_SIGN_ADDR);
+ if ((u16)ESDHC_BOOT_IMAGE_SIGN != val) {
+ free(tmp_buf);
+ return;
+ }
Why do you need this cast?
[Zhang Ying]
The offset 0x1FE of the config data sector should contain the value
0x55AA. If the value in this location doesn't match 0x55AA, it means
that the SD/MMC card doesn't contain a valid user code.
But why do you need to cast ESDHC_BOOT_IMAGE_SIGN to (u16)?
And the other cast probably violates C99 aliasing rules.
+ *
+ * You should have received a copy of the GNU General Public
License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __SDHC_BOOT_H_
+#define __SDHC_BOOT_H_1
+
+
+int mmc_get_env_addr(struct mmc *mmc, u32 *env_addr); void
+mmc_get_env(void); void mmc_boot(void);
+
+#endif /* __SDHC_BOOT_H_ */
Does this stuff really belong in board/freescale? Should probably at
least be in arch/powerpc/cpu/mpc85xx, if not more generic.
[Zhang Ying]
Ok, whether we can handle like this: sdhc_boot.c and spi_boot.c will
be deleted. All this stuff in the sdhc_boot.c will be moved to
drivers/mmc/fsl_esdhc.c, and the functions in the spi_boot.c will be
moved to drivers/mmc/fsl_espi.c.
Maybe drivers/mmc/fsl_espi_spl.c and such?
+void hang(void)
+{
+ puts(### ERROR ### Please RESET the board ###\n);
+ for (;;)
+ ;
+}
Whitespace
[Zhang Ying]
?
I'm not sure what I meant here. :-P
Maybe I meant to put this comment elsewhere, or trimmed the wrong
context...
diff --git a/common/Makefile b/common/Makefile index
0e0fff1..bc80414
100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -225,6 +225,11 @@ COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_common.o
COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_flags.o
COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_nowhere.o
COBJS-$(CONFIG_SPL_NET_SUPPORT) += miiphyutil.o
+COBJS-$(CONFIG_SPL_HWCONFIG_SUPPORT) += hwconfig.o
+COBJS-$(CONFIG_SPL_INIT_DDR_SUPPORT) += ddr_spd.o
+COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_attr.o
+COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_flags.o
+COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_callback.o
CONFIG_SPL_ENV_SUPPORT should replace CONFIG_SPL_NET_SUPPORT here
(and add it to the boards that already have CONFIG_SPL_NET_SUPPORT).
This sort of refactoring needs to be a separate patch, BTW.
Can ddr_spd.o and hwconfig just use their normal CONFIG symbols (i.e.
move the existing makefile line out of the !SPL ifdef)? It's getting
a bit excessive with all the new SPL symbols.
[Zhang Ying]
If do it, the SPL's size will increase. I fear this will affect the
other SPL no CONFIG_SPL_NET_SUPPORT is defined.
Which SPL in particular are you concerned about, that uses
common/Makefile at all, and have CONFIG_SPD and/or CONFIG_HWCONFIG?
How much will they grow, after gc-sections (mainly all that's left is
anonymous strings)?
+Where $file is the target file. Also keep in mind the u-boot.bin
file needs
+to be the u-boot built for your particular platform and target
media.
+
+Hint: To generate a u-boot.bin for a P1022DS booting from SD I
would
run the
+following in the u-boot repository:
+
+ $ make P1022DS_SDCARD
s/Hint/Example/ and s/from SD I would run/from SD, run/
[Zhang Ying]
run bootsd? This is another independent requirement. If we want, we
can do it in another project.
Hmm? I was just fixing up the wording -- change Hint to Example
and change from SD I would run to from SD, run.
That said, yes I would like to see run bootsd. :-)
-Scott
___
Re: [U-Boot] [PATCH 4/4] arm: factorize relocate_code routine
Hi Albert,
On Friday, May 10, 2013 11:56:52 PM, Albert ARIBAUD wrote:
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
arch/arm/cpu/arm1136/start.S | 82
arch/arm/cpu/arm1176/start.S | 75 --
arch/arm/cpu/arm720t/start.S | 82
arch/arm/cpu/arm920t/start.S | 75 --
arch/arm/cpu/arm925t/start.S | 75 --
arch/arm/cpu/arm926ejs/start.S | 82
arch/arm/cpu/arm946es/start.S | 75 --
arch/arm/cpu/arm_intcm/start.S | 75 --
arch/arm/cpu/armv7/start.S | 78 ---
arch/arm/cpu/ixp/start.S | 75 --
arch/arm/cpu/pxa/start.S | 84 -
arch/arm/cpu/s3c44b0/start.S | 75 --
arch/arm/cpu/sa1100/start.S| 75 --
arch/arm/lib/Makefile |2 +-
arch/arm/lib/relocate.S| 100
15 files changed, 101 insertions(+), 1009 deletions(-)
create mode 100644 arch/arm/lib/relocate.S
[...]
diff --git a/arch/arm/cpu/pxa/start.S b/arch/arm/cpu/pxa/start.S
index ada91a6..3078bec 100644
--- a/arch/arm/cpu/pxa/start.S
+++ b/arch/arm/cpu/pxa/start.S
@@ -170,90 +170,6 @@ reset:
bl _main
-/*--*/
-#ifndef CONFIG_SPL_BUILD
-/*
- * void relocate_code(addr_moni)
- *
- * This function relocates the monitor code.
- */
- .globl relocate_code
-relocate_code:
- mov r6, r0 /* save addr of destination */
-
-/* Disable the Dcache RAM lock for stack now */
-#ifdef CONFIG_CPU_PXA25X
- mov r12, lr
- bl cpu_init_crit
- mov lr, r12
-#endif
What about this thing that you silently drop?
-
- adr r0, _start
- subsr9, r6, r0 /* r9 - relocation offset */
- beq relocate_done /* skip relocation */
- mov r1, r6 /* r1 - scratch for copy_loop */
- ldr r3, _image_copy_end_ofs
- add r2, r0, r3 /* r2 - source end address */
-
-copy_loop:
- ldmia r0!, {r10-r11} /* copy from source address [r0]*/
- stmia r1!, {r10-r11} /* copy to target address [r1]*/
- cmp r0, r2 /* until source end address [r2]*/
- blo copy_loop
-
-#ifndef CONFIG_SPL_BUILD
- /*
- * fix .rel.dyn relocations
- */
- ldr r0, _TEXT_BASE /* r0 - Text base */
- ldr r10, _dynsym_start_ofs /* r10 - sym table ofs */
- add r10, r10, r0/* r10 - sym table in FLASH */
- ldr r2, _rel_dyn_start_ofs /* r2 - rel dyn start ofs */
- add r2, r2, r0 /* r2 - rel dyn start in FLASH */
- ldr r3, _rel_dyn_end_ofs/* r3 - rel dyn end ofs */
- add r3, r3, r0 /* r3 - rel dyn end in FLASH */
-fixloop:
- ldr r0, [r2]/* r0 - location to fix up, IN FLASH!
*/
- add r0, r0, r9 /* r0 - location to fix up in RAM */
- ldr r1, [r2, #4]
- and r7, r1, #0xff
- cmp r7, #23 /* relative fixup? */
- beq fixrel
- cmp r7, #2 /* absolute fixup? */
- beq fixabs
- /* ignore unknown type of fixup */
- b fixnext
-fixabs:
- /* absolute fix: set location to (offset) symbol value */
- mov r1, r1, LSR #4 /* r1 - symbol index in .dynsym */
- add r1, r10, r1 /* r1 - address of symbol in table */
- ldr r1, [r1, #4]/* r1 - symbol value */
- add r1, r1, r9 /* r1 - relocated sym addr */
- b fixnext
-fixrel:
- /* relative fix: increase location by offset */
- ldr r1, [r0]
- add r1, r1, r9
-fixnext:
- str r1, [r0]
- add r2, r2, #8 /* each rel.dyn entry is 8 bytes */
- cmp r2, r3
- blo fixloop
-#endif
-
-relocate_done:
-
- bx lr
-
-_rel_dyn_start_ofs:
- .word __rel_dyn_start - _start
-_rel_dyn_end_ofs:
- .word __rel_dyn_end - _start
-_dynsym_start_ofs:
- .word __dynsym_start - _start
-
-#endif
-
.globl c_runtime_cpu_setup
c_runtime_cpu_setup:
[...]
diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
new file mode 100644
index 000..ce533ca
--- /dev/null
+++ b/arch/arm/lib/relocate.S
@@ -0,0 +1,100 @@
+/*
+ * relocate - common relocation function for ARM U-Boot
+ *
+ * Copyright (c) 2013 Albert ARIBAUD albert.u.b...@aribaud.net
+ *
+ * See file CREDITS for list of
[U-Boot] [PATCH 3/3] usb: Correct CLEAR_FEATURE code in ehci-hcd
This commit broke USB2 on link (Chromebook Pixel):
020bbcb usb: hub: Power-cycle on root-hub ports
However the root cause seems to be a missing mask and missing 'break'
in ehci-hcd.c. This patch fixes both.
On link, 'usb start' with a USB keyboard and memory stick inserted now
finds both. The keyboard works as expected. Also ext2ls shows a directory
listing from the memory stick.
Signed-off-by: Simon Glass s...@chromium.org
---
drivers/usb/host/ehci-hcd.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index e0f3e4b..445759b 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -809,21 +809,23 @@ ehci_submit_root(struct usb_device *dev, unsigned long
pipe, void *buffer,
break;
case USB_REQ_CLEAR_FEATURE | ((USB_DIR_OUT | USB_RT_PORT) 8):
reg = ehci_readl(status_reg);
+ reg = ~EHCI_PS_CLEAR;
switch (le16_to_cpu(req-value)) {
case USB_PORT_FEAT_ENABLE:
reg = ~EHCI_PS_PE;
break;
case USB_PORT_FEAT_C_ENABLE:
- reg = (reg ~EHCI_PS_CLEAR) | EHCI_PS_PE;
+ reg |= EHCI_PS_PE;
break;
case USB_PORT_FEAT_POWER:
if (HCS_PPC(ehci_readl(ctrl-hccr-cr_hcsparams)))
- reg = reg ~(EHCI_PS_CLEAR | EHCI_PS_PP);
+ reg = ~EHCI_PS_PP;
+ break;
case USB_PORT_FEAT_C_CONNECTION:
- reg = (reg ~EHCI_PS_CLEAR) | EHCI_PS_CSC;
+ reg |= EHCI_PS_CSC;
break;
case USB_PORT_FEAT_OVER_CURRENT:
- reg = (reg ~EHCI_PS_CLEAR) | EHCI_PS_OCC;
+ reg |= EHCI_PS_OCC;
break;
case USB_PORT_FEAT_C_RESET:
ctrl-portreset = ~(1 port);
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] usb: workaround non-working keyboards.
From: Vincent Palatin vpala...@chromium.org
If the USB keyboard is not answering properly the first request on its
interrupt endpoint, just skip it and try the next one.
This workarounds an issue with a wireless mouse dongle which presents
itself both as a keyboard and a mouse but has a non-functional keyboard
interface.
Signed-off-by: Vincent Palatin vpala...@chromium.org
(cherry picked from commit 012bbf0ce0301be2482857e3f03b481dd15c2340)
Rebased to upstream/master:
Signed-off-by: Simon Glass s...@chromium.org
Reviewed-by: Stefan Reinauer reina...@chromium.org
Tested-by: Vincent Palatin vpala...@chromium.org
---
common/usb_kbd.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/common/usb_kbd.c b/common/usb_kbd.c
index 188763d..3174b5e 100644
--- a/common/usb_kbd.c
+++ b/common/usb_kbd.c
@@ -461,8 +461,13 @@ static int usb_kbd_probe(struct usb_device *dev, unsigned
int ifnum)
usb_set_idle(dev, iface-desc.bInterfaceNumber, REPEAT_RATE, 0);
debug(USB KBD: enable interrupt pipe...\n);
- usb_submit_int_msg(dev, pipe, data-new, maxp 8 ? 8 : maxp,
- ep-bInterval);
+ if (usb_submit_int_msg(dev, pipe, data-new, maxp 8 ? 8 : maxp,
+ ep-bInterval) 0) {
+ printf(Failed to get keyboard state from device %04x:%04x\n,
+ dev-descriptor.idVendor, dev-descriptor.idProduct);
+ /* Abort, we don't want to use that non-functional keyboard. */
+ return 0;
+ }
/* Success. */
return 1;
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] usb: properly re-initialize the USB keyboard.
From: Vincent Palatin vpala...@chromium.org
Allow to reconfigure properly the USB keyboard driver when we enumerate
several times the USB devices and its position in the device tree has
changes.
Signed-off-by: Vincent Palatin vpala...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
Reviewed-by: Stefan Reinauer reina...@chromium.org
Tested-by: Vincent Palatin vpala...@chromium.org
---
common/usb_kbd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/common/usb_kbd.c b/common/usb_kbd.c
index b962849..188763d 100644
--- a/common/usb_kbd.c
+++ b/common/usb_kbd.c
@@ -496,6 +496,7 @@ int drv_usb_kbd_init(void)
if (old_dev) {
/* Already registered, just return ok. */
debug(USB KBD: is already registered.\n);
+ usb_kbd_deregister();
return 1;
}
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Tegra: clk: always use find_best_divider() for periph clocks
When adjusting peripheral clocks always use find_best_divider() instead of clk_get_divider() even when a secondary divider is not available. In the case where is requested clock is too slow to be derived from the parent clock this allows a best effort to get close to the requested clock. This comes up for commands like sf where the user can pass a clock speed on the command line or sspi where the clock is hardcoded to 1MHz, but the Tegra114 SPI controller can't go that low. Signed-off-by: Allen Martin amar...@nvidia.com --- arch/arm/cpu/tegra-common/clock.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm/cpu/tegra-common/clock.c b/arch/arm/cpu/tegra-common/clock.c index 9156d00..268fb91 100644 --- a/arch/arm/cpu/tegra-common/clock.c +++ b/arch/arm/cpu/tegra-common/clock.c @@ -321,17 +321,17 @@ unsigned clock_adjust_periph_pll_div(enum periph_id periph_id, unsigned effective_rate; int mux_bits, divider_bits, source; int divider; + int xdiv = 0; /* work out the source clock and set it */ source = get_periph_clock_source(periph_id, parent, mux_bits, divider_bits); + divider = find_best_divider(divider_bits, pll_rate[parent], + rate, xdiv); if (extra_div) - divider = find_best_divider(divider_bits, pll_rate[parent], - rate, extra_div); - else - divider = clk_get_divider(divider_bits, pll_rate[parent], - rate); + *extra_div = xdiv; + assert(divider = 0); if (adjust_periph_pll(periph_id, source, mux_bits, divider)) return -1U; -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Tegra: clk: always use find_best_divider() for periph clocks
On Fri, May 10, 2013 at 8:56 PM, Allen Martin amar...@nvidia.com wrote: When adjusting peripheral clocks always use find_best_divider() instead of clk_get_divider() even when a secondary divider is not available. In the case where is requested clock is too slow to be derived from the parent clock this allows a best effort to get close to the requested clock. This comes up for commands like sf where the user can pass a clock speed on the command line or sspi where the clock is hardcoded to 1MHz, but the Tegra114 SPI controller can't go that low. Signed-off-by: Allen Martin amar...@nvidia.com Seems right to me, Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] exynos: Enable mmc for snow
Snow has an internal eMMC and an external SD card. Enable these in the
device tree.
Signed-off-by: Simon Glass s...@chromium.org
---
board/samsung/dts/exynos5250-snow.dts | 24
1 file changed, 24 insertions(+)
diff --git a/board/samsung/dts/exynos5250-snow.dts
b/board/samsung/dts/exynos5250-snow.dts
index 24658c1..d167df9 100644
--- a/board/samsung/dts/exynos5250-snow.dts
+++ b/board/samsung/dts/exynos5250-snow.dts
@@ -30,6 +30,10 @@
spi2 = /spi@12d4;
spi3 = /spi@131a;
spi4 = /spi@131b;
+ mmc0 = /mmc@1220;
+ mmc1 = /mmc@1221;
+ mmc2 = /mmc@1222;
+ mmc3 = /mmc@1223;
};
sound@12d6 {
@@ -56,6 +60,26 @@
};
};
+ mmc@1220 {
+ samsung,bus-width = 8;
+ samsung,timing = 1 3 3;
+ samsung,removable = 0;
+ };
+
+ mmc@1221 {
+ status = disabled;
+ };
+
+ mmc@1222 {
+ samsung,bus-width = 4;
+ samsung,timing = 1 2 3;
+ samsung,removable = 1;
+ };
+
+ mmc@1223 {
+ status = disabled;
+ };
+
tmu@1006 {
samsung,min-temp= 25;
samsung,max-temp= 125;
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V9 0/9] EXYNOS5: Enable DWMMC, add FDT support for DWMMC and enable EMMC boot
On Sat, Apr 27, 2013 at 12:12 AM, amar_g amarendra...@samsung.com wrote: From: Amar amarendra...@samsung.com This patch set enables and initialises DWMMC for Exynos5250 on SMDK5250. Adds driver changes required for DWMMC. Adds FDT support for DWMMC. Adds EMMC boot support for SMDK5250. This patch set is based on: EXYNOS: mmc: support DesignWare Controller for Samsung-SoC, which is merged in u-boot-mmc. Exynos: clock: support get_mmc_clk for exynos. Add DT based ethernet driver for SMDK5250. SMDK5250: Add FDT support present at the following link http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/149991 Changes since V1: 1)Corrected in response to review comments. 2)Created separate board files for FDT and non-FDT versions. 3)Added binding file for DWMMC device node. 4)Removed the propname 'index' from device node. 5)Prefixed the vendor name 'samsung' before propname in device node. 6)Ensured to have same signature for the function exynos_dwmci_init() for both FDT and non-FDT versions. 7)EMMC clock setting has been moved from spl_boot.c to clock_init.c. Changes since V2: 1)Updation of commit message and resubmition of proper patch set. Changes since V3: 1)Updated to use the macro DWMCI_CTRL_SEND_AS_CCSD instead of the hard coded value (1 10). 2)In the file exynos_dw_mmc.c, replaced the new function exynos5_mmc_set_clk_div() with the existing function set_mmc_clk(). set_mmc_clk() will do the purpose. 3)In the file exynos_dw_mmc.c, computation of FSYS block clock divisor (pre-ratio) value is added. 4)Removed the new function exynos5_mmc_set_clk_div() from clock.c. Changes since V4: 1)Updated the function dwmci_send_cmd() to use get_timer() instead of using mdelay(1). 2)Replaced the function call 'exynos_dwmmc_init(0, 8);' with the function exynos_dwmmc_add_port() in smdk5250.c. 3)The function get_irom_func(int index) has been added to avoid type casting at many places. 4)Used the generic function mmc_boot_part_access() instead of two functions mmc_boot_open() and mmc_boot_close(). By doing so user can specify which boot partition to be accessed (opened / closed). Changes since V5: 1)Added the 'removable' flag to mmc device node. 2)Changed the mmc clock value from 50MHz to 52MHz in the function exynos_dwmci_add_port() present in file drivers/mmc/exynos_dw_mmc.c. 3)Enabled CONFIG_LCD only for non-FDT operation. 4)Removed the function call i2c_init() present inside the function board_i2c_init(). Changes since V6: 1)Re-based to the patch SMDK5250: Add PMIC voltage settings. Changes since V7: 1)Re-based to the patch Exynos: pwm: Remove dead code of function exynos5_get_pwm_clk. 2)In file dw_mmc.c, updated the function dwmci_setup_bus() to return 0 if (freq == 0).This is to avoid the run time exception raise:Signal # 8 caught. 3)In the files drivers/mmc/mmc.c and common/cmd_mmc.c, the piece of code involved in EMMC open/close and resize of EMMC boot partition has been made conditional and is enabled only if the macro CONFIG_SUPPORT_EMMC_BOOT is defined. 4)The macros FSYS1_MMC0_DIV_MASK and FSYS1_MMC0_DIV_VAL are made local to file clock_init.c. Changes since V8: 1)Re-based to the patch exynos: fdt: Add TMU node for snow. 2)In spl_boot.c, updated USB boot piece of code, to use get_irom_func(int index) to avoid type casting. 3)Updated the below in response to review comments a)Changed the type of input parameters from u32 to u8 for the function boot_part_access(). b)Updated the function call to use a constant value 1, for boot_part_access(mmc, 1, part_num, access). c)In function dwmci_init, auto stop command is disabled, as this feature is not required. The series tested on snow: Acked-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org Amar (9): FDT: Add compatible string for DWMMC EXYNOS5: FDT: Add DWMMC device node data DWMMC: Initialise dwmci and resolve EMMC read write issues EXYNOS5: DWMMC: Added FDT support for DWMMC EXYNOS5: DWMMC: Initialise the local variable to avoid unwanted results. SMDK5250: Initialise and Enable DWMMC, support FDT and non-FDT MMC: APIs to support resize of EMMC boot partition SMDK5250: Enable EMMC booting COMMON: MMC: Command to support EMMC booting and to resize EMMC boot partition arch/arm/cpu/armv7/exynos/clock.c |4 +- arch/arm/dts/exynos5250.dtsi | 33 +++ arch/arm/include/asm/arch-exynos/dwmmc.h | 11 +- board/samsung/dts/exynos5250-smdk5250.dts | 24 ++
Re: [U-Boot] [PATCH 1/2] lcd: add functions to setup up simplefb device tree
On 05/08/2013 09:33 PM, Simon Glass wrote:
Hi Stephen,
On Tue, May 7, 2013 at 10:21 PM, Stephen Warren swar...@wwwdotorg.org wrote:
simple-framebuffer is a new device tree binding that describes a pre-
configured frame-buffer memory region and its format. The Linux kernel
contains a driver that supports this binding. Implement functions to
create a DT node (or fill in an existing node) with parameters that
describe the framebuffer format that U-Boot is using.
This will be immediately used by the Raspberry Pi board in U-Boot, and
likely will be used by the Samsung ARM ChromeBook support soon too. It
could well be used by many other boards (e.g. Tegra boards with built-in
LCD panels, which aren't yet supported by the Linux kernel).
This looks OK - is a better place for it than the common lcd code? I
presume it is here because it accesses panel_info?
I believe it really is common code; the DT content this code generates
is defined by a generic binding and isn't SoC-/board-specific. Perhaps a
common DT-related file would be OK too, although as you mention I'm not
sure if any other file would have access to the required LCD variables.
Also is there a binding file we can bring in?
Yes, there's a simple-framebuffer.txt I could copy from the kernel.
+int lcd_dt_simplefb_add_node(void *blob)
Can we not automatically find the node and update it?
Some DTs might have the node already exist and want to edit it, whereas
others might not contain it at all and need it added. This is rather up
to the author of individual boards' DTs. I wanted to make the code
explicitly select between those two options so that the U-Boot board
author always thought about exactly which behaviour they wanted.
+int lcd_dt_simplefb_enable_existing_node(void *blob)
+{
+ int off;
+
+ off = fdt_node_offset_by_compatible(blob, -1, simple-framebuffer);
Do we ever need to support more than one node, iwc perhaps we want to
pass in the offset? If not, then see above question re searching.
I don't think U-Boot supports multiple panels does it? If the DT
contained multiple nodes to start with, I think they'd have to all be
initially disabled since some firmware would be required to fill in the
fields before they were useful.
As such, finding and editing the first node in all cases seems to make
sense for now. If this ever becomes false, we can add an index parameter
quite easily without significant impact.
diff --git a/include/lcd.h b/include/lcd.h
+#if defined(CONFIG_LCD_DT_SIMPLEFB)
Probably don't need this #ifdef? It will complicate things if we use
the autoconf series.
What's the autoconf series? I did this in order to get compile errors
rather than link errors if the functions were used without being
enabled, but I guess most linkers generate useful error messages so
perhaps this isn't needed.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] at91sam9x5ek: Pass serial and revision tags to Linux
Thanks Andreas.
In this case, I too think its better to drop this particular patch and
right a new one to support reading 1 wire Id chip.
If Bo doesn't have any code in pipeline as of now, then I shall start
working on it.
Regards,
Julius Hemanth P.
On May 10, 2013 7:07 PM, Andreas Bießmann andreas.de...@googlemail.com
wrote:
Hi Julius,
On 05/10/2013 01:40 PM, Julius Hemanth P wrote:
Hi Andreas,
On Fri, May 10, 2013 at 12:21 PM, Andreas Bießmann
andreas.de...@googlemail.com wrote:
Dear Julius Hemanth P,
On 09.05.13 19:07, Julius Hemanth P wrote:
snip
diff --git a/board/atmel/at91sam9x5ek/at91sam9x5ek.c
b/board/atmel/at91sam9x5ek/at91sam9x5ek.c
index 8773e6f..116bd83 100644
--- a/board/atmel/at91sam9x5ek/at91sam9x5ek.c
+++ b/board/atmel/at91sam9x5ek/at91sam9x5ek.c
@@ -27,6 +27,7 @@
#include asm/arch/at91_common.h
#include asm/arch/at91_pmc.h
#include asm/arch/at91_rstc.h
+#include asm/arch/at91_gpbr.h
#include asm/arch/gpio.h
#include asm/arch/clk.h
#include lcd.h
@@ -48,8 +49,34 @@ DECLARE_GLOBAL_DATA_PTR;
/*
- */
/*
- * Miscelaneous platform dependent initialisations
+ * Miscellaneous platform dependent initializations
*/
+
+#ifdef CONFIG_LOAD_ONE_WIRE_INFO
What the hell has this one wire thing to do with reading internal
GPBR's?
This is a new config parameter (which lacks documentation in this patch)
is not required at all cause it is enabled in any case, or do I miss
something?
AT91Bootstrap reads board revision and serial info from 1 wire chip
and writes it to GPBR registers. U-boot, in board_init(), reads that
info from GPBR and places it in global variables in order to pass it
to Linux. At the time of boot_prep_linux(), these info will be read
from global variables and passed to linux kernel as ATAGs.
there are a lot of outdated stuff involved ;)
* ATAGs will be replaced by FDT
* AT91bootstrap should be replaced with u-boot SPL
The board at91sam9x5ek I came across has this 1 wire chip connected,
But I am really not sure if this is true with all at91sam9x5ek boards,
hence I made a config parameter so that others can just enable or
disable reading rev and serial info from 1 wire chip(in this case from
GPBR registers).
We have a single definition for all at91sam9x5ek variants. If there are
some which do not provide such an 1wire id chip we need to address this
here (or in at91bootstrap). I think we shouldn't force the user to
change the board config header to enable different variants. We could
introduce a new 'board name' (in boards.cfg) to address this, but as
long as we do not know that we break other boards which do _not_ have
such an 1wire id chip I think it is ok to not introduce a new config.
If we decide to introduce the config parameter we should document it
somewhere.
+static u32 system_rev;
+static u32 system_serial_low;
Can we please omit these global variables? We could just read the GPBR's
in respective get-functions. This will reduce the .bss and .text size
and is therefore reasonable.
May be yes, if we have some place to preserve these info for
processing at later stage, As of now I am really not aware of any such
struct. If you have any suggestion of one such place, please suggest
me so that I can omit these global variables. I too dislike the idea
of using global variables.
Well, my first idea was to define these places in GPBR to be
'system_rev' and 'system_serial_low', but the provided location does not
fit current definition of GPBR ...
+
+u32 get_board_rev(void)
+{
+ return system_rev;
+}
+
+void get_board_serial(struct tag_serialnr *serialnr)
+{
+ serialnr-high = 0; /* Not used */
+ serialnr-low = system_serial_low;
+}
+
+void load_1wire_info(void)
+{
+ at91_gpbr_t *gpbr = (at91_gpbr_t *) ATMEL_BASE_GPBR;
+
+ /* serial is in GPBR #2 and revision is in GPBR #3 */
Why is that so? Which code places the serial and revision version into
the GPBR's?
Please add documentation and mark the usage in at91_gpbr.h.
As at91_gpbr.h states GPBR[3] is already used for bootcount ... so I
tend to completely NAK this patch.
In early stage of U-boot, at the time of board_init(), we read serial
and revision info from GPBR registers, which making GPBR registers
free and available for other purpose (like bootcount). Hence, this
patch will not conflict with any part of code which plays with GPBR.
board_init() runs in board_init_r(), this is way to late cause a lot of
stuff runs before, board_early_init_f() is a better place, but I dunno
if we can use .bss while in the board_init_f() phase.
Currently GPBR[3] is reserved for bootcount (in some at91 boards), the
aim of bootcount is to read the bootcount store, increment it and write
the new value. The value in the store must not be changed during
[U-Boot] [PATCH v2] spi: mxc_spi: Update pre and post divider algorithm
The spi clock divisor is of the form x * (2**y), or x y, where x is
1 to 16, and y is 0 to 15. Note the similarity with floating point numbers.
Convert the desired divisor to the smallest number which is = desired divisor,
and can be represented in this form. The previous algorithm chose a divisor
which could be almost twice as large as needed.
Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
Signed-off-by: Dirk Behme dirk.be...@gmail.com
---
Notes:
- Changes in v2: Make the alogrithm simpler by removing the -1 as proposed
by Troy. Make the pre_div and post_div u32.
- This replaces v1 of this patch and depends on the previous sent patch
http://patchwork.ozlabs.org/patch/242709/
drivers/spi/mxc_spi.c | 30 --
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 3e903b3..e87b899 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -128,8 +128,8 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned
int cs,
unsigned int max_hz, unsigned int mode)
{
u32 clk_src = mxc_get_clock(MXC_CSPI_CLK);
- s32 pre_div = 1, post_div = 0, i, reg_ctrl, reg_config;
- u32 ss_pol = 0, sclkpol = 0, sclkpha = 0;
+ s32 reg_ctrl, reg_config;
+ u32 ss_pol = 0, sclkpol = 0, sclkpha = 0, pre_div = 0, post_div = 0;
struct cspi_regs *regs = (struct cspi_regs *)mxcs-base;
if (max_hz == 0) {
@@ -147,26 +147,20 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs,
unsigned int cs,
reg_ctrl |= MXC_CSPICTRL_EN;
reg_write(regs-ctrl, reg_ctrl);
- /*
-* The following computation is taken directly from Freescale's code.
-*/
if (clk_src max_hz) {
- pre_div = DIV_ROUND_UP(clk_src, max_hz);
- if (pre_div 16) {
- post_div = pre_div / 16;
- pre_div = 16;
- }
- if (post_div != 0) {
- for (i = 0; i 16; i++) {
- if ((1 i) = post_div)
- break;
- }
- if (i == 16) {
+ pre_div = (clk_src - 1) / max_hz;
+ /* fls(1) = 1, fls(0x8000) = 32, fls(16) = 5 */
+ post_div = fls(pre_div);
+ if (post_div 4) {
+ post_div -= 4;
+ if (post_div = 16) {
printf(Error: no divider for the freq: %d\n,
max_hz);
return -1;
}
- post_div = i;
+ pre_div = post_div;
+ } else {
+ post_div = 0;
}
}
@@ -174,7 +168,7 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned
int cs,
reg_ctrl = (reg_ctrl ~MXC_CSPICTRL_SELCHAN(3)) |
MXC_CSPICTRL_SELCHAN(cs);
reg_ctrl = (reg_ctrl ~MXC_CSPICTRL_PREDIV(0x0F)) |
- MXC_CSPICTRL_PREDIV(pre_div - 1);
+ MXC_CSPICTRL_PREDIV(pre_div);
reg_ctrl = (reg_ctrl ~MXC_CSPICTRL_POSTDIV(0x0F)) |
MXC_CSPICTRL_POSTDIV(post_div);
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
