Re: [U-Boot] dfu: make data buffer size configurable
Hello Tom,
Am 06.06.2013 17:55, schrieb Tom Rini:
On Wed, Jun 05, 2013 at 04:04:46PM +0200, Heiko Schocher wrote:
[snip]
In current code CONFIG_SYS_DFU_MAX_FILE_SIZE is not used in dfu_nand.c,
Nor anywhere else. As I said in the DFU + UBI thread, there's a bug
here :)
CONFIG_SYS_DFU_MAX_FILE_SIZE is used in ./drivers/dfu/dfu_mmc.c ...
Ah yes, right.
as if buffer is full, it is immediately flushed to nand.
Also default value from CONFIG_SYS_DFU_MAX_FILE_SIZE is smaller (4MiB)
as default value of CONFIG_SYS_DFU_DATA_BUF_SIZE (8MiB) ...
Right, and the commit that did it was about increasing the size of the
kernel that could be sent over.
Hmm.. the CONFIG_SYS_DFU_DATA_BUF_SIZE limits not the size of
a file that could be loaded into a partition. It specifies
only the size of one chunk, that get burned into the raw nand ...
And this should be a configurable size ...
Or a saner, smaller size? I think we've got a few things being done in
a confusing and/or incorrect manner, see below.
Yes, smaller size is maybe the way to go ... see below
I used on my upcoming board port a CONFIG_SYS_DFU_DATA_BUF_SIZE from
1MiB and that worked perfectly, when transferring a file 200MB.
The default value from 8MiB sometimes caused an error on the host:
[]# date;dfu-util -a rootfs -D
dxr2-org/dxr2.xx-release-image-UNKNOWN-dxr2.ubi;date
Di 28. Mai 14:20:44 CEST 2013
dfu-util 0.5
[...]
Copying data from PC to DFU device
Starting download:
[#dfu_download:
libusb_control_transfer returned -7
Error during download
Why we have a buffersize from 8MiB for raw writes, but a max file size
from 4MiB only?
Then we need to poke around the code here a bit more and see what's
going on, and fix things so that we can both do larger (say, 8MiB)
filesystem transfers and not have dfu-util get mad sometimes.
Timeout in libusb_control_transfer while the target writes
the 8MiB into the nand ... ?
I try to find out something ...
Well, it ought to be fine, but we're pushing some boundaries here, and
I don't know if we have a good reason for it. We aren't changing the
size of the chunks being passed along.
My suspicion that the problem is a timeout was the right idea!
I tried following patch in the current dfu-util sources:
(git clone git://gitorious.org/dfu-util/dfu-util.git
current head: f66634406e9397e67c34033c3c0c26dde486528c)
diff --git a/src/main.c b/src/main.c
index 2aea134..12f6f1d 100644
--- a/src/main.c
+++ b/src/main.c
@@ -290,7 +290,8 @@ int main(int argc, char **argv)
exit(0);
}
- dfu_init(5000);
+ printf(Using 20 sec timeout\n);
+ dfu_init(2);
num_devs = count_dfu_devices(ctx, dif);
if (num_devs == 0) {
and I see no longer the above error! So I see two solutions
for my problem:
- make DFU_DATA_BUF_SIZE in U-Boot smaller or configurable
- make the timeout in dfu-util bigger or configurable
-#define DFU_DATA_BUF_SIZE (1024*1024*8) /* 8 MiB */
+#ifndef CONFIG_SYS_DFU_DATA_BUF_SIZE
+#define CONFIG_SYS_DFU_DATA_BUF_SIZE(1024*1024*8) /* 8
MiB */
+#endif
#ifndef CONFIG_SYS_DFU_MAX_FILE_SIZE
#define CONFIG_SYS_DFU_MAX_FILE_SIZE(4 20) /* 4 MiB */
#endif
We use one variable for both spots. Or is there some case I'm missing
where we need to buffer 8MiB at a time for raw writes? In which case we
still need to make CONFIG_SYS_DFU_MAX_FILE_SIZE be used :)
I do not really know, why we have 2 defines here!
File size vs buffer size? I'm not quite certain it was the right way to
go either.
Yeah, but why is the file size buffer size as default?
A bug, I'm pretty sure. The change that made buffer file was with the
comment to allow for bigger files. I think it might not have been
completely tested :)
Maybe. I don't know.
In dfu_mmc:
If raw partition, if dfu_buf (size of CONFIG_SYS_DFU_DATA_BUF_SIZE)
full - write it to the mmc. Same for nand.
Right. Since we want to buffer up some amount of data, flush, repeat
until done.
Yep.
If FAT or EXT4 partition (mmc only), write the dfu_buffer through
mmc_file_buffer() to dfu_file_buf[CONFIG_SYS_DFU_MAX_FILE_SIZE] ...
this seems buggy to me, but maybe I oversee something, I could not
try it ... and if the hole file is transfered, the dfu_file_buf
gets flushed to the partition ...
The need here is that since we can't append to files, transfer the whole
file, then write. We will not be told the filesize ahead of time, so we
have to transfer up to the buffer and if we would exceed, error out at
that point, otherwise continue. Now I'm pretty sure, but not 100% sure
that there's a reason we can't use dfu_buf in both places. That needs
re-checking.
Ok.
The CONFIG_SYS_DFU_MAX_FILE_SIZE is only needed as we can only
write a complete image to FAT, EXT4 (also UBI) partitions, I think.
It'll be needed for any file write, rather than block
Re: [U-Boot] patches never reviewed
-Original Message- From: Angelo Dureghello [mailto:sysa...@gmail.com] Sent: Thursday, June 06, 2013 10:21 PM To: u-boot@lists.denx.de Cc: Jin Zhengxiong-R64188 Subject: Re: [U-Boot] patches never reviewed Dear Scott, please be sure before replying to verify the history of the threads. This patch is around for more than one year. 1) i was quite sure that last patch body was ok. Please let me know eventually what are these issues, if any, with a feedback. 2) in most of the cases i always included Mr, Jason Jim in CC, that in most of the cases never reply. Maybe could be the case to verify this and clarify with him. 3) this subject is in this form because is not the 1st but the second reminder to review the patches, and not a patch. You told me board: add support for amcore board is not correct, but of course you can check the patchwork site and see other title like that passed. And in case i fix this, someone will say the m68k in the title is wrong, becouse is a board patch. To the community, i fixed several and several things on this patch over more than one year, following several and several feedbacks from many of you. I was expecting a minimal of flexibility and a final approval, since i contributed also for bug fixing sometime, and since some other boards has been approved wthout too many troubles. I have seen this is depending much from the cpu/arch tree maintainer or custodian. And the custodian of Coldfire tree from Freescale seems is not partecipating to much in this patch. The result is that there is no way to have the board nor m5307 cpu patch accepted becouse again, for the 100th time, there is something not correct. I am not stupid, and understanding now that whatever would be my changes, patch will still be stopped and stopped from a different guy. I don't want to accuse anyone of any form of discrimination, but i stop to contribute for now, almost for m68k branch. [Jason Jin-R64188] I'm sorry for late response for this V6 version patches. But you really need to send the patch by git-send-email instead of by attachments, so everybody can review it in the mail. Please resend it. Thanks. On Tue, Jun 04, 2013 at 12:54:31PM -0500, Scott Wood wrote: On 06/04/2013 12:47:47 PM, Scott Wood wrote: On 06/03/2013 03:51:48 PM, Angelo Dureghello wrote: Dear All, i worked hardly through v6 for approval of this AMCORE Coldfire board support. Waited patiently for review of this patches: http://patchwork.ozlabs.org/patch/215904/ http://patchwork.ozlabs.org/patch/214686/ then asked again later for the review: http://marc.info/?l=u-bootm=136059580219228w=2 still, at today, i had no feedbacks. Unfortunately (i can be wrong) but i have the impression at freescale no-one have time to spend for following this board addition. Jason Jin is the Coldfire custodian. I've added him on CC here; please be sure to put him on CC when you send Coldfire patches or inquiries. Sigh, and of course the list ate the CC. So for all I know maybe you had him on CC to begin with... Another thing that can help is using better subject lines. patches review isn't going to let people know what sort of patches they are and if it's their responsibility or not. Likewise, board: add support for amcore board doesn't have m68k or coldfire in the title (whereas board: is redundant). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: exynos: make spl_boot common for all exynos based platforms
Dear Minkyu Kang,
Thanks for the review.
On 4 June 2013 12:56, Minkyu Kang mk7.k...@samsung.com wrote:
Dear Inderpal Singh,
On 27/03/13 17:48, Inderpal Singh wrote:
Dear Minkyu,
Please let me know if you have any comments for this patch.
With Regards,
Inder
On 16 March 2013 14:16, Inderpal Singh inderpal.si...@linaro.org
wrote:
The spl_boot.c which copies the u-boot from the booting device to ram
is made common for all the exynos based platforms. To do so:
1. Moved smdk5250/spl_boot.c to common armv7/exynos folder and updated
to make it common for exynos4 and exynos5
2. Introduced a CONFIG_SPL_BOOTING option as only exynos5250 supports
booting from SPI device
3. Renamed some config options to make them common between exynos5250,
origen and smdkv310.
SD/MMC booting: tested on exynos4210 based origen, exynos5250 based
Arndale
and SMDK5250 boards.
SPI booting: tested on SMDK5250 board
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
It depends on the patchset at [1] as it provides the infrastructure to
detect the SOC type and revision in spl at runtime.
[1] http://www.mail-archive.com/u-boot@lists.denx.de/msg108301.html
arch/arm/cpu/armv7/exynos/Makefile |4 ++
.../arm/cpu/armv7/exynos}/spl_boot.c | 33 +++
board/samsung/origen/Makefile |4 --
board/samsung/origen/mmc_boot.c| 58
---
board/samsung/smdk5250/Makefile|4 --
board/samsung/smdkv310/Makefile|4 --
board/samsung/smdkv310/mmc_boot.c | 60
include/configs/exynos5250-dt.h| 10 ++--
include/configs/origen.h | 21 +++
include/configs/smdkv310.h | 21 +++
10 files changed, 54 insertions(+), 165 deletions(-)
rename {board/samsung/smdk5250 =
arch/arm/cpu/armv7/exynos}/spl_boot.c (73%)
delete mode 100644 board/samsung/origen/mmc_boot.c
delete mode 100644 board/samsung/smdkv310/mmc_boot.c
Since this patch had wait too long on queue, need to rebase.
I'm sorry to late review.
diff --git a/arch/arm/cpu/armv7/exynos/Makefile
b/arch/arm/cpu/armv7/exynos/Makefile
index b9cf921..c507608 100644
--- a/arch/arm/cpu/armv7/exynos/Makefile
+++ b/arch/arm/cpu/armv7/exynos/Makefile
@@ -24,6 +24,10 @@ LIB = $(obj)lib$(SOC).o
COBJS += clock.o power.o soc.o system.o pinmux.o tzpc_init.o
+ifdef CONFIG_SPL_BUILD
+COBJS += spl_boot.o
+endif
+
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
diff --git a/board/samsung/smdk5250/spl_boot.c
b/arch/arm/cpu/armv7/exynos/spl_boot.c
similarity index 73%
rename from board/samsung/smdk5250/spl_boot.c
rename to arch/arm/cpu/armv7/exynos/spl_boot.c
index d8f3c1e..e970ff6 100644
--- a/board/samsung/smdk5250/spl_boot.c
+++ b/arch/arm/cpu/armv7/exynos/spl_boot.c
@@ -23,6 +23,8 @@
#includecommon.h
#includeconfig.h
+#define OM_STAT(0x1f 1)
+
enum boot_mode {
BOOT_MODE_MMC = 4,
BOOT_MODE_SERIAL = 20,
@@ -31,8 +33,6 @@ enum boot_mode {
BOOT_MODE_USB, /* Boot using USB download */
};
- typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
-
/*
* Copy U-boot from mmc to RAM:
* COPY_BL2_FNPTR_ADDR: Address in iRAM, which Contains
@@ -40,26 +40,37 @@ enum boot_mode {
*/
void copy_uboot_to_ram(void)
{
- spi_copy_func_t spi_copy;
enum boot_mode bootmode;
- u32 (*copy_bl2)(u32, u32, u32);
+ u32 (*copy_bl2)(u32, u32, u32) = NULL;
+ u32 offset = 0, size = 0;
- bootmode = readl(EXYNOS5_POWER_BASE) OM_STAT;
+ bootmode = readl(samsung_get_base_power()) OM_STAT;
switch (bootmode) {
+#ifdef CONFIG_SPI_BOOTING
Is this ifdef needs?
I introduced this ifdef because only exynos5250 has
EXYNOS_COPY_SPI_FNPTR_ADDR defined.
If i don't use this ifdef, It won't compile for origen, smdkv310 etc.
case BOOT_MODE_SERIAL:
- spi_copy = *(spi_copy_func_t
*)EXYNOS_COPY_SPI_FNPTR_ADDR;
- spi_copy(SPI_FLASH_UBOOT_POS, CONFIG_BL2_SIZE,
- CONFIG_SYS_TEXT_BASE);
+ offset = CONFIG_BL2_OFFSET - CONFIG_RES_BLOCK_SIZE;
+ size = CONFIG_BL2_SIZE;
+ copy_bl2 = (void *) *(u32 *)EXYNOS_COPY_SPI_FNPTR_ADDR;
break;
+#endif
case BOOT_MODE_MMC:
- copy_bl2 = (void *) *(u32 *)COPY_BL2_FNPTR_ADDR;
- copy_bl2(BL2_START_OFFSET, BL2_SIZE_BLOC_COUNT,
- CONFIG_SYS_TEXT_BASE);
+ offset = CONFIG_BL2_BLOCK_OFFSET;
+ size = CONFIG_BL2_SIZE_BLOCK_COUNT;
+
+
Re: [U-Boot] [PATCH 1/2] mx28evk: Convert to PHYLIB
On 07/06/2013 02:25, Fabio Estevam wrote: Hi Stefano, On Thu, Jun 6, 2013 at 9:04 PM, Fabio Estevam feste...@gmail.com wrote: From: Fabio Estevam fabio.este...@freescale.com Phylib framework is more appropriate for handling the PHYs, so let's use it on mx28evk. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Please discard this one for now. I found an issue with this one. Ok, thanks. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uboot ERROR nfs: Cannot umount error
Dear jinghui shi, please, can you post your messages just _once_ ? Thanks. In message ca+cqljef8f_5lseyw+jyo30oorpxfqyxquoqwim2crrnvnb...@mail.gmail.com you wrote: if there is a Cannot umount error(NetState = NETLOOP_FAIL), the net core does not call the halt function of the driver, that means the ethernet driver is still working. But before the loading(starting) of linux image, all DMA devices(my NIC is one of them) should be quieted. I wanted to know, Why we do not call ethernet driver's halt function if there was a Cannot umount error? It appears you have discovered a bug. As this happens only in the error handling branch of the code, it is no big surprise that this has not been detected before. But yes, this should be fixed. (I am so sorry that I do not know whether I send this mail to the right mail address, That's OK but you could / should have added the network custodian to the Cc: list - see [1] (I did this now). I couldn't find net or nfs's maintainer from u-boot/MAINTAINERS, it seems only boards' maintainers are there, Correct - the MAINTAINERS file lists only board maintainers. The U-Boot custodians are listed on the web page [1] so this mail to mail addresses contains in nfs.c and net.c. If it is wrong, and anyone knows the right ones, please give me a help, I will fix it. Thanks) Thanks for your report. [1] http://www.denx.de/wiki/U-Boot/Custodians 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 Why can you only have two doors on a chicken coop? If it had four it would be a chicken sedan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_bootm: Add command line arguments to Plan 9
Dear Steven Stallion,
In message 1370563140-31368-1-git-send-email-sstall...@gmail.com you wrote:
This patch introduces support for command line arguments to Plan 9.
Plan 9 generally dedicates a small region of kernel memory (known
as CONFADDR) for runtime configuration. A new environment variable
named confaddr was introduced to indicate this location when copying
arguments.
Please make this code configurable, so that people who never intend to
use Plan 9 do not suffer from the increased code size.
Then please run your patch through ckeckpatch - as is, this reports
two errors:
ERROR: do not use assignment in if condition
Finally:
+ if ((s = getenv(confaddr)) != NULL) {
+ char *confaddr = (char *)simple_strtoul(s, NULL, 16);
+
+ if (argc 2) {
+ int i;
+
+ s = confaddr;
+ for (i = 2; i argc; i++) {
+ if (i 2)
+ *s++ = '\n';
+ strcpy(s, argv[i]);
+ s += strlen(argv[i]);
+ }
+ } else if ((s = getenv(bootargs)) != NULL) {
+ strcpy(confaddr, s);
+ }
+ }
This design looks pretty much inconsistent and non-intuitive to me.
There is absolutely no length checking in this code. Is the size of
the available area truely unlimited? I doubt that...
Why do you make this (completely undocumented!!!) distinction between
bootm being used with one or more arguments? Why can you not
simply _always_ use bootargs ?
What if the user did not set the confaddr environment variable?
Then the memory reagion there is left uninitialized? Does this not
cause undefined behaviour when booting Plan 9?
And how does Plan 9 learn where to find this date? I cannot see how
you pass this address on to Plan 9?
Even worse - this code is actually pretty dangerous: confaddr is
neither a reserved name, nor is it in any way exotic enough to be sure
nobody else would use this in his environment. But if somebody does,
he will suddenly find that some (for him random) data is copied unex-
pectedly to that memory range. This may cause nasty crashes or other
undefined behaviour which is very difficult to debug.
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
Bus error -- please leave by the rear door.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] dfu: make data buffer size configurable
Dear Heiko, In message 51b17815.8060...@denx.de you wrote: and I see no longer the above error! So I see two solutions for my problem: - make DFU_DATA_BUF_SIZE in U-Boot smaller or configurable - make the timeout in dfu-util bigger or configurable I think we have just learned that the one-size-fits-all approach does not work for everybody. Actually both parameters should be configurable. 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 Artificial Intelligence is no match for natural stupidity. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot V4] spi/arm-pl022: Add support for ARM PL022 spi controller
This patch adds the support for the ARM PL022 SPI controller for the standard
variant (0x00041022), which has a 16bit wide and 8 locations deep TX/RX FIFO.
Signed-off-by: Armando Visconti armando.visco...@st.com
Signed-off-by: Vipin Kumar vipin.ku...@st.com
Acked-by: Stefan Roese s...@denx.de
---
v3-v4
Just removed all warnings when running checkpatch.
Didn't find Jagan's feedback... So, pls, let me know if we
need to change anything else...
Armando
drivers/spi/Makefile| 1 +
drivers/spi/pl022_spi.c | 310
2 files changed, 311 insertions(+)
create mode 100644 drivers/spi/pl022_spi.c
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index d08609e..b6443b1 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -47,6 +47,7 @@ COBJS-$(CONFIG_MXC_SPI) += mxc_spi.o
COBJS-$(CONFIG_MXS_SPI) += mxs_spi.o
COBJS-$(CONFIG_OC_TINY_SPI) += oc_tiny_spi.o
COBJS-$(CONFIG_OMAP3_SPI) += omap3_spi.o
+COBJS-$(CONFIG_PL022_SPI) += pl022_spi.o
COBJS-$(CONFIG_SOFT_SPI) += soft_spi.o
COBJS-$(CONFIG_SH_SPI) += sh_spi.o
COBJS-$(CONFIG_FSL_ESPI) += fsl_espi.o
diff --git a/drivers/spi/pl022_spi.c b/drivers/spi/pl022_spi.c
new file mode 100644
index 000..8a8b9ab
--- /dev/null
+++ b/drivers/spi/pl022_spi.c
@@ -0,0 +1,310 @@
+/*
+ * (C) Copyright 2012
+ * Armando Visconti, ST Microelectronics, armando.visco...@st.com.
+ *
+ * Driver for ARM PL022 SPI Controller. Based on atmel_spi.c
+ * by Atmel Corporation.
+ *
+ * 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 malloc.h
+#include spi.h
+#include asm/io.h
+#include asm/arch/hardware.h
+
+/* SSP registers mapping */
+struct pl022 {
+ u32 ssp_cr0;/* 0x000 */
+ u32 ssp_cr1;/* 0x004 */
+ u32 ssp_dr; /* 0x008 */
+ u32 ssp_sr; /* 0x00c */
+ u32 ssp_cpsr; /* 0x010 */
+ u32 ssp_imsc; /* 0x014 */
+ u32 ssp_ris;/* 0x018 */
+ u32 ssp_mis;/* 0x01c */
+ u32 ssp_icr;/* 0x020 */
+ u32 ssp_dmacr; /* 0x024 */
+ u8 reserved_1[0x080 - 0x028];
+ u32 ssp_itcr; /* 0x080 */
+ u32 ssp_itip; /* 0x084 */
+ u32 ssp_itop; /* 0x088 */
+ u32 ssp_tdr;/* 0x08c */
+ u8 reserved_2[0xFE0 - 0x090];
+ u32 ssp_pid0; /* 0xfe0 */
+ u32 ssp_pid1; /* 0xfe4 */
+ u32 ssp_pid2; /* 0xfe8 */
+ u32 ssp_pid3; /* 0xfec */
+ u32 ssp_cid0; /* 0xff0 */
+ u32 ssp_cid1; /* 0xff4 */
+ u32 ssp_cid2; /* 0xff8 */
+ u32 ssp_cid3; /* 0xffc */
+};
+
+/* SSP Control Register 0 - SSP_CR0 */
+#define SSP_CR0_SPO(0x1 6)
+#define SSP_CR0_SPH(0x1 7)
+#define SSP_CR0_8BIT_MODE (0x07)
+#define SSP_SCR_MAX(0xFF)
+#define SSP_SCR_SHFT 8
+
+/* SSP Control Register 0 - SSP_CR1 */
+#define SSP_CR1_MASK_SSE (0x1 1)
+
+#define SSP_CPSR_MAX (0xFE)
+
+/* SSP Status Register - SSP_SR */
+#define SSP_SR_MASK_TFE(0x1 0) /* Transmit FIFO empty */
+#define SSP_SR_MASK_TNF(0x1 1) /* Transmit FIFO not full */
+#define SSP_SR_MASK_RNE(0x1 2) /* Receive FIFO not empty */
+#define SSP_SR_MASK_RFF(0x1 3) /* Receive FIFO full */
+#define SSP_SR_MASK_BSY(0x1 4) /* Busy Flag */
+
+struct pl022_spi_slave {
+ struct spi_slave slave;
+ void *regs;
+ unsigned int freq;
+};
+
+static inline struct pl022_spi_slave *to_pl022_spi(struct spi_slave *slave)
+{
+ return container_of(slave, struct pl022_spi_slave, slave);
+}
+
+/*
+ * Following three functions should be provided by the
+ * board support package.
+ */
+int __weak spi_cs_is_valid(unsigned int bus, unsigned int cs)
+{
+ return 1;
+}
+
+void __weak spi_cs_activate(struct spi_slave *slave)
+{
+ /* do nothing */
+}
+
+void __weak spi_cs_deactivate(struct spi_slave *slave)
+{
+ /* do nothing */
+}
+
+void spi_init(void)
+{
+ /* do nothing */
+}
+
+/*
+ * ARM PL022 exists in different 'flavors'.
+ * This drivers currently support the standard variant (0x00041022),
Re: [U-Boot] pull request for u-boot-tegra/master into ARM/master
Hi Tom, On Thu, 6 Jun 2013 09:30:51 -0700, Tom Warren twarren.nvi...@gmail.com wrote: Albert, Please pull u-boot-tegra/master into ARM/master. Thanks! ./MAKEALL -s tegra AOK, checkpatch.pl is clean. The following changes since commit 4596dcc1d4ea5763e0f92cf5becd9fc7d4c6e674: am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c (2013-06-05 08:46:49 -0400) are available in the git repository at: git://git.denx.de/u-boot-tegra master for you to fetch changes up to dbc000bfb51eb30d786521e6b8e29048c36cbefa: ARM: tegra: only enable SCU on Tegra20 (2013-06-06 09:12:32 -0700) Tom Warren (1): ARM: tegra: only enable SCU on Tegra20 arch/arm/cpu/tegra-common/ap.c | 4 1 file changed, 4 insertions(+) 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] cmd_bootm: Add command line arguments to Plan 9
Dear Steven, please always keep the mailing list on Cc: - this is especially important for patch reviews, where such messages need to be picked up for patchwork, too. In message CAGGHmKHmLAd_85SgHyC=ceumhu8u4enqyj3wt3rqyvdzatw...@mail.gmail.com you wrote: Please make this code configurable, so that people who never intend to use Plan 9 do not suffer from the increased code size. This is already done, if you look at the do_bootm_plan9 function, you'll see it is guarded by CONFIG_BOOTM_PLAN9. These changes only affect users that are booting Plan 9. I see. Hm... I wonder which version of U-Boot your patch is against? The line numbers in your patch are off by at least 126 lines, and common/cmd_bootm.c has not been touched for many months ? ERROR: do not use assignment in if condition I noticed the errors, however the style and format of my changes are the same as those in other functions in cmd_bootm; do_bootm_netbsd probably being the closest example. I did not watch to introduce style drift. But we should not add more bad style code either. Feel free to send a cleanup patch for the existing code parts. In any case, do not add more such stuff. It's as unlimited as you have memory :-) That said, adjacent pages to CONFADDR are zeroed out at boot, so there is no possibility of overflow once you branch to the kernel. Adjacent pages being zeroed - that means that you _are_ actually limited to one page size? Why do you make this (completely undocumented!!!) distinction between bootm being used with one or more arguments? Why can you not simply _always_ use bootargs ? This is to support passing arguments via bootm. This behavior is consistent with NetBSD. ...which I consider a really weird desiign that IMO should not be followed without need. If you decide to do so nevertheless, then please 1) document the behaviour 2) factor out the common code instead of copying it What if the user did not set the confaddr environment variable? Then the memory reagion there is left uninitialized? Does this not cause undefined behaviour when booting Plan 9? There are checks which account for uninitialized memory at boot. It's ugly, but it's how the OS deals with configuration. I don't like it either. How does it detect if there are valid arguments (versus random crap) in the memory range starting at confaddr? I can see no checksum or similar? And how does Plan 9 learn where to find this date? I cannot see how you pass this address on to Plan 9? Like most things in Plan 9, it is a compiled offset (defined in mem.h). CONFADDR is fixed, so as long as the configuration is dumped to the right location (which can change between kernels), it will work. But then makes no sense to use a confaddr environment variable for this - the user has no real choice of setting this variable: either it matches the fixed CONFADDR value, in which case it works, or it is different, in which case it will silently fail. This is bad. I think you should use a CONFIG_SYS_CONFADDR constant instead. Even worse - this code is actually pretty dangerous: confaddr is neither a reserved name, nor is it in any way exotic enough to be sure nobody else would use this in his environment. But if somebody does, he will suddenly find that some (for him random) data is copied unex- pectedly to that memory range. This may cause nasty crashes or other undefined behaviour which is very difficult to debug. True, but it's no different than loadaddr. This only affects Plan 9 users, and this behavior will be documented for the kernels which support U-Boot. I don't think there is too much danger here, though documentation will be important. It is not documented in U-Boot. But actually I think this is void - using an envrionment variable here makes no sense in the first place. 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 To be is to program. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Hi Fabio, I have not come any further yet in finding the real cause. For now, I just tested with workarounds like lowering the ARP timeout and skipping the phy reset (or only reset for the 1st transfer). Note that also the phy reset and waiting for link-up takes about 2 seconds every time. I did not realise earlier that it would take this long, but this is the part before the TFTP from server... line is displayed and he transfer even starts. To my opinion, resetting the phy and restarting auto-negotiation before each transfer seems a bit overdone, especially if a number of transfers are started in a row. But since the MAC is also halted and restarted, perhaps a freshly started phy is recommended? Up till now, I have not seen too many timeouts during a transfer. But for the last weeks I've been testing mostly with smaller files and focused on the start of the transfer. Regards, Ruud -Oorspronkelijk bericht- Van: Fabio Estevam [mailto:feste...@gmail.com] Verzonden: vrijdag 7 juni 2013 2:16 Aan: Ruud Commandeur CC: U-Boot list; Marek Vašut; Stefano Babic Onderwerp: Re: [U-Boot] TFTP timeouts, i.mx fec problem? Hi Ruud, On Fri, May 31, 2013 at 3:56 AM, Ruud Commandeur rcommand...@clb.nl wrote: Hi everyone, I have been testing for a while now on the i.mx28 evk, and I noticed that almost all tftp transfers take some time before they actually start. It will show a 'T' as first character, then followed by '#' Besides the initial timeout you mentioned, I also see some timeouts during the kernel transfer. I have just sent two patches converting mx28evk to use phylib, but I still see the timeouts there. I see that in the kernel there is a workaround for LAN8270 low por mode and I will try it when I have a chance. Please let me know if you make any progress on this. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Booting ELF image of Integrity on p2041rdb using u-boot
Hello, According to README in /board/freescale/p2041rdb there are 2 files I should burn except uboot.bin: rcw.bin ucode.bin I tried to google those file names and found nothing. 1. Can you tell (a link will be great) what is the purpose of those files ? How should I create them ? Using u-boot I want to launch an ELF image of Integrity O.S from the NOR flash. 2. Are there any preconditions (h.w initializations in u-boot) for doing this ? 3. Should I use the device tree (p2041rdb.dtb) for booting Integrity ? Thank you in advance for your reply. Keep on the great work with u-boot !!! Best regards, Zvika ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Hi Ruud, Le Fri, 7 Jun 2013 11:28:54 +0200, Ruud Commandeur rcommand...@clb.nl a écrit : I have not come any further yet in finding the real cause. For now, I just tested with workarounds like lowering the ARP timeout and skipping the phy reset (or only reset for the 1st transfer). Note that also the phy reset and waiting for link-up takes about 2 seconds every time. I did not realise earlier that it would take this long, but this is the part before the TFTP from server... line is displayed and he transfer even starts. isn't your problem related to the fact that when you reset the PHY it samples some pins to get some settings and that after the first reset it could gets wrong settings because the i.MX pins are in a wrong state (because handled by the FEC) leading to the errors you meet ? Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/8] powerpc: spl: deleted unused symbol CONFIG_SPL_NAND_MINIMAL and introduced new symbol CONFIG_SPL_MINIMAL
From: Ying Zhang b40...@freescale.com
1. The symbol CONFIG_SPL_NAND_MINIMAL is unused, so deleted it.
2. Introduced a new symbol CONFIG_SPL_MINIMAL:
It is different from the common SPL. If set, only a
tiny part code of the SPL is built and to avoid unreferenced
functions. For example: mpc85xx nand SPL. It belongs to
minimal SPL, it's size is less than 4K.
Now, some functions were unused in the minimal SPL,
but it is useful in the common SPL. They can be avoid by
defining CONFIG_SPL_MINIMAL in minimal SPL.
Signed-off-by: Ying Zhang b40...@freescale.com
---
This patch is split from the previous patch spl: Make CONFIG_SPL_BUILD
contain more functionality
README |5 +
arch/powerpc/cpu/mpc85xx/tlb.c |2 +-
arch/powerpc/cpu/mpc8xxx/law.c |4 ++--
include/configs/MPC8313ERDB.h |2 +-
include/configs/P1022DS.h |4 +++-
include/configs/p1_p2_rdb_pc.h |4 +++-
6 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/README b/README
index e30e787..fbb50fb 100644
--- a/README
+++ b/README
@@ -2911,6 +2911,11 @@ FIT uImage format:
CONFIG_SPL_INIT_MINIMAL
Arch init code should be built for a very small image
+ CONFIG_SPL_MINIMAL
+ It is different from common SPL. if set, the SPL image
+ as small as possible, only a tiny part of the SPL code
+ is built.
+
CONFIG_SPL_LIBCOMMON_SUPPORT
Support for common/libcommon.o in SPL binary
diff --git a/arch/powerpc/cpu/mpc85xx/tlb.c b/arch/powerpc/cpu/mpc85xx/tlb.c
index 0dff37f..8d08b53 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_MINIMAL)
void read_tlbcam_entry(int idx, u32 *valid, u32 *tsize, unsigned long *epn,
phys_addr_t *rpn)
{
diff --git a/arch/powerpc/cpu/mpc8xxx/law.c b/arch/powerpc/cpu/mpc8xxx/law.c
index 6f9d568..b6d5554 100644
--- a/arch/powerpc/cpu/mpc8xxx/law.c
+++ b/arch/powerpc/cpu/mpc8xxx/law.c
@@ -92,7 +92,7 @@ void disable_law(u8 idx)
return;
}
-#if !defined(CONFIG_NAND_SPL) !defined(CONFIG_SPL_BUILD)
+#if !defined(CONFIG_NAND_SPL) !defined(CONFIG_SPL_MINIMAL)
static int get_law_entry(u8 i, struct law_entry *e)
{
u32 lawar;
@@ -122,7 +122,7 @@ int set_next_law(phys_addr_t addr, enum law_size sz, enum
law_trgt_if id)
return idx;
}
-#if !defined(CONFIG_NAND_SPL) !defined(CONFIG_SPL_BUILD)
+#if !defined(CONFIG_NAND_SPL) !defined(CONFIG_SPL_MINIMAL)
int set_last_law(phys_addr_t addr, enum law_size sz, enum law_trgt_if id)
{
u32 idx;
diff --git a/include/configs/MPC8313ERDB.h b/include/configs/MPC8313ERDB.h
index c28dfe0..934f7ac 100644
--- a/include/configs/MPC8313ERDB.h
+++ b/include/configs/MPC8313ERDB.h
@@ -40,13 +40,13 @@
#define CONFIG_SPL_INIT_MINIMAL
#define CONFIG_SPL_SERIAL_SUPPORT
#define CONFIG_SPL_NAND_SUPPORT
-#define CONFIG_SPL_NAND_MINIMAL
#define CONFIG_SPL_FLUSH_IMAGE
#define CONFIG_SPL_TARGET u-boot-with-spl.bin
#define CONFIG_SPL_MPC83XX_WAIT_FOR_NAND
#ifdef CONFIG_SPL_BUILD
#define CONFIG_NS16550_MIN_FUNCTIONS
+#define CONFIG_SPL_MINIMAL
#endif
#define CONFIG_SYS_TEXT_BASE 0x0010 /* CONFIG_SYS_NAND_U_BOOT_DST */
diff --git a/include/configs/P1022DS.h b/include/configs/P1022DS.h
index 69412e4..238aa77 100644
--- a/include/configs/P1022DS.h
+++ b/include/configs/P1022DS.h
@@ -41,7 +41,6 @@
#define CONFIG_SPL_INIT_MINIMAL
#define CONFIG_SPL_SERIAL_SUPPORT
#define CONFIG_SPL_NAND_SUPPORT
-#define CONFIG_SPL_NAND_MINIMAL
#define CONFIG_SPL_FLUSH_IMAGE
#define CONFIG_SPL_TARGET u-boot-with-spl.bin
@@ -55,6 +54,9 @@
#define CONFIG_SYS_NAND_U_BOOT_START 0x0020
#define CONFIG_SYS_NAND_U_BOOT_OFFS0
#define CONFIG_SYS_LDSCRIPT
arch/powerpc/cpu/mpc85xx/u-boot-nand.lds
+#ifdef CONFIG_SPL_BUILD
+#define CONFIG_SPL_MINIMAL
+#endif
#endif
/* High Level Configuration Options */
diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
index 7ed634b..99a55fb 100644
--- a/include/configs/p1_p2_rdb_pc.h
+++ b/include/configs/p1_p2_rdb_pc.h
@@ -159,7 +159,6 @@
#define CONFIG_SPL_INIT_MINIMAL
#define CONFIG_SPL_SERIAL_SUPPORT
#define CONFIG_SPL_NAND_SUPPORT
-#define CONFIG_SPL_NAND_MINIMAL
#define CONFIG_SPL_FLUSH_IMAGE
#define CONFIG_SPL_TARGET u-boot-with-spl.bin
@@ -187,6 +186,9 @@
#define CONFIG_SYS_NAND_U_BOOT_SIZE((512 10) - 0x2000)
#define CONFIG_SYS_NAND_U_BOOT_OFFS0
#define CONFIG_SYS_LDSCRIPT
arch/powerpc/cpu/mpc85xx/u-boot-nand.lds
+#ifdef CONFIG_SPL_BUILD
+#define CONFIG_SPL_MINIMAL
+#endif
#endif
#ifndef CONFIG_SYS_TEXT_BASE
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
[U-Boot] [PATCH 6/8 v2] spl: env_common.c: make CONFIG_SPL_BUILD contain function env_import
From: Ying Zhang b40...@freescale.com
The functionality env_import will be used in the SPL. They
had been excluded by ifndef CONFIG_SPL_BUILD. Now, put it
into the SPL.
Signed-off-by: Ying Zhang b40...@freescale.com
---
Compared with the previous version, split into two separate patches.
this pactch only enables function env_import in SPL.
common/env_common.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/common/env_common.c b/common/env_common.c
index 906b41f..8cb81e9 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -156,7 +156,6 @@ int set_default_vars(int nvars, char * const vars[])
H_NOCLEAR | H_INTERACTIVE, nvars, vars);
}
-#ifndef CONFIG_SPL_BUILD
/*
* Check if CRC is valid and (if yes) import the environment.
* Note that buf may or may not be aligned.
@@ -188,7 +187,6 @@ int env_import(const char *buf, int check)
return 0;
}
-#endif
void env_relocate(void)
{
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/8] powerpc/p1022ds: boot from spi flash with SPL
From: Ying Zhang b40...@freescale.com
Support to boot from spi flash.
This patch is on top of the patch:
powerpc/p1022ds: boot from SD Card with SPL
Signed-off-by: Ying Zhang b40...@freescale.com
---
board/freescale/p1022ds/spl.c | 12 +-
drivers/mtd/spi/Makefile |1 +
drivers/mtd/spi/fsl_espi_spl.c | 79
drivers/mtd/spi/spi_flash.c|2 +
include/configs/P1022DS.h | 36 +++
5 files changed, 121 insertions(+), 9 deletions(-)
create mode 100644 drivers/mtd/spi/fsl_espi_spl.c
diff --git a/board/freescale/p1022ds/spl.c b/board/freescale/p1022ds/spl.c
index 40f000f..1dd9050 100644
--- a/board/freescale/p1022ds/spl.c
+++ b/board/freescale/p1022ds/spl.c
@@ -21,13 +21,12 @@
#include common.h
#include ns16550.h
-#include asm/fsl_law.h
-#include asm/fsl_ddr_sdram.h
#include malloc.h
#include mmc.h
#include i2c.h
#include ../common/ngpixis.h
#include fsl_esdhc.h
+#include spi_flash.h
DECLARE_GLOBAL_DATA_PTR;
@@ -54,6 +53,11 @@ void board_init_f(ulong bootflag)
setbits_be32(gur-pmuxcr,
in_be32(gur-pmuxcr) | MPC85xx_PMUXCR_SD_DATA);
+#ifdef CONFIG_SPL_SPI_BOOT
+ /* Enable the SPI */
+ clrsetbits_8(pixis-brdcfg0, PIXIS_ELBC_SPI_MASK, PIXIS_SPI);
+#endif
+
/* Read back the register to synchronize the write. */
in_be32(gur-pmuxcr);
@@ -67,6 +71,8 @@ void board_init_f(ulong bootflag)
bus_clk / 16 / CONFIG_BAUDRATE);
#ifdef CONFIG_SPL_MMC_BOOT
puts(\nSD boot...\n);
+#elif defined(CONFIG_SPL_SPI_BOOT)
+ puts(\nSPI Flash boot...\n);
#endif
/* copy code to RAM and jump to it - this should not return */
@@ -108,5 +114,7 @@ void board_init_r(gd_t *gd, ulong dest_addr)
#ifdef CONFIG_SPL_MMC_BOOT
mmc_boot();
+#elif defined(CONFIG_SPL_SPI_BOOT)
+ spi_boot();
#endif
}
diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
index 90f8392..5f130d5 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -27,6 +27,7 @@ LIB := $(obj)libspi_flash.o
ifdef CONFIG_SPL_BUILD
COBJS-$(CONFIG_SPL_SPI_LOAD) += spi_spl_load.o
+COBJS-$(CONFIG_SPL_SPI_BOOT) += fsl_espi_spl.o
endif
COBJS-$(CONFIG_SPI_FLASH) += spi_flash.o
diff --git a/drivers/mtd/spi/fsl_espi_spl.c b/drivers/mtd/spi/fsl_espi_spl.c
new file mode 100644
index 000..75ffc8a
--- /dev/null
+++ b/drivers/mtd/spi/fsl_espi_spl.c
@@ -0,0 +1,79 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * 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 spi_flash.h
+#include malloc.h
+
+#define ESPI_BOOT_IMAGE_SIZE 0x48
+#define ESPI_BOOT_IMAGE_ADDR 0x50
+#define CONFIG_CFG_DATA_SECTOR 0
+
+/*
+ * The main entry for SPI booting. It's necessary that SDRAM is already
+ * configured and available since this code loads the main U-Boot image
+ * from SPI into SDRAM and starts it from there.
+ */
+void spi_boot(void)
+{
+ void (*uboot)(void) __noreturn;
+ u32 offset, code_len, i;
+ unsigned char *buf = NULL;
+ struct spi_flash *flash;
+
+ flash = spi_flash_probe(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS,
+ CONFIG_ENV_SPI_MAX_HZ, CONFIG_ENV_SPI_MODE);
+ if (flash == NULL) {
+ puts(\nspi_flash_probe failed);
+ hang();
+ }
+
+ /*
+ * Load U-Boot image from SPI flash into RAM
+ */
+ buf = malloc(flash-page_size);
+ if (buf == NULL) {
+ puts(\nmalloc failed);
+ hang();
+ }
+ memset(buf, 0, flash-page_size);
+
+ spi_flash_read(flash, CONFIG_CFG_DATA_SECTOR, \
+ flash-page_size, (void *)buf);
+ offset = *(u32 *)(buf + ESPI_BOOT_IMAGE_ADDR);
+ /* Skip spl code */
+ offset += CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS;
+ /* Get the code size from offset 0x48 */
+ code_len = *(u32 *)(buf + ESPI_BOOT_IMAGE_SIZE);
+ /* Skip spl code */
+ code_len = code_len - CONFIG_SPL_MAX_SIZE;
+ /* copy code to DDR */
+ spi_flash_read(flash, offset, code_len, \
+ (void *)CONFIG_SYS_SPI_FLASH_U_BOOT_DST);
+ /*
+ * Jump to U-Boot image
+ */
+
[U-Boot] [PATCH 2/8 v2] powerpc/mpc85xx: modify the functionality clear_bss and aligning the end address of the BSS
From: Ying Zhang b40...@freescale.com
There will clear the BSS in the function clear_bss(), the reset address of
the BSS started from the __bss_start, and increased by four-byte increments,
finally stoped depending on the address is equal to the _bss_end. If the end
address __bss_end is not alignment to 4byte, it will be an infinite loop.
1. The reset action stoped depending on the reset address is greater
than or equal the end address of the BSS.
2. The end address of the BSS should be 4byte aligned. Because the reset unit
is 4 Bytes.
This patch is on top of the patch powerpc/mpc85xx: support application
without resetvec segment in the linker script.
Signed-off-by: Ying Zhang b40...@freescale.com
---
Compared with the previous version, add explicit alignment of the BSS start
address.
arch/powerpc/cpu/mpc85xx/start.S|2 +-
arch/powerpc/cpu/mpc85xx/u-boot-spl.lds |2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index 4f0480b..2657982 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -1795,7 +1795,7 @@ clear_bss:
stw r0,0(r3)
addir3,r3,4
cmplw 0,r3,r4
- bne 5b
+ blt 5b
6:
mr r3,r9 /* Init Data pointer*/
diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
index c613e58..5c7c598 100644
--- a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
+++ b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
@@ -89,10 +89,12 @@ SECTIONS
*/
. |= 0x10;
+ . = ALIGN(4);
__bss_start = .;
.bss : {
*(.sbss*)
*(.bss*)
}
+ . = ALIGN(4);
__bss_end = .;
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: DRA7: Add Maintainer
Adding Maintainer for DRA7xx. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- MAINTAINERS |4 1 file changed, 4 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index d86f0f1..2f4ea84 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -960,6 +960,10 @@ Hugo Villeneuve hugo.villene...@lyrtech.com SFFSDR ARM926EJS +Lokesh Vutla lokeshvu...@ti.com + + dra7xx_evm ARM ARMV7 (DRA7xx Soc) + Matt Waddel matt.wad...@linaro.org ca9x4_ct_vxpARM ARMV7 (Quad Core) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] ARM: add SMP support for non-secure switch
Hi, experts: Do these patch code exist in current u-boot code base? Or, i have to download linaro version uboot? Best wishes, -邮件原件- 发件人: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] 代表 Andre Przywara 发送时间: 2013年5月31日 17:33 收件人: Christoffer Dall 抄送: geoff.lev...@linaro.org; cd...@cs.columbia.edu; peter.mayd...@linaro.org; ag...@suse.de; marc.zyng...@arm.com; tr...@ti.com; kvm...@lists.cs.columbia.edu; u-boot@lists.denx.de 主题: Re: [U-Boot] [PATCH 4/6] ARM: add SMP support for non-secure switch On 05/31/2013 07:32 AM, Christoffer Dall wrote: On Mon, May 06, 2013 at 03:17:48PM +0200, Andre Przywara 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/include/asm/armv7.h| 1 + arch/arm/lib/virt-v7.c | 9 - include/configs/vexpress_ca15_tc2.h | 1 + 4 files changed, 36 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index e63e892..02234c7 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -575,8 +575,19 @@ fiq: #ifdef CONFIG_ARMV7_VIRT /* 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 instead of this subtle abuse of lr, why not make this routine simply take a parameter? How would this work if this is called out of SMP pen? Shall I rely on the registers being zero, then? Not very stable, I guess. I think this whole routine is special anyways, so I felt this subtle abuse is OK. An option would be to set r0 to 1 in the smp_pen path and pass 0 as the first parameter when calling from C. But then I'd need to save this value - possibly in the LR register ;-) I also slightly object against wrapping the _smp_pen around the _nonsec_gic_switch, I really think these are separate routines, where one can just call the other...? The actual routine and the purpose are the same, just the entry and exit code is different. So this fitted nicely in here. I can add a more specific comment on the different entry points. _nonsec_gic_switch: mrc p15, 4, r2, c15, c0, 0 @ r2 = PERIPHBASE add r3, r2, #0x1000 @ GIC dist i/f offset @@ -617,5 +628,19 @@ _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 I think I raised this issue previously, but this code is in a core u-boot file, but I could imagine a board with a different crazy boot protocol that required you to check two different fields and jump through other hoops to wake up from the smp pen, so I really think the whole smp pen belongs in a board specific place. Right, but I didn't want to do this prematurely without knowing what is really needed. So my plan is to refactor this when adding Arndale support. I think this is special
[U-Boot] [PATCH] Origen: Set FIMD as the default display path
On EXYNOS4210, there are three paths for display data to be processed,
namely MIE, MDNIE and FIMD. On Origen board, FIMD display controller
is used.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
This patch is rebased on master branch of u-boot-samsung tree.
board/samsung/origen/lowlevel_init.S | 13 +
board/samsung/origen/origen_setup.h |7 +++
2 files changed, 20 insertions(+)
diff --git a/board/samsung/origen/lowlevel_init.S
b/board/samsung/origen/lowlevel_init.S
index be9d418..a7ea680 100644
--- a/board/samsung/origen/lowlevel_init.S
+++ b/board/samsung/origen/lowlevel_init.S
@@ -89,6 +89,7 @@ lowlevel_init:
bl uart_asm_init
bl arch_cpu_init
bl tzpc_init
+ bl display_init
pop {pc}
wakeup_reset:
@@ -96,6 +97,7 @@ wakeup_reset:
bl mem_ctrl_asm_init
bl arch_cpu_init
bl tzpc_init
+ bl display_init
exit_wakeup:
/* Load return address and jump to kernel */
@@ -355,3 +357,14 @@ uart_asm_init:
nop
nop
+/* Setting default display path to FIMD */
+display_init:
+ push{lr}
+ ldr r0, =EXYNOS4_SYSREG_BASE
+
+ /* DISPLAY_CONTROL */
+ ldr r1, =DISPLAY_CONTROL_VAL
+ ldr r2, =DISPLAY_CONTROL_OFFSET
+ str r1, [r0, r2]
+
+ pop {pc}
diff --git a/board/samsung/origen/origen_setup.h
b/board/samsung/origen/origen_setup.h
index 926a4cc..b0e1bc2 100644
--- a/board/samsung/origen/origen_setup.h
+++ b/board/samsung/origen/origen_setup.h
@@ -83,6 +83,8 @@
#define VPLL_CON0_OFFSET 0xC120
#define VPLL_CON1_OFFSET 0xC124
+#define DISPLAY_CONTROL_OFFSET 0x210
+
/* DMC: DRAM Controllor Register offsets */
#define DMC_CONCONTROL 0x00
#define DMC_MEMCONTROL 0x04
@@ -485,6 +487,11 @@
| (VPLL_MRR 24) \
| (VPLL_MFR 16) \
| (VPLL_K 0))
+
+/* DISPLAY_CONTROL */
+#define FIMDBYPASS_LBLK0 0x1
+#define DISPLAY_CONTROL_VAL(FIMDBYPASS_LBLK0 1)
+
/*
* UART GPIO_A0/GPIO_A1 Control Register Value
* 0x2: UART Function
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Add Arndale board support
Dear Minkyu Kang, Thanks for the comments. On 21 May 2013 18:23, Minkyu Kang mk7.k...@samsung.com wrote: On 26/03/13 18:37, Inderpal Singh wrote: The Arndale board is based on samsung's exynos5250 SOC. First patch just removes the redundant SPI configs from common exynos5250 config file. Second patch moves the board specific configs to board specific config file. The third adds the andale board support. This patchset depends on [1] for tzpc initialization, on [2] for copying u-boot to RAM from spl, and on first 6 patches of [3] for mmc support. [1] http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/156168 [2] http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/156272 [3] http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/155368 Inderpal Singh (3): exynos5250: remove redundant SPI related configs exynos5250: move board specific configs to board specific config file exynos5250: Add arndale board support MAINTAINERS |4 + board/samsung/arndale/Makefile | 54 +++ board/samsung/arndale/arndale.c | 117 ++ board/samsung/arndale/arndale_spl.c | 66 +++ board/samsung/arndale/clock_init.c | 655 ++ board/samsung/arndale/clock_init.h | 149 +++ board/samsung/arndale/dmc_common.c | 199 + board/samsung/arndale/dmc_init_ddr3.c| 228 +++ board/samsung/arndale/lowlevel_init.S| 92 + board/samsung/arndale/setup.h| 569 ++ board/samsung/dts/exynos5250-arndale.dts | 36 ++ boards.cfg |1 + include/configs/arndale.h| 39 ++ include/configs/exynos5250-dt.h | 29 +- include/configs/smdk5250.h | 12 +- include/configs/snow.h | 12 +- tools/Makefile |2 + 17 files changed, 2232 insertions(+), 32 deletions(-) create mode 100644 board/samsung/arndale/Makefile create mode 100644 board/samsung/arndale/arndale.c create mode 100644 board/samsung/arndale/arndale_spl.c create mode 100644 board/samsung/arndale/clock_init.c create mode 100644 board/samsung/arndale/clock_init.h create mode 100644 board/samsung/arndale/dmc_common.c create mode 100644 board/samsung/arndale/dmc_init_ddr3.c create mode 100644 board/samsung/arndale/lowlevel_init.S create mode 100644 board/samsung/arndale/setup.h create mode 100644 board/samsung/dts/exynos5250-arndale.dts create mode 100644 include/configs/arndale.h Patch 1,2 looks good. But please rebase. Ok. I will rebase and send it again. please split patch 3 to another patchset. And please check Wolfgang's review. Ok, I will split the 3rd patch into another patchset and incorporate the review comments. With Regards, Inder Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Origen: Set FIMD as the default display path
On EXYNOS4210, there are three paths for display data to be processed,
namely MIE, MDNIE and FIMD. On Origen board, FIMD display controller
is used.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
This patch is rebased on master branch of u-boot-samsung tree.
board/samsung/origen/lowlevel_init.S | 13 +
board/samsung/origen/origen_setup.h |7 +++
2 files changed, 20 insertions(+)
diff --git a/board/samsung/origen/lowlevel_init.S
b/board/samsung/origen/lowlevel_init.S
index be9d418..a7ea680 100644
--- a/board/samsung/origen/lowlevel_init.S
+++ b/board/samsung/origen/lowlevel_init.S
@@ -89,6 +89,7 @@ lowlevel_init:
bl uart_asm_init
bl arch_cpu_init
bl tzpc_init
+ bl display_init
pop {pc}
wakeup_reset:
@@ -96,6 +97,7 @@ wakeup_reset:
bl mem_ctrl_asm_init
bl arch_cpu_init
bl tzpc_init
+ bl display_init
exit_wakeup:
/* Load return address and jump to kernel */
@@ -355,3 +357,14 @@ uart_asm_init:
nop
nop
+/* Setting default display path to FIMD */
+display_init:
+ push{lr}
+ ldr r0, =EXYNOS4_SYSREG_BASE
+
+ /* DISPLAY_CONTROL */
+ ldr r1, =DISPLAY_CONTROL_VAL
+ ldr r2, =DISPLAY_CONTROL_OFFSET
+ str r1, [r0, r2]
+
+ pop {pc}
diff --git a/board/samsung/origen/origen_setup.h
b/board/samsung/origen/origen_setup.h
index 926a4cc..b0e1bc2 100644
--- a/board/samsung/origen/origen_setup.h
+++ b/board/samsung/origen/origen_setup.h
@@ -83,6 +83,8 @@
#define VPLL_CON0_OFFSET 0xC120
#define VPLL_CON1_OFFSET 0xC124
+#define DISPLAY_CONTROL_OFFSET 0x210
+
/* DMC: DRAM Controllor Register offsets */
#define DMC_CONCONTROL 0x00
#define DMC_MEMCONTROL 0x04
@@ -485,6 +487,11 @@
| (VPLL_MRR 24) \
| (VPLL_MFR 16) \
| (VPLL_K 0))
+
+/* DISPLAY_CONTROL */
+#define FIMDBYPASS_LBLK0 0x1
+#define DISPLAY_CONTROL_VAL(FIMDBYPASS_LBLK0 1)
+
/*
* UART GPIO_A0/GPIO_A1 Control Register Value
* 0x2: UART Function
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] exynos5250: move board specific configs to board specific config file
Not all boards based on exynos5250 have SPI flash, same serial port and might not require display and the same lds script. Hence move them to board specific config file. Signed-off-by: Inderpal Singh inderpal.si...@linaro.org --- v1 was posted as the second patch of [1] Changes in v2: - split from the patchset at [1] - moved CONFIG_LCD and CONFIG_SPI_FLASH - rebased to latest u-boot-samsung master branch [1] http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/157101 include/configs/exynos5250-dt.h | 11 +-- include/configs/smdk5250.h | 16 ++-- include/configs/snow.h | 16 ++-- 3 files changed, 29 insertions(+), 14 deletions(-) diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index 03b07b2..22e47eb 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -29,7 +29,6 @@ #define CONFIG_SAMSUNG /* in a SAMSUNG core */ #define CONFIG_S5P /* S5P Family */ #define CONFIG_EXYNOS5 /* which is in a Exynos5 Family */ -#define CONFIG_SMDK5250/* which is in a SMDK5250 */ #include asm/arch/cpu.h /* get chip and board defs */ @@ -78,7 +77,6 @@ #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (4 20)) /* select serial console configuration */ -#define CONFIG_SERIAL3 /* use SERIAL 3 */ #define CONFIG_BAUDRATE115200 #define EXYNOS5_DEFAULT_UART_OFFSET0x01 @@ -148,8 +146,6 @@ #define CONFIG_SPL #define COPY_BL2_FNPTR_ADDR0x02020030 -/* specific .lds file */ -#define CONFIG_SPL_LDSCRIPTboard/samsung/smdk5250/smdk5250-uboot-spl.lds #define CONFIG_SPL_TEXT_BASE 0x02023400 #define CONFIG_SPL_MAX_FOOTPRINT (14 * 1024) @@ -158,7 +154,7 @@ /* Miscellaneous configurable options */ #define CONFIG_SYS_LONGHELP/* undef to save memory */ #define CONFIG_SYS_HUSH_PARSER /* use hush command parser*/ -#define CONFIG_SYS_PROMPT SMDK5250 # +#define CONFIG_SYS_PROMPT EXYNOS5250 # #define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ #define CONFIG_SYS_PBSIZE 384 /* Print Buffer Size */ #define CONFIG_SYS_MAXARGS 16 /* max number of command args */ @@ -198,7 +194,6 @@ /* FLASH and environment organization */ #define CONFIG_SYS_NO_FLASH #undef CONFIG_CMD_IMLS -#define CONFIG_IDENT_STRING for SMDK5250 #define CONFIG_SYS_MMC_ENV_DEV 0 @@ -247,9 +242,6 @@ #define CONFIG_I2C_EDID /* SPI */ -#define CONFIG_ENV_IS_IN_SPI_FLASH -#define CONFIG_SPI_FLASH - #ifdef CONFIG_SPI_FLASH #define CONFIG_EXYNOS_SPI #define CONFIG_CMD_SF @@ -306,7 +298,6 @@ #define CONFIG_SHA256 /* Display */ -#define CONFIG_LCD #ifdef CONFIG_LCD #define CONFIG_EXYNOS_FB #define CONFIG_EXYNOS_DP diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h index 81f83a8..4af1909 100644 --- a/include/configs/smdk5250.h +++ b/include/configs/smdk5250.h @@ -25,9 +25,21 @@ #ifndef __CONFIG_SMDK_H #define __CONFIG_SMDK_H -#include configs/exynos5250-dt.h - #undef CONFIG_DEFAULT_DEVICE_TREE #define CONFIG_DEFAULT_DEVICE_TREE exynos5250-smdk5250 +#define CONFIG_SMDK5250/* which is in a SMDK5250 */ +#define CONFIG_SERIAL3 /* use SERIAL 3 */ + +/* specific .lds file */ +#define CONFIG_SPL_LDSCRIPTboard/samsung/smdk5250/smdk5250-uboot-spl.lds +#define CONFIG_IDENT_STRING for SMDK5250 +#define CONFIG_SPI_FLASH +#define CONFIG_ENV_IS_IN_SPI_FLASH + +/* Display */ +#define CONFIG_LCD + +#include configs/exynos5250-dt.h + #endif /* __CONFIG_SMDK_H */ diff --git a/include/configs/snow.h b/include/configs/snow.h index b8460fd..e940c69 100644 --- a/include/configs/snow.h +++ b/include/configs/snow.h @@ -25,9 +25,21 @@ #ifndef __CONFIG_SNOW_H #define __CONFIG_SNOW_H -#include configs/exynos5250-dt.h - #undef CONFIG_DEFAULT_DEVICE_TREE #define CONFIG_DEFAULT_DEVICE_TREE exynos5250-snow +#define CONFIG_SMDK5250/* which is in a SMDK5250 */ +#define CONFIG_SERIAL3 /* use SERIAL 3 */ + +/* specific .lds file */ +#define CONFIG_SPL_LDSCRIPTboard/samsung/smdk5250/smdk5250-uboot-spl.lds +#define CONFIG_IDENT_STRING for SMDK5250 +#define CONFIG_SPI_FLASH +#define CONFIG_ENV_IS_IN_SPI_FLASH + +/* Display */ +#define CONFIG_LCD + +#include configs/exynos5250-dt.h + #endif /* __CONFIG_SNOW_H */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] exynos5250: remove redundant SPI and PMIC related configs
They have been defined once already. Hence remove the redundant definitions. Signed-off-by: Inderpal Singh inderpal.si...@linaro.org --- v1 was posted as the first patch of [1] Changes in v2: - split from the patchset at [1] - removed redundant configs for PMIC - rebased to latest u-boot-samsung master branch [1] http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/157101 include/configs/exynos5250-dt.h | 26 -- 1 file changed, 26 deletions(-) diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index 62b83d4..03b07b2 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -246,11 +246,6 @@ #define CONFIG_SYS_I2C_SLAVE0x0 #define CONFIG_I2C_EDID -/* PMIC */ -#define CONFIG_PMIC -#define CONFIG_PMIC_I2C -#define CONFIG_PMIC_MAX77686 - /* SPI */ #define CONFIG_ENV_IS_IN_SPI_FLASH #define CONFIG_SPI_FLASH @@ -278,27 +273,6 @@ #define CONFIG_POWER_I2C #define CONFIG_POWER_MAX77686 -/* SPI */ -#define CONFIG_ENV_IS_IN_SPI_FLASH -#define CONFIG_SPI_FLASH - -#ifdef CONFIG_SPI_FLASH -#define CONFIG_EXYNOS_SPI -#define CONFIG_CMD_SF -#define CONFIG_CMD_SPI -#define CONFIG_SPI_FLASH_WINBOND -#define CONFIG_SF_DEFAULT_MODE SPI_MODE_0 -#define CONFIG_SF_DEFAULT_SPEED5000 -#define EXYNOS5_SPI_NUM_CONTROLLERS5 -#endif - -#ifdef CONFIG_ENV_IS_IN_SPI_FLASH -#define CONFIG_ENV_SPI_MODESPI_MODE_0 -#define CONFIG_ENV_SECT_SIZE CONFIG_ENV_SIZE -#define CONFIG_ENV_SPI_BUS 1 -#define CONFIG_ENV_SPI_MAX_HZ 5000 -#endif - /* Ethernet Controllor Driver */ #ifdef CONFIG_CMD_NET #define CONFIG_SMC911X -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/2] Add Arndale board support
The Arndale board is based on samsung's exynos5250 SOC. This patchset depends on basic clean up patch at [1]. First patch provides the basic arndale board support. The second patch adds the MMC support to arndale and it depends on the first 6 patches of [2] for dwmmc support. Changes in v2: - split from earlier patchset at [3] as per Minkyu - Removed checkpatch errors pointed out by Wolfgang - rebased to latest u-boot-samsung master branch - created mmc_boot.c to remove dependency on consolidation patch at [4] - split the mmc support to new patch as it depends on [2] [1] http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/162883 [2] http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/159887 [3] http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/157101 [4] http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/156272 Inderpal Singh (2): exynos5250: Add arndale board support exynos5250: arndale: Add mmc support MAINTAINERS |4 + board/samsung/arndale/Makefile | 58 +++ board/samsung/arndale/arndale.c | 117 ++ board/samsung/arndale/arndale_spl.c | 66 +++ board/samsung/arndale/clock_init.c | 655 ++ board/samsung/arndale/clock_init.h | 149 +++ board/samsung/arndale/dmc_common.c | 199 + board/samsung/arndale/dmc_init_ddr3.c| 228 +++ board/samsung/arndale/lowlevel_init.S| 92 + board/samsung/arndale/mmc_boot.c | 58 +++ board/samsung/arndale/setup.h| 569 ++ board/samsung/dts/exynos5250-arndale.dts | 36 ++ boards.cfg |1 + include/configs/arndale.h| 39 ++ tools/Makefile |2 + 15 files changed, 2273 insertions(+) create mode 100644 board/samsung/arndale/Makefile create mode 100644 board/samsung/arndale/arndale.c create mode 100644 board/samsung/arndale/arndale_spl.c create mode 100644 board/samsung/arndale/clock_init.c create mode 100644 board/samsung/arndale/clock_init.h create mode 100644 board/samsung/arndale/dmc_common.c create mode 100644 board/samsung/arndale/dmc_init_ddr3.c create mode 100644 board/samsung/arndale/lowlevel_init.S create mode 100644 board/samsung/arndale/mmc_boot.c create mode 100644 board/samsung/arndale/setup.h create mode 100644 board/samsung/dts/exynos5250-arndale.dts create mode 100644 include/configs/arndale.h -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] exynos5250: arndale: Add mmc support
This patch adds mmc support to the arndale board.
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
board/samsung/arndale/arndale.c | 14 ++
board/samsung/dts/exynos5250-arndale.dts | 18 ++
2 files changed, 32 insertions(+)
diff --git a/board/samsung/arndale/arndale.c b/board/samsung/arndale/arndale.c
index 627583b..7f8a568 100644
--- a/board/samsung/arndale/arndale.c
+++ b/board/samsung/arndale/arndale.c
@@ -22,6 +22,7 @@
#include common.h
#include asm/arch/pinmux.h
+#include asm/arch/dwmmc.h
#include asm/arch/power.h
DECLARE_GLOBAL_DATA_PTR;
@@ -64,6 +65,19 @@ void dram_init_banksize(void)
}
}
+#ifdef CONFIG_GENERIC_MMC
+int board_mmc_init(bd_t *bis)
+{
+ int ret;
+ /* dwmmc initializattion for available channels */
+ ret = exynos_dwmmc_init(gd-fdt_blob);
+ if (ret)
+ debug(dwmmc init failed\n);
+
+ return ret;
+}
+#endif
+
static int board_uart_init(void)
{
int err, uart_id, ret = 0;
diff --git a/board/samsung/dts/exynos5250-arndale.dts
b/board/samsung/dts/exynos5250-arndale.dts
index b6ca4d9..9b4d6b2 100644
--- a/board/samsung/dts/exynos5250-arndale.dts
+++ b/board/samsung/dts/exynos5250-arndale.dts
@@ -15,4 +15,22 @@
/ {
model = SAMSUNG Arndale board based on EXYNOS5250;
compatible = samsung,arndale, samsung,exynos5250;
+
+ mmc@1220 {
+ samsung,bus-width = 8;
+ samsung,timing = 1 3 3;
+ };
+
+ mmc@1221 {
+ status = disabled;
+ };
+
+ mmc@1222 {
+ samsung,bus-width = 4;
+ samsung,timing = 1 2 3;
+ };
+
+ mmc@1223 {
+ status = disabled;
+ };
};
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/7] Add cros-ec protocol driver and enable it in smdk5250
On Wed, May 15, 2013 at 06:27:27PM +0800, Hung-ying Tyan wrote: This patch series adds the drivers for the cros-ec protocol that is used to communicate with the Chrome OS Embedded Controller (EC). The series also enables its use in Google Snow which is based on smdk5250. The last patch in this series depends on the patch in the MMC series that brings in exynos5-dt.c: http://patchwork.ozlabs.org/patch/240084. And that patch is part 6 of 9 in a big series that needs to come in via u-boot-samsung. Minkyu, where's all that at? 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] [PATCH] cfi_flash: Fix detection of 8-bit bus flash devices via address shift
We had a problem detecting 8/16bit flash devices connected only via
8bits to the SoC for quite a while. Commit 239cb9d9
[mtd: cfi_flash: Fix CFI flash driver for 8-bit bus support] finally
fixed this 8-bit bus support. But also broke some other boards using
this cfi driver. So this patch had to be reverted.
I spotted a different, simpler approach for this 8-bit bus support
on the barebox mailing list posted by
Oleksij Rempel bug-tr...@fisher-privat.net:
http://www.spinics.net/lists/u-boot-v2/msg14687.html
Here the commit text:
Many cfi chips support 16 and 8 bit modes. Most important
difference is use of so called Q15/A-1 pin. In 16bit mode this
pin is used for data IO. In 8bit mode, it is an address input
which add one more least significant bit (LSB). In this case
we should shift all adresses by one:
For example 0xaa 1 = 0x154
This patch now is a port of this barebox patch to U-Boot.
Along with the change w.r.t from barebox,
Some flash chips can support multiple bus widths, override the
interface width and limit it to the port width.
Tested on 16-bit Spansion flash on sequoia.
Tested 8-bit flashes like 256M29EW, 512M29EW.
Signed-off-by: Stefan Roese s...@denx.de
Tested-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
drivers/mtd/cfi_flash.c | 37 +
include/flash.h | 2 ++
2 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 22d8440..e23e394 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -212,7 +212,7 @@ flash_map (flash_info_t * info, flash_sect_t sect, uint
offset)
{
unsigned int byte_offset = offset * info-portwidth;
- return (void *)(info-start[sect] + byte_offset);
+ return (void *)(info-start[sect] + (byte_offset info-chip_lsb));
}
static inline void flash_unmap(flash_info_t *info, flash_sect_t sect,
@@ -1892,12 +1892,27 @@ static int __flash_detect_cfi (flash_info_t * info,
struct cfi_qry *qry)
flash_read_cfi(info, qry, FLASH_OFFSET_CFI_RESP,
sizeof(struct cfi_qry));
info-interface = le16_to_cpu(qry-interface_desc);
+ /* Some flash chips can support multiple bus widths.
+* In this case, override the interface width and
+* limit it to the port width.
+*/
+ if ((info-interface == FLASH_CFI_X8X16)
+ (info-portwidth == FLASH_CFI_8BIT)) {
+ debug(Overriding 16-bit interface width to
+8-bit port width\n);
+ info-interface = FLASH_CFI_X8;
+ } else if ((info-interface == FLASH_CFI_X16X32)
+ (info-portwidth == FLASH_CFI_16BIT)) {
+ debug(Overriding 16-bit interface width to
+16-bit port width\n);
+ info-interface = FLASH_CFI_X16;
+ }
info-cfi_offset = flash_offset_cfi[cfi_offset];
debug (device interface is %d\n,
info-interface);
- debug (found port %d chip %d ,
- info-portwidth, info-chipwidth);
+ debug(found port %d chip %d chip_lsb %d ,
+ info-portwidth, info-chipwidth, info-chip_lsb);
debug (port %d bits chip %d bits\n,
info-portwidth CFI_FLASH_SHIFT_WIDTH,
info-chipwidth CFI_FLASH_SHIFT_WIDTH);
@@ -1937,9 +1952,23 @@ static int flash_detect_cfi (flash_info_t * info, struct
cfi_qry *qry)
info-portwidth = FLASH_CFI_64BIT; info-portwidth = 1) {
for (info-chipwidth = FLASH_CFI_BY8;
info-chipwidth = info-portwidth;
-info-chipwidth = 1)
+info-chipwidth = 1) {
+ /*
+* First, try detection without shifting the addresses
+* for 8bit devices (16bit wide connection)
+*/
+ info-chip_lsb = 0;
+ if (__flash_detect_cfi(info, qry))
+ return 1;
+
+ /*
+* Not detected, so let's try with shifting
+* for 8bit devices
+*/
+ info-chip_lsb = 1;
if (__flash_detect_cfi(info, qry))
return 1;
+ }
}
debug (not found\n);
return 0;
diff --git a/include/flash.h b/include/flash.h
index
Re: [U-Boot] [PATCH] cmd_bootm: Add command line arguments to Plan 9
On Fri, Jun 7, 2013 at 1:16 AM, Wolfgang Denk w...@denx.de wrote: In message CAGGHmKHmLAd_85SgHyC= ceumhu8u4enqyj3wt3rqyvdzatw...@mail.gmail.com you wrote: Please make this code configurable, so that people who never intend to use Plan 9 do not suffer from the increased code size. This is already done, if you look at the do_bootm_plan9 function, you'll see it is guarded by CONFIG_BOOTM_PLAN9. These changes only affect users that are booting Plan 9. I see. Hm... I wonder which version of U-Boot your patch is against? The line numbers in your patch are off by at least 126 lines, and common/cmd_bootm.c has not been touched for many months ? That's odd. I just double checked and my repository seems to be in sync. I'll do some poking around to make sure I didn't miss something. ERROR: do not use assignment in if condition I noticed the errors, however the style and format of my changes are the same as those in other functions in cmd_bootm; do_bootm_netbsd probably being the closest example. I did not watch to introduce style drift. But we should not add more bad style code either. Feel free to send a cleanup patch for the existing code parts. In any case, do not add more such stuff. Will do. It's as unlimited as you have memory :-) That said, adjacent pages to CONFADDR are zeroed out at boot, so there is no possibility of overflow once you branch to the kernel. Adjacent pages being zeroed - that means that you _are_ actually limited to one page size? Why do you make this (completely undocumented!!!) distinction between bootm being used with one or more arguments? Why can you not simply _always_ use bootargs ? This is to support passing arguments via bootm. This behavior is consistent with NetBSD. ...which I consider a really weird desiign that IMO should not be followed without need. If you decide to do so nevertheless, then please 1) document the behaviour 2) factor out the common code instead of copying it Hmm. Are you arguing against supporting command line arguments to bootm, or that bootm should copy these arguments to bootargs prior to boot? This has actually been very useful to test changes without having to update my bootargs environment variable. Where is the best place to document the behavior, README? The code looks as though it's common, but unfortunately it's not. plan9.ini(8) requires that arguments be terminated with a newline, the NetBSD loader uses spaces. What if the user did not set the confaddr environment variable? Then the memory reagion there is left uninitialized? Does this not cause undefined behaviour when booting Plan 9? There are checks which account for uninitialized memory at boot. It's ugly, but it's how the OS deals with configuration. I don't like it either. How does it detect if there are valid arguments (versus random crap) in the memory range starting at confaddr? I can see no checksum or similar? Some ports (such as OMAP) will stop once it encounters the first non-ASCII character. In general, the parsing for the configuration is fairly strict and is only a small risk if a user configures the system incorrectly. There is also something subtle in not specifying confaddr (or bootargs for that matter). Many ports support loading configuration from a FAT file system. U-Boot would be no different. I realize this probably seems very foreign. Plan 9 is somewhat unique in that it relies on a variety of loaders. Some are more intelligent than others, but in the end, configuration has to be dropped in a known location for the kernel to parse. There is no second-stage loader, so passing a pointer has limited utility since the code to parse the config happens after the MMU has been initialized. And how does Plan 9 learn where to find this date? I cannot see how you pass this address on to Plan 9? Like most things in Plan 9, it is a compiled offset (defined in mem.h). CONFADDR is fixed, so as long as the configuration is dumped to the right location (which can change between kernels), it will work. But then makes no sense to use a confaddr environment variable for this - the user has no real choice of setting this variable: either it matches the fixed CONFADDR value, in which case it works, or it is different, in which case it will silently fail. This is bad. I think you should use a CONFIG_SYS_CONFADDR constant instead. Ah, this is another subtlety. CONFADDR can change depending on the kernel you are booting. Some ports use as much as 64K to store configuration. Having to recompile U-Boot and reflash based on a kernel change would add a lot of complication and frustration. Having confaddr also makes it somewhat simpler to write a generic boot command which will do a fatload rather than use bootargs. Even worse - this code is actually pretty dangerous: confaddr is neither a reserved name, nor is it in any way exotic enough to be sure nobody else would
Re: [U-Boot] [PATCH 5/8] powerpc: spl: deleted unused symbol CONFIG_SPL_NAND_MINIMAL and introduced new symbol CONFIG_SPL_MINIMAL
On 06/07/2013 04:25:17 AM, ying.zh...@freescale.com wrote: diff --git a/README b/README index e30e787..fbb50fb 100644 --- a/README +++ b/README @@ -2911,6 +2911,11 @@ FIT uImage format: CONFIG_SPL_INIT_MINIMAL Arch init code should be built for a very small image + CONFIG_SPL_MINIMAL + It is different from common SPL. if set, the SPL image + as small as possible, only a tiny part of the SPL code + is built. How is this different from CONFIG_SPL_INIT_MINIMAL? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/8] sf: winbond: Update the names for W25Q 0x40XX ID's flash parts
On Thu, Jun 6, 2013 at 11:02 AM, Michal Simek mon...@monstr.eu wrote: move this discussion back to mailing list. On 06/05/2013 05:56 PM, Jagan Teki wrote: And are your ok with below representation for common id's parts ? + .name = W25Q80BL/W25Q80BV, + .name = W25Q16CL/W25Q16DV, + .name = W25Q32BV/W25Q32FV_SPI, + .name = W25Q64CV/W25Q64FV_SPI, + .name = W25Q128BV/W25Q128FV_SPI, + .name = W25Q32DW/W25Q32FV_QPI, + .name = W25Q64DW/W25Q64FV_QPI, + .name = W25Q128FW/W25Q128FV_QPI, Any comments on above representation of part names, as the id's to these pairs are common. This will enhance u-boot sf to support all parts from winbond, but seems like different view of names. what's the difference between that parts? parts were diff in terms of voltages and sone SPI and QPI configurations. but from the manufacture defeat, pair of parts were same ID's ok. Does software care if it is W25G80BL or BV? Or software behaviour is the same and there is only difference in voltage or so. SW is same even if it 1.8 or 3.3 v. The only reason for giving the pair of names to support all different parts You are supporting them but you are just not list them. I don't care about it so much but it is increase u-boot size. Why does u-boot size increase, is it because of below representation on name filed = W25Q80BL/W25Q80BV Just because of longer names which go probably to rodata section. It is not a problem for me at all. OK, I can go ahead to applied these. Let me know for any more concerns. -- Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] SPL: Makefile: Build a separate autoconf.mk for SPL
On Tue, May 28, 2013 at 06:51:47PM -0500, Joel A Fernandes wrote: SPL defines CONFIG_SPL_BUILD but this does not percolate to the autoconf.mk Makefile. As a result the build breaks when CONFIG_SPL_BUILD is used in the board-specific include header file. With this, there is a possibility of having a CONFIG option defined in the header file but not defined in the Makefile causing all kinds of build failure and problems. It also messes things for up, for example, when one might want to undefine options to keep the SPL small and doesn't want to be stuck with the CONFIG options used for U-boot. Lastly, this also avoids defining special CONFIG_SPL_ variables for cases where some options are required in U-boot but not in SPL. We add a spl-autoconf.mk rule that is generated for SPL with the CONFIG_SPL_BUILD flag and conditionally include it for SPL builds. v2 changes: Fixed issue where builds in a different directory were failing. Suggested-by: Muddegowda, Deepak x0171...@ti.com . Thanks Deepak! Reported-by: Tom Rini tr...@ti.com Signed-off-by: Joel A Fernandes joelag...@ti.com Cc: Muddegowda, Deepak x0171...@ti.com Cc: Tom Rini tr...@ti.com This breaks building of am335x_evm_usbspl :( 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
Re: [U-Boot] generic_board: reduce the redundancy of gd_t struct members
On Mon, May 27, 2013 at 12:37:30AM -, Masahiro Yamada wrote: This commit refactors common/board_f.c and common/board_r.c in order to delete the dest_addr and dest_addr_sp from gd_t struct. As mentioned as follows in include/asm-generic/global_data.h, /* TODO: is this the same as relocaddr, or something else? */ unsigned long dest_addr;/* Post-relocation address of U-Boot */ dest_addr is the same as relocaddr. Likewise, dest_addr_sp is the same as start_addr_sp. It seemed dest_addr/dest_addr_sp was used only as a scratch variable to calculate relocaddr/start_addr_sp, respectively. With a little refactoring, we can delete dest_addr and dest_addr_sp. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Simon Glass s...@chromium.org 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] fdt: remove unaligned access in fdt_fixup_ethernet()
On Mon, May 27, 2013 at 06:01:19PM -, Stephen Warren wrote: Some ARM compilers may emit code that makes unaligned accesses when faced with constructs such as: char mac[16] = ethaddr; Replace this with a strcpy() call instead to avoid this. strcpy() is used here, rather than replacing all usage of the mac variable with the string itself, since the loop itself sprintf()s to the variable each iteration, so strcpy() is doing basically the same thing. Reported-by: Florian Meier Signed-off-by: Stephen Warren swar...@wwwdotorg.org 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] input: Finish simplifing key_matrix_decode_fdt()
On Thu, Jun 06, 2013 at 10:49:32AM -0400, Tom Rini wrote: From: Stephen Warren swar...@nvidia.com [trini: Applied v1 of the series rather than v2, this commit is the delta from v1 to v2] Signed-off-by: Stephen Warren swar...@nvidia.com Signed-off-by: Tom Rini tr...@ti.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] [PATCHv3 0/6] Falcon boot mode for spl_mmc
On Mon, May 13, 2013 at 08:36:24PM +0200, Peter Korsgaard wrote:
This patch series adds falcon boot mode for MMC (raw and FAT), similar to
the existing nand support.
As an example, it adds falcon boot support for the am335x evm board, which
is the platform that has been used to test the series (FAT and raw).
Changes since V2:
- Drop RFC and adjust am335x nand MTDPARTS_DEFAULT settings according to
Tom Rini's feedback.
Changes since V1:
- Adjusted am335x parameters according to Tom Rini's feedback. Added spl
command for easy kernel parameter area snapshot creation.
Peter Korsgaard (6):
spl_mmc: return error from mmc_load_image_{raw,fat} rather than
hanging
spl_mmc: mmc_load_image_fat(): Add filename argument and move fat
init out
spl_mmc: add Falcon mode support for FAT variant
spl_mmc: mmc_load_image_raw(): Add sector argument
spl_mmc: add Falcon mode support for raw variant
am335x: enable falcon boot mode for mmc (raw and fat) and nand
README | 18 +
board/ti/am335x/board.c |9 +
drivers/mmc/spl_mmc.c| 91
++
include/configs/am335x_evm.h | 30 --
4 files changed, 119 insertions(+), 29 deletions(-)
Applied to u-boot/master, with the following additional patch:
From b6144dfce98c6a893a411052256b81b5afc6e5c4 Mon Sep 17 00:00:00 2001
From: Tom Rini tr...@ti.com
Date: Fri, 7 Jun 2013 14:16:43 -0400
Subject: [PATCH 1/1] devkit8000: Add SPL_OS for MMC support
Signed-off-by: Tom Rini tr...@ti.com
---
include/configs/devkit8000.h |8
1 file changed, 8 insertions(+)
diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
index 788227d..3b74d7c 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -360,6 +360,14 @@
#define CONFIG_CMD_SPL_NAND_OFS (CONFIG_SYS_NAND_SPL_KERNEL_OFFS+\
0x40)
#define CONFIG_SYS_NAND_SPL_KERNEL_OFFS 0x28
+
+#define CONFIG_SPL_FAT_LOAD_KERNEL_NAMEuImage
+#define CONFIG_SPL_FAT_LOAD_ARGS_NAME args
+
+#define CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR0x500 /* address
0xa */
+#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR 0x8 /* address 0x1000 */
+#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS 8 /* 4KB */
+
#define CONFIG_SYS_SPL_ARGS_ADDR(PHYS_SDRAM_1 + 0x100)
#endif /* __CONFIG_H */
--
1.7.9.5
Otherwise this series breaks building of devkit8000.
--
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] pci: introduce CONFIG_PCI_INDIRECT_BRIDGE option
On Thu, May 30, 2013 at 07:06:12AM -, Gabor Juhos wrote: The pci_indirect.c file is always compiled when CONFIG_PCI is defined although the indirect PCI bridge support is not needed by every board. Introduce a new CONFIG_PCI_INDIRECT_BRIDGE config option and only compile indirect PCI bridge support if this options is enabled. Also add the new option into the configuration files of the boards which needs that. 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] checkpatch.pl: Add 'printf' to logFunctions
On Thu, Jun 06, 2013 at 09:28:49AM -0400, Tom Rini wrote:
Signed-off-by: Tom Rini tr...@ti.com
---
tools/checkpatch.pl |1 +
1 file changed, 1 insertion(+)
diff --git a/tools/checkpatch.pl b/tools/checkpatch.pl
index 9f23901..896e2bc 100755
--- a/tools/checkpatch.pl
+++ b/tools/checkpatch.pl
@@ -273,6 +273,7 @@ our $logFunctions = qr{(?x:
WARN(?:_RATELIMIT|_ONCE|)|
panic|
debug|
+ printf|
MODULE_[A-Z_]+
)};
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] Pull request: nand flash
On Thu, Jun 06, 2013 at 11:33:47AM -0500, Scott Wood wrote: The following changes since commit d6639d10dbfa42dc888f8917012550b632a88959: Merge branch 'master' of git://git.denx.de/u-boot-nand-flash (2013-05-31 18:28:47 -0400) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git master for you to fetch changes up to 4bfd0002b653dfc9f9ddd8e9a4ce0acd40bde3ac: bug, nand, am33xx: nand-ecc.strength not set in board_nand_init() (2013-06-04 11:50:04 -0500) Sergey Lapin (1): bug, nand, am33xx: nand-ecc.strength not set in board_nand_init() drivers/mtd/nand/omap_gpmc.c |2 ++ 1 file changed, 2 insertions(+) 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] am33xx/omap4+: Move SRAM_SCRATCH_SPACE_ADDR to asm/arch/omap.h
On Thu, Jun 06, 2013 at 09:19:31AM -0400, Tom Rini wrote: The location of valid scratch space is dependent on SoC, so move that there. On OMAP4+ we continue to use SRAM_SCRATCH_SPACE_ADDR. On am33xx/ti814x we want to use what the ROM defines as public stack which is the area after our defined download image space. Correct the comment about and location of CONFIG_SPL_TEXT_BASE. Signed-off-by: Tom Rini tr...@ti.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] Pull request: u-boot-video/master
On Thu, Jun 06, 2013 at 12:38:23AM +0200, Anatolij Gustschin wrote: Hey Tom, The following changes since commit 5ed6f447af60aabd2669d913f673793c1ce48f47: P1022DS: Set CONFIG_SPL_MAX_SIZE directly (2013-05-03 09:19:43 -0400) are available in the git repository at: git://git.denx.de/u-boot-video.git master for you to fetch changes up to ea697ae7eb059d7467c6854ce562c31df510eb59: ARM: bcm2835: add simplefb DT node during bootz/m (2013-06-05 22:40:38 +0200) Eric Nelson (1): cfb_console: flush FB cache at end of public functions Stephen Warren (2): lcd: add functions to set up simplefb device tree ARM: bcm2835: add simplefb DT node during bootz/m board/raspberrypi/rpi_b/rpi_b.c| 14 +++- common/lcd.c | 87 .../video/simple-framebuffer.txt | 25 ++ drivers/video/cfb_console.c| 15 ++-- include/configs/rpi_b.h|2 + include/lcd.h |3 + 6 files changed, 139 insertions(+), 7 deletions(-) create mode 100644 doc/device-tree-bindings/video/simple-framebuffer.txt 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] pull request: u-boot-arm/master
On Wed, Jun 05, 2013 at 05:02:02PM +0200, Albert ARIBAUD wrote: Hello Tom, The following changes since commit 3da0e5750b24a9491058df6126c7be577a276c09: arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to 4596dcc1d4ea5763e0f92cf5becd9fc7d4c6e674: am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c (2013-06-05 08:46:49 -0400) Tom Rini (3): omap-common/hwinit-common.c: Mark omap_rev_string as static am33xx: Correct NON_SECURE_SRAM_START/END am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c arch/arm/cpu/armv7/omap-common/boot-common.c | 39 arch/arm/cpu/armv7/omap-common/hwinit-common.c | 38 +-- arch/arm/include/asm/arch-am33xx/omap.h |4 +-- arch/arm/include/asm/arch-am33xx/sys_proto.h |1 + arch/arm/include/asm/arch-omap4/sys_proto.h|1 + arch/arm/include/asm/arch-omap5/sys_proto.h|1 + board/isee/igep0033/board.c|9 ++ board/phytec/pcm051/board.c|9 ++ board/ti/am335x/board.c|9 ++ board/ti/ti814x/evm.c |9 ++ include/configs/am335x_evm.h | 10 -- include/configs/igep0033.h | 10 -- include/configs/pcm051.h | 10 -- 13 files changed, 105 insertions(+), 45 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
[U-Boot] Please pull u-boot-ti/master
Hello,
The following changes since commit 3da0e5750b24a9491058df6126c7be577a276c09:
arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-ti.git master
for you to fetch changes up to 80dd596d1b442ff53dbeb33eccdb8efd2283be79:
arm: da830: moved pinmux configurations to the arch tree (2013-06-07 14:26:08
-0400)
Andrii Tseglytskyi (2):
OMAP3+: introduce generic ABB support
OMAP5: add ABB setup for MPU voltage domain
Balaji T K (1):
mmc: omap_hsmmc: Update pbias programming
Joel A Fernandes (1):
am33xx: Board: Make CPSW section of ethernet initialization depend on
CPSW driver
Lokesh Vutla (10):
ARM: OMAP4+: Cleanup header files
ARM: OMAP2+: Rename asm/arch/clocks.h asm/arch/clock.h
ARM: OMAP4+: pmic: Make generic bus init and write functions
ARM: DRA7xx: Add control id code for DRA7xx
ARM: DRA7xx: power Add support for tps659038 PMIC
ARM: DRA7xx: clocks: Fixing i2c_init for PMIC
ARM: DRA7xx: Do not enable srcomp for DRA7xx Soc's
ARM: DRA7xx: Update pinmux data
ARM: DRA7xx: clocks: Update PLL values
ARM: DRA7: Add Maintainer
Lubomir Popov (4):
OMAP5: Fix bug in omap5_es1_prcm struct
ARM: OMAP5: Power: Add more functionality to Palmas driver
ARM: OMAP: I2C: New read, write and probe functions
OMAP5: Enable access to auxclk registers
Michael Trimarchi (1):
usb: omap: ulpi: fix ulpi transceiver access
Nishanth Menon (1):
ARM: OMAP5: DRA7xx: support class 0 optimized voltages
Sricharan R (5):
ARM: OMAP5: clocks: Do not enable sgx clocks
ARM: DRA7xx: Change the Debug UART to UART1
ARM: DRA7xx: Correct the SYS_CLK to 20MHZ
ARM: DRA7xx: Correct SRAM END address
ARM: DRA7xx: EMIF: Change settings required for EVM board
Tom Rini (4):
omap-common/hwinit-common.c: Mark omap_rev_string as static
am33xx: Correct NON_SECURE_SRAM_START/END
am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c
arm: Remove OMAP2420H4 and all omap24xx support
Vishwanathrao Badarkhe, Manish (2):
da830: add MMC support
arm: da830: moved pinmux configurations to the arch tree
MAINTAINERS|8 +-
arch/arm/cpu/arm1136/start.S | 18 -
arch/arm/cpu/arm926ejs/davinci/Makefile|1 +
arch/arm/cpu/arm926ejs/davinci/da830_pinmux.c | 151
arch/arm/cpu/armv7/omap-common/Makefile|1 +
arch/arm/cpu/armv7/omap-common/abb.c | 137
arch/arm/cpu/armv7/omap-common/boot-common.c | 39 +
arch/arm/cpu/armv7/omap-common/clocks-common.c | 101 ++-
arch/arm/cpu/armv7/omap-common/emif-common.c | 28 +-
arch/arm/cpu/armv7/omap-common/hwinit-common.c | 40 +-
arch/arm/cpu/armv7/omap-common/timer.c |1 +
arch/arm/cpu/armv7/omap-common/vc.c| 14 +-
arch/arm/cpu/armv7/omap3/clock.c |2 +-
arch/arm/cpu/armv7/omap4/hw_data.c | 13 +-
arch/arm/cpu/armv7/omap4/prcm-regs.c |3 +
arch/arm/cpu/armv7/omap5/Makefile |1 +
arch/arm/cpu/armv7/omap5/abb.c | 67 ++
arch/arm/cpu/armv7/omap5/hw_data.c | 167 ++--
arch/arm/cpu/armv7/omap5/hwinit.c | 24 +-
arch/arm/cpu/armv7/omap5/prcm-regs.c | 20 +
arch/arm/cpu/armv7/omap5/sdram.c | 170 +++-
arch/arm/include/asm/arch-am33xx/omap.h|4 +-
arch/arm/include/asm/arch-am33xx/sys_proto.h |1 +
arch/arm/include/asm/arch-davinci/pinmux_defs.h| 15 +-
arch/arm/include/asm/arch-omap24xx/bits.h | 48 --
arch/arm/include/asm/arch-omap24xx/clocks.h| 112 ---
arch/arm/include/asm/arch-omap24xx/i2c.h | 68 --
arch/arm/include/asm/arch-omap24xx/mem.h | 156
arch/arm/include/asm/arch-omap24xx/mux.h | 176
arch/arm/include/asm/arch-omap24xx/omap2420.h | 236 --
arch/arm/include/asm/arch-omap24xx/sys_info.h | 82 --
arch/arm/include/asm/arch-omap24xx/sys_proto.h | 54 --
.../include/asm/arch-omap3/{clocks.h = clock.h} |0
arch/arm/include/asm/arch-omap3/omap3.h|7 +
.../include/asm/arch-omap4/{clocks.h = clock.h} | 34 +-
arch/arm/include/asm/arch-omap4/cpu.h | 12 -
arch/arm/include/asm/arch-omap4/omap.h | 22 +-
arch/arm/include/asm/arch-omap4/sys_proto.h|6 +-
.../include/asm/arch-omap5/{clocks.h = clock.h} | 91 +-
arch/arm/include/asm/arch-omap5/cpu.h | 12 -
arch/arm/include/asm/arch-omap5/mux_dra7xx.h |7 +-
arch/arm/include/asm/arch-omap5/omap.h | 67 +-
arch/arm/include/asm/arch-omap5/sys_proto.h|8
Re: [U-Boot] [PATCH] cmd_bootm: Add command line arguments to Plan 9
Dear Steven, In message cagghmkh2nsdoqjbrucb5xjsjcuoyfco6cz8msjtxdshh6p6...@mail.gmail.com you wrote: Hmm. Are you arguing against supporting command line arguments to bootm, or that bootm should copy these arguments to bootargs prior to boot? This has actually been very useful to test changes without having to update my bootargs environment variable. bootm has a well-known an documented API: it takes up to three arguments: kernel address, ramdisk address, and device tree address. Nothing else. If you want to implement a different interface, this should at least be documented - but then I doubt if this should be named bootm. If I use it with 3 arguments, I expect the well-known behaviour, on all systems. Where is the best place to document the behavior, README? The code looks as though it's common, but unfortunately it's not. plan9.ini(8) requires that arguments be terminated with a newline, the NetBSD loader uses spaces. A readme in doc/ is OK, too. How does it detect if there are valid arguments (versus random crap) in the memory range starting at confaddr? I can see no checksum or similar? Some ports (such as OMAP) will stop once it encounters the first non-ASCII character. In general, the parsing for the configuration is fairly strict and is only a small risk if a user configures the system incorrectly. Hm. This is just a subterfuge for there is no security at all, and you are invoking undefined behaviour ... There is also something subtle in not specifying confaddr (or bootargs for that matter). Many ports support loading configuration from a FAT file system. U-Boot would be no different. I don't see what this has to do with it? But then makes no sense to use a confaddr environment variable for this - the user has no real choice of setting this variable: either it matches the fixed CONFADDR value, in which case it works, or it is different, in which case it will silently fail. This is bad. I think you should use a CONFIG_SYS_CONFADDR constant instead. Ah, this is another subtlety. CONFADDR can change depending on the kernel you are booting. Some ports use as much as 64K to store configuration. Having to recompile U-Boot and reflash based on a kernel change would add a lot of complication and frustration. Having confaddr also makes it somewhat simpler to write a generic boot command which will do a fatload rather than use bootargs. You have no way to check for valid data, and you have no way to know the correct address, because it is neither fixed nor known to both the producer and the consumer? I'm sorry, but this is crap. Is there a better method to allow confaddr to change without forcing a re-compile, or duplication if a user decides to do a fatload rather than define bootargs? I'm sorry, but it appears this design is completely borked, so how should I answer this? If you have no way to know the correct adddress, and the consumer has no way to verify the data it recives, it's all just trial and error. Not exactly a robust design, that is. --485b395e78db9b448d04de92b574 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable div dir=3DltrOn Fri, Jun 7, 2013 at 1:16 AM, Wolfgang Denk span dir=3D= ltrlt;a href=3Dmailto:w...@denx.de; target=3D_blankw...@denx.de/agt= ;/span wrote:brdiv class=3Dgmail_extradiv class=3Dgmail_quoteb= lockquote class=3Dgmail_quote style=3Dmargin:0 0 0 .8ex;border-left:1px = #ccc solid;padding-left:1ex Can you PLEASE stop sending HTML? Thanks. 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 All men should freely use those seven words which have the power to make any marriage run smoothly: You know dear, you may be right. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_bootm: Add command line arguments to Plan 9
On Fri, Jun 7, 2013 at 2:57 PM, Wolfgang Denk w...@denx.de wrote: Dear Steven, In message cagghmkh2nsdoqjbrucb5xjsjcuoyfco6cz8msjtxdshh6p6...@mail.gmail.com you wrote: Hmm. Are you arguing against supporting command line arguments to bootm, or that bootm should copy these arguments to bootargs prior to boot? This has actually been very useful to test changes without having to update my bootargs environment variable. bootm has a well-known an documented API: it takes up to three arguments: kernel address, ramdisk address, and device tree address. Nothing else. Is there a reason that this should only be used by Linux? The changes I have submitted follow the same behavior as NetBSD. VxWorks and QNX also have their own quirks that don't follow the same path/usage as Linux. If you want to implement a different interface, this should at least be documented - but then I doubt if this should be named bootm. If I use it with 3 arguments, I expect the well-known behaviour, on all systems. The usage seems to indicate this is a valid approach: Usage: bootm [addr [arg ...]] If this is such a contentious change, I'm happy to drop it. I was following the NetBSD approach since it was the most similar. It would be a shame to let it go - it's useful. Some ports (such as OMAP) will stop once it encounters the first non-ASCII character. In general, the parsing for the configuration is fairly strict and is only a small risk if a user configures the system incorrectly. Hm. This is just a subterfuge for there is no security at all, and you are invoking undefined behaviour ... This would only happen if a user did not configure the loader appropriately. There is also something subtle in not specifying confaddr (or bootargs for that matter). Many ports support loading configuration from a FAT file system. U-Boot would be no different. I don't see what this has to do with it? Plan 9 was traditionally loaded from FAT on PC architectures. Much of that support still exists today. Typically, a small FAT partition exists, which houses the kernel and the configuration (plan9.ini). With U-Boot, to emulate this behavior a fatload would be issued to copy the file to the proper location. This allows users to modify their configuration and reboot without having to drop into the U-Boot shell. If do_plan9_bootm writes a NUL byte if no bootargs are defined, this would break the fatload method. Ah, this is another subtlety. CONFADDR can change depending on the kernel you are booting. Some ports use as much as 64K to store configuration. Having to recompile U-Boot and reflash based on a kernel change would add a lot of complication and frustration. Having confaddr also makes it somewhat simpler to write a generic boot command which will do a fatload rather than use bootargs. You have no way to check for valid data, and you have no way to know the correct address, because it is neither fixed nor known to both the producer and the consumer? I'm sorry, but this is crap. It's known to both the producer and consumer, but can change during development. Having it compiled in also means that you do not have quick access to the value to use for a fatload, though this is a minor annoyance. Is there a better method to allow confaddr to change without forcing a re-compile, or duplication if a user decides to do a fatload rather than define bootargs? I'm sorry, but it appears this design is completely borked, so how should I answer this? If you have no way to know the correct adddress, and the consumer has no way to verify the data it recives, it's all just trial and error. Not exactly a robust design, that is. It's a known address for known kernels but needs to have the flexibility to change without a recompile. Personal feelings aside, this is how the kernel handles configuration at boot - I can only do so much. I very much want these changes (or an acceptable version of them) to go upstream. Most users tend to just hack up U-Boot for the boards they use and maintain private forks, but I would like to see better support in both directions. I'm happy to keep a fork, but these changes do not seem onerous, especially given that other operating systems that are already supported follow this exact behavior. Cheers, Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/16] sf: Update sf to support all sizes of flashes
Hi Jagan,
On Fri, May 31, 2013 at 5:52 AM, Jagannadha Sutradharudu Teki
jagannadha.sutradharudu-t...@xilinx.com wrote:
Updated the spi_flash framework to handle all sizes of flashes
using bank/extd addr reg facility
The current implementation in spi_flash supports 3-byte address mode
due to this up to 16Mbytes amount of flash is able to access for those
flashes which has an actual size of 16MB.
As most of the flashes introduces a bank/extd address registers
for accessing the flashes in 16Mbytes of banks if the flash size
is 16Mbytes, this new scheme will add the bank selection feature
for performing write/erase operations on all flashes.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
I have a few comments on this series, but it mostly looks fine. I think the
new code is correct.
The patches did not apply cleanly for me. Perhaps I am missing something.
My tree looks like this after I did a bit of merging:
5864e87 (HEAD, try-spi) cfi_flash: Fix detection of 8-bit bus flash devices
via address shift
f700095 sf: Add Flag status register polling support
42f4b70 sf: Remove spi_flash_cmd_poll_bit()
fc31387 sf: Use spi_flash_read_common() in write status poll
923e40e sf: spansion: Add support for S25FL512S_256K
c72e52a sf: stmicro: Add support for N25Q1024A
4066f71 sf: stmicro: Add support for N25Q1024
0efaf86 sf: stmicro: Add support for N25Q512A
8fd962f sf: stmicro: Add support for N25Q512
f1a2080 sf: Use spi_flash_addr() in write call
31ed498 sf: Update sf read to support all sizes of flashes
0f77642 sf: Update sf to support all sizes of flashes
9e57220 sf: read flash bank addr register at probe time
e99a43d sf: Add extended addr read support for winbond|stmicro
2f06d56 sf: Add extended addr write support for winbond|stmicro
f02ecf1 sf: Add bank address register reading support
02ba27c sf: Add bank address register writing support
Also do you think spi_flash_cmd_bankaddr_write() and related stuff should
be behind a flag like CONFIG_SPI_BANK_ADDR or similar? How much code space
does this add?
In your change to spi_flash_cmd_poll_bit() the effect is not the same I
think. It is designed to hold CS active and read the status byte
continuously until it changes. But your implementation asserts CS, reads
the status byte, de-asserts CS, then repeats. Why do we want to change
this?
---
Changes for v2:
- none
drivers/mtd/spi/spi_flash.c | 39 ++-
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 4576a16..5386884 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -74,11 +74,9 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash,
u32 offset,
unsigned long page_addr, byte_addr, page_size;
size_t chunk_len, actual;
int ret;
- u8 cmd[4];
+ u8 cmd[4], bank_sel;
page_size = flash-page_size;
- page_addr = offset / page_size;
- byte_addr = offset % page_size;
ret = spi_claim_bus(flash-spi);
if (ret) {
@@ -88,6 +86,16 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash,
u32 offset,
cmd[0] = CMD_PAGE_PROGRAM;
for (actual = 0; actual len; actual += chunk_len) {
+ bank_sel = offset / SPI_FLASH_16MB_BOUN;
+
+ ret = spi_flash_cmd_bankaddr_write(flash, bank_sel);
+ if (ret) {
+ debug(SF: fail to set bank%d\n, bank_sel);
+ return ret;
+ }
So we are now doing this for all chips. But isn't it true that only some
chips (16MB?) have a bank address. If so, then I think we should have a
flag somewhere to enable this feature
+
+ page_addr = offset / page_size;
+ byte_addr = offset % page_size;
This is OK I think. We really don't care about the slower divide so it is
not worth optimising for I think.
chunk_len = min(len - actual, page_size - byte_addr);
if (flash-spi-max_write_size)
@@ -117,11 +125,7 @@ int spi_flash_cmd_write_multi(struct spi_flash
*flash, u32 offset,
if (ret)
break;
- byte_addr += chunk_len;
- if (byte_addr == page_size) {
- page_addr++;
- byte_addr = 0;
- }
+ offset += chunk_len;
}
spi_release_bus(flash-spi);
@@ -204,9 +208,9 @@ int spi_flash_cmd_wait_ready(struct spi_flash *flash,
unsigned long timeout)
int spi_flash_cmd_erase(struct spi_flash *flash, u32 offset, size_t len)
{
- u32 end, erase_size;
+ u32 erase_size;
int ret;
- u8 cmd[4];
+ u8 cmd[4], bank_sel;
erase_size = flash-sector_size;
if (offset % erase_size || len % erase_size) {
@@ -224,11 +228,17 @@ int spi_flash_cmd_erase(struct spi_flash
Re: [U-Boot] [U-BOOT] mmc: sdhci: Enable 8-bit bus width only for 3.0 spec onwards
Hi,
On Wed, May 29, 2013 at 4:42 AM, Jagan Teki jagannadh.t...@gmail.comwrote:
Any help on this, was this a useful fix.
Thanks,
Jagan.
On Mon, May 27, 2013 at 10:49 AM, Jagannadha Sutradharudu Teki
jagannadha.sutradharudu-t...@xilinx.com wrote:
Request for an update on this.
Thanks,
Jagan.
-Original Message-
From: Jagannadha Sutradharudu Teki [mailto:jagannadha.sutradharudu-
t...@xilinx.com]
Sent: 21 May 2013 15:02
To: u-boot@lists.denx.de
Cc: mon...@monstr.eu; Andy Fleming; Jagannadha Sutradharudu Teki
Subject: [U-BOOT] mmc: sdhci: Enable 8-bit bus width only for 3.0 spec
onwards
CAP register don't have any information for 8-bit buswidth support on
2.0 sdhci
spec, only from 3.0 onwards bit[18] got this information.
Due to this misassignment in sdhci, mmc is setting 8-bit buswidth using
mmc_set_bus_width even if controller doesn't support.
Below change has code information.
mmc: Properly determine maximum supported bus width
(sha1: 7798f6dbd5e1a3030ed81a81da5dfb57c3307cac)
Bug log: mmc plus and emmc cards)
---
zynq-uboot mmcinfo
Error detected in status(0x208100)!
Device: zynq_sdhci
Manufacturer ID: fe
This seems like a reasonable patch to me. I don't have hardware to test it
though, and have not looked up the spec.
Reviewed-by: Simon Glass s...@chromium.org
.
So enable 8-bit support only for 3.0 spec using CAP and for below 3.0
assign
mmc-host_caps = MMC_MODE_8BIT on respective platform driver if host
have
a support.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
drivers/mmc/sdhci.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index
1eaea04..c5631bf
100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -486,8 +486,10 @@ int add_sdhci(struct sdhci_host *host, u32 max_clk,
u32 min_clk)
mmc-voltages |= host-voltages;
mmc-host_caps = MMC_MODE_HS | MMC_MODE_HS_52MHz |
MMC_MODE_4BIT;
- if (caps SDHCI_CAN_DO_8BIT)
- mmc-host_caps |= MMC_MODE_8BIT;
+ if ((host-version SDHCI_SPEC_VER_MASK) = SDHCI_SPEC_300) {
+ if (caps SDHCI_CAN_DO_8BIT)
+ mmc-host_caps |= MMC_MODE_8BIT;
+ }
if (host-host_caps)
mmc-host_caps |= host-host_caps;
--
1.7.4
This email and any attachments are intended for the sole use of the
named recipient(s) and contain(s) confidential information that may be
proprietary, privileged or copyrighted under applicable law. If you are not
the intended recipient, do not read, copy, or forward this email message or
any attachments. Delete this email message and any attachments immediately.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
--
Thanks,
Jagan.
___
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 5/8] powerpc: spl: deleted unused symbol CONFIG_SPL_NAND_MINIMAL and introduced new symbol CONFIG_SPL_MINIMAL
-Original Message- From: Wood Scott-B07421 Sent: Saturday, June 08, 2013 1:21 AM To: Zhang Ying-B40530 Cc: u-boot@lists.denx.de; aflem...@gmail.com; Xie Xiaobo-R63061; Zhang Ying-B40530 Subject: Re: [PATCH 5/8] powerpc: spl: deleted unused symbol CONFIG_SPL_NAND_MINIMAL and introduced new symbol CONFIG_SPL_MINIMAL On 06/07/2013 04:25:17 AM, ying.zh...@freescale.com wrote: diff --git a/README b/README index e30e787..fbb50fb 100644 --- a/README +++ b/README @@ -2911,6 +2911,11 @@ FIT uImage format: CONFIG_SPL_INIT_MINIMAL Arch init code should be built for a very small image + CONFIG_SPL_MINIMAL + It is different from common SPL. if set, the SPL image + as small as possible, only a tiny part of the SPL code + is built. How is this different from CONFIG_SPL_INIT_MINIMAL? [Zhang Ying] It is really some confusion. So, we have two options: 1. CONFIG_SPL_INIT_MINIMAL coexist with CONFIG_SPL_MINIMAL, I can increase the description for the difference between both: CONFIG_SPL_INIT_MINIMAL expressed support for minimal SPL. But it cannot be used independently, it must be applied with CONFIG_SPL_BUILD. It mainly used in Makefiles. CONFIG_SPL_MINIMAL equals to CONFIG_SPL_BUILD CONFIG_SPL_INIT_MINIMAL. It is applied to C files. Just as you said: it would be nice to limit SPL symbols to only be defined for the SPL part of the build, so we don't have to add checks for CONFIG_SPL_BUILD all over the place. Currently this won't work for symbols that makefiles look at, if SPL: Makefile: Build a separate autoconf.mk for SPL gets merged, we could just define CONFIG_SPL_MINIMAL in the SPL build case. 2. No longer adds the new symbol CONFIG_SPL_MINIMAL: We can use CONFIG_SPL_BUILD CONFIG_SPL_INIT_MINIMAL to replace it in the C files. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] nds32: Enable two banks of SDRAM on Andes board
The original adp-ag101/adp-ag101p initialize only one bank(64MB)
by default at boot time, but it is not enough for some application,
so increasing to two banks(128M).
Signed-off-by: Kuan-Yu Kuo ken.ku...@gmail.com
Cc: Macpaul Lin macp...@gmail.com
---
arch/nds32/cpu/n1213/ag101/lowlevel_init.S |6 +-
board/AndesTech/adp-ag101/adp-ag101.c | 10 +-
board/AndesTech/adp-ag101p/adp-ag101p.c| 10 +-
include/configs/adp-ag101.h| 10 +-
include/configs/adp-ag101p.h |9 -
5 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/arch/nds32/cpu/n1213/ag101/lowlevel_init.S
b/arch/nds32/cpu/n1213/ag101/lowlevel_init.S
index 29c93fe..55985cf 100644
--- a/arch/nds32/cpu/n1213/ag101/lowlevel_init.S
+++ b/arch/nds32/cpu/n1213/ag101/lowlevel_init.S
@@ -38,6 +38,7 @@
#define SDMC_CR1_A (CONFIG_FTSDMC021_BASE + FTSDMC021_CR1)
#define SDMC_CR2_A (CONFIG_FTSDMC021_BASE + FTSDMC021_CR2)
#define SDMC_B0_BSR_A (CONFIG_FTSDMC021_BASE + FTSDMC021_BANK0_BSR)
+#define SDMC_B1_BSR_A (CONFIG_FTSDMC021_BASE + FTSDMC021_BANK1_BSR)
#define SDMC_TP1_D CONFIG_SYS_FTSDMC021_TP1
#define SDMC_TP2_D CONFIG_SYS_FTSDMC021_TP2
@@ -45,6 +46,7 @@
#define SDMC_CR2_D CONFIG_SYS_FTSDMC021_CR2
#define SDMC_B0_BSR_D CONFIG_SYS_FTSDMC021_BANK0_BSR
+#define SDMC_B1_BSR_D CONFIG_SYS_FTSDMC021_BANK1_BSR
/*
* parameters for the static memory controller
@@ -167,12 +169,12 @@ relo_base:
*/
led 0x1a
write32 SDMC_B0_BSR_A, SDMC_B0_BSR_D! 0x1100
+ write32 SDMC_B1_BSR_A, SDMC_B1_BSR_D! 0x1140
/* clear empty BSR registers */
led 0x1b
li $r4, CONFIG_FTSDMC021_BASE
li $r5, 0x0
- swi $r5, [$r4 + FTSDMC021_BANK1_BSR]
swi $r5, [$r4 + FTSDMC021_BANK2_BSR]
swi $r5, [$r4 + FTSDMC021_BANK3_BSR]
@@ -223,6 +225,8 @@ relo_base:
* - after remap: flash/rom 0x8000, sdram: 0x
*/
led 0x1c
+ write32 SDMC_B0_BSR_A, 0x1000
+ write32 SDMC_B1_BSR_A, 0x1040
setbf15 AHBC_CR_A, FTAHBC020S_CR_REMAP ! 0x1
#endif /* #ifdef CONFIG_MEM_REMAP */
diff --git a/board/AndesTech/adp-ag101/adp-ag101.c
b/board/AndesTech/adp-ag101/adp-ag101.c
index 82ce4c9..ebc20a5 100644
--- a/board/AndesTech/adp-ag101/adp-ag101.c
+++ b/board/AndesTech/adp-ag101/adp-ag101.c
@@ -50,7 +50,7 @@ int board_init(void)
int dram_init(void)
{
unsigned long sdram_base = PHYS_SDRAM_0;
- unsigned long expected_size = PHYS_SDRAM_0_SIZE;
+ unsigned long expected_size = PHYS_SDRAM_0_SIZE + PHYS_SDRAM_1_SIZE;
unsigned long actual_size;
actual_size = get_ram_size((void *)sdram_base, expected_size);
@@ -65,6 +65,14 @@ int dram_init(void)
return 0;
}
+void dram_init_banksize(void)
+{
+ gd-bd-bi_dram[0].start = PHYS_SDRAM_0;
+ gd-bd-bi_dram[0].size = PHYS_SDRAM_0_SIZE;
+ gd-bd-bi_dram[1].start = PHYS_SDRAM_1;
+ gd-bd-bi_dram[1].size = PHYS_SDRAM_1_SIZE;
+}
+
int board_eth_init(bd_t *bd)
{
return ftmac100_initialize(bd);
diff --git a/board/AndesTech/adp-ag101p/adp-ag101p.c
b/board/AndesTech/adp-ag101p/adp-ag101p.c
index 8dd2043..26d67e2 100644
--- a/board/AndesTech/adp-ag101p/adp-ag101p.c
+++ b/board/AndesTech/adp-ag101p/adp-ag101p.c
@@ -50,7 +50,7 @@ int board_init(void)
int dram_init(void)
{
unsigned long sdram_base = PHYS_SDRAM_0;
- unsigned long expected_size = PHYS_SDRAM_0_SIZE;
+ unsigned long expected_size = PHYS_SDRAM_0_SIZE + PHYS_SDRAM_1_SIZE;
unsigned long actual_size;
actual_size = get_ram_size((void *)sdram_base, expected_size);
@@ -65,6 +65,14 @@ int dram_init(void)
return 0;
}
+void dram_init_banksize(void)
+{
+ gd-bd-bi_dram[0].start = PHYS_SDRAM_0;
+ gd-bd-bi_dram[0].size = PHYS_SDRAM_0_SIZE;
+ gd-bd-bi_dram[1].start = PHYS_SDRAM_1;
+ gd-bd-bi_dram[1].size = PHYS_SDRAM_1_SIZE;
+}
+
int board_eth_init(bd_t *bd)
{
return ftmac100_initialize(bd);
diff --git a/include/configs/adp-ag101.h b/include/configs/adp-ag101.h
index b6e3844..1b84b04 100644
--- a/include/configs/adp-ag101.h
+++ b/include/configs/adp-ag101.h
@@ -235,6 +235,11 @@
#define CONFIG_SYS_FTSDMC021_BANK0_BSR (FTSDMC021_BANK_ENABLE | \
CONFIG_SYS_FTSDMC021_BANK0_BASE)
+#define CONFIG_SYS_FTSDMC021_BANK1_BASE \
+ (CONFIG_SYS_FTAHBC020S_SLAVE_BSR_BASE + (PHYS_SDRAM_0_SIZE 20))
+#define CONFIG_SYS_FTSDMC021_BANK1_BSR (FTSDMC021_BANK_ENABLE | \
+ CONFIG_SYS_FTSDMC021_BANK1_BASE)
+
#endif
/*
@@ -248,9 +253,12 @@
#else /* !CONFIG_SKIP_LOWLEVEL_INIT !CONFIG_MEM_REMAP */
#define PHYS_SDRAM_0 0x1000 /* SDRAM Bank #1 */
#endif
+#define PHYS_SDRAM_1 \
+
[U-Boot] [PATCH 4/4] nds32: Enable the function of passing parameters to Linux
Add a header file, setup.h, which copy from Linux source code,
this file contain structures are used to pass initialisation parameters
to Linux. Enable this function on adp-ag101/adp-ag101p target
Signed-off-by: Kuan-Yu Kuo ken.ku...@gmail.com
Cc: Macpaul Lin macp...@gmail.com
---
arch/nds32/include/asm/setup.h | 192
include/common.h |1 +
include/configs/adp-ag101.h|7 ++
include/configs/adp-ag101p.h |7 ++
4 files changed, 207 insertions(+)
create mode 100644 arch/nds32/include/asm/setup.h
diff --git a/arch/nds32/include/asm/setup.h b/arch/nds32/include/asm/setup.h
new file mode 100644
index 000..0a14ea0
--- /dev/null
+++ b/arch/nds32/include/asm/setup.h
@@ -0,0 +1,192 @@
+/*
+ * linux/arch/nds32/include/asm/setup.h
+ *
+ * Copyright (C) 1997-1999 Russell King
+ * Copyright (C) 2008 Andes Technology Corporation
+ * Copyright (C) 2013 Ken Kuo (ken_...@andestech.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Structure passed to kernel to tell it about the
+ * hardware it's running on. See Documentation/arm/Setup
+ * for more info.
+ */
+#ifndef __ASMNDS32_SETUP_H
+#define __ASMNDS32_SETUP_H
+
+#define COMMAND_LINE_SIZE 256
+
+/* The list ends with an ATAG_NONE node. */
+#define ATAG_NONE 0x
+
+struct tag_header {
+ u32 size;
+ u32 tag;
+};
+
+/* The list must start with an ATAG_CORE node */
+#define ATAG_CORE 0x54410001
+
+struct tag_core {
+ u32 flags; /* bit 0 = read-only */
+ u32 pagesize;
+ u32 rootdev;
+};
+
+/* it is allowed to have multiple ATAG_MEM nodes */
+#define ATAG_MEM 0x54410002
+
+struct tag_mem32 {
+ u32 size;
+ u32 start; /* physical start address */
+};
+
+/* VGA text type displays */
+#define ATAG_VIDEOTEXT 0x54410003
+
+struct tag_videotext {
+ u8 x;
+ u8 y;
+ u16 video_page;
+ u8 video_mode;
+ u8 video_cols;
+ u16 video_ega_bx;
+ u8 video_lines;
+ u8 video_isvga;
+ u16 video_points;
+};
+
+/* describes how the ramdisk will be used in kernel */
+#define ATAG_RAMDISK 0x54410004
+
+struct tag_ramdisk {
+ u32 flags; /* bit 0 = load, bit 1 = prompt */
+ u32 size; /* decompressed ramdisk size in _kilo_ bytes */
+ u32 start; /* starting block of floppy-based RAM disk image */
+};
+
+/*
+ * this one accidentally used virtual addresses - as such,
+ * it's deprecated.
+ * describes where the compressed ramdisk image lives (virtual address)
+ */
+#define ATAG_INITRD0x54410005
+
+/* describes where the compressed ramdisk image lives (physical address) */
+#define ATAG_INITRD2 0x54420005
+
+struct tag_initrd {
+ u32 start; /* physical start address */
+ u32 size; /* size of compressed ramdisk image in bytes */
+};
+
+/* board serial number. 64 bits should be enough for everybody */
+#define ATAG_SERIAL0x54410006
+
+struct tag_serialnr {
+ u32 low;
+ u32 high;
+};
+
+/* board revision */
+#define ATAG_REVISION 0x54410007
+
+struct tag_revision {
+ u32 rev;
+};
+
+/* initial values for vesafb-type framebuffers. see struct screen_info
+ * in include/linux/tty.h
+ */
+#define ATAG_VIDEOLFB 0x54410008
+
+struct tag_videolfb {
+ u16 lfb_width;
+ u16 lfb_height;
+ u16 lfb_depth;
+ u16 lfb_linelength;
+ u32 lfb_base;
+ u32 lfb_size;
+ u8 red_size;
+ u8 red_pos;
+ u8 green_size;
+ u8 green_pos;
+ u8 blue_size;
+ u8 blue_pos;
+ u8 rsvd_size;
+ u8 rsvd_pos;
+};
+
+/* command line: \0 terminated string */
+#define ATAG_CMDLINE 0x54410009
+
+struct tag_cmdline {
+ charcmdline[COMMAND_LINE_SIZE];
+};
+
+struct tag {
+ struct tag_header hdr;
+ union {
+ struct tag_core core;
+ struct tag_mem32mem;
+ struct tag_videotextvideotext;
+ struct tag_ramdisk ramdisk;
+ struct tag_initrd initrd;
+ struct tag_serialnr serialnr;
+ struct tag_revision revision;
+ struct tag_videolfb videolfb;
+ struct tag_cmdline cmdline;
+ } u;
+};
+
+struct tagtable {
+ u32 tag;
+ int (*parse)(const struct tag *);
+};
+
+#define tag_member_present(tag, member)\
+ ((unsigned long)(((struct tag *)0L)-member + 1) \
+
[U-Boot] [PATCH 3/4] nds32: Enable SDIO and EXT2 command support for Andes board
Signed-off-by: Kuan-Yu Kuo ken.ku...@gmail.com Cc: Macpaul Lin macp...@gmail.com --- include/configs/adp-ag101.h |2 ++ include/configs/adp-ag101p.h |2 ++ 2 files changed, 4 insertions(+) diff --git a/include/configs/adp-ag101.h b/include/configs/adp-ag101.h index 1b84b04..85dbad2 100644 --- a/include/configs/adp-ag101.h +++ b/include/configs/adp-ag101.h @@ -116,7 +116,9 @@ #define CONFIG_DOS_PARTITION #define CONFIG_FTSDC010 #define CONFIG_FTSDC010_NUMBER 1 +#define CONFIG_FTSDC010_SDIO #define CONFIG_CMD_FAT +#define CONFIG_CMD_EXT2 /* * Command line configuration. diff --git a/include/configs/adp-ag101p.h b/include/configs/adp-ag101p.h index cec89f6..6085208 100644 --- a/include/configs/adp-ag101p.h +++ b/include/configs/adp-ag101p.h @@ -116,7 +116,9 @@ #define CONFIG_DOS_PARTITION #define CONFIG_FTSDC010 #define CONFIG_FTSDC010_NUMBER 1 +#define CONFIG_FTSDC010_SDIO #define CONFIG_CMD_FAT +#define CONFIG_CMD_EXT2 /* * Command line configuration. -- 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/4] nds32: Add bitwise operation macros for drivers
Add clrbits_* setbits_* clrsetbits_* for peripheral drivers Signed-off-by: Kuan-Yu Kuo ken.ku...@gmail.com Cc: Macpaul Lin macp...@gmail.com --- arch/nds32/include/asm/io.h | 38 ++ 1 file changed, 38 insertions(+) diff --git a/arch/nds32/include/asm/io.h b/arch/nds32/include/asm/io.h index 39c3dc8..5168c8d 100644 --- a/arch/nds32/include/asm/io.h +++ b/arch/nds32/include/asm/io.h @@ -6,6 +6,7 @@ * Copyright (C) 2011 Andes Technology Corporation * Shawn Lin, Andes Technology Corporation nobuh...@andestech.com * Macpaul Lin, Andes Technology Corporation macp...@andestech.com + * Ken Kuo, Andes Technology Corporation ken_...@andestech.com * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -165,6 +166,14 @@ static inline unsigned int readl(unsigned int *addr) #define __raw_base_readw(base, off)__arch_base_getw(base, off) #define __raw_base_readl(base, off)__arch_base_getl(base, off) +/* + * Clear and set bits in one shot. These macros can be used to clear and + * set multiple bits in a register using a single call. These macros can + * also be used to set a multiple-bit bit pattern using a mask, by + * specifying the mask in the 'clear' parameter and the new bit pattern + * in the 'set' parameter. + */ + #define out_arch(type, endian, a, v) __raw_write##type(cpu_to_##endian(v), a) #define in_arch(type, endian, a) endian##_to_cpu(__raw_read##type(a)) @@ -183,6 +192,35 @@ static inline unsigned int readl(unsigned int *addr) #define out_8(a, v)__raw_writeb(v, a) #define in_8(a)__raw_readb(a) +#define clrbits(type, addr, clear) \ + out_##type((addr), in_##type(addr) ~(clear)) + +#define setbits(type, addr, set) \ + out_##type((addr), in_##type(addr) | (set)) + +#define clrsetbits(type, addr, clear, set) \ + out_##type((addr), (in_##type(addr) ~(clear)) | (set)) + +#define clrbits_be32(addr, clear) clrbits(be32, addr, clear) +#define setbits_be32(addr, set) setbits(be32, addr, set) +#define clrsetbits_be32(addr, clear, set) clrsetbits(be32, addr, clear, set) + +#define clrbits_le32(addr, clear) clrbits(le32, addr, clear) +#define setbits_le32(addr, set) setbits(le32, addr, set) +#define clrsetbits_le32(addr, clear, set) clrsetbits(le32, addr, clear, set) + +#define clrbits_be16(addr, clear) clrbits(be16, addr, clear) +#define setbits_be16(addr, set) setbits(be16, addr, set) +#define clrsetbits_be16(addr, clear, set) clrsetbits(be16, addr, clear, set) + +#define clrbits_le16(addr, clear) clrbits(le16, addr, clear) +#define setbits_le16(addr, set) setbits(le16, addr, set) +#define clrsetbits_le16(addr, clear, set) clrsetbits(le16, addr, clear, set) + +#define clrbits_8(addr, clear) clrbits(8, addr, clear) +#define setbits_8(addr, set) setbits(8, addr, set) +#define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set) + /* * Now, pick up the machine-defined IO definitions * #include asm/arch/io.h -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
