Re: [U-Boot] [PATCH 2/2] wandboard: Add Boot Splash image with Wandboard logo
Dear Otavio Salvador, In message cap9odko_uo4bs1xr3c5mjupmiw+t1t+vzvmzrvjkwpr+igz...@mail.gmail.com you wrote: --- a/tools/Makefile +++ b/tools/Makefile @@ -146,6 +146,9 @@ endif ifeq ($(VENDOR),syteco) LOGO_BMP= logos/syteco.bmp endif +ifeq ($(VENDOR),wandboard) +LOGO_BMP= logos/wandboard.bmp +endif This does not scale; it never did, but now we're running out of control. Can we please fix the logo selection? Thanks. I can work on this but how you think we can make it? Like check for vendor, than board? No, this doesn't really work, as the wandboard case shows, where there is no such thing as a vendor name. Eventually we should/could change LOGO_BMP into CONFIG_LOGO_BMP and move the setting of the BMP file name to board / vendor specific locations. [But this needs to be thought about, too, as it makes little sense to edit zillions of board config files for that.] 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 Cleverness and Style have no place in getting a project completed. -- Tom Christiansen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [HELP]: sf: winbond: add W25Q32
Hi Jagan,
Yes you are right it has to be 16.
So you want me to and send a patch correcting it?
Or you want me to revert it and send a new patch?
--
Regards,
Rajeshwari Shinde
On Mon, May 27, 2013 at 12:30 PM, Jagan Teki jagannadh.t...@gmail.com wrote:
Hi Rajeshwari,
On Mon, May 27, 2013 at 11:59 AM, Jagan Teki jagannadh.t...@gmail.com wrote:
Hi,
Thanks for your response.
On Mon, May 27, 2013 at 11:09 AM, Rajeshwari Birje
rajeshwari.bi...@gmail.com wrote:
Hi Jagan,
Hope following reply answer your query.
On Sat, May 25, 2013 at 2:08 AM, Jagan Teki jagannadh.t...@gmail.com
wrote:
Hi,
Any update on this, is this a different part w.r.t what I refer for?
Thanks,
Jagan.
On Thu, May 23, 2013 at 2:22 PM, Jagan Teki jagannadh.t...@gmail.com
wrote:
Hi Rajeshwari,
+ {
+ .id = 0x5014,
is this id code is correct? it seems like 0x4014
When you see the datasheet of W25Q80BW page 16, the table says its 5014h
+ .nr_blocks = 128,
nr_blocks must be 16 i think?
We use W25Q80BW which is 8MB, hence it is correct as per following
calculation;
flash-size = 4096 * 16 * params-nr_blocks;
Yes, it is 8M-BIT so the nr_blocks should be 16 to calculate the flash
size as 1Mbyte.
--
Thanks,
Jagan.
+ .name = W25Q80,
+ },
};
Honestly the commit message itself is wrong, i guess.
Yes this I agree is my fault, but wonder how it went in through all the
reviews.
1. Can you please revert this patch, as commit message not looks good
me and also some incorrect nr_blocks
Please mentioned the exact details on commit message body reason
for reverting
2. And also send one more patch with a proper details. [exact name,
nr_blocks .etc]
---
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] dfu: dfu and UBI Volumes
Hello Wolfgang, Am 28.05.2013 07:58, schrieb Wolfgang Denk: Dear Heiko, In message 51a42ccd.1020...@denx.de you wrote: I would imagine, but testing and implementation might show a better way, we do UBI as name ubi ubiN volume-name, ie: rootfs ubi ubi0 rootfs user ubi ubi0 user-data and so forth, and augment dfu_nand.c with UBI knowledge, ala dfu_mmc and fat/ext knowledge. Yes, I think, thats the way to go ... I doubt that dfu_nand.c is the right place for this. What if I start using DFU on NOR flash? The decisions which device type (NAND, MMC, NOR, USB mass storage, ...) to habdle on one side, and which partition type / image type (raw, UBI volume, file, ...) on the other side are fully orthogonal to each other. They should be handled by independent code, and not one of them repeated for all implementations of the other. Yes, exactly ... bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/CoreNet: Allow pbl images to take u-boot images != 512K
On 27/05/13 18:18, Xie Shaohui-B21989 wrote: Hi, Chris, For the init value of next_pbl_cmd, there was a patch at below link can be used: http://lists.denx.de/pipermail/u-boot/2013-March/150260.html Thanks for the pointer. I did check the main u-boot.git tree but didn't search the list. I don't know if it's a concern for u-boot but the patch linked above assumes something that isn't quite true for my usage. My board uses the SPI booting option for factory boot-strap. The normal method is booting from NOR. When I build a NOR image I prepend a standalone application image to the bootloader for convenience of only having to program one image to NOR. In my case CONFIG_SYS_TEXT_BASE is not the base address of the binary I'm trying to wrap in a pbl image. Another advantage of my version is that you don't necessarily have to be using mkimage/pblimage on the current u-boot configuration. It could be an externally built image and we're just using mkimage/pblimage to wrap it into something that we can program into SPI. [S.H] OK. I see what is your requirement. ACK. Best Regards, Shaohui Xie ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [HELP]: sf: winbond: add W25Q32
On Tue, May 28, 2013 at 11:38 AM, Rajeshwari Birje
rajeshwari.bi...@gmail.com wrote:
Hi Jagan,
Yes you are right it has to be 16.
So you want me to and send a patch correcting it?
Or you want me to revert it and send a new patch?
--
Regards,
Rajeshwari Shinde
On Mon, May 27, 2013 at 12:30 PM, Jagan Teki jagannadh.t...@gmail.com wrote:
Hi Rajeshwari,
On Mon, May 27, 2013 at 11:59 AM, Jagan Teki jagannadh.t...@gmail.com
wrote:
Hi,
Thanks for your response.
On Mon, May 27, 2013 at 11:09 AM, Rajeshwari Birje
rajeshwari.bi...@gmail.com wrote:
Hi Jagan,
Hope following reply answer your query.
On Sat, May 25, 2013 at 2:08 AM, Jagan Teki jagannadh.t...@gmail.com
wrote:
Hi,
Any update on this, is this a different part w.r.t what I refer for?
Thanks,
Jagan.
On Thu, May 23, 2013 at 2:22 PM, Jagan Teki jagannadh.t...@gmail.com
wrote:
Hi Rajeshwari,
+ {
+ .id = 0x5014,
is this id code is correct? it seems like 0x4014
When you see the datasheet of W25Q80BW page 16, the table says its 5014h
+ .nr_blocks = 128,
nr_blocks must be 16 i think?
We use W25Q80BW which is 8MB, hence it is correct as per following
calculation;
flash-size = 4096 * 16 * params-nr_blocks;
Yes, it is 8M-BIT so the nr_blocks should be 16 to calculate the flash
size as 1Mbyte.
--
Thanks,
Jagan.
+ .name = W25Q80,
+ },
};
Honestly the commit message itself is wrong, i guess.
Yes this I agree is my fault, but wonder how it went in through all the
reviews.
1. Can you please revert this patch, as commit message not looks good
me and also some incorrect nr_blocks
Please mentioned the exact details on commit message body reason
for reverting
2. And also send one more patch with a proper details. [exact name,
nr_blocks .etc]
Not required, i sent it already.
http://patchwork.ozlabs.org/patch/246644/
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 V2] SF: Add driver for Gigabyte device GD25LQ and GD25Q64B
Any update on this.
Was this patch refereed for denx tree?
Thanks,
Jagan.
On Tue, May 21, 2013 at 6:40 PM, Jagan Teki jagannadh.t...@gmail.com wrote:
Hi,
I think this reviewed already, but have a very few comments.
On Wed, Jan 23, 2013 at 12:00 PM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
This patch adds driver for the gigabyte devices
GD25LQ and GD25Q64B required for Snow Board.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- Added U-Boot copyright header to gigadevice.c
- Removed unnecessary blank lines.
drivers/mtd/spi/Makefile |1 +
drivers/mtd/spi/gigadevice.c | 81
++
drivers/mtd/spi/spi_flash.c |3 +
drivers/mtd/spi/spi_flash_internal.h |1 +
4 files changed, 86 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/spi/gigadevice.c
diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
index 90f8392..ecbb210 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -32,6 +32,7 @@ endif
COBJS-$(CONFIG_SPI_FLASH) += spi_flash.o
COBJS-$(CONFIG_SPI_FLASH_ATMEL)+= atmel.o
COBJS-$(CONFIG_SPI_FLASH_EON) += eon.o
+COBJS-$(CONFIG_SPI_FLASH_GIGADEVICE) += gigadevice.o
COBJS-$(CONFIG_SPI_FLASH_MACRONIX) += macronix.o
COBJS-$(CONFIG_SPI_FLASH_SPANSION) += spansion.o
COBJS-$(CONFIG_SPI_FLASH_SST) += sst.o
diff --git a/drivers/mtd/spi/gigadevice.c b/drivers/mtd/spi/gigadevice.c
new file mode 100644
index 000..b5e1ebe
--- /dev/null
+++ b/drivers/mtd/spi/gigadevice.c
@@ -0,0 +1,81 @@
+/*
+ * Gigadevice SPI flash driver
+ * Copyright 2013, Samsung Electronics Co., Ltd.
+ * Author: Banajit Goswami banaji...@samsung.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include malloc.h
+#include spi_flash.h
+
+#include spi_flash_internal.h
+
+struct gigadevice_spi_flash_params {
+ uint16_tid;
+ uint16_tnr_blocks;
I think it's better to use u16 instead of uint16_t, uin16_t will get
back to arch include from include/linux which does u16 for directly
for first time.
+ const char *name;
+};
+
+static const struct gigadevice_spi_flash_params
gigadevice_spi_flash_table[] = {
+ {
+ .id = 0x6016,
+ .nr_blocks = 64,
+ .name = GD25LQ,
+ },
+ {
+ .id = 0x4017,
+ .nr_blocks = 128,
+ .name = GD25Q64B,
+ },
Better to use clean code shape like..
{
.id = 0x60,
.nr_blocks = 64,
.name = GD25LQ,
}
+};
+
+struct spi_flash *spi_flash_probe_gigadevice(struct spi_slave *spi, u8
*idcode)
+{
+ const struct gigadevice_spi_flash_params *params;
+ struct spi_flash *flash;
+ unsigned int i;
+
+ for (i = 0; i ARRAY_SIZE(gigadevice_spi_flash_table); i++) {
+ params = gigadevice_spi_flash_table[i];
+ if (params-id == ((idcode[1] 8) | idcode[2]))
+ break;
+ }
+
+ if (i == ARRAY_SIZE(gigadevice_spi_flash_table)) {
+ debug(SF: Unsupported Gigadevice ID %02x%02x\n,
+ idcode[1], idcode[2]);
+ return NULL;
+ }
+
+ flash = spi_flash_alloc_base(spi, params-name);
+ if (!flash) {
+ debug(SF: Failed to allocate memory\n);
+ return NULL;
+ }
better to add a space here
+ /* page_size */
+ flash-page_size = 256;
+ /* sector_size = page_size * pages_per_sector */
+ flash-sector_size = flash-page_size * 16;
+ /* size = sector_size * sector_per_block * number of blocks */
+ flash-size = flash-sector_size * 16 * params-nr_blocks;
comments on above size calculations are good, but not that much
important i guess.
And also please provide a stand' link for flash part data sheet on
commit message, if possible.
I thought it's a good to refers don't
Re: [U-Boot] [PATCH] drivers:lcd: fix unaligned access on lcd
Hi Piotr, On 05/27/2013 02:35 PM, Piotr Wilczek wrote: Dear Wolfgang Denk, -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Friday, May 24, 2013 8:33 PM To: Piotr Wilczek Cc: u-boot@lists.denx.de; Kyungmin Park Subject: Re: [U-Boot] [PATCH] drivers:lcd: fix unaligned access on lcd [...] My case is a bmp unzipped to a 4-byte aligned address. The two signature bytes of the bmp header make the other fields 4-byte unaligned. We could force unzip the bmp to an aligned address + 2. Is this a better solution? That is the solution we settled on the last time this was discussed. See CONFIG_SPLASHIMAGE_GUARD in the README file if your use case involves user input, or just pick an aligned address + 2 in your code. -- Regards, Nikita. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/6] Optimize ARM relocation
*** NOTE: this series applies over the 'Factorize
ARM relocate_code instances' series.
This series optimizes relocation by ensuring ARM
binaries only use one type of relocation record,
R_ARM_RELATIVE., then optimizing relocation code
accordingly.
1. A Makefile rule is added that checks that no
other relocation record types are generated except
R_ARM_RELATIVE; build fails if this is the case.
2. All references to dymsym are removed, as this
table is not used for R_ARM_RELATIVE relocations.
3. arch/arm/lib/bss.c is replaced by a more generic
arch/arm/lib/sections.c where all section symbols will
be defined.
4. __image_copy_start and __image_copy_end symbols
are moved from linker scripts to arch/arm/lib/sections.c
5. __rel_dyn_start and __rel_dyn_end are moved from
linker scripts into arch/arm/lib/sections.c
6. relocate_code is optimized based on the fact that
symbol references are now always valid even before
relcation, and that only R_ARM_RELATIVE relocations
will be met.
Changes in v2:
- use $ instead of $(obj)u-boot
- new in V2: remove all dynsym references
- various comment fixes
Albert ARIBAUD (6):
arm: ensure u-boot only uses relative relocations
remove all references to .dynsym
arm: generalize lib/bss.c into lib/sections.c
arm: make __image_copy_{start,end} compiler-generated
arm: make __rel_dyn_{start,end} compiler-generated
arm: optimize relocate_code routine
Makefile |7 +++
arch/arm/config.mk |5 ++
arch/arm/cpu/arm920t/ep93xx/u-boot.lds |6 ++-
arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds |5 --
arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds|5 --
arch/arm/cpu/ixp/u-boot.lds| 20 +---
arch/arm/cpu/u-boot-spl.lds|6 +--
arch/arm/cpu/u-boot.lds| 21 +---
arch/arm/lib/Makefile |2 +-
arch/arm/lib/relocate.S| 61 ++--
arch/arm/lib/{bss.c = sections.c} |8 +++-
board/actux1/u-boot.lds| 20 +---
board/actux2/u-boot.lds| 20 +---
board/actux3/u-boot.lds| 20 +---
board/ait/cam_enc_4xx/u-boot-spl.lds |5 --
board/davinci/da8xxevm/u-boot-spl-da850evm.lds |5 --
board/davinci/da8xxevm/u-boot-spl-hawk.lds |1 -
board/dvlhost/u-boot.lds | 20 +---
board/freescale/mx31ads/u-boot.lds | 20 +---
board/vpac270/u-boot-spl.lds |6 +--
include/asm-generic/sections.h |3 --
21 files changed, 139 insertions(+), 127 deletions(-)
rename arch/arm/lib/{bss.c = sections.c} (79%)
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/6] remove all references to .dynsym
Discard all .dynsym sections from linker scripts
Remove all __dynsym_start definitions from linker scripts
Remove all __dynsym_start references from the codebase
Note: this touches include/asm-generic/sections.h, which
is not ARM-specific, but actual uses of __dynsym_start
are only in ARM, so this patch can safely go through
the ARM repository.
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
Changes in v2:
- new in V2: remove all dynsym references
arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds |5 -
arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds|5 -
arch/arm/cpu/ixp/u-boot.lds|6 +-
arch/arm/cpu/u-boot-spl.lds|6 +-
arch/arm/cpu/u-boot.lds|6 +-
arch/arm/lib/relocate.S| 13 -
board/actux1/u-boot.lds|6 +-
board/actux2/u-boot.lds|6 +-
board/actux3/u-boot.lds|6 +-
board/ait/cam_enc_4xx/u-boot-spl.lds |5 -
board/davinci/da8xxevm/u-boot-spl-da850evm.lds |5 -
board/davinci/da8xxevm/u-boot-spl-hawk.lds |1 -
board/dvlhost/u-boot.lds |6 +-
board/freescale/mx31ads/u-boot.lds |6 +-
board/vpac270/u-boot-spl.lds |6 +-
include/asm-generic/sections.h |3 ---
16 files changed, 9 insertions(+), 82 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
b/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
index 673c725..f4e7525 100644
--- a/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
+++ b/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
@@ -57,11 +57,6 @@ SECTIONS
__rel_dyn_end = .;
}
- .dynsym : {
- __dynsym_start = .;
- *(.dynsym)
- }
-
.bss : {
. = ALIGN(4);
__bss_start = .;
diff --git a/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
b/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
index 967a135..446d095 100644
--- a/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
+++ b/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
@@ -57,11 +57,6 @@ SECTIONS
__rel_dyn_end = .;
}
- .dynsym : {
- __dynsym_start = .;
- *(.dynsym)
- }
-
.bss : {
. = ALIGN(4);
__bss_start = .;
diff --git a/arch/arm/cpu/ixp/u-boot.lds b/arch/arm/cpu/ixp/u-boot.lds
index 553589c..5cfff68 100644
--- a/arch/arm/cpu/ixp/u-boot.lds
+++ b/arch/arm/cpu/ixp/u-boot.lds
@@ -62,11 +62,6 @@ SECTIONS
__rel_dyn_end = .;
}
- .dynsym : {
- __dynsym_start = .;
- *(.dynsym)
- }
-
_end = .;
/*
@@ -88,6 +83,7 @@ SECTIONS
KEEP(*(.__bss_end));
}
+ /DISCARD/ : { *(.dynsym) }
/DISCARD/ : { *(.dynstr*) }
/DISCARD/ : { *(.dynamic*) }
/DISCARD/ : { *(.plt*) }
diff --git a/arch/arm/cpu/u-boot-spl.lds b/arch/arm/cpu/u-boot-spl.lds
index 1408f03..b6ed25f 100644
--- a/arch/arm/cpu/u-boot-spl.lds
+++ b/arch/arm/cpu/u-boot-spl.lds
@@ -58,11 +58,6 @@ SECTIONS
__rel_dyn_end = .;
}
- .dynsym : {
- __dynsym_start = .;
- *(.dynsym)
- }
-
_end = .;
.bss __rel_dyn_start (OVERLAY) : {
@@ -72,6 +67,7 @@ SECTIONS
__bss_end = .;
}
+ /DISCARD/ : { *(.dynsym) }
/DISCARD/ : { *(.dynstr*) }
/DISCARD/ : { *(.dynamic*) }
/DISCARD/ : { *(.plt*) }
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index d9bbee3..fe2ca98 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -65,11 +65,6 @@ SECTIONS
__rel_dyn_end = .;
}
- .dynsym : {
- __dynsym_start = .;
- *(.dynsym)
- }
-
_end = .;
/*
@@ -101,6 +96,7 @@ SECTIONS
KEEP(*(.__bss_end));
}
+ /DISCARD/ : { *(.dynsym) }
/DISCARD/ : { *(.dynstr*) }
/DISCARD/ : { *(.dynamic*) }
/DISCARD/ : { *(.plt*) }
diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 4446da9..7a7c4c0 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -56,8 +56,6 @@ copy_loop:
/*
* fix .rel.dyn relocations
*/
- ldr r10, _dynsym_start_ofs /* r10 - __dynsym_start local ofs */
- add r10, r10, r7/* r10 - SRC __dynsym_start */
ldr r2, _rel_dyn_start_ofs /* r2 - __rel_dyn_start local ofs */
add r2, r2, r7 /* r2 - SRC __rel_dyn_start */
ldr r3, _rel_dyn_end_ofs/* r3 - __rel_dyn_end local ofs */
@@ -69,17 +67,8 @@ fixloop:
and r7, r1, #0xff
cmp r7, #23 /* relative fixup? */
beq fixrel
- cmp
[U-Boot] [PATCH v2 1/6] arm: ensure u-boot only uses relative relocations
Add a Makefile target ('checkarmreloc') which
fails of the ELF binary contains relocation records
of types other than R_ARM_RELATIVE.
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
Changes in v2:
- use $ instead of $(obj)u-boot
Makefile |7 +++
arch/arm/config.mk |5 +
2 files changed, 12 insertions(+)
diff --git a/Makefile b/Makefile
index c52f0f1..70b5183 100644
--- a/Makefile
+++ b/Makefile
@@ -746,6 +746,13 @@ tools: $(VERSION_FILE) $(TIMESTAMP_FILE)
$(MAKE) -C $@ all
endif # config.mk
+# ARM relocations should all be R_ARM_RELATIVE.
+checkarmreloc: $(obj)u-boot
+ @if test R_ARM_RELATIVE != \
+ `readelf -r $ | cut -d ' ' -f 4 | grep R_ARM | sort -u`; \
+ then echo $ contains relocations other than \
+ R_ARM_RELATIVE; false; fi
+
$(VERSION_FILE):
@mkdir -p $(dir $(VERSION_FILE))
@( localvers='$(shell $(TOPDIR)/tools/setlocalversion
$(TOPDIR))' ; \
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index dc64160..e80e1ed 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -109,3 +109,8 @@ ifeq ($(GAS_BUG_12532),y)
PLATFORM_RELFLAGS += -fno-optimize-sibling-calls
endif
endif
+
+# check that only R_ARM_RELATIVE relocations are generated
+ifneq ($(CONFIG_SPL_BUILD),y)
+ALL-y += checkarmreloc
+endif
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/6] arm: make __image_copy_{start, end} compiler-generated
This change is only done where needed: some linker
scripts may contain __image_copy_{start,end} yet
remain unchanged.
Also, __image_copy_end needs its own section; putting
it in relocation sections changes their flags and makes
relocation breaks.
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
Changes in v2: None
arch/arm/cpu/arm920t/ep93xx/u-boot.lds |6 +-
arch/arm/cpu/ixp/u-boot.lds|6 +-
arch/arm/cpu/u-boot.lds|7 +--
arch/arm/lib/relocate.S|7 ++-
arch/arm/lib/sections.c|2 ++
board/actux1/u-boot.lds|6 +-
board/actux2/u-boot.lds|6 +-
board/actux3/u-boot.lds|6 +-
board/dvlhost/u-boot.lds |6 +-
board/freescale/mx31ads/u-boot.lds |6 +-
10 files changed, 44 insertions(+), 14 deletions(-)
diff --git a/arch/arm/cpu/arm920t/ep93xx/u-boot.lds
b/arch/arm/cpu/arm920t/ep93xx/u-boot.lds
index cf55bf7..367c805 100644
--- a/arch/arm/cpu/arm920t/ep93xx/u-boot.lds
+++ b/arch/arm/cpu/arm920t/ep93xx/u-boot.lds
@@ -31,6 +31,7 @@ SECTIONS
. = ALIGN(4);
.text :
{
+ *(.__image_copy_start)
arch/arm/cpu/arm920t/start.o (.text*)
/* the EP93xx expects to find the pattern 'CRUS' at 0x1000 */
. = 0x1000;
@@ -56,7 +57,10 @@ SECTIONS
. = ALIGN(4);
- __image_copy_end = .;
+ .image_copy_end :
+ {
+ *(.__image_copy_end)
+ }
__bss_start = .;
.bss : { *(.bss*) }
diff --git a/arch/arm/cpu/ixp/u-boot.lds b/arch/arm/cpu/ixp/u-boot.lds
index 5cfff68..9141199 100644
--- a/arch/arm/cpu/ixp/u-boot.lds
+++ b/arch/arm/cpu/ixp/u-boot.lds
@@ -31,6 +31,7 @@ SECTIONS
. = ALIGN(4);
.text :
{
+ *(.__image_copy_start)
arch/arm/cpu/ixp/start.o(.text*)
*(.text*)
}
@@ -54,7 +55,10 @@ SECTIONS
. = ALIGN(4);
- __image_copy_end = .;
+ .image_copy_end :
+ {
+ *(.__image_copy_end)
+ }
.rel.dyn : {
__rel_dyn_start = .;
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index fe2ca98..d7adf90 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -33,7 +33,7 @@ SECTIONS
. = ALIGN(4);
.text :
{
- __image_copy_start = .;
+ *(.__image_copy_start)
CPUDIR/start.o (.text*)
*(.text*)
}
@@ -57,7 +57,10 @@ SECTIONS
. = ALIGN(4);
- __image_copy_end = .;
+ .image_copy_end :
+ {
+ *(.__image_copy_end)
+ }
.rel.dyn : {
__rel_dyn_start = .;
diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 7a7c4c0..3767a95 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -39,13 +39,12 @@
ENTRY(relocate_code)
mov r6, r0 /* save addr of destination */
- ldr r0, =_start /* r0 - SRC _start */
+ ldr r0, =__image_copy_start /* r0 - SRC __image_copy_start */
subsr9, r6, r0 /* r9 - relocation offset */
beq relocate_done /* skip relocation */
mov r1, r6 /* r1 - scratch for copy loop */
adr r7, relocate_code /* r7 - SRC relocate_code */
- ldr r3, _image_copy_end_ofs /* r3 - __image_copy_end local ofs */
- add r2, r7, r3 /* r2 - SRC __image_copy_end */
+ ldr r2, =__image_copy_end /* r2 - SRC __image_copy_end */
copy_loop:
ldmia r0!, {r10-r11} /* copy from source address [r0]*/
@@ -89,8 +88,6 @@ relocate_done:
bxlr
#endif
-_image_copy_end_ofs:
- .word __image_copy_end - relocate_code
_rel_dyn_start_ofs:
.word __rel_dyn_start - relocate_code
_rel_dyn_end_ofs:
diff --git a/arch/arm/lib/sections.c b/arch/arm/lib/sections.c
index e52fec9..03e846f 100644
--- a/arch/arm/lib/sections.c
+++ b/arch/arm/lib/sections.c
@@ -37,3 +37,5 @@
char __bss_start[0] __attribute__((section(.__bss_start)));
char __bss_end[0] __attribute__((section(.__bss_end)));
+char __image_copy_start[0] __attribute__((section(.__image_copy_start)));
+char __image_copy_end[0] __attribute__((section(.__image_copy_end)));
diff --git a/board/actux1/u-boot.lds b/board/actux1/u-boot.lds
index 989ad71..531e598 100644
--- a/board/actux1/u-boot.lds
+++ b/board/actux1/u-boot.lds
@@ -30,6 +30,7 @@ SECTIONS
. = ALIGN (4);
.text : {
+ *(.__image_copy_start)
arch/arm/cpu/ixp/start.o(.text*)
net/libnet.o(.text*)
board/actux1/libactux1.o(.text*)
@@ -62,7 +63,10 @@ SECTIONS
. = ALIGN (4);
- __image_copy_end = .;
+ .image_copy_end :
+ {
+
[U-Boot] [PATCH v2 5/6] arm: make __rel_dyn_{start, end} compiler-generated
This change is only done where needed: some linker
scripts may contain relocation symbols yet remain
unchanged.
__rel_dyn_start and __rel_dyn_end each requires
its own output section; putting them in relocation
sections changes their flags and breaks relocation.
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
Changes in v2:
- various comment fixes
arch/arm/cpu/ixp/u-boot.lds| 12 ++--
arch/arm/cpu/u-boot.lds| 12 ++--
arch/arm/lib/relocate.S| 11 ++-
arch/arm/lib/sections.c|2 ++
board/actux1/u-boot.lds| 12 ++--
board/actux2/u-boot.lds| 12 ++--
board/actux3/u-boot.lds| 12 ++--
board/dvlhost/u-boot.lds | 12 ++--
board/freescale/mx31ads/u-boot.lds | 12 ++--
9 files changed, 74 insertions(+), 23 deletions(-)
diff --git a/arch/arm/cpu/ixp/u-boot.lds b/arch/arm/cpu/ixp/u-boot.lds
index 9141199..54bafda 100644
--- a/arch/arm/cpu/ixp/u-boot.lds
+++ b/arch/arm/cpu/ixp/u-boot.lds
@@ -60,10 +60,18 @@ SECTIONS
*(.__image_copy_end)
}
+ .rel_dyn_start :
+ {
+ *(.__rel_dyn_start)
+ }
+
.rel.dyn : {
- __rel_dyn_start = .;
*(.rel*)
- __rel_dyn_end = .;
+ }
+
+ .rel_dyn_end :
+ {
+ *(.__rel_dyn_end)
}
_end = .;
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index d7adf90..3037885 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -62,10 +62,18 @@ SECTIONS
*(.__image_copy_end)
}
+ .rel_dyn_start :
+ {
+ *(.__rel_dyn_start)
+ }
+
.rel.dyn : {
- __rel_dyn_start = .;
*(.rel*)
- __rel_dyn_end = .;
+ }
+
+ .rel_dyn_end :
+ {
+ *(.__rel_dyn_end)
}
_end = .;
diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 3767a95..3f444c1 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -55,10 +55,8 @@ copy_loop:
/*
* fix .rel.dyn relocations
*/
- ldr r2, _rel_dyn_start_ofs /* r2 - __rel_dyn_start local ofs */
- add r2, r2, r7 /* r2 - SRC __rel_dyn_start */
- ldr r3, _rel_dyn_end_ofs/* r3 - __rel_dyn_end local ofs */
- add r3, r3, r7 /* r3 - SRC __rel_dyn_end */
+ ldr r2, =__rel_dyn_start/* r2 - SRC __rel_dyn_start */
+ ldr r3, =__rel_dyn_end /* r3 - SRC __rel_dyn_end */
fixloop:
ldr r0, [r2]/* r0 - SRC location to fix up */
add r0, r0, r9 /* r0 - DST location to fix up */
@@ -88,9 +86,4 @@ relocate_done:
bxlr
#endif
-_rel_dyn_start_ofs:
- .word __rel_dyn_start - relocate_code
-_rel_dyn_end_ofs:
- .word __rel_dyn_end - relocate_code
-
ENDPROC(relocate_code)
diff --git a/arch/arm/lib/sections.c b/arch/arm/lib/sections.c
index 03e846f..5921dd8 100644
--- a/arch/arm/lib/sections.c
+++ b/arch/arm/lib/sections.c
@@ -39,3 +39,5 @@ char __bss_start[0] __attribute__((section(.__bss_start)));
char __bss_end[0] __attribute__((section(.__bss_end)));
char __image_copy_start[0] __attribute__((section(.__image_copy_start)));
char __image_copy_end[0] __attribute__((section(.__image_copy_end)));
+char __rel_dyn_start[0] __attribute__((section(.__rel_dyn_start)));
+char __rel_dyn_end[0] __attribute__((section(.__rel_dyn_end)));
diff --git a/board/actux1/u-boot.lds b/board/actux1/u-boot.lds
index 531e598..74aec5f 100644
--- a/board/actux1/u-boot.lds
+++ b/board/actux1/u-boot.lds
@@ -68,10 +68,18 @@ SECTIONS
*(.__image_copy_end)
}
+ .rel_dyn_start :
+ {
+ *(.__rel_dyn_start)
+ }
+
.rel.dyn : {
- __rel_dyn_start = .;
*(.rel*)
- __rel_dyn_end = .;
+ }
+
+ .rel_dyn_end :
+ {
+ *(.__rel_dyn_end)
}
_end = .;
diff --git a/board/actux2/u-boot.lds b/board/actux2/u-boot.lds
index aff773c..c276501 100644
--- a/board/actux2/u-boot.lds
+++ b/board/actux2/u-boot.lds
@@ -68,10 +68,18 @@ SECTIONS
*(.__image_copy_end)
}
+ .rel_dyn_start :
+ {
+ *(.__rel_dyn_start)
+ }
+
.rel.dyn : {
- __rel_dyn_start = .;
*(.rel*)
- __rel_dyn_end = .;
+ }
+
+ .rel_dyn_end :
+ {
+ *(.__rel_dyn_end)
}
_end = .;
diff --git a/board/actux3/u-boot.lds b/board/actux3/u-boot.lds
index 9d43e95..5610644 100644
--- a/board/actux3/u-boot.lds
+++ b/board/actux3/u-boot.lds
@@ -68,10 +68,18 @@ SECTIONS
*(.__image_copy_end)
}
+ .rel_dyn_start :
+ {
+
[U-Boot] [PATCH v2 3/6] arm: generalize lib/bss.c into lib/sections.c
File arch/arm/lib/bss.c was initially defined for BSS only,
but is now going to also contain definitions for other
section-boundary-related symbols, so rename it for better
accuracy.
Also, remove useless 'used' attributes.
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
Changes in v2: None
arch/arm/lib/Makefile |2 +-
arch/arm/lib/{bss.c = sections.c} |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
rename arch/arm/lib/{bss.c = sections.c} (92%)
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 30e3290..dbad5c1 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -43,7 +43,7 @@ SOBJS-y += relocate.o
ifndef CONFIG_SYS_GENERIC_BOARD
COBJS-y+= board.o
endif
-COBJS-y += bss.o
+COBJS-y += sections.o
COBJS-y+= bootm.o
COBJS-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
diff --git a/arch/arm/lib/bss.c b/arch/arm/lib/sections.c
similarity index 92%
rename from arch/arm/lib/bss.c
rename to arch/arm/lib/sections.c
index 99eda59..e52fec9 100644
--- a/arch/arm/lib/bss.c
+++ b/arch/arm/lib/sections.c
@@ -35,5 +35,5 @@
* aliasing warnings.
*/
-char __bss_start[0] __attribute__((used, section(.__bss_start)));
-char __bss_end[0] __attribute__((used, section(.__bss_end)));
+char __bss_start[0] __attribute__((section(.__bss_start)));
+char __bss_end[0] __attribute__((section(.__bss_end)));
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 6/6] arm: optimize relocate_code routine
Use section symbols directly
Drop support for R_ARM_ABS32 record types
Eliminate unneeded intermediate registers
Optimize relocation table iteration
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
Changes in v2: None
arch/arm/lib/relocate.S | 32
1 file changed, 12 insertions(+), 20 deletions(-)
diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 3f444c1..949b9e8 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -37,19 +37,15 @@
*/
ENTRY(relocate_code)
- mov r6, r0 /* save addr of destination */
-
- ldr r0, =__image_copy_start /* r0 - SRC __image_copy_start */
- subsr9, r6, r0 /* r9 - relocation offset */
+ ldr r1, =__image_copy_start /* r1 - SRC __image_copy_start */
+ subsr9, r0, r1 /* r9 - relocation offset */
beq relocate_done /* skip relocation */
- mov r1, r6 /* r1 - scratch for copy loop */
- adr r7, relocate_code /* r7 - SRC relocate_code */
ldr r2, =__image_copy_end /* r2 - SRC __image_copy_end */
copy_loop:
- ldmia r0!, {r10-r11} /* copy from source address [r0]*/
- stmia r1!, {r10-r11} /* copy to target address [r1]*/
- cmp r0, r2 /* until source end address [r2]*/
+ ldmia r1!, {r10-r11} /* copy from source address [r1]*/
+ stmia r0!, {r10-r11} /* copy to target address [r0]*/
+ cmp r1, r2 /* until source end address [r2]*/
blo copy_loop
/*
@@ -58,21 +54,17 @@ copy_loop:
ldr r2, =__rel_dyn_start/* r2 - SRC __rel_dyn_start */
ldr r3, =__rel_dyn_end /* r3 - SRC __rel_dyn_end */
fixloop:
- ldr r0, [r2]/* r0 - SRC location to fix up */
- add r0, r0, r9 /* r0 - DST location to fix up */
- ldr r1, [r2, #4]
- and r7, r1, #0xff
- cmp r7, #23 /* relative fixup? */
- beq fixrel
- /* ignore unknown type of fixup */
- b fixnext
-fixrel:
+ ldmia r2!, {r0-r1}/* (r0,r1) - (SRC location,fixup) */
+ and r1, r1, #0xff
+ cmp r1, #23 /* relative fixup? */
+ bne fixnext
+
/* relative fix: increase location by offset */
+ add r0, r0, r9
ldr r1, [r0]
add r1, r1, r9
-fixnext:
str r1, [r0]
- add r2, r2, #8 /* each rel.dyn entry is 8 bytes */
+fixnext:
cmp r2, r3
blo fixloop
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] build: Use generic boot logo matching
Dear Otavio Salvador, In message 1369693124-26106-1-git-send-email-ota...@ossystems.com.br you wrote: The boot logo matching is now done in following way: - use LOGO_BMP if it is set, or - use $(BOARD).bmp if it exists in tools/logos, or - use $(VENDOR).bmp if it exists in tools/logos, or - use denx.bmp otherwise. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- Changes in v3: - New patch, which replaces the 1/2 from v1 and v2 Looks good to me, at least it solves the immediate issues. Thanks! Acked-by: Wolfgang Denk w...@denx.de 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 I'm not a god, I was misquoted. - Lister, Red Dwarf ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SF: Add Spansion S25FL064P IDs
On 28-08-2012 20:43, Marek Vasut wrote:
This is a S25FL064A successor. It supports up to 104MHz bus
speed.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Heiko Schocher h...@denx.de
Cc: Mike Frysinger vap...@gentoo.org
Cc: Scott Wood scottw...@freescale.com
Cc: Wolfgang Denk w...@denx.de
---
drivers/mtd/spi/spansion.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
index 9a114ac..faf4414 100644
--- a/drivers/mtd/spi/spansion.c
+++ b/drivers/mtd/spi/spansion.c
@@ -90,6 +90,13 @@ static const struct spansion_spi_flash_params
spansion_spi_flash_table[] = {
.name = S25FL032P,
},
{
+ .idcode1 = 0x0216,
+ .idcode2 = 0x4d00,
+ .pages_per_sector = 256,
+ .nr_sectors = 128,
+ .name = S25FL064P,
+ },
+ {
.idcode1 = 0x2018,
.idcode2 = 0x4d01,
.pages_per_sector = 256,
Applied to u-boot-spi/master
--
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Wandboard: Add support for Wandboard quad
On Mon, 27 May 2013 13:56:30 -0300 Otavio Salvador ota...@ossystems.com.br wrote: I have sent two patches for adding the Boot Splash with Wandboard logo. Please take a look on them and if you agree please base on this to avoid conflicts. (For easyness: http://patchwork.ozlabs.org/bundle/otavio/wandboard-20130527/ ) Otavio, while I do agree with the work you are doing (HDMI bootlogo into mainline), and would not have minded to base my patches on top of yours. However, the patches you sent seem to have been NAK:ed. The v3 does not apply on top of 2013.04 (maybe I am basing on the wrong release!?). So for now, I am basing the resubmission on the 2013.04 release. regards, //Tapani ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Wandboard: Add support for Wandboard quad
On Mon, 27 May 2013 07:22:42 -0300 Fabio Estevam feste...@gmail.com wrote: Hi Tapani, On Mon, May 27, 2013 at 1:13 AM, Tapani Utriainen tap...@technexion.com wrote: Add support for the Wandboard quad. Signed-off-by: Tapani Utriainen tap...@technexion.com --- boards.cfg | 1 + include/configs/wandboard.h | 2 ++ 2 files changed, 3 insertions(+) It looks good. Could you also add an entry for the quad version into the README file? Regards, Fabio Estevam Fabio, thank you, will do (resubmitting a v2). //Tapani ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] sf: winbond: Add support for W25PXX SPI flash
On 23-05-2013 20:39, Kuo-Jung Su wrote:
From: Kuo-Jung Su dant...@faraday-tech.com
Add support for Winbond's W25PXX SPI flash.
These devices is used on Faraday A369 evaluation board.
Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
CC: Jagan Teki jagannadh.t...@gmail.com
CC: Tom Rini tr...@ti.com
---
Changes for v2:
- Update commit message header
- Add commit message body
drivers/mtd/spi/winbond.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index 2716209..2a27837 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -18,6 +18,21 @@ struct winbond_spi_flash_params {
static const struct winbond_spi_flash_params winbond_spi_flash_table[] = {
{
+ .id = 0x2014,
+ .nr_blocks = 16,
+ .name = W25P80,
+ },
+ {
+ .id = 0x2015,
+ .nr_blocks = 32,
+ .name = W25P16,
+ },
+ {
+ .id = 0x2016,
+ .nr_blocks = 64,
+ .name = W25P32,
+ },
+ {
.id = 0x3013,
.nr_blocks = 8,
.name = W25X40,
@@ -104,7 +119,7 @@ struct spi_flash *spi_flash_probe_winbond(struct spi_slave
*spi, u8 *idcode)
}
flash-page_size = 256;
- flash-sector_size = 4096;
+ flash-sector_size = (idcode[1] == 0x20) ? 65536 : 4096;
flash-size = 4096 * 16 * params-nr_blocks;
return flash;
Applied to u-boot-spi/master
--
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,4/4] sf: winbond: Add support for W25Q256
On 23-02-2013 07:09, Jagannadha Sutradharudu Teki wrote:
Add support for Winbond W25Q256 SPI flash.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
drivers/mtd/spi/winbond.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index 4418302..ceec0cb 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -63,6 +63,11 @@ static const struct winbond_spi_flash_params
winbond_spi_flash_table[] = {
.name = W25Q128,
},
{
+ .id = 0x4019,
+ .nr_blocks = 512,
+ .name = W25Q256,
+ },
+ {
.id = 0x5014,
.nr_blocks = 128,
.name = W25Q80,
Applied to u-boot-spi/master
--
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/10] powerpc/ppc4xx: Use generic FPGA accessors on all gdsys 405ep/ex boards
Hello Wolfgang,
would you please have a look at this? I need some feedback to get this
finally sorted.
Cheers
Dirk
2013/5/15 Dirk Eibach dirk.eib...@gdsys.cc:
Hello Wolfgang,
sorry for the delay, I had to clean some other things on my ToDoList.
I cleaned up my patchseries and wanted to start implementing your proposal.
And ran into a problem. Remember, the basic reason for the the generic FPGA
accessors was, that we have a certain amount of basically identical FPGAs
which are only connected to the CPU in different ways. The drivers accessing
those FPGAs should be agnostic of that and simply be able to access those
FPGAs by index.
It appears you need both the element address and the offset in your
fpga_set_reg() code, so you should pass this information, like that
[note that we no longer need an array of addresses]:
struct ihs_fpga fpga_ptr = (struct ihs_fpga *)CONFIG_SYS_FPGA_BASE;
...
void fpga_set_reg(u32 fpga, u16 *reg, off_t regoff, u16 data)
{
if (fpga)
return mclink_send(fpga - 1, regoff, data);
return out_le16(reg, data);
}
where mclink_send() is the routine to access the non memory mapped
FPGAs through the memory mapped FPGA:
int mclink_send(u8 slave, u16 addr, u16 data)
{
...
fpga_set_reg(0, system_fpgas[0].mc_tx_address, addr);
fpga_set_reg(0, system_fpgas[0].mc_tx_data, data);
fpga_set_reg(0, system_fpgas[0].mc_tx_cmd, (slave 0x03)
14);
}
And this becomes:
fpga_set_reg(0,
fpga_ptr-mc_tx_address,
offsetof(struct ihs_fpga, mc_tx_address),
addr);
etc. Yes, this is long and ugly to write, so you may want to define a
helper macro like:
#define FPGA_SET_REG(ix,fld,val)\
fpga_set_reg((ix), \
fpga_ptr-fld, \
offsetof(struct ihs_fpga, fld), \
val)
so this turns into a plain and simple
FPGA_SET_REG(0, mc_tx_address, addr);
FPGA_SET_REG(0, mc_tx_data, data);
FPGA_SET_REG(0, mc_tx_cmd, (slave 0x03) 14);
This works nicely for our memory mapped FPGA. But how about the other FPGAs?
I don't have a fpga_ptr for them. Setting it NULL would make FPGA_SET_REG
dereference a NULL pointer.
Certainly I might call
fpga_set_reg(1,
NULL,
offsetof(struct ihs_fpga, mc_tx_address),
addr);
but that would not be generic any more.
Do you have any idea how to solve this?
Cheers
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/10] powerpc/ppc4xx: Use generic FPGA accessors on all gdsys 405ep/ex boards
Hello Wolfgang,
would you please have a look at this? I need some feedback to get this
finally sorted.
Cheers
Dirk
2013/5/15 Dirk Eibach dirk.eib...@gdsys.cc:
Hello Wolfgang,
sorry for the delay, I had to clean some other things on my ToDoList.
I cleaned up my patchseries and wanted to start implementing your proposal.
And ran into a problem. Remember, the basic reason for the the generic FPGA
accessors was, that we have a certain amount of basically identical FPGAs
which are only connected to the CPU in different ways. The drivers accessing
those FPGAs should be agnostic of that and simply be able to access those
FPGAs by index.
It appears you need both the element address and the offset in your
fpga_set_reg() code, so you should pass this information, like that
[note that we no longer need an array of addresses]:
struct ihs_fpga fpga_ptr = (struct ihs_fpga *)CONFIG_SYS_FPGA_BASE;
...
void fpga_set_reg(u32 fpga, u16 *reg, off_t regoff, u16 data)
{
if (fpga)
return mclink_send(fpga - 1, regoff, data);
return out_le16(reg, data);
}
where mclink_send() is the routine to access the non memory mapped
FPGAs through the memory mapped FPGA:
int mclink_send(u8 slave, u16 addr, u16 data)
{
...
fpga_set_reg(0, system_fpgas[0].mc_tx_address, addr);
fpga_set_reg(0, system_fpgas[0].mc_tx_data, data);
fpga_set_reg(0, system_fpgas[0].mc_tx_cmd, (slave 0x03)
14);
}
And this becomes:
fpga_set_reg(0,
fpga_ptr-mc_tx_address,
offsetof(struct ihs_fpga, mc_tx_address),
addr);
etc. Yes, this is long and ugly to write, so you may want to define a
helper macro like:
#define FPGA_SET_REG(ix,fld,val)\
fpga_set_reg((ix), \
fpga_ptr-fld, \
offsetof(struct ihs_fpga, fld), \
val)
so this turns into a plain and simple
FPGA_SET_REG(0, mc_tx_address, addr);
FPGA_SET_REG(0, mc_tx_data, data);
FPGA_SET_REG(0, mc_tx_cmd, (slave 0x03) 14);
This works nicely for our memory mapped FPGA. But how about the other FPGAs?
I don't have a fpga_ptr for them. Setting it NULL would make FPGA_SET_REG
dereference a NULL pointer.
Certainly I might call
fpga_set_reg(1,
NULL,
offsetof(struct ihs_fpga, mc_tx_address),
addr);
but that would not be generic any more.
Do you have any idea how to solve this?
Cheers
Dirk
___
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] minimum bdi config to read flash on 85xx
Hi Fabio, The CPU is imx6 customed processor. The Prog command shows it passed but the u-boot.bin is not uploaded. Regards, Monica.S From: Fabio Estevam-2 [via U-Boot] [mailto:ml-node+s10912n155717...@n7.nabble.com] Sent: Monday, May 27, 2013 7:08 PM To: Monica Sampathkumar Subject: Re: minimum bdi config to read flash on 85xx Hi Monica, On Mon, May 27, 2013 at 10:01 AM, Monica [hidden email]/user/SendEmail.jtp?type=nodenode=155717i=0 wrote: We are using BDI3000 to Burn u-boot.bin to Flash memory. The flash we are using is Spansion S29GL512S. As per the flash datasheet we tried programming 4 bytes( using telnet mmb command) write buffer programming cycle. We succeeded. But when we tried programming a binary file ( u-boot.bin) ,it was failing. Even though the log shows Flash programming passed but in the location when we do a mdh there is no u-boot data. Please find the log captured below. IMX6#0 Your email subject mentions 85xx, but the prompt above says mx6. Which CPU does your board have? ___ U-Boot mailing list [hidden email]/user/SendEmail.jtp?type=nodenode=155717i=1 http://lists.denx.de/mailman/listinfo/u-boot If you reply to this email, your message will be added to the discussion below: http://u-boot.10912.n7.nabble.com/minimum-bdi-config-to-read-flash-on-85xx-tp23684p155717.html To unsubscribe from minimum bdi config to read flash on 85xx, click herehttp://u-boot.10912.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=23684code=bW9uaWNhX3NAaGNsLmNvbXwyMzY4NHw3MDA1NTgxNTM=. NAMLhttp://u-boot.10912.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- View this message in context: http://u-boot.10912.n7.nabble.com/minimum-bdi-config-to-read-flash-on-85xx-tp23684p155770.html Sent from the U-Boot mailing list archive at Nabble.com.___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Add support for Wandboard quad.
Add support for Wandboard quad. Signed-off-by: Tapani Utriainen tap...@technexion.com --- Changes from v1: - reorganized the board names into alphabetical order - added quad entry to the Wandboard README board/wandboard/README | 5 + boards.cfg | 1 + include/configs/wandboard.h | 2 ++ 3 files changed, 8 insertions(+) diff --git a/board/wandboard/README b/board/wandboard/README index e0b0b33..ff43e03 100644 --- a/board/wandboard/README +++ b/board/wandboard/README @@ -17,6 +17,11 @@ To build U-Boot for the Wandboard Dual Lite version: $ make wanboard_dl_config $ make +To build U-Boot for the Wandboard Quad version: + +$ make wandboard_quad_config +$ make + To build U-Boot for the Wandboard Solo version: $ make wanboard_solo_config diff --git a/boards.cfg b/boards.cfg index 98a512e..b510555 100644 --- a/boards.cfg +++ b/boards.cfg @@ -267,6 +267,7 @@ nitrogen6q2g arm armv7 nitrogen6x boundar nitrogen6s arm armv7 nitrogen6x boundary mx6 nitrogen6x:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6s.cfg,MX6S,DDR_MB=512 nitrogen6s1g arm armv7 nitrogen6x boundary mx6 nitrogen6x:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6s1g.cfg,MX6S,DDR_MB=1024 wandboard_dlarm armv7 wandboard - mx6 wandboard:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6dl.cfg,MX6DL,DDR_MB=1024 +wandboard_quad arm armv7 wandboard - mx6 wandboard:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q2g.cfg,MX6Q,DDR_MB=2048 wandboard_solo arm armv7 wandboard - mx6 wandboard:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6s.cfg,MX6S,DDR_MB=512 cm_t35 arm armv7 cm_t35 - omap3 omap3_overo arm armv7 overo - omap3 diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h index 120e3f6..ac86626 100644 --- a/include/configs/wandboard.h +++ b/include/configs/wandboard.h @@ -83,6 +83,8 @@ #if defined(CONFIG_MX6DL) #define CONFIG_DEFAULT_FDT_FILEimx6dl-wandboard.dtb +#elif defined(CONFIG_MX6Q) +#define CONFIG_DEFAULT_FDT_FILEimx6q-wandboard.dtb #elif defined(CONFIG_MX6S) #define CONFIG_DEFAULT_FDT_FILEimx6s-wandboard.dtb #endif -- 1.8.0.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Wandboard: Add support for Wandboard quad
On 28/05/2013 09:44, Tapani Utriainen wrote: Hi Tapani, Otavio, while I do agree with the work you are doing (HDMI bootlogo into mainline), and would not have minded to base my patches on top of yours. However, the patches you sent seem to have been NAK:ed. The v3 does not apply on top of 2013.04 (maybe I am basing on the wrong release!?). So for now, I am basing the resubmission on the 2013.04 release. regards, Even if you are not constrained to take care of underlying patches (this can maybe discussed in this mailing list if it is strictly required, but of course it helps to avoid conflicts), it is not correct to stick with a release. Basis for development is TOT on git.denx.de/u-boot.git, or, for the i.MXes, git.denx.de/u-boot-imx. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-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] [PATCH v3 0/6] arm: mvf600: Add Freescale Vybrid MVF600 CPU and MVF600TWR board support
Hi, Stefano, On 24/05/2013 08:18, Wang Huan-B18965 wrote: [Alison Wang] We usually named the Powerpc(before QorIQ) as MPC and ColdFire as MCF, So we generally named the Vybrid as MVF. We had some internal discussion for this, and we think we should use VF instead of MVF, we will follow the internal suggestions to name the soc as VF610. Thanks for your comments. It is nice if you use the same name everybody finds on Freescale's Website. However, I hope you decide that the names will be consistent with the kernel, and also the patches that are currently posted to linux-arm will change the processor name. The worst thing is if we get a name in u-boot and another one in kernel. [Alison Wang] Thanks for your reminder, we have discussed this with the kernel maintainer and get agreement to use the SoC name vf610. We'll use the 'vf610' in both u-boot and kernel. any comments for the name? Thanks. Best Regards, Alison Wang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/6] arm: mvf600: Add Freescale Vybrid MVF600 CPU and MVF600TWR board support
Hi, benoit, On Tuesday, May 21, 2013 11:02:55 AM, Alison Wang wrote: This series contain the support for Freescale Vybrid MVF600 CPU and MVF600TWR board. Vybird devices are built on an asymmetrical-multiprocessing architecture using ARM cores. The families in the Vybrid portfolio span entry-level, single core Cortex-A class SoCs all the way to dual heterogeneous core SoCs with multiple communication and connectivity options. Part of the Vybrid platform, MVF600 is a dual-core eMPU combining the ARM Cortex A5 and Cortex M4 cores. MVF600 shares some IPs with i.MX family, such as FEC,ESDHC,WATCHDOG,I2C,ASRC and ESAI. MVF600 also shares some IPs with ColdFire family, such as eDMA and DSPI. MVF600 still has its own IPs, such as PIT,SAI,UART,QSPI and DCU. More documents for this soc can be found at: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=VF6 xxf srch=1sr=5 http://www.freescale.com/webapp/sps/site/homepage.jsp?code=VYBRI D I have a question about the naming of this SoC. On Freescale's website, it is VF6xx everywhere, but you add a leading M (_M_VF600). Is it because you are using an internal SoC name known only by Freescale and different from the marketing SoC name, or is this M from the part number, or will the marketing SoC name change later, or some other reason? Please clarify. U-Boot users must be able to identify a SoC and to find information about it easily. [Alison Wang] We always use the name MVF600 in the internal development. We will check it with marketing team, and confirm it. Thanks. OK. You should also check for each part of the code in this patch set if it is specific to the (M)VF600 or common to all (M)VF6xx SoCs. In the latter case, the names in the code should be changed to either (m)vf6xx or (m)vf6, just like U-Boot uses mx5 to mean i.MX5xx. The naming for your Linux patches should also preferably be the same as in U-Boot in order to avoid confusion for users. [Alison Wang] We usually named the Powerpc(before QorIQ) as MPC and ColdFire as MCF, So we generally named the Vybrid as MVF. We had some internal discussion for this, and we think we should use VF instead of MVF, we will follow the internal suggestions to name the soc as VF610. Thanks for your comments. We have no detail spec for other vf6xx chips so far, so from technical side we can only make sure current code in this patch set is work for VF610. So we'll use VF610 instead of vf6xx. [Alison Wang] Do you have any comments about the SoC name? I'd like to send out the next version patch set based on the new SoC name vf610. Thanks. Best Regards, Alison Wang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/6] arm: mvf600: Add Freescale Vybrid MVF600 CPU and MVF600TWR board support
On 28/05/2013 10:51, Wang Huan-B18965 wrote: Hi, Stefano, On 24/05/2013 08:18, Wang Huan-B18965 wrote: [Alison Wang] We usually named the Powerpc(before QorIQ) as MPC and ColdFire as MCF, So we generally named the Vybrid as MVF. We had some internal discussion for this, and we think we should use VF instead of MVF, we will follow the internal suggestions to name the soc as VF610. Thanks for your comments. It is nice if you use the same name everybody finds on Freescale's Website. However, I hope you decide that the names will be consistent with the kernel, and also the patches that are currently posted to linux-arm will change the processor name. The worst thing is if we get a name in u-boot and another one in kernel. [Alison Wang] Thanks for your reminder, we have discussed this with the kernel maintainer and get agreement to use the SoC name vf610. We'll use the 'vf610' in both u-boot and kernel. any comments for the name? Thanks. No, you are the developer, you work in Freescale and your is the final decision about the names. My point of view, and maybe it is the same for most of Freescale's customers, is to have consistent names. Everybody checking Freescale's website knows that the SOC / board is supported in u-boot and/or kernel if he finds the same names as on the website. But is the mx53loco the same as mx53qsb, the official name to buy the board ? Of course, it is the same, but not at the first glance. Or mx51evk and babbage ? Or (following some other bad examples...) ? Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-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
[U-Boot] [PATCH v4 4/7] arm: vf610: Add watchdog support for Vybrid VF610
This patch adds watchdog support for Vybrid VF610 platform. Signed-off-by: Alison Wang b18...@freescale.com --- Changes in v4: - Rename mvf600 to vf610 Changes in v3: None Changes in v2: - Add watchdog support - Use reset_cpu() in imx_watchdog.c drivers/watchdog/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index 13e7c37..e96acab 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -27,7 +27,7 @@ LIB := $(obj)libwatchdog.o COBJS-$(CONFIG_AT91SAM9_WATCHDOG) += at91sam9_wdt.o COBJS-$(CONFIG_FTWDT010_WATCHDOG) += ftwdt010_wdt.o -ifneq (,$(filter $(SOC), mx31 mx35 mx5 mx6)) +ifneq (,$(filter $(SOC), mx31 mx35 mx5 mx6 vf610)) COBJS-y += imx_watchdog.o endif COBJS-$(CONFIG_TNETV107X_WATCHDOG) += tnetv107x_wdt.o -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/7] arm: vf610: Add Freescale Vybrid VF610 CPU and VF610TWR board support
This series contain the support for Freescale Vybrid VF610 CPU and VF610TWR board. Vybird devices are built on an asymmetrical-multiprocessing architecture using ARM cores. The families in the Vybrid portfolio span entry-level, single core Cortex-A class SoCs all the way to dual heterogeneous core SoCs with multiple communication and connectivity options. Part of the Vybrid platform, VF610 is a dual-core eMPU combining the ARM Cortex A5 and Cortex M4 cores. VF610 shares some IPs with i.MX family, such as FEC,ESDHC,WATCHDOG,I2C,ASRC and ESAI. VF610 also shares some IPs with ColdFire family, such as eDMA and DSPI. VF610 still has its own IPs, such as PIT,SAI,UART,QSPI and DCU. More documents for this soc can be found at: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=VF6xxfsrch=1sr=5 http://www.freescale.com/webapp/sps/site/homepage.jsp?code=VYBRID To align with the description in the above documents, VF610 is used as the SoC name instead of MVF600. The u-boot runs on Cortex A5 core. Changes in v4: - Rename MVF600 to VF610 - Define PAD_CTL_PUS_47K_UP and PAD_CTL_PUS_100K_UP with PAD_CTL_PUE enabled - Reorganize the definitions - Correct the spaces and tabs - Rename mvf_pins.h to iomux-vf610.h - Add README.vf610 about fuse assignments for MAC addresses - Rename directory name 'mvf600' to 'vf610' - Rename directory 'arch-mvf600' to 'arch-vf610' - Add Vybrid VF610 to mxc_ocotp document - Rename directory name 'mvf600twr' to 'vf610twr' - Rename mvf600twr.h to vf610twr.h - Use NEW_PAD_CTRL instead of MUX_PAD_CTRL - Remove CONFIG_ETHPRIME option - Add CONFIG_CMD_MEMSET option Changes in v3: - Rename the common functions and enums - Move the structure definitions to imx-regs.h - Define PAD_CTL_PUE with PKE enabled - Remove the changes for FEC_RCNTRL_RGMII / FEC_RCNTRL_RMII / FEC_RCNTRL_MII_MODE bits, as they are already set in fec_reg_setup() - Replace BOOT_FROM by BOOT_OFFSET - Enable CONFIG_OF_LIBFDT option - Add useful define instead of raw number - Use clrsetbits_le32 to set the single bits - Move setup_iomux_enet() to board_early_init_f and remove board_eth_init() - Remove redundant define - Move CONFIG_IOMUX_SHARE_CONF_REG to imx-regs.h Changes in v2: - Remove vybrid-common directory - Rename directory name 'vybrid' to 'mvf600' - Add generic.c file - Rewrite get_reset_cause() to make it readable - Remove reset_cpu(), and use the function in imx_watchdog.c - Rewrite timer.c file - Use vybrid_get_clock(VYBRID_UART_CLK) instead of vybrid_get_uartclk() - Remove lowlevel_init.S, and add clock_init() in board_early_init_f() - Remove useless CONFIG_SYS_ defines - Move CONFIG_MACH_TYPE to board configuration file - Define C structures and access C structures to set/read registers - Remove useless errata - Remove useless macros - Rename directory 'arch-vybrid' to 'arch-mvf600' - Use common iomux-v3 code - Use common FEC driver fec_mxc.c - Add watchdog support - Add an entry to MAINTAINERS file - Rename directory name 'vybird' to 'mvf600twr' - Use standard method to set gd-ram_size - Rewrite board_mmc_getcd() function - Remove useless undef - Remove hardcoded IP addresses and MAC addresses - Move CONFIG_MACH_TYPE to board configuration file Alison Wang (7): arm: vf610: Add IOMUX support for Vybrid VF610 arm: vf610: Add Vybrid VF610 CPU support net: fec_mxc: Add support for Vybrid VF610 arm: vf610: Add watchdog support for Vybrid VF610 arm: vf610: Add uart support for Vybrid VF610 arm: vf610: Add Vybrid VF610 to mxc_ocotp document arm: vf610: Add basic support for Vybrid VF610TWR board MAINTAINERS | 4 + Makefile | 2 +- arch/arm/cpu/armv7/vf610/Makefile | 42 +++ arch/arm/cpu/armv7/vf610/generic.c| 324 +++ arch/arm/cpu/armv7/vf610/timer.c | 103 ++ arch/arm/imx-common/Makefile | 2 +- arch/arm/imx-common/iomux-v3.c| 6 ++ arch/arm/include/asm/arch-vf610/clock.h | 39 ++ arch/arm/include/asm/arch-vf610/crm_regs.h| 225 +++ arch/arm/include/asm/arch-vf610/imx-regs.h| 419 +++ arch/arm/include/asm/arch-vf610/iomux-vf610.h | 101 + arch/arm/include/asm/imx-common/iomux-v3.h| 18 + board/freescale/vf610twr/Makefile | 39 ++ board/freescale/vf610twr/imximage.cfg | 33 + board/freescale/vf610twr/vf610twr.c | 410 boards.cfg| 1 +
[U-Boot] [PATCH v4 1/7] arm: vf610: Add IOMUX support for Vybrid VF610
This patch adds the IOMUX support for Vybrid VF610 platform. There is a little difference for IOMUXC module between VF610 and i.MX platform, the muxmode and pad configuration share one 32bit register on VF610, but they are two independent registers on I.MX platform. A CONFIG_IOMUX_SHARE_CONFIG_REG was introduced to fit this difference. Signed-off-by: Alison Wang b18...@freescale.com --- Changes in v4: - Rename MVF600 to VF610 - Define PAD_CTL_PUS_47K_UP and PAD_CTL_PUS_100K_UP with PAD_CTL_PUE enabled - Reorganize the definitions - Correct the spaces and tabs Changes in v3: - Define PAD_CTL_PUE with PKE enabled Changes in v2: - Use common iomux-v3 code arch/arm/imx-common/Makefile | 2 +- arch/arm/imx-common/iomux-v3.c | 6 ++ arch/arm/include/asm/imx-common/iomux-v3.h | 18 ++ 3 files changed, 25 insertions(+), 1 deletion(-) diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile index 8bba8a5..9492326 100644 --- a/arch/arm/imx-common/Makefile +++ b/arch/arm/imx-common/Makefile @@ -27,7 +27,7 @@ include $(TOPDIR)/config.mk LIB = $(obj)libimx-common.o -ifeq ($(SOC),$(filter $(SOC),mx25 mx35 mx5 mx6)) +ifeq ($(SOC),$(filter $(SOC),mx25 mx35 mx5 mx6 vf610)) COBJS-y= iomux-v3.o endif ifeq ($(SOC),$(filter $(SOC),mx5 mx6)) diff --git a/arch/arm/imx-common/iomux-v3.c b/arch/arm/imx-common/iomux-v3.c index 7fe5ce7..35880c7 100644 --- a/arch/arm/imx-common/iomux-v3.c +++ b/arch/arm/imx-common/iomux-v3.c @@ -48,8 +48,14 @@ void imx_iomux_v3_setup_pad(iomux_v3_cfg_t pad) if (sel_input_ofs) __raw_writel(sel_input, base + sel_input_ofs); +#ifdef CONFIG_IOMUX_SHARE_CONF_REG + if (!(pad_ctrl NO_PAD_CTRL)) + __raw_writel((mux_mode PAD_MUX_MODE_SHIFT) | pad_ctrl, + base + pad_ctrl_ofs); +#else if (!(pad_ctrl NO_PAD_CTRL) pad_ctrl_ofs) __raw_writel(pad_ctrl, base + pad_ctrl_ofs); +#endif } void imx_iomux_v3_setup_multiple_pads(iomux_v3_cfg_t const *pad_list, diff --git a/arch/arm/include/asm/imx-common/iomux-v3.h b/arch/arm/include/asm/imx-common/iomux-v3.h index 0b4e763..ebf54cf 100644 --- a/arch/arm/include/asm/imx-common/iomux-v3.h +++ b/arch/arm/include/asm/imx-common/iomux-v3.h @@ -121,6 +121,24 @@ typedef u64 iomux_v3_cfg_t; #define PAD_CTL_DSE_40ohm (6 3) #define PAD_CTL_DSE_34ohm (7 3) +#elif defined(CONFIG_VF610) + +#define PAD_MUX_MODE_SHIFT 20 + +#define PAD_CTL_SPEED_MED (1 12) +#define PAD_CTL_SPEED_HIGH (3 12) + +#define PAD_CTL_DSE_50ohm (3 6) +#define PAD_CTL_DSE_25ohm (6 6) +#define PAD_CTL_DSE_20ohm (7 6) + +#define PAD_CTL_PUS_47K_UP (1 4 | PAD_CTL_PUE) +#define PAD_CTL_PUS_100K_UP(2 4 | PAD_CTL_PUE) +#define PAD_CTL_PKE(1 3) +#define PAD_CTL_PUE(1 2 | PAD_CTL_PKE) + +#define PAD_CTL_OBE_IBE_ENABLE (3 0) + #else #define PAD_CTL_DVS(1 13) -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 5/7] arm: vf610: Add uart support for Vybrid VF610
This patch adds lpuart support for Vybrid VF610 platform.
Signed-off-by: TsiChung Liew tsicl...@gmail.com
Signed-off-by: Alison Wang b18...@freescale.com
---
Changes in v4: None
Changes in v3:
- Move the structure definition to imx-regs.h
Changes in v2:
- Define C structures and access C structures to set/read registers
- Change the names to reuse this driver on other platforms
drivers/serial/Makefile| 1 +
drivers/serial/serial_lpuart.c | 132 +
2 files changed, 133 insertions(+)
create mode 100644 drivers/serial/serial_lpuart.c
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index fbc4e97..bb6559b 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -52,6 +52,7 @@ COBJS-$(CONFIG_XILINX_UARTLITE) += serial_xuartlite.o
COBJS-$(CONFIG_SANDBOX_SERIAL) += sandbox.o
COBJS-$(CONFIG_SCIF_CONSOLE) += serial_sh.o
COBJS-$(CONFIG_ZYNQ_SERIAL) += serial_zynq.o
+COBJS-$(CONFIG_FSL_LPUART) += serial_lpuart.o
ifndef CONFIG_SPL_BUILD
COBJS-$(CONFIG_USB_TTY) += usbtty.o
diff --git a/drivers/serial/serial_lpuart.c b/drivers/serial/serial_lpuart.c
new file mode 100644
index 000..51d5666
--- /dev/null
+++ b/drivers/serial/serial_lpuart.c
@@ -0,0 +1,132 @@
+/*
+ * 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 watchdog.h
+#include asm/io.h
+#include serial.h
+#include linux/compiler.h
+#include asm/arch/imx-regs.h
+#include asm/arch/clock.h
+
+#define US1_TDRE(1 7)
+#define US1_RDRF(1 5)
+#define UC2_TE (1 3)
+#define UC2_RE (1 2)
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct lpuart_fsl *base = (struct lpuart_fsl *)LPUART_BASE;
+
+static void lpuart_serial_setbrg(void)
+{
+ u32 clk = mxc_get_clock(MXC_UART_CLK);
+ u16 sbr;
+
+ if (!gd-baudrate)
+ gd-baudrate = CONFIG_BAUDRATE;
+
+ sbr = (u16)(clk / (16 * gd-baudrate));
+ /* place adjustment later - n/32 BRFA */
+
+ __raw_writeb(sbr 8, base-ubdh);
+ __raw_writeb(sbr 0xff, base-ubdl);
+}
+
+static int lpuart_serial_getc(void)
+{
+ u8 status;
+
+ while (!(__raw_readb(base-us1) US1_RDRF))
+ WATCHDOG_RESET();
+
+ status = __raw_readb(base-us1);
+ status |= US1_RDRF;
+ __raw_writeb(status, base-us1);
+
+ return __raw_readb(base-ud);
+}
+
+static void lpuart_serial_putc(const char c)
+{
+ if (c == '\n')
+ serial_putc('\r');
+
+ while (!(__raw_readb(base-us1) US1_TDRE))
+ WATCHDOG_RESET();
+
+ __raw_writeb(c, base-ud);
+}
+
+/*
+ * Test whether a character is in the RX buffer
+ */
+static int lpuart_serial_tstc(void)
+{
+ if (__raw_readb(base-urcfifo) == 0)
+ return 0;
+
+ return 1;
+}
+
+/*
+ * Initialise the serial port with the given baudrate. The settings
+ * are always 8 data bits, no parity, 1 stop bit, no start bits.
+ */
+static int lpuart_serial_init(void)
+{
+ u8 ctrl;
+
+ ctrl = __raw_readb(base-uc2);
+ ctrl = ~UC2_RE;
+ ctrl = ~UC2_TE;
+ __raw_writeb(ctrl, base-uc2);
+
+ __raw_writeb(0, base-umodem);
+ __raw_writeb(0, base-uc1);
+
+ /* provide data bits, parity, stop bit, etc */
+
+ serial_setbrg();
+
+ __raw_writeb(UC2_RE | UC2_TE, base-uc2);
+
+ return 0;
+}
+
+static struct serial_device lpuart_serial_drv = {
+ .name = lpuart_serial,
+ .start = lpuart_serial_init,
+ .stop = NULL,
+ .setbrg = lpuart_serial_setbrg,
+ .putc = lpuart_serial_putc,
+ .puts = default_serial_puts,
+ .getc = lpuart_serial_getc,
+ .tstc = lpuart_serial_tstc,
+};
+
+void lpuart_serial_initialize(void)
+{
+ serial_register(lpuart_serial_drv);
+}
+
+__weak struct serial_device *default_serial_console(void)
+{
+ return lpuart_serial_drv;
+}
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/7] arm: vf610: Add Vybrid VF610 CPU support
This patch adds generic codes to support Freescale's Vybrid VF610 CPU. It aligns Vybrid VF610 platform with i.MX platform. As there are some differences between VF610 and i.MX platforms, the specific codes are in the arch/arm/cpu/armv7/vf610 directory. Signed-off-by: Alison Wang b18...@freescale.com --- Changes in v4: - Rename mvf_pins.h to iomux-vf610.h - Add README.vf610 about fuse assignments for MAC addresses - Rename directory name 'mvf600' to 'vf610' - Rename directory 'arch-mvf600' to 'arch-vf610' Changes in v3: - Rename the common functions and enums - Move the structure definitions to imx-regs.h Changes in v2: - Remove vybrid-common directory - Rename directory name 'vybrid' to 'mvf600' - Add generic.c file - Rewrite get_reset_cause() to make it readable - Remove reset_cpu(), and use the function in imx_watchdog.c - Rewrite timer.c file - Use vybrid_get_clock(VYBRID_UART_CLK) instead of vybrid_get_uartclk() - Remove lowlevel_init.S, and add clock_init() in board_early_init_f() - Remove useless CONFIG_SYS_ defines - Move CONFIG_MACH_TYPE to board configuration file - Define C structures and access C structures to set/read registers - Remove useless errata - Remove useless macros - Rename directory 'arch-vybrid' to 'arch-mvf600' Makefile | 2 +- arch/arm/cpu/armv7/vf610/Makefile | 42 +++ arch/arm/cpu/armv7/vf610/generic.c| 324 arch/arm/cpu/armv7/vf610/timer.c | 103 +++ arch/arm/include/asm/arch-vf610/clock.h | 39 +++ arch/arm/include/asm/arch-vf610/crm_regs.h| 225 ++ arch/arm/include/asm/arch-vf610/imx-regs.h| 419 ++ arch/arm/include/asm/arch-vf610/iomux-vf610.h | 101 +++ doc/README.vf610 | 10 + 9 files changed, 1264 insertions(+), 1 deletion(-) create mode 100644 arch/arm/cpu/armv7/vf610/Makefile create mode 100644 arch/arm/cpu/armv7/vf610/generic.c create mode 100644 arch/arm/cpu/armv7/vf610/timer.c create mode 100644 arch/arm/include/asm/arch-vf610/clock.h create mode 100644 arch/arm/include/asm/arch-vf610/crm_regs.h create mode 100644 arch/arm/include/asm/arch-vf610/imx-regs.h create mode 100644 arch/arm/include/asm/arch-vf610/iomux-vf610.h create mode 100644 doc/README.vf610 diff --git a/Makefile b/Makefile index c52f0f1..363180c 100644 --- a/Makefile +++ b/Makefile @@ -341,7 +341,7 @@ ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP34XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(C LIBS-y += $(CPUDIR)/omap-common/libomap-common.o endif -ifneq (,$(filter $(SOC), mx25 mx27 mx5 mx6 mx31 mx35 mxs)) +ifneq (,$(filter $(SOC), mx25 mx27 mx5 mx6 mx31 mx35 mxs vf610)) LIBS-y += arch/$(ARCH)/imx-common/libimx-common.o endif diff --git a/arch/arm/cpu/armv7/vf610/Makefile b/arch/arm/cpu/armv7/vf610/Makefile new file mode 100644 index 000..9232cd4 --- /dev/null +++ b/arch/arm/cpu/armv7/vf610/Makefile @@ -0,0 +1,42 @@ +# +# 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 $(TOPDIR)/config.mk + +LIB= $(obj)lib$(SOC).o + +COBJS += generic.o +COBJS += timer.o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +all: $(obj).depend $(LIB) + +$(LIB):$(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/arch/arm/cpu/armv7/vf610/generic.c b/arch/arm/cpu/armv7/vf610/generic.c new file mode 100644 index 000..87f2a86 --- /dev/null +++ b/arch/arm/cpu/armv7/vf610/generic.c @@ -0,0 +1,324 @@ +/* + * 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
[U-Boot] [PATCH v4 6/7] arm: vf610: Add Vybrid VF610 to mxc_ocotp document
This patch adds Vybrid VF610 to mxc_ocotp document. Signed-off-by: Alison Wang b18...@freescale.com --- Changes in v4: New Changes in v3: None Changes in v2: None doc/README.mxc_ocotp | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/README.mxc_ocotp b/doc/README.mxc_ocotp index 9a53311..7a2863c 100644 --- a/doc/README.mxc_ocotp +++ b/doc/README.mxc_ocotp @@ -2,6 +2,7 @@ Driver implementing the fuse API for Freescale's On-Chip OTP Controller (OCOTP) on MXC This IP can be found on the following SoCs: + - Vybrid VF610, - i.MX6. Note that this IP is different from albeit similar to the IPs of the same name -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 3/7] net: fec_mxc: Add support for Vybrid VF610
This patch adds FEC support for Vybrid VF610 platform.
In function fec_open(), RCR register is only set as RGMII mode. But RCR
register should be set as RMII mode for VF610 platform.
This configuration is already done in fec_reg_setup(), so this piece of
code could just leave untouched the FEC_RCNTRL_RGMII / FEC_RCNTRL_RMII /
FEC_RCNTRL_MII_MODE bits.
Signed-off-by: Alison Wang b18...@freescale.com
Reviewed-by: Benoit Thebaudeau benoit.thebaud...@advansee.com
---
Changes in v4: None
Changes in v3:
- Remove the changes for FEC_RCNTRL_RGMII / FEC_RCNTRL_RMII /
FEC_RCNTRL_MII_MODE bits, as they are already set in fec_reg_setup()
Changes in v2:
- Use common FEC driver fec_mxc.c
drivers/net/fec_mxc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 4dbcdca..da95e28 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -516,9 +516,7 @@ static int fec_open(struct eth_device *edev)
#ifdef FEC_QUIRK_ENET_MAC
{
u32 ecr = readl(fec-eth-ecntrl) ~FEC_ECNTRL_SPEED;
- u32 rcr = (readl(fec-eth-r_cntrl)
- ~(FEC_RCNTRL_RMII | FEC_RCNTRL_RMII_10T)) |
- FEC_RCNTRL_RGMII | FEC_RCNTRL_MII_MODE;
+ u32 rcr = readl(fec-eth-r_cntrl) ~FEC_RCNTRL_RMII_10T;
if (speed == _1000BASET)
ecr |= FEC_ECNTRL_SPEED;
else if (speed != _100BASET)
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 7/7] arm: vf610: Add basic support for Vybrid VF610TWR board
VF610TWR is a board based on Vybrid VF610 SoC. This patch adds basic support for Vybrid VF610TWR board. Signed-off-by: Alison Wang b18...@freescale.com Signed-off-by: Jason Jin jason@freescale.com Signed-off-by: TsiChung Liew tsicl...@gmail.com --- Changes in v4: - Rename directory name 'mvf600twr' to 'vf610twr' - Rename mvf600twr.h to vf610twr.h - Use NEW_PAD_CTRL instead of MUX_PAD_CTRL - Remove CONFIG_ETHPRIME option - Add CONFIG_CMD_MEMSET option Changes in v3: - Replace BOOT_FROM by BOOT_OFFSET - Enable CONFIG_OF_LIBFDT option - Add useful define instead of raw number - Use clrsetbits_le32 to set the single bits - Move setup_iomux_enet() to board_early_init_f and remove board_eth_init() - Remove redundant define - Move CONFIG_IOMUX_SHARE_CONF_REG to imx-regs.h Changes in v2: - Add an entry to MAINTAINERS file - Rename directory name 'vybird' to 'mvf600twr' - Use standard method to set gd-ram_size - Rewrite board_mmc_getcd() function - Remove useless undef - Remove hardcoded IP addresses and MAC addresses - Remove useless CONFIG_SYS_ defines - Define C structures and access C structures to set/read registers - Move CONFIG_MACH_TYPE to board configuration file - Use common iomux-v3 code MAINTAINERS | 4 + board/freescale/vf610twr/Makefile | 39 board/freescale/vf610twr/imximage.cfg | 33 +++ board/freescale/vf610twr/vf610twr.c | 410 ++ boards.cfg| 1 + include/configs/vf610twr.h| 140 6 files changed, 627 insertions(+) create mode 100644 board/freescale/vf610twr/Makefile create mode 100644 board/freescale/vf610twr/imximage.cfg create mode 100644 board/freescale/vf610twr/vf610twr.c create mode 100644 include/configs/vf610twr.h diff --git a/MAINTAINERS b/MAINTAINERS index c05433a..e4113d8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1057,6 +1057,10 @@ Eric Nelson eric.nel...@boundarydevices.com nitrogen6s i.MX6S 512MB nitrogen6s1gi.MX6S 1GB +Alison Wang b18...@freescale.com + + vf610twrVF610 + - Unknown / orphaned boards: diff --git a/board/freescale/vf610twr/Makefile b/board/freescale/vf610twr/Makefile new file mode 100644 index 000..7416228 --- /dev/null +++ b/board/freescale/vf610twr/Makefile @@ -0,0 +1,39 @@ +# +# 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 $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS := $(BOARD).o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/freescale/vf610twr/imximage.cfg b/board/freescale/vf610twr/imximage.cfg new file mode 100644 index 000..b00d4c1 --- /dev/null +++ b/board/freescale/vf610twr/imximage.cfg @@ -0,0 +1,33 @@ +/* + * Copyright 2013 Freescale Semiconductor, Inc. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not write to the Free Software + * Foundation Inc. 51 Franklin Street Fifth Floor Boston, + * MA 02110-1301 USA + * + * Refer docs/README.imxmage for more details about how-to configure + * and create imximage boot image + * + * The syntax is taken as close as possible with the kwbimage + */ +#include asm/imx-common/imximage.cfg
[U-Boot] about uboot leads to LAN disconnected
Dear all, Device is a camera connected LAN, camera board CPU is RT5350(based on MIPS) . I have met a problem about uboot. uboot leads to LAN disconnected in the following cases. I have been looking forward to answers. with best wishes case 1 : when CRC checksum bad Please choose the operation: 1: Load system code to SDRAM via TFTP. 2: Load system code then write to Flash via TFTP. 3: Boot system code via Flash (default). 4: Entr boot command line interface. 7: Load Boot Loader code then write to Flash via Serial. 9: Load Boot Loader code then write to Flash via TFTP. 0 3: System Boot system code via Flash. ## Booting image at bc05 ... raspi_read: from:5 len:40 . Image Name: Linux Kernel Image Created: 2013-03-14 6:22:22 UTC Image Type: MIPS Linux Kernel Image (lzma compressed) Data Size:3113308 Bytes = 3 MB Load Address: 8000 Entry Point: 802fb000 raspi_read: from:50040 len:2f815c Verifying Checksum ... Bad Data CRC case 2 when modify parameters spend over 10 seconds 1: System Load Linux to SDRAM via TFTP. Please Input new ones /or Ctrl-C to discard Input device IP (192.168.0.121) ==:192.168.0.121 Input server IP (192.168.0.66) ==:192.168.0.66 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/10] powerpc/ppc4xx: Use generic FPGA accessors on all gdsys 405ep/ex boards
Dear Dirk,
In message 0e4604dcfff89a1bd2b7f144a5b3c...@gdsys.cc you wrote:
sorry for the delay, I had to clean some other things on my ToDoList.
Ditto :-(
void fpga_set_reg(u32 fpga, u16 *reg, off_t regoff, u16 data)
{
if (fpga)
return mclink_send(fpga - 1, regoff, data);
return out_le16(reg, data);
}
...
#define FPGA_SET_REG(ix,fld,val)\
fpga_set_reg((ix), \
fpga_ptr-fld, \
offsetof(struct ihs_fpga, fld), \
val)
...
FPGA_SET_REG(0, mc_tx_address, addr);
FPGA_SET_REG(0, mc_tx_data, data);
FPGA_SET_REG(0, mc_tx_cmd, (slave 0x03) 14);
This works nicely for our memory mapped FPGA. But how about the other
FPGAs? I don't have a fpga_ptr for them. Setting it NULL would make
FPGA_SET_REG dereference a NULL pointer.
No, it does not.
In your setup you have a single memory mapped FPGA, addressed by the
globally visible pointer fpga_ptr.
When accessing this memory mapped FPGA (index is zero), then this
pointer gets used, which is OK.
For the other devices (index is not zero), then the pointer is
ignored, and only the offset is used.
In case you had more memory mapped devices (not only index 0; say,
something like index N) you can still use this, and pass any
(properly aligned) pointer for the non-memory mapped case. Note that
the pointer will NOT be dereferenced - only the address of field fld
will be calculated (and even this only in theory, because this code
will not be executed for the non-memory mapped case).
Certainly I might call
fpga_set_reg(1,
NULL,
offsetof(struct ihs_fpga, mc_tx_address),
addr);
but that would not be generic any more.
You don't call fpga_set_reg() any more, you just use the
FPGA_SET_REG() macro described above.
Do you have any idea how to solve this?
I think this needs no new solution, because it shoul just work :-)
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
Alan Turing thought about criteria to settle the question of whether
machines can think, a question of which we now know that it is about
as relevant as the question of whether submarines can swim.
-- Edsger Dijkstra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Add support for Wandboard quad.
On Tue, May 28, 2013 at 5:04 AM, Tapani Utriainen tap...@technexion.comwrote: Add support for Wandboard quad. Signed-off-by: Tapani Utriainen tap...@technexion.com Acked-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Wandboard: Add support for Wandboard quad
On Tue, May 28, 2013 at 4:44 AM, Tapani Utriainen tap...@technexion.comwrote: On Mon, 27 May 2013 13:56:30 -0300 Otavio Salvador ota...@ossystems.com.br wrote: I have sent two patches for adding the Boot Splash with Wandboard logo. Please take a look on them and if you agree please base on this to avoid conflicts. (For easyness: http://patchwork.ozlabs.org/bundle/otavio/wandboard-20130527/ ) Otavio, while I do agree with the work you are doing (HDMI bootlogo into mainline), and would not have minded to base my patches on top of yours. However, the patches you sent seem to have been NAK:ed. The v3 does not apply on top of 2013.04 (maybe I am basing on the wrong release!?). So for now, I am basing the resubmission on the 2013.04 release. You must base on imx/master as this is the custodian tree for upcoming 2013.07 release. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT PATCH] sf: Fix sf read for memory-mapped SPI flashes
Hi Simon,
Can you please check this change.
Thanks,
Jagan.
On Tue, May 28, 2013 at 1:44 AM, Jagannadha Sutradharudu Teki
jagannadha.sutradharudu-t...@xilinx.com wrote:
Missing return after memcpy is done for memory-mapped SPI flashes,
hence added retun 0 after memcpy done.
The return is missing in below patch
sf: Enable FDT-based configuration and memory mapping
(sha1: bb8215f437a7c948eec82a6abe754c226978bd6d)
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
drivers/mtd/spi/spi_flash.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index aeb1ccb..1d45e3b 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -148,8 +148,10 @@ int spi_flash_cmd_read_fast(struct spi_flash *flash, u32
offset,
u8 cmd[5];
/* Handle memory-mapped SPI */
- if (flash-memory_map)
+ if (flash-memory_map) {
memcpy(data, flash-memory_map + offset, len);
+ return 0;
+ }
cmd[0] = CMD_READ_ARRAY_FAST;
spi_flash_addr(offset, cmd);
--
1.7.4
--
--
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/4] Factorize ARM relocate_code instances
Hi Fabio, On Tue, 21 May 2013 10:24:19 -0300, Fabio Estevam feste...@gmail.com wrote: Hi Benoît, On Mon, May 20, 2013 at 12:39 PM, Benoît Thébaudeau benoit.thebaud...@advansee.com wrote: Can you test this series on mx31pdk (directly changed by this series), and some other i.MX EVK (e.g. ARMv7, so mx51evk or mx53*) board please? That should be enough for ARM. I don't have access to my mx31pdk currently, but I will try to get access to it later this week. Then I can test this series on mx31pdk and also on mx53loco. Did you manage this test? If you did and it succeeded, then I'll merge the series into u-boot-arm. Regards, Fabio Estevam Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] EXYNOS: SPL: Add a custom spi copy function
Hi Wolfgang Denk,
Thank you for review comments.
On Sun, May 12, 2013 at 2:01 AM, Wolfgang Denk w...@denx.de wrote:
Dear Simon Glass,
In message 1368285471-11039-1-git-send-email-...@chromium.org you wrote:
From: Rajeshwari Shinde rajeshwar...@samsung.com
This CL implements a custom spi_copy funtion to copy u-boot from SF to
What is a CL ?
Changed a printf in pimux.c to debug just to avoid the the compilation
s/the the/the/ ??
Removed the enum for boot mode from spl_boot.c as it was already define in
spl.h
s/define/defined/
Line length in commit messages should be not more than 72 characters.
Will correct these issues and resubmit the patch set soon.
+/**
+ * Copy uboot from spi flash to RAM
+ *
+ * @parma uboot_size size of u-boot to copy
+ * @param uboot_addr address of u-boot to copy
+ */
Incorrect multiline comment style.
Will correct these
+static void exynos_spi_copy(unsigned int uboot_size, unsigned int
uboot_addr)
+{
+ int upto, todo;
+ int i;
+ struct exynos_spi *regs = (struct exynos_spi *)CONFIG_ENV_SPI_BASE;
+
+ set_spi_clk(PERIPH_ID_SPI1, 5000); /* set spi clock to 50Mhz */
+ /* set the spi1 GPIO */
+ exynos_pinmux_config(PERIPH_ID_SPI1, PINMUX_FLAG_NONE);
+
+ /* set pktcnt and enable it */
+ writel(4 | SPI_PACKET_CNT_EN, regs-pkt_cnt);
+ /* set FB_CLK_SEL */
+ writel(SPI_FB_DELAY_180, regs-fb_clk);
+ /* set CH_WIDTH and BUS_WIDTH as word */
+ setbits_le32(regs-mode_cfg, SPI_MODE_CH_WIDTH_WORD |
+ SPI_MODE_BUS_WIDTH_WORD);
+ clrbits_le32(regs-ch_cfg, SPI_CH_CPOL_L); /* CPOL: active high */
+
+ /* clear rx and tx channel if set priveously */
+ clrbits_le32(regs-ch_cfg, SPI_RX_CH_ON | SPI_TX_CH_ON);
+
+ typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
We do not allow typedefs or variable declarations etc. right in the
middle of the code.
I'm surprised that checkpatch does not complain here about not to add
new typedefs ??
Basically typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32
dst); was removed in my original patch.
Will check and remove this from the version of patch set I submit.
+ /* waiting for TX done */
+ while (!(readl(regs-spi_sts) SPI_ST_TX_DONE))
+ ;
Potentially infinite loop. This (and similar code) should always have
a timeout and appropriate error handling.
Will add a timeout check here
+ /* let us our own function to copy u-boot from SF */
Please fix the wording of this comment.
Will correct this.
diff --git a/spl/Makefile b/spl/Makefile
index b5a8de7..5e7816a 100644
--- a/spl/Makefile
+++ b/spl/Makefile
@@ -94,6 +94,10 @@ LIBS-y +=
arch/$(ARCH)/cpu/tegra-common/libcputegra-common.o
LIBS-y += $(CPUDIR)/tegra-common/libtegra-common.o
endif
+ifneq ($(CONFIG_EXYNOS4)$(CONFIG_EXYNOS5),)
+LIBS-y += $(CPUDIR)/s5p-common/libs5p-common.o
+endif
This should be done without the ifneq.
This is specific to samsung and currently used only by EXYNOS hence it
was added with a ifneq
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
Love all, trust a few. - William Shakespeare
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
Regards,
Rajeshwari Shinde
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Soft_spi questions
Hello all, i have integrated soft_spi driver in u-boot, in order to communicate with a FRAM device, using some GPIO. I use mode 0 of spi (CPHA=0, CPOL=0). When i try to communicate with the device, i have a problem, none of my commands are answered. After looking signals with scope, i see that if CPHA and CPOL are 0, there is a rising edge on the clock signal, before data is set on mosi signal. So the device get a first byte in an unknown state. looking at the code, we can see that if CPHA is 0, we put a rising edge on clock before any data management. I made work the communication by forcing CPHA to 1 but i think it is not good way. Is there something i don't understand? thank you in advance for your answer. Regards Laurent Vaudoit ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] da830: add MMC support
On Mon, May 27, 2013 at 03:33:58AM +, Vishwanathrao Badarkhe, Manish wrote: Hi Tom On Fri, May 24, 2013 at 21:31:56, Rini, Tom wrote: On Fri, May 24, 2013 at 08:16:14AM +0530, Vishwanathrao Badarkhe, Manish wrote: Add MMC support for da830 boards in order to perform mmc operations(read,write and erase). Signed-off-by: Vishwanathrao Badarkhe, Manish manish...@ti.com Has anything changed between patch postings? Thanks. Nothing has changed between postings. I resent same patch because during first posting of this patch I got message as below: [U-Boot] [PATCH] da830: add MMC support Is being held until the list moderator can review it for approval. Apologize, If you got two versions of same patch. Please ignore first version and consider this patch for review. OK, thanks. The first copy was approved by the moderators :) I should pick this up for the TI tree soon. -- 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] Soft_spi questions
HI, Few little comments. CCed driver contributed delegate, may be they will help if I am missing any thing. On Tue, May 28, 2013 at 6:48 PM, laurent vaudoit laurent.vaud...@gmail.com wrote: Hello all, i have integrated soft_spi driver in u-boot, in order to communicate with a FRAM device, using some GPIO. I use mode 0 of spi (CPHA=0, CPOL=0). When i try to communicate with the device, i have a problem, none of my commands are answered. Giving to an understnding how does it works, ignore if you know it already. usually we have give an mode bit as 0, so the mode bit will check at driver level to get any change on clock phase and polarity level(CPHA and CPOL) u-boot sf probe 0 0 0 last argument assigns the global mode variable. You checked with mode 0 or 1? What exactly the issue log, means where it goes wrong? Does it on spi_xfer?, or spi_claim_bus? After looking signals with scope, i see that if CPHA and CPOL are 0, there is a rising edge on the clock signal, before data is set on mosi signal. So the device get a first byte in an unknown state. looking at the code, we can see that if CPHA is 0, we put a rising edge on clock before any data management. I made work the communication by forcing CPHA to 1 but i think it is not good way. What you made by default the CPHA is 0x1, did you make change on the spi_xfer? Thanks, Jagan. Is there something i don't understand? thank you in advance for your answer. Regards Laurent Vaudoit ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/2] cmd_sf: print message support
On Tue, May 28, 2013 at 01:41:44AM +0530, Jagannadha Sutradharudu Teki wrote: I agreed that adding new prints will increase the foot-print, but here I have removed the verbose messages from sf_flash and add on cmd_sf. These are much essential for showing print messages while user using sf erase|write|read commands. Thanks, Jagan. Jagannadha Sutradharudu Teki (2): cmd_sf: Add print mesg for 'sf erase' command cmd_sf: Add print mesgs on sf read/write commands common/cmd_sf.c | 34 ++ drivers/mtd/spi/spi_flash.c | 10 ++ 2 files changed, 20 insertions(+), 24 deletions(-) Acked-by: Tom Rini tr...@ti.com -- 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] Soft_spi questions
Hi, thanks for your answer. On Tue, May 28, 2013 at 4:41 PM, Jagan Teki jagannadh.t...@gmail.comwrote: HI, Few little comments. CCed driver contributed delegate, may be they will help if I am missing any thing. On Tue, May 28, 2013 at 6:48 PM, laurent vaudoit laurent.vaud...@gmail.com wrote: Hello all, i have integrated soft_spi driver in u-boot, in order to communicate with a FRAM device, using some GPIO. I use mode 0 of spi (CPHA=0, CPOL=0). When i try to communicate with the device, i have a problem, none of my commands are answered. Giving to an understnding how does it works, ignore if you know it already. usually we have give an mode bit as 0, so the mode bit will check at driver level to get any change on clock phase and polarity level(CPHA and CPOL) u-boot sf probe 0 0 0 last argument assigns the global mode variable. You checked with mode 0 or 1? What exactly the issue log, means where it goes wrong? Does it on spi_xfer?, or spi_claim_bus? My problem is on sspi_xfer function for testing i use command sspi 0 (chip select) size data i have ss-mode to 0 (so CPHA and CPOL is 0) When i look at the code, i have: if (!cpha) SPI_SCL(!cpol); My problem is this line SPI_SDA(tmpdout 0x80); SPI_DELAY; if (cpha) SPI_SCL(!cpol); else SPI_SCL(cpol); tmpdin = 1; tmpdin |= SPI_READ; tmpdout = 1; SPI_DELAY; if (cpha) SPI_SCL(cpol); After looking signals with scope, i see that if CPHA and CPOL are 0, there is a rising edge on the clock signal, before data is set on mosi signal. So the device get a first byte in an unknown state. looking at the code, we can see that if CPHA is 0, we put a rising edge on clock before any data management. I made work the communication by forcing CPHA to 1 but i think it is not good way. What you made by default the CPHA is 0x1, did you make change on the spi_xfer? yes for testing, i force local variable cpha to 1 in spi_xfer. I hope i'm clear, thanks Laurent Thanks, Jagan. Is there something i don't understand? thank you in advance for your answer. Regards Laurent Vaudoit ___ 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] dfu: dfu and UBI Volumes
On Tue, May 28, 2013 at 07:50:46AM +0200, Wolfgang Denk wrote: Dear Tom, In message 20130527233735.GZ17119@bill-the-cat you wrote: Where exactly is this 8 MB limit coming into play? In buffering the data. We cannot write a chunk of a file to a filesystem and then append to it, we don't have the API today. Sorry, I still don't get it. Assuming I have a GiB of RAM, why can I not load a 256 MiB file to RAM, and then write it to a file system? I have definitely dealt with images and files bigger than 8 MiB in thepast, so I really don't see where any buffer problem could be. I thought I might not have been clear about where this limit comes from, after I sent the email. The problem we have, and this is only for writing to a filesystem (_not_ writing of a filesystem) is that we do not have the API for appending to files, only create/overwrite. So we must read the whole file into memory, and then write it out. The DFU protocol doesn't have (I would swear anyhow) a part where it says I'm about to send you a blob of X bytes, so we cannot know at the start how much data is coming our way. Today we solve this with a statically defined CONFIG_SYS_DFU_MAX_FILE_SIZE. Looking at things again, I think this is buggy right now in that we need to also whack DFU_DATA_BUF_SIZE to also be that same value. Going forward, we may be able to switch this to (and both of these are off the top of my head) a getenv to see how much space to malloc, or just making it a malloc and adding some compile-time check to ensure that the malloc area is at least as big as CONFIG_SYS_DFU_MAX_FILE_SIZE. -- 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 V2] input: simplify key_matrix_decode_fdt()
From: Stephen Warren swar...@nvidia.com
We know the exact property names that the code wants to process. Look
these up directly with fdt_get_property(), rather than iterating over
all properties within the node, and checking each property's name, in
a convoluted fashion, against the expected name.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
V2:
* Add back debug() on missing plain keymap
* Fix error-check after parsing fn keymap
Note: This depends on my previous patch input: fix unaligned access
in key_matrix_decode_fdt(). While to two patches could be squashed
together, I'd prefer them to go in separately, since the former is a
bug-fix that makes the original code work again on ARMv7 at least, and
this patch is an unrelated refactoring.
---
drivers/input/key_matrix.c | 68 ++--
1 file changed, 28 insertions(+), 40 deletions(-)
diff --git a/drivers/input/key_matrix.c b/drivers/input/key_matrix.c
index c8b048e..c900e45 100644
--- a/drivers/input/key_matrix.c
+++ b/drivers/input/key_matrix.c
@@ -154,54 +154,42 @@ static uchar *create_keymap(struct key_matrix *config,
u32 *data, int len,
return map;
}
-int key_matrix_decode_fdt(struct key_matrix *config, const void *blob,
- int node)
+int key_matrix_decode_fdt(struct key_matrix *config, const void *blob, int
node)
{
const struct fdt_property *prop;
- static const char prefix[] = linux,;
- int plen = sizeof(prefix) - 1;
- int offset;
-
- /* Check each property name for ones that we understand */
- for (offset = fdt_first_property_offset(blob, node);
- offset 0;
- offset = fdt_next_property_offset(blob, offset)) {
- const char *name;
- int len;
-
- prop = fdt_get_property_by_offset(blob, offset, NULL);
- name = fdt_string(blob, fdt32_to_cpu(prop-nameoff));
- len = strlen(name);
-
- /* Name needs to match 1,typekeymap */
- debug(%s: property '%s'\n, __func__, name);
- if (strncmp(name, prefix, plen) ||
- len plen + 6 ||
- strcmp(name + len - 6, keymap))
- continue;
+ int proplen;
+ uchar *plain_keycode;
- len -= plen + 6;
- if (len == 0) {
- config-plain_keycode = create_keymap(config,
- (u32 *)prop-data, fdt32_to_cpu(prop-len),
- KEY_FN, config-fn_pos);
- } else if (0 == strncmp(name + plen, fn-, len)) {
- config-fn_keycode = create_keymap(config,
- (u32 *)prop-data, fdt32_to_cpu(prop-len),
- -1, NULL);
- } else {
- debug(%s: unrecognised property '%s'\n, __func__,
- name);
- }
+ prop = fdt_get_property(blob, node, linux,keymap, proplen);
+ /* Basic keymap is required */
+ if (!prop) {
+ debug(%s: cannot find keycode-plain map\n, __func__);
+ return -1;
}
- debug(%s: Decoded key maps %p, %p from fdt\n, __func__,
- config-plain_keycode, config-fn_keycode);
- if (!config-plain_keycode) {
- debug(%s: cannot find keycode-plain map\n, __func__);
+ plain_keycode = create_keymap(config, (u32 *)prop-data,
+ proplen, KEY_FN, config-fn_pos);
+ config-plain_keycode = plain_keycode;
+ /* Conversion error - fail */
+ if (!config-plain_keycode)
+ return -1;
+
+ prop = fdt_get_property(blob, node, linux,fn-keymap, proplen);
+ /* fn keymap is optional */
+ if (!prop)
+ goto done;
+
+ config-fn_keycode = create_keymap(config, (u32 *)prop-data,
+ proplen, -1, NULL);
+ /* Conversion error - fail */
+ if (!config-fn_keycode) {
+ free(plain_keycode);
return -1;
}
+done:
+ debug(%s: Decoded key maps %p, %p from fdt\n, __func__,
+ config-plain_keycode, config-fn_keycode);
return 0;
}
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] dfu: dfu and UBI Volumes
Hi Tom, On May 28, 2013, at 6:01 PM, Tom Rini wrote: On Tue, May 28, 2013 at 07:50:46AM +0200, Wolfgang Denk wrote: Dear Tom, In message 20130527233735.GZ17119@bill-the-cat you wrote: Where exactly is this 8 MB limit coming into play? In buffering the data. We cannot write a chunk of a file to a filesystem and then append to it, we don't have the API today. Sorry, I still don't get it. Assuming I have a GiB of RAM, why can I not load a 256 MiB file to RAM, and then write it to a file system? I have definitely dealt with images and files bigger than 8 MiB in thepast, so I really don't see where any buffer problem could be. I thought I might not have been clear about where this limit comes from, after I sent the email. The problem we have, and this is only for writing to a filesystem (_not_ writing of a filesystem) is that we do not have the API for appending to files, only create/overwrite. So we must read the whole file into memory, and then write it out. The DFU protocol doesn't have (I would swear anyhow) a part where it says I'm about to send you a blob of X bytes, so we cannot know at the start how much data is coming our way. Today we solve this with a statically defined CONFIG_SYS_DFU_MAX_FILE_SIZE. Looking at things again, I think this is buggy right now in that we need to also whack DFU_DATA_BUF_SIZE to also be that same value. Going forward, we may be able to switch this to (and both of these are off the top of my head) a getenv to see how much space to malloc, or just making it a malloc and adding some compile-time check to ensure that the malloc area is at least as big as CONFIG_SYS_DFU_MAX_FILE_SIZE. Correct, the DFU protocol doesn't have a method to inform you before hand about the size of the transfer about to happen. The only possible solution I see at this point is to have an environment variable, i.e. dfubuf that controls the size of the buffer. Upon start of a dfu transfer we can allocate the buffer, and do our thing. -- Tom Regards -- Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] powerpc/mpc8xxx failed to compile: operand out of range
On 05/27/2013 11:25:17 AM, Jérôme Arzel wrote: On 05/24/2013 10:13:55 PM, Scott Wood wrote: On 05/23/2013 04:52:26 AM, Jérôme Arzel wrote: Hi all, I have an issue when I compile U-Boot for my target machine (P1022DS, 36-bit). Here is the error message: release.S: Assembler messages: release.S:154: Error: operand out of range (0xf144 is not between 0x and 0x) release.S:286: Error: operand out of range (0xf144 is not between 0x and 0x) release.S:311: Error: operand out of range (0xf140 is not between 0x and 0x) (release.S is located to arch/powerpc/cpu/mpc85xx/release.S) And here is the code for the first error (line 150): #define toreset(x) (x - __secondary_start_page + 0xf000) /* get our PIR to figure out our table entry */ lis r3,toreset(__spin_table_addr)@h ori r3,r3,toreset(__spin_table_addr)@l I don't really know why it doesn't work, but I think that ori is inappropried, the immediate value must be a 16-bit value. The @l means take the low 16 bits of the constant. Likewise, the @h in the lis takes the upper 16 bits. Could you try to see what that instruction looks like after the preprocessor stage (i.e. use -E rather than -c in gcc)? OK, I tried and unsurprisingly it's: lis 3,(__spin_table_addr - __secondary_start_page + 0xf000)@h ori 3,3,(__spin_table_addr - __secondary_start_page + 0xf000)@l lwz 3,0(3) If the @l takes the low 16 bits of (__spin_table_addr - __secondary_start_page + 0xf000), so the immediate value should not be 0xf144, but 0xf144. The error is maybe in GCC... Jérôme In fact my tests was in a virtual machine. I restarted the compilation of GCC from scratch, directly on my machine (x86_64) and the result is slightly different, but almost the same: powerpc-e500v2-linux-gnuspe-gcc -D__ASSEMBLY__ -g -Os \ -fpic -mrelocatable -ffunction-sections -fdata-sections \ -meabi -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x1100 \ -I/home/arzel/u-boot/u-boot-git/P1022DS_SDCARD/include2 \ -I/home/arzel/u-boot/u-boot-git/P1022DS_SDCARD/include \ -I/home/arzel/u-boot/u-boot-git/include -fno-builtin \ -ffreestanding -nostdinc \ -isystem /home/arzel/cross_compile/tools/lib/gcc/powerpc- e500v2-linux-gnuspe/4.8.0/include \ -pipe -DCONFIG_PPC -D__powerpc__ -ffixed-r2 -Wa,-me500 \ -msoft-float -mno-string -mspe=yes -mno-spe \ -o /home/arzel/u-boot/u-boot-git/P1022DS_SDCARD/ arch/powerpc/cpu/mpc85xx/release.o release.S -c release.S: Assembler messages: release.S:153: Error: value of 4294963524 too large for field of 2 bytes at 170 release.S:154: Error: operand out of range (0xf144 is not between 0x and 0x) release.S:154: Error: value of 4294963524 too large for field of 2 bytes at 174 release.S:282: Error: value of 4294963524 too large for field of 2 bytes at 206 release.S:283: Error: operand out of range (0xf144 is not between 0x and 0x) release.S:283: Error: value of 4294963524 too large for field of 2 bytes at 210 release.S:307: Error: value of 4294963520 too large for field of 2 bytes at 278 release.S:308: Error: operand out of range (0xf140 is not between 0x and 0x) release.S:308: Error: value of 4294963520 too large for field of 2 bytes at 282 By curiosity, I tried to replace toreset(__spin_table_addr) by 0xf144 and it works... but it's not a solution. I use the last version of U-Boot from the git branch 'master'. Here is my configuration for GCC: export PATH=/home/arzel/cross_compile/tools/bin:$PATH Binutils (v2.23.2) configure --target=powerpc-e500v2-linux-gnuspe \ --prefix=/home/arzel/cross_compile/tools \ --with-sysroot=/home/home/arzel/cross_compile/sysroot \ --disable-nls --disable-multilib make all make install GCC (v4.8.0) configure --target=powerpc-e500v2-linux-gnuspe \ --prefix=/home/arzel/cross_compile/tools \ --with-sysroot=/home/arzel/cross_compile/sysroot \ --without-headers --with-newlib --disable-shared \ --disable-threads --enable-languages=c \ --disable-decimal-float --disable-__cxa_atexit \ --disable-libquadmath --disable-libssp \ --disable-libgomp --disable-libmudflap \ --disable-nls --disable-multilib \ --enable-e500_double --with-long-double-128 \ --with-cpu=8548 make all-host all-target-libgcc make install-host install-target-libgcc Normally, I can build U-Boot with this small GCC. Jérôme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] dfu: dfu and UBI Volumes
On Tue, May 28, 2013 at 07:55:03AM +0200, Wolfgang Denk wrote: Dear Heiko, In message 51a427a8.8090...@denx.de you wrote: Where exactly is this 8 MB limit coming into play? You find this in drivers/dfu/dfu.c: static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE) dfu_buf[DFU_DATA_BUF_SIZE]; Ah, so it is a DFU restriction! [snip] drivers/dfu/dfu_mmc.c use (another?, why?) buffer: static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE) dfu_file_buf[CONFIG_SYS_DFU_MAX_FILE_SIZE]; ... and use this buffer for not raw partitions ... and this buffer gets flushed, only if the complete file is transfered, as the README states: CONFIG_SYS_DFU_MAX_FILE_SIZE When updating files rather than the raw storage device, we use a static buffer to copy the file into and then write the buffer once we've been given the whole file. Define this to the maximum filesize (in bytes) for the buffer. Default is 4 MiB if undefined. This makes very little sense to me. Why do we need another (and even smaller) buffer when we already have one? Per my other email, the intention and implementation didn't quite match-up. The intent of the README should be (but isn't) reflected) in the code. And perhaps we can come up with something better than a big static allocation. Perhaps. -- 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] dfu: dfu and UBI Volumes
On Tue, May 28, 2013 at 08:24:06AM +0200, Heiko Schocher wrote: Hello Wolfgang, Am 28.05.2013 07:58, schrieb Wolfgang Denk: Dear Heiko, In message 51a42ccd.1020...@denx.de you wrote: I would imagine, but testing and implementation might show a better way, we do UBI as name ubi ubiN volume-name, ie: rootfs ubi ubi0 rootfs user ubi ubi0 user-data and so forth, and augment dfu_nand.c with UBI knowledge, ala dfu_mmc and fat/ext knowledge. Yes, I think, thats the way to go ... I doubt that dfu_nand.c is the right place for this. What if I start using DFU on NOR flash? The decisions which device type (NAND, MMC, NOR, USB mass storage, ...) to habdle on one side, and which partition type / image type (raw, UBI volume, file, ...) on the other side are fully orthogonal to each other. They should be handled by independent code, and not one of them repeated for all implementations of the other. Yes, exactly ... We can see about what re-org makes sense once we've got another implementation here. We might be able to share the filesystem-based write code, but that in part might cause some screams since it'll depend on our continued (ab)use of run_command. The device-specific code does end up being the device-specific API part. Unless we're adding ubifs in addition to ubi volume support to DFU, we don't have real shared filesystem stuff, yet. -- 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] dfu: dfu and UBI Volumes
Dear Pantelis Antoniou, On Tuesday, May 28, 2013 5:05:12 PM, Pantelis Antoniou wrote: Hi Tom, On May 28, 2013, at 6:01 PM, Tom Rini wrote: On Tue, May 28, 2013 at 07:50:46AM +0200, Wolfgang Denk wrote: Dear Tom, In message 20130527233735.GZ17119@bill-the-cat you wrote: Where exactly is this 8 MB limit coming into play? In buffering the data. We cannot write a chunk of a file to a filesystem and then append to it, we don't have the API today. Sorry, I still don't get it. Assuming I have a GiB of RAM, why can I not load a 256 MiB file to RAM, and then write it to a file system? I have definitely dealt with images and files bigger than 8 MiB in thepast, so I really don't see where any buffer problem could be. I thought I might not have been clear about where this limit comes from, after I sent the email. The problem we have, and this is only for writing to a filesystem (_not_ writing of a filesystem) is that we do not have the API for appending to files, only create/overwrite. So we must read the whole file into memory, and then write it out. The DFU protocol doesn't have (I would swear anyhow) a part where it says I'm about to send you a blob of X bytes, so we cannot know at the start how much data is coming our way. Today we solve this with a statically defined CONFIG_SYS_DFU_MAX_FILE_SIZE. Looking at things again, I think this is buggy right now in that we need to also whack DFU_DATA_BUF_SIZE to also be that same value. Going forward, we may be able to switch this to (and both of these are off the top of my head) a getenv to see how much space to malloc, or just making it a malloc and adding some compile-time check to ensure that the malloc area is at least as big as CONFIG_SYS_DFU_MAX_FILE_SIZE. Correct, the DFU protocol doesn't have a method to inform you before hand about the size of the transfer about to happen. The only possible solution I see at this point is to have an environment variable, i.e. dfubuf that controls the size of the buffer. Upon start of a dfu transfer we can allocate the buffer, and do our thing. I don't know the details of the DFU implementation in U-Boot, but the specification leaves the choice between programming the firmware on-the-fly during the download, and later during the manifestation phase (or a mix of both). Hence, there is not need for a global firmware buffer if U-Boot goes for the on-the-fly programming strategy. The only buffer constraint would be wTransferSize (chosen by U-Boot for the control endpoint) in that case. See 7. Manifestation Phase on page 26 here: http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf Of course this can't yet apply to writing files on file systems since the current API in U-Boot misses the append feature, but this could be applied to program raw memory partitions, including UBI images. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] dfu: dfu and UBI Volumes
Hi Benoît On May 28, 2013, at 7:31 PM, Benoît Thébaudeau wrote: Dear Pantelis Antoniou, On Tuesday, May 28, 2013 5:05:12 PM, Pantelis Antoniou wrote: Hi Tom, On May 28, 2013, at 6:01 PM, Tom Rini wrote: On Tue, May 28, 2013 at 07:50:46AM +0200, Wolfgang Denk wrote: Dear Tom, In message 20130527233735.GZ17119@bill-the-cat you wrote: Where exactly is this 8 MB limit coming into play? In buffering the data. We cannot write a chunk of a file to a filesystem and then append to it, we don't have the API today. Sorry, I still don't get it. Assuming I have a GiB of RAM, why can I not load a 256 MiB file to RAM, and then write it to a file system? I have definitely dealt with images and files bigger than 8 MiB in thepast, so I really don't see where any buffer problem could be. I thought I might not have been clear about where this limit comes from, after I sent the email. The problem we have, and this is only for writing to a filesystem (_not_ writing of a filesystem) is that we do not have the API for appending to files, only create/overwrite. So we must read the whole file into memory, and then write it out. The DFU protocol doesn't have (I would swear anyhow) a part where it says I'm about to send you a blob of X bytes, so we cannot know at the start how much data is coming our way. Today we solve this with a statically defined CONFIG_SYS_DFU_MAX_FILE_SIZE. Looking at things again, I think this is buggy right now in that we need to also whack DFU_DATA_BUF_SIZE to also be that same value. Going forward, we may be able to switch this to (and both of these are off the top of my head) a getenv to see how much space to malloc, or just making it a malloc and adding some compile-time check to ensure that the malloc area is at least as big as CONFIG_SYS_DFU_MAX_FILE_SIZE. Correct, the DFU protocol doesn't have a method to inform you before hand about the size of the transfer about to happen. The only possible solution I see at this point is to have an environment variable, i.e. dfubuf that controls the size of the buffer. Upon start of a dfu transfer we can allocate the buffer, and do our thing. I don't know the details of the DFU implementation in U-Boot, but the specification leaves the choice between programming the firmware on-the-fly during the download, and later during the manifestation phase (or a mix of both). Hence, there is not need for a global firmware buffer if U-Boot goes for the on-the-fly programming strategy. The only buffer constraint would be wTransferSize (chosen by U-Boot for the control endpoint) in that case. See 7. Manifestation Phase on page 26 here: http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf The problem is not DFU TBH, it's that since we don't have an option to append to a file, we have to have the whole file transferred in RAM and written in one go. The raw medium dfu methods in u-boot don't have a problem. Of course this can't yet apply to writing files on file systems since the current API in U-Boot misses the append feature, but this could be applied to program raw memory partitions, including UBI images. It already happens for raw memory partitions, it's the UBI images being discussed. Best regards, Benoît Regards -- Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] dfu: dfu and UBI Volumes
Hi Pantelis, On Tuesday, May 28, 2013 6:43:06 PM, Pantelis Antoniou wrote: Hi Benoît On May 28, 2013, at 7:31 PM, Benoît Thébaudeau wrote: Dear Pantelis Antoniou, On Tuesday, May 28, 2013 5:05:12 PM, Pantelis Antoniou wrote: Hi Tom, On May 28, 2013, at 6:01 PM, Tom Rini wrote: On Tue, May 28, 2013 at 07:50:46AM +0200, Wolfgang Denk wrote: Dear Tom, In message 20130527233735.GZ17119@bill-the-cat you wrote: Where exactly is this 8 MB limit coming into play? In buffering the data. We cannot write a chunk of a file to a filesystem and then append to it, we don't have the API today. Sorry, I still don't get it. Assuming I have a GiB of RAM, why can I not load a 256 MiB file to RAM, and then write it to a file system? I have definitely dealt with images and files bigger than 8 MiB in thepast, so I really don't see where any buffer problem could be. I thought I might not have been clear about where this limit comes from, after I sent the email. The problem we have, and this is only for writing to a filesystem (_not_ writing of a filesystem) is that we do not have the API for appending to files, only create/overwrite. So we must read the whole file into memory, and then write it out. The DFU protocol doesn't have (I would swear anyhow) a part where it says I'm about to send you a blob of X bytes, so we cannot know at the start how much data is coming our way. Today we solve this with a statically defined CONFIG_SYS_DFU_MAX_FILE_SIZE. Looking at things again, I think this is buggy right now in that we need to also whack DFU_DATA_BUF_SIZE to also be that same value. Going forward, we may be able to switch this to (and both of these are off the top of my head) a getenv to see how much space to malloc, or just making it a malloc and adding some compile-time check to ensure that the malloc area is at least as big as CONFIG_SYS_DFU_MAX_FILE_SIZE. Correct, the DFU protocol doesn't have a method to inform you before hand about the size of the transfer about to happen. The only possible solution I see at this point is to have an environment variable, i.e. dfubuf that controls the size of the buffer. Upon start of a dfu transfer we can allocate the buffer, and do our thing. I don't know the details of the DFU implementation in U-Boot, but the specification leaves the choice between programming the firmware on-the-fly during the download, and later during the manifestation phase (or a mix of both). Hence, there is not need for a global firmware buffer if U-Boot goes for the on-the-fly programming strategy. The only buffer constraint would be wTransferSize (chosen by U-Boot for the control endpoint) in that case. See 7. Manifestation Phase on page 26 here: http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf The problem is not DFU TBH, it's that since we don't have an option to append to a file, we have to have the whole file transferred in RAM and written in one go. The raw medium dfu methods in u-boot don't have a problem. Of course this can't yet apply to writing files on file systems since the current API in U-Boot misses the append feature, but this could be applied to program raw memory partitions, including UBI images. It already happens for raw memory partitions, it's the UBI images being discussed. But what does appending to a file has to do with programming a UBI image, which is a memory partition containing a whole file system? This is what I don't get in this discussion. Is it because of a restriction of the DFU API in U-Boot? Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] dfu: dfu and UBI Volumes
Hi On May 28, 2013, at 7:43 PM, Benoît Thébaudeau wrote: Hi Pantelis, On Tuesday, May 28, 2013 6:43:06 PM, Pantelis Antoniou wrote: Hi Benoît On May 28, 2013, at 7:31 PM, Benoît Thébaudeau wrote: Dear Pantelis Antoniou, On Tuesday, May 28, 2013 5:05:12 PM, Pantelis Antoniou wrote: Hi Tom, On May 28, 2013, at 6:01 PM, Tom Rini wrote: On Tue, May 28, 2013 at 07:50:46AM +0200, Wolfgang Denk wrote: Dear Tom, In message 20130527233735.GZ17119@bill-the-cat you wrote: Where exactly is this 8 MB limit coming into play? In buffering the data. We cannot write a chunk of a file to a filesystem and then append to it, we don't have the API today. Sorry, I still don't get it. Assuming I have a GiB of RAM, why can I not load a 256 MiB file to RAM, and then write it to a file system? I have definitely dealt with images and files bigger than 8 MiB in thepast, so I really don't see where any buffer problem could be. I thought I might not have been clear about where this limit comes from, after I sent the email. The problem we have, and this is only for writing to a filesystem (_not_ writing of a filesystem) is that we do not have the API for appending to files, only create/overwrite. So we must read the whole file into memory, and then write it out. The DFU protocol doesn't have (I would swear anyhow) a part where it says I'm about to send you a blob of X bytes, so we cannot know at the start how much data is coming our way. Today we solve this with a statically defined CONFIG_SYS_DFU_MAX_FILE_SIZE. Looking at things again, I think this is buggy right now in that we need to also whack DFU_DATA_BUF_SIZE to also be that same value. Going forward, we may be able to switch this to (and both of these are off the top of my head) a getenv to see how much space to malloc, or just making it a malloc and adding some compile-time check to ensure that the malloc area is at least as big as CONFIG_SYS_DFU_MAX_FILE_SIZE. Correct, the DFU protocol doesn't have a method to inform you before hand about the size of the transfer about to happen. The only possible solution I see at this point is to have an environment variable, i.e. dfubuf that controls the size of the buffer. Upon start of a dfu transfer we can allocate the buffer, and do our thing. I don't know the details of the DFU implementation in U-Boot, but the specification leaves the choice between programming the firmware on-the-fly during the download, and later during the manifestation phase (or a mix of both). Hence, there is not need for a global firmware buffer if U-Boot goes for the on-the-fly programming strategy. The only buffer constraint would be wTransferSize (chosen by U-Boot for the control endpoint) in that case. See 7. Manifestation Phase on page 26 here: http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf The problem is not DFU TBH, it's that since we don't have an option to append to a file, we have to have the whole file transferred in RAM and written in one go. The raw medium dfu methods in u-boot don't have a problem. Of course this can't yet apply to writing files on file systems since the current API in U-Boot misses the append feature, but this could be applied to program raw memory partitions, including UBI images. It already happens for raw memory partitions, it's the UBI images being discussed. But what does appending to a file has to do with programming a UBI image, which is a memory partition containing a whole file system? This is what I don't get in this discussion. Is it because of a restriction of the DFU API in U-Boot? Don't expect a discussion on a mailing list to stay on topic for long :) We sort of drifted from UBI to the fixed sized buffer. Best regards, Benoît Regards -- Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] arm: ensure u-boot only uses relative relocations
Hi Albert,
On Tuesday, May 28, 2013 9:01:46 AM, Albert ARIBAUD wrote:
Add a Makefile target ('checkarmreloc') which
fails of the ELF binary contains relocation records
^
if
Sorry to have missed that in my review of v1.
of types other than R_ARM_RELATIVE.
The rest of the patch is OK.
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/6] arm: make __image_copy_{start, end} compiler-generated
Hi Albert,
On Tuesday, May 28, 2013 9:01:49 AM, Albert ARIBAUD wrote:
This change is only done where needed: some linker
scripts may contain __image_copy_{start,end} yet
remain unchanged.
Also, __image_copy_end needs its own section; putting
it in relocation sections changes their flags and makes
relocation breaks.
^
break
The rest of the patch is OK.
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] dfu: dfu and UBI Volumes
On Tue, May 28, 2013 at 06:31:41PM +0200, Beno??t Th??baudeau wrote: [snip] Of course this can't yet apply to writing files on file systems since the current API in U-Boot misses the append feature, but this could be applied to program raw memory partitions, including UBI images. Correct. We can write a whole UBI image, today, of NAND size, regardless of DDR size. But modifying UBI volumes (so UBIFS or your kernel in UBI or ...) will depend on what the UBI API provides us today. Modifying files on UBIFS (say replacing the kernel that's in UBIFS rather than a UBI volume itself) is another wrinkle, due to a lack of filesystem append. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] arm: ensure u-boot only uses relative relocations
Hi Benoît,
On Tue, 28 May 2013 19:04:23 +0200 (CEST), Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
Hi Albert,
On Tuesday, May 28, 2013 9:01:46 AM, Albert ARIBAUD wrote:
Add a Makefile target ('checkarmreloc') which
fails of the ELF binary contains relocation records
^
if
(and)
Also, __image_copy_end needs its own section; putting
it in relocation sections changes their flags and makes
relocation breaks.
^
break
Sorry to have missed that in my review of v1.
Never mind: I'd missed them too. :)
I'll wait a bit for other comments if any, then send out a fixed V3.
Best regards,
Benoît
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 4/7] Add Kconfig scripts and related material
On Tue, May 28, 2013 at 10:31:59AM +0900, Masahiro Yamada wrote: [snip] So, my first request is that this commit should just import scripts as they are in Linux Kernel (plus renaming from Makefile to Makefile.kbuild) All modification you make for U-Boot should be pushed into the next commit Adjust Kconfig scripts for use by U-Boot. I think this would be helpful for reviewers to track which lines are changed. The seconde request is subject of personal preference but I like the white spaces to be kept untouched when importing files from another project. Although I was not sure they were corrected by you, I noticed some white space errors diffs when comparing your patches with Linux Kernel makefiles. The reason is, as you mentioned in commit log, to minimise conflicts with future Kbuild updates. Agreed on both points. -- 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] mmc: fsl_esdhc: Fix hang after 'save' command
Since commit 48e0b2bd (powerpc/esdhc: Correct judgement for DATA PIO mode) we see mx6 systems to hang after doing a 'save' command. Revert this commit since the original 'ifdef' logic from 7b43db92 (drivers/mmc/fsl_esdhc.c: fix compiler warnings) was the correct one. Reported-by: Tapani Utriainen tap...@technexion.com Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- drivers/mmc/fsl_esdhc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index 861f4b9..ec01795 100644 --- a/drivers/mmc/fsl_esdhc.c +++ b/drivers/mmc/fsl_esdhc.c @@ -178,7 +178,7 @@ static int esdhc_setup_data(struct mmc *mmc, struct mmc_data *data) int timeout; struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv; struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg-esdhc_base; -#ifdef CONFIG_SYS_FSL_ESDHC_USE_PIO +#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO uint wml_value; wml_value = data-blocksize/4; -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: fsl_esdhc: Fix hang after 'save' command
On Tue, May 28, 2013 at 3:09 PM, Fabio Estevam fabio.este...@freescale.comwrote: Since commit 48e0b2bd (powerpc/esdhc: Correct judgement for DATA PIO mode) we see mx6 systems to hang after doing a 'save' command. Revert this commit since the original 'ifdef' logic from 7b43db92 (drivers/mmc/fsl_esdhc.c: fix compiler warnings) was the correct one. Reported-by: Tapani Utriainen tap...@technexion.com Signed-off-by: Fabio Estevam fabio.este...@freescale.com This seem to affect 'master' branch, not 'imx' tree. Is that correct? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: fsl_esdhc: Fix hang after 'save' command
On Tue, May 28, 2013 at 3:31 PM, Otavio Salvador ota...@ossystems.com.br wrote: This seem to affect 'master' branch, not 'imx' tree. Is that correct? Yes, the offending commit is in master, but not on u-boot-imx branch. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SF: Add Spansion S25FL064P IDs
Dear Jagan Teki,
On 28-08-2012 20:43, Marek Vasut wrote:
This is a S25FL064A successor. It supports up to 104MHz bus
speed.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Heiko Schocher h...@denx.de
Cc: Mike Frysinger vap...@gentoo.org
Cc: Scott Wood scottw...@freescale.com
Cc: Wolfgang Denk w...@denx.de
---
drivers/mtd/spi/spansion.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
index 9a114ac..faf4414 100644
--- a/drivers/mtd/spi/spansion.c
+++ b/drivers/mtd/spi/spansion.c
@@ -90,6 +90,13 @@ static const struct spansion_spi_flash_params
spansion_spi_flash_table[] = {
.name = S25FL032P,
},
{
+ .idcode1 = 0x0216,
+ .idcode2 = 0x4d00,
+ .pages_per_sector = 256,
+ .nr_sectors = 128,
+ .name = S25FL064P,
+ },
+ {
.idcode1 = 0x2018,
.idcode2 = 0x4d01,
.pages_per_sector = 256,
Applied to u-boot-spi/master
Wow, do we have a new custodian? In any case, nice to meet you ;-)
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/7] arm: vf610: Add IOMUX support for Vybrid VF610
Hi Alison, On Tuesday, May 28, 2013 10:55:41 AM, Alison Wang wrote: This patch adds the IOMUX support for Vybrid VF610 platform. There is a little difference for IOMUXC module between VF610 and i.MX platform, the muxmode and pad configuration share one 32bit register on VF610, but they are two independent registers on I.MX platform. A CONFIG_IOMUX_SHARE_CONFIG_REG was introduced to fit this difference. Signed-off-by: Alison Wang b18...@freescale.com [...] diff --git a/arch/arm/imx-common/iomux-v3.c b/arch/arm/imx-common/iomux-v3.c index 7fe5ce7..35880c7 100644 --- a/arch/arm/imx-common/iomux-v3.c +++ b/arch/arm/imx-common/iomux-v3.c @@ -48,8 +48,14 @@ void imx_iomux_v3_setup_pad(iomux_v3_cfg_t pad) if (sel_input_ofs) __raw_writel(sel_input, base + sel_input_ofs); +#ifdef CONFIG_IOMUX_SHARE_CONF_REG Where is this one defined? I don't see it in include/configs/vf610twr.h. Why not use #ifdef CONFIG_VF610 since this is a platform-dependent code, and not a board-specific config option? + if (!(pad_ctrl NO_PAD_CTRL)) + __raw_writel((mux_mode PAD_MUX_MODE_SHIFT) | pad_ctrl, + base + pad_ctrl_ofs); +#else if (!(pad_ctrl NO_PAD_CTRL) pad_ctrl_ofs) __raw_writel(pad_ctrl, base + pad_ctrl_ofs); +#endif } void imx_iomux_v3_setup_multiple_pads(iomux_v3_cfg_t const *pad_list, [...] Apart from that, this patch is OK. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx27: add function enable_caches
Signed-off-by: Philippe Reynes trem...@yahoo.fr
---
arch/arm/cpu/arm926ejs/mx27/generic.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx27/generic.c
b/arch/arm/cpu/arm926ejs/mx27/generic.c
index 41bb84b..4239fa0 100644
--- a/arch/arm/cpu/arm926ejs/mx27/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx27/generic.c
@@ -380,3 +380,9 @@ void mx27_sd2_init_pins(void)
}
#endif /* CONFIG_MXC_MMC */
+
+void enable_caches(void)
+{
+ /* Enable D-cache. I-cache is already enabled in start.S */
+ dcache_enable();
+}
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx27: add i2c clock
Signed-off-by: Eric Jarrige eric.jarr...@armadeus.org
---
arch/arm/cpu/arm926ejs/mx27/generic.c |2 ++
arch/arm/include/asm/arch-mx27/clock.h |1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx27/generic.c
b/arch/arm/cpu/arm926ejs/mx27/generic.c
index 4239fa0..25e1250 100644
--- a/arch/arm/cpu/arm926ejs/mx27/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx27/generic.c
@@ -159,6 +159,8 @@ unsigned int mxc_get_clock(enum mxc_clock clk)
switch (clk) {
case MXC_ARM_CLK:
return imx_get_armclk();
+ case MXC_I2C_CLK:
+ return imx_get_ahbclk()/2;
case MXC_UART_CLK:
return imx_get_perclk1();
case MXC_FEC_CLK:
diff --git a/arch/arm/include/asm/arch-mx27/clock.h
b/arch/arm/include/asm/arch-mx27/clock.h
index fd062d3..2b03a41 100644
--- a/arch/arm/include/asm/arch-mx27/clock.h
+++ b/arch/arm/include/asm/arch-mx27/clock.h
@@ -26,6 +26,7 @@
enum mxc_clock {
MXC_ARM_CLK,
+ MXC_I2C_CLK,
MXC_UART_CLK,
MXC_ESDHC_CLK,
MXC_FEC_CLK,
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx27: add missing constant for mx27
Add some missing constant (chip select, ...)
Signed-off-by: Philippe Reynes trem...@yahoo.fr
Signed-off-by: Eric Jarrige eric.jarr...@armadeus.org
---
arch/arm/cpu/arm926ejs/mx27/asm-offsets.c |5 +
arch/arm/include/asm/arch-mx27/imx-regs.h |3 ++-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx27/asm-offsets.c
b/arch/arm/cpu/arm926ejs/mx27/asm-offsets.c
index f3a8d7b..215c562 100644
--- a/arch/arm/cpu/arm926ejs/mx27/asm-offsets.c
+++ b/arch/arm/cpu/arm926ejs/mx27/asm-offsets.c
@@ -41,5 +41,10 @@ int main(void)
DEFINE(ESDCFG1_ROF, offsetof(struct esdramc_regs, esdcfg1));
DEFINE(ESDMISC_ROF, offsetof(struct esdramc_regs, esdmisc));
+ DEFINE(GPCR, IMX_SYSTEM_CTL_BASE +
+ offsetof(struct system_control_regs, gpcr));
+ DEFINE(FMCR, IMX_SYSTEM_CTL_BASE +
+ offsetof(struct system_control_regs, fmcr));
+
return 0;
}
diff --git a/arch/arm/include/asm/arch-mx27/imx-regs.h
b/arch/arm/include/asm/arch-mx27/imx-regs.h
index 8867e9f..707ca4b 100644
--- a/arch/arm/include/asm/arch-mx27/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx27/imx-regs.h
@@ -185,7 +185,7 @@ struct iim_regs {
struct fuse_bank {
u32 fuse_regs[0x20];
u32 fuse_rsvd[0xe0];
- } bank[1];
+ } bank[2];
};
struct fuse_bank0_regs {
@@ -225,6 +225,7 @@ struct fuse_bank0_regs {
#define IIM_BASE_ADDR IMX_IIM_BASE
#define IMX_FEC_BASE (0x2b000 + IMX_IO_BASE)
+#define IMX_NFC_BASE (0xD800)
#define IMX_ESD_BASE (0xD8001000)
#define IMX_WEIM_BASE (0xD8002000)
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/7] arm: vf610: Add Vybrid VF610 CPU support
Hi Alison, On Tuesday, May 28, 2013 10:55:42 AM, Alison Wang wrote: This patch adds generic codes to support Freescale's Vybrid VF610 CPU. It aligns Vybrid VF610 platform with i.MX platform. As there are some differences between VF610 and i.MX platforms, the specific codes are in the arch/arm/cpu/armv7/vf610 directory. Signed-off-by: Alison Wang b18...@freescale.com [...] diff --git a/doc/README.vf610 b/doc/README.vf610 new file mode 100644 index 000..38cf5cf --- /dev/null +++ b/doc/README.vf610 @@ -0,0 +1,10 @@ +U-Boot for Freescale Vybrid VF610 + +This file contains information for the port of U-Boot to the Freescale Vybrid +VF610 SoC. + +1. CONVENTIONS FOR FUSE ASSIGNMENTS +--- + +1.1 MAC Address: It is stored in fuse bank 4, with the 16 msbs in word 2 and the +32 lsbs in word 3. The hunk below is still missing: doc/README.mxc_ocotp: --- on MXC This IP can be found on the following SoCs: + - Vybrid VF610, - i.MX6. Note that this IP is different from albeit similar to the IPs of the same name --- Apart from that, this patch is correct. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/7] net: fec_mxc: Add support for Vybrid VF610
Hi Alison, On Tuesday, May 28, 2013 10:55:43 AM, Alison Wang wrote: This patch adds FEC support for Vybrid VF610 platform. In function fec_open(), RCR register is only set as RGMII mode. But RCR register should be set as RMII mode for VF610 platform. This configuration is already done in fec_reg_setup(), so this piece of code could just leave untouched the FEC_RCNTRL_RGMII / FEC_RCNTRL_RMII / FEC_RCNTRL_MII_MODE bits. [...] Reviewed-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/7] arm: vf610: Add Vybrid VF610 CPU support
Hi Alison, On Tuesday, May 28, 2013 9:16:20 PM, Benoît Thébaudeau wrote: Hi Alison, On Tuesday, May 28, 2013 10:55:42 AM, Alison Wang wrote: This patch adds generic codes to support Freescale's Vybrid VF610 CPU. It aligns Vybrid VF610 platform with i.MX platform. As there are some differences between VF610 and i.MX platforms, the specific codes are in the arch/arm/cpu/armv7/vf610 directory. Signed-off-by: Alison Wang b18...@freescale.com [...] diff --git a/doc/README.vf610 b/doc/README.vf610 new file mode 100644 index 000..38cf5cf --- /dev/null +++ b/doc/README.vf610 @@ -0,0 +1,10 @@ +U-Boot for Freescale Vybrid VF610 + +This file contains information for the port of U-Boot to the Freescale Vybrid +VF610 SoC. + +1. CONVENTIONS FOR FUSE ASSIGNMENTS +--- + +1.1 MAC Address: It is stored in fuse bank 4, with the 16 msbs in word 2 and the +32 lsbs in word 3. The hunk below is still missing: doc/README.mxc_ocotp: --- on MXC This IP can be found on the following SoCs: + - Vybrid VF610, - i.MX6. Note that this IP is different from albeit similar to the IPs of the same name --- I have just noticed that this was actually in 6/7. Why are you putting this into a separate patch? Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men
There are a few partially conflicting requirements in compiling the device
tree, since U-Boot relies on whatever is installed on the build machine.
Some versions of dtc support -i, and this is often better than using #include
since you get correct line number information in errors. Unfortunately this
version must be installed manually in current Linux distributions.
Some device tree files use the word 'linux' which gets replaced with '1' by
many version of gcc, including version 4.7. So undefine this.
When an device tree file has an error we want to direct the user to the
right file and line number. So instead of piping the file into dts through
stdin, put it in a real file so that we get a fairly sensible error message
from dts. Then print out the original file details to help further.
This is based on a commit from Tom Warren. It would help if people can
test it in different environments.
Signed-off-by: Tom Warren twar...@nvidia.com
Signed-off-by: Simon Glass s...@chromium.org
---
dts/Makefile | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/dts/Makefile b/dts/Makefile
index 03e163e..1f6fabb 100644
--- a/dts/Makefile
+++ b/dts/Makefile
@@ -37,11 +37,29 @@ $(if $(CONFIG_ARCH_DEVICE_TREE),,\
$(error Your architecture does not have device tree support enabled. \
Please define CONFIG_ARCH_DEVICE_TREE))
+# Provide a list of include directories for dtc
+DTS_INCS-y := -i $(SRCTREE)/arch/$(ARCH)/dts
+
+DTS_INCS-y += -i $(SRCTREE)/board/$(VENDOR)/dts
+
+DTS_INCS-$(CONFIG_CHROMEOS) += -i $(SRCTREE)/cros/dts
+
+# Check if our dtc includes the -i option
+DTS_FLAGS := $(shell if ! dtc -i 21 | grep -q invalid option; then \
+ echo $(DTS_INCS-y); fi)
+
# We preprocess the device tree file provide a useful define
-DTS_CPPFLAGS := -x assembler-with-cpp \
+# Undefine 'linux' since it might be used in device tree files
+DTS_CPPFLAGS := -x assembler-with-cpp -Ulinux \
-DARCH_CPU_DTS=\$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\ \
-DBOARD_DTS=\$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\ \
- -I$(SRCTREE)/board/$(VENDOR)/dts -I$(SRCTREE)/arch/$(ARCH)/dts
+ -D__ASSEMBLY__ -I$(OBJTREE)/include -I$(SRCTREE)/include \
+ -I$(OBJTREE)/include2 \
+ -I$(SRCTREE)/board/$(VENDOR)/dts -I$(SRCTREE)/arch/$(ARCH)/dts \
+ -include $(OBJTREE)/include/config.h
+
+DTS_TMP := $(OBJTREE)/include/generated/$(DEVICE_TREE).dts.in
+DTS_SRC := board/$(VENDOR)/dts/$(DEVICE_TREE).dts
all: $(obj).depend $(LIB)
@@ -50,13 +68,19 @@ all:$(obj).depend $(LIB)
# the filename.
DT_BIN := $(obj)dt.dtb
-$(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
+DTC_CMD := $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} $(DTS_FLAGS) $(DTS_TMP)
+
+$(DT_BIN): $(TOPDIR)/$(DTS_SRC)
rc=$$( \
- cat $ | $(CPP) -P $(DTS_CPPFLAGS) - | \
- { { $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} - 21 ; \
+ cat $ | $(CPP) -P $(DTS_CPPFLAGS) - $(DTS_TMP); \
+ { { $(DTC_CMD) 21 ; \
echo $$? 3 ; } | \
grep -v '^DTC: dts-dtb on file' ; \
} 31 12 ) ; \
+ if [ $$rc != 0 ]; then \
+ echo Source file is $(DTS_SRC); \
+ echo Compiler: $(DTC_CMD); \
+ fi; \
exit $$rc
process_lds = \
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: fsl_esdhc: Fix hang after 'save' command
On May 28, 2013, at 1:09 PM, Fabio Estevam wrote: Since commit 48e0b2bd (powerpc/esdhc: Correct judgement for DATA PIO mode) we see mx6 systems to hang after doing a 'save' command. Revert this commit since the original 'ifdef' logic from 7b43db92 (drivers/mmc/fsl_esdhc.c: fix compiler warnings) was the correct one. Reported-by: Tapani Utriainen tap...@technexion.com Signed-off-by: Fabio Estevam fabio.este...@freescale.com My apologies. I misread that patch. I found it hard to believe that Wolfgang had broken the logic, and that it had been broken for 2 years, but somehow my brain insisted that was the case. I now agree with your assessment, and will apply your patch. Haijun, please investigate the problem you were trying to solve with this patch, and determine what the actual cause was, and then submit a new patch to fix it. Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men
Simon,
-Original Message-
From: Simon Glass [mailto:s...@chromium.org]
Sent: Tuesday, May 28, 2013 12:36 PM
To: U-Boot Mailing List
Cc: Tom Rini; Stephen Warren; Devicetree Discuss; u-boot-
rev...@google.com; Simon Glass; Tom Warren; Jerry Van Baren
Subject: [PATCH] fdt: Enhance dts/Makefile to be all things to all men
There are a few partially conflicting requirements in compiling the device
tree, since U-Boot relies on whatever is installed on the build machine.
Some versions of dtc support -i, and this is often better than using #include
since you get correct line number information in errors. Unfortunately this
version must be installed manually in current Linux distributions.
Some device tree files use the word 'linux' which gets replaced with '1' by
many version of gcc, including version 4.7. So undefine this.
When an device tree file has an error we want to direct the user to the right
file and line number. So instead of piping the file into dts through stdin,
put it
in a real file so that we get a fairly sensible error message from dts. Then
print out the original file details to help further.
This is based on a commit from Tom Warren. It would help if people can test
it in different environments.
Signed-off-by: Tom Warren twar...@nvidia.com
Signed-off-by: Simon Glass s...@chromium.org
Works for me for all Tegra builds, so:
Tested-by: Tom Warren twar...@nvidia.com
Tom
---
dts/Makefile | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/dts/Makefile b/dts/Makefile index 03e163e..1f6fabb 100644
--- a/dts/Makefile
+++ b/dts/Makefile
@@ -37,11 +37,29 @@ $(if $(CONFIG_ARCH_DEVICE_TREE),,\ $(error Your
architecture does not have device tree support enabled. \ Please define
CONFIG_ARCH_DEVICE_TREE))
+# Provide a list of include directories for dtc DTS_INCS-y := -i
+$(SRCTREE)/arch/$(ARCH)/dts
+
+DTS_INCS-y += -i $(SRCTREE)/board/$(VENDOR)/dts
+
+DTS_INCS-$(CONFIG_CHROMEOS) += -i $(SRCTREE)/cros/dts
+
+# Check if our dtc includes the -i option DTS_FLAGS := $(shell if ! dtc
+-i 21 | grep -q invalid option; then \
+ echo $(DTS_INCS-y); fi)
+
# We preprocess the device tree file provide a useful define -DTS_CPPFLAGS
:= -x assembler-with-cpp \
+# Undefine 'linux' since it might be used in device tree files
+DTS_CPPFLAGS := -x assembler-with-cpp -Ulinux \
-
DARCH_CPU_DTS=\$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVIC
E_TREE).dtsi\ \
-
DBOARD_DTS=\$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TR
EE).dts\ \
- -I$(SRCTREE)/board/$(VENDOR)/dts -
I$(SRCTREE)/arch/$(ARCH)/dts
+ -D__ASSEMBLY__ -I$(OBJTREE)/include -I$(SRCTREE)/include
\
+ -I$(OBJTREE)/include2 \
+ -I$(SRCTREE)/board/$(VENDOR)/dts -
I$(SRCTREE)/arch/$(ARCH)/dts \
+ -include $(OBJTREE)/include/config.h
+
+DTS_TMP := $(OBJTREE)/include/generated/$(DEVICE_TREE).dts.in
+DTS_SRC := board/$(VENDOR)/dts/$(DEVICE_TREE).dts
all: $(obj).depend $(LIB)
@@ -50,13 +68,19 @@ all: $(obj).depend $(LIB)
# the filename.
DT_BIN := $(obj)dt.dtb
-$(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
+DTC_CMD := $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} $(DTS_FLAGS)
+$(DTS_TMP)
+
+$(DT_BIN): $(TOPDIR)/$(DTS_SRC)
rc=$$( \
- cat $ | $(CPP) -P $(DTS_CPPFLAGS) - | \
- { { $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} - 21 ; \
+ cat $ | $(CPP) -P $(DTS_CPPFLAGS) - $(DTS_TMP); \
+ { { $(DTC_CMD) 21 ; \
echo $$? 3 ; } | \
grep -v '^DTC: dts-dtb on file' ; \
} 31 12 ) ; \
+ if [ $$rc != 0 ]; then \
+ echo Source file is $(DTS_SRC); \
+ echo Compiler: $(DTC_CMD); \
+ fi; \
exit $$rc
process_lds = \
--
1.8.2.1
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 7/7] arm: vf610: Add basic support for Vybrid VF610TWR board
Hi Alison, On Tuesday, May 28, 2013 10:55:47 AM, Alison Wang wrote: VF610TWR is a board based on Vybrid VF610 SoC. This patch adds basic support for Vybrid VF610TWR board. Signed-off-by: Alison Wang b18...@freescale.com Signed-off-by: Jason Jin jason@freescale.com Signed-off-by: TsiChung Liew tsicl...@gmail.com [...] diff --git a/include/configs/vf610twr.h b/include/configs/vf610twr.h new file mode 100644 index 000..77fe893 --- /dev/null +++ b/include/configs/vf610twr.h @@ -0,0 +1,140 @@ +/* + * Copyright 2013 Freescale Semiconductor, Inc. + * + * Configuration settings for the Freescale Vybrid vf610twr board. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#ifndef __CONFIG_H +#define __CONFIG_H + +#include asm/arch/imx-regs.h +#include config_cmd_default.h + +#define CONFIG_VF610 + +#define CONFIG_DISPLAY_CPUINFO +#define CONFIG_DISPLAY_BOARDINFO + +#define CONFIG_MACH_TYPE 4146 + +#define CONFIG_SKIP_LOWLEVEL_INIT + +/* Enable passing of ATAGs */ +#define CONFIG_CMDLINE_TAG + +#define CONFIG_CMD_FUSE +#ifdef CONFIG_CMD_FUSE +#define CONFIG_MXC_OCOTP +#endif + +/* Size of malloc() pool */ +#define CONFIG_SYS_MALLOC_LEN(CONFIG_ENV_SIZE + 2 * 1024 * 1024) + +#define CONFIG_BOARD_EARLY_INIT_F + +#define CONFIG_FSL_LPUART +#define LPUART_BASE UART1_BASE + +/* Allow to overwrite serial and ethaddr */ +#define CONFIG_ENV_OVERWRITE +#define CONFIG_SYS_UART_PORT (1) +#define CONFIG_BAUDRATE 115200 + +#undef CONFIG_CMD_IMLS + +#define CONFIG_MMC +#define CONFIG_FSL_ESDHC +#define CONFIG_SYS_FSL_ESDHC_ADDR0 +#define CONFIG_SYS_FSL_ESDHC_NUM 1 + +#define CONFIG_SYS_FSL_ERRATUM_ESDHC111 + +#define CONFIG_CMD_MMC +#define CONFIG_GENERIC_MMC +#define CONFIG_CMD_FAT +#define CONFIG_DOS_PARTITION + +#define CONFIG_CMD_PING +#define CONFIG_CMD_DHCP +#define CONFIG_CMD_MII +#define CONFIG_CMD_NET +#define CONFIG_FEC_MXC +#define CONFIG_MII +#define IMX_FEC_BASE ENET_BASE_ADDR +#define CONFIG_FEC_XCV_TYPE RMII +#define CONFIG_FEC_MXC_PHYADDR 0 Why don't you add support for the 2nd FEC? Do you plan to do it later? +#define CONFIG_PHYLIB +#define CONFIG_PHY_MICREL + +#define CONFIG_BOOTDELAY 3 + +#define CONFIG_SYS_TEXT_BASE 0x3f008000 + +/* Miscellaneous configurable options */ +#define CONFIG_SYS_LONGHELP /* undef to save memory */ +#define CONFIG_SYS_HUSH_PARSER /* use hush command parser */ +#define CONFIG_SYS_PROMPT_HUSH_PS2 +#define CONFIG_SYS_PROMPTVybrid U-Boot +#undef CONFIG_AUTO_COMPLETE +#define CONFIG_SYS_CBSIZE256 /* Console I/O Buffer Size */ +#define CONFIG_SYS_PBSIZE\ + (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16) +#define CONFIG_SYS_MAXARGS 16 /* max number of command args */ +#define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE + +#define CONFIG_CMD_MEMTEST +#define CONFIG_SYS_MEMTEST_START 0x8001 +#define CONFIG_SYS_MEMTEST_END 0x87C0 Please make sure to have runtime-tested this address range with the mtest command since bad mtest addresses are the reason why CONFIG_CMD_MEMTEST has been removed from the default commands. [...] Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] dfu: dfu and UBI Volumes
Dear Tom, In message 20130528172309.GF5829@bill-the-cat you wrote: Of course this can't yet apply to writing files on file systems since the current API in U-Boot misses the append feature, but this could be applied to program raw memory partitions, including UBI images. Correct. We can write a whole UBI image, today, of NAND size, regardless of DDR size. But modifying UBI volumes (so UBIFS or your I don't think so. To write a UBI volume on an existing UBI device, you would use the ubi write command. This translates into a call of ubi_volume_write(char *volume, void *buf, size_t size) which means the size must be known before you start writing; as far as I can tell ubi_volume_write() does not support incremental write operations of individual parts of a volume. 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 Its always easier short term to pee in the pond than install a toilet - it's just not a good long term plan. - Alan Cox in 20100101145701.6432e...@lxorguk.ukuu.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] OMAP5: Fix bug in omap5_es1_prcm struct
On Sun, May 26, 2013 at 11:03:17PM +0300, Lubomir Popov wrote: The newly introduced function setup_warmreset_time(), called from within prcm_init(), tries to write to the prm_rsttime OMAP5 register. The struct member holding this register's address is however initialized for OMAP5 ES2.0 only. On ES1.0 devices this uninitialized value causes a second (warm) reset at startup. Add .prm_rsttime address init to the ES1.0 struct. Signed-off-by: Lubomir Popov lpo...@mm-sol.com Acked-by: Tom Rini tr...@ti.com -- 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 0/5] sf: Code cleanup patch set
On Tue, May 28, 2013 at 01:27:23AM +0530, Jagannadha Sutradharudu Teki wrote: This patch set consist of code clean-up on sf. Thanks, Jagan. Jagannadha Sutradharudu Teki (5): sf: eon|spansion|ramtron: Fix code cleanup sf: sst: Fix code cleanup sf: stmicro: Fix code cleanup sf: Fix line over 80 chars cleanup cmd_sf: Fix code cleanup common/cmd_sf.c |5 +++-- drivers/mtd/spi/eon.c |3 +-- drivers/mtd/spi/ramtron.c |6 -- drivers/mtd/spi/spansion.c |3 ++- drivers/mtd/spi/spi_flash.c |9 ++--- drivers/mtd/spi/sst.c | 32 drivers/mtd/spi/stmicro.c |7 +++ 7 files changed, 39 insertions(+), 26 deletions(-) Everything looks OK, but to be clear, at the end of this checkpatch.pl says style problems have all been fixed? Or this just fixes some of them? 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] fdt: Enhance dts/Makefile to be all things to all men
On 05/28/2013 01:36 PM, Simon Glass wrote:
There are a few partially conflicting requirements in compiling the device
tree, since U-Boot relies on whatever is installed on the build machine.
Some versions of dtc support -i, and this is often better than using #include
since you get correct line number information in errors.
What issue is there with line numbers when using dtc? Recent dtc
supports #line directives from the pre-processing results, and hence
reports errors in terms of the source files, just like raw dtc without cpp.
Unfortunately this
version must be installed manually in current Linux distributions.
Well, then that gets into the problem of some .dts files choosing to use
/include/ and rely on -i, but others using #include and not. I don't
really think it's a good idea to propagate both versions. Picking one
and using it would be far better.
I really do think we should simply require a reasonably recent dtc and
be done with it.
Some device tree files use the word 'linux' which gets replaced with '1' by
many version of gcc, including version 4.7. So undefine this.
Linux chose to use -undef rather than undefining specific/individual
defines. It'd be best to be consistent to that .dts files are more
likely to be portable between the two.
diff --git a/dts/Makefile b/dts/Makefile
+# Provide a list of include directories for dtc
+DTS_INCS-y := -i $(SRCTREE)/arch/$(ARCH)/dts
+
+DTS_INCS-y += -i $(SRCTREE)/board/$(VENDOR)/dts
That has arch/ first then board/ ... (continued a few comments below)
+DTS_INCS-$(CONFIG_CHROMEOS) += -i $(SRCTREE)/cros/dts
Is that meant to be upstream?
+# Check if our dtc includes the -i option
+DTS_FLAGS := $(shell if ! dtc -i 21 | grep -q invalid option; then \
+ echo $(DTS_INCS-y); fi)
+
# We preprocess the device tree file provide a useful define
-DTS_CPPFLAGS := -x assembler-with-cpp \
+# Undefine 'linux' since it might be used in device tree files
+DTS_CPPFLAGS := -x assembler-with-cpp -Ulinux \
I'll repeat my request to use -undef instead.
-DARCH_CPU_DTS=\$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\
\
-DBOARD_DTS=\$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\ \
- -I$(SRCTREE)/board/$(VENDOR)/dts -I$(SRCTREE)/arch/$(ARCH)/dts
+ -D__ASSEMBLY__ -I$(OBJTREE)/include -I$(SRCTREE)/include \
+ -I$(OBJTREE)/include2 \
Do we really want include or include2 (what's that?) at all? The .dts
files really should be standalone, and not interact with the U-Boot
headers at all.
+ -I$(SRCTREE)/board/$(VENDOR)/dts -I$(SRCTREE)/arch/$(ARCH)/dts \
... whereas this has board/ first then arch/. It'd be better to be
consistent.
+ -include $(OBJTREE)/include/config.h
+
+DTS_TMP := $(OBJTREE)/include/generated/$(DEVICE_TREE).dts.in
Hmm. This really isn't a generated header file. Can this instead be
$(OBJTREE)/$(dir $@).$(notdir $@).dts or something like that?
+DTS_SRC := board/$(VENDOR)/dts/$(DEVICE_TREE).dts
all: $(obj).depend $(LIB)
@@ -50,13 +68,19 @@ all: $(obj).depend $(LIB)
# the filename.
DT_BIN := $(obj)dt.dtb
-$(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
+DTC_CMD := $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} $(DTS_FLAGS) $(DTS_TMP)
It may be better to leave $(DTS_TMP) in the make script below, so it's
more obvious what file is being compiled; the re-direct to $(DTS_TMP) is
left in the $(CPP) invocation below, so it'd also be consistent with that.
+$(DT_BIN): $(TOPDIR)/$(DTS_SRC)
rc=$$( \
- cat $ | $(CPP) -P $(DTS_CPPFLAGS) - | \
- { { $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} - 21 ; \
+ cat $ | $(CPP) -P $(DTS_CPPFLAGS) - $(DTS_TMP); \
+ { { $(DTC_CMD) 21 ; \
...
+ if [ $$rc != 0 ]; then \
+ echo Source file is $(DTS_SRC); \
+ echo Compiler: $(DTC_CMD); \
+ fi; \
Isn't that what make V=1 is for?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men
Dear Simon Glass, In message 1369769778-12455-1-git-send-email-...@chromium.org you wrote: Some device tree files use the word 'linux' which gets replaced with '1' by many version of gcc, including version 4.7. So undefine this. I think this is not a good way to address this issue. The GCC documentation (section System-specific Predefined Macros [1]) desribes how this should be handled. The correct (TM) way to fix this is by adding -ansi or any -std option that requests strict conformance to the compiler/preprocessor command line. [1] http://gcc.gnu.org/onlinedocs/cpp/System_002dspecific-Predefined-Macros.html#System_002dspecific-Predefined-Macros 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 The human race is faced with a cruel choice: work or daytime tele- vision. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] dfu: dfu and UBI Volumes
On Tue, May 28, 2013 at 11:01:09PM +0200, Wolfgang Denk wrote: Dear Tom, In message 20130528172309.GF5829@bill-the-cat you wrote: Of course this can't yet apply to writing files on file systems since the current API in U-Boot misses the append feature, but this could be applied to program raw memory partitions, including UBI images. Correct. We can write a whole UBI image, today, of NAND size, regardless of DDR size. But modifying UBI volumes (so UBIFS or your I don't think so. To write a UBI volume on an existing UBI device, you would use the ubi write command. This translates into a call of ubi_volume_write(char *volume, void *buf, size_t size) which means the size must be known before you start writing; as far as I can tell ubi_volume_write() does not support incremental write operations of individual parts of a volume. OK. A very quick read of ubi_volume_write leads into the guts of the write being in drivers/mtd/ubi/upd.c and it feels like you could actually do the volume write in chunks with ubi_start_update() and ubi_more_update_data() (and maybe some other housekeeping bits). It might take a bit more work since it looks like looks like both functions rely on knowing the size at the start, but that's just to make sure the size will fit in the volume. -- 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] pull request for u-boot-tegra/master into ARM/master
Albert, Please pull u-boot-tegra/master into ARM/master. Thanks! ./MAKEALL for all the Tegra boards is OK, running a ./MAKEALL -a arm now. tools/checkpatch.pl is clean. The following changes since commit fd725691797bb3192af15a15c2cba7d0b2ee9327: arm: Enable -ffunction-sections / -fdata-sections / --gc-sections (2013-05-23 12:09:56 +0200) are available in the git repository at: git://git.denx.de/u-boot-tegra master for you to fetch changes up to 60985bba58e7695dac1fddae8cdbb62d8cfd1254: tegra: Define CONFIG_SKIP_LOWLEVEL_INIT for SPL build (2013-05-28 12:58:44 -0700) Allen Martin (1): Tegra: clk: always use find_best_divider() for periph clocks Axel Lin (2): ARM: arm720t: Add missing CONFIG_SKIP_LOWLEVEL_INIT guard for cpu_init_crit tegra: Define CONFIG_SKIP_LOWLEVEL_INIT for SPL build Stephen Warren (3): tegra: always build u-boot-nodtb-tegra.bin ARM: tegra: support SKU 1 of Tegra114 ARM: tegra: support SKU 7 of Tegra20 Tom Warren (2): Tegra: T30: Beaver: Fix board/board_name env vars, s/b beaver, not cardhu Tegra: Remove unused/non-existent spl linker script reference Makefile| 17 ++- arch/arm/cpu/arm720t/start.S| 4 ++-- arch/arm/cpu/tegra-common/ap.c | 2 ++ arch/arm/cpu/tegra-common/clock.c | 10 - arch/arm/include/asm/arch-tegra/tegra.h | 2 ++ board/nvidia/beaver/Makefile| 38 + boards.cfg | 2 +- include/configs/tegra-common-post.h | 2 ++ include/configs/tegra114-common.h | 2 -- include/configs/tegra20-common.h| 2 -- include/configs/tegra30-common.h| 2 -- 11 files changed, 59 insertions(+), 24 deletions(-) create mode 100644 board/nvidia/beaver/Makefile ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/pixis: Fix pixis help message
pixis_reset help command prints the message without a new line \n, which makes the prompt on the same line. Signed-off-by: York Sun york...@freescale.com --- board/freescale/common/pixis.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/freescale/common/pixis.c b/board/freescale/common/pixis.c index 8d07061..577a542 100644 --- a/board/freescale/common/pixis.c +++ b/board/freescale/common/pixis.c @@ -552,5 +552,5 @@ U_BOOT_CMD( pixis_reset [altbank]\n pixis_reset altbank wd\n pixis_reset altbank cf SYSCLK freq COREPLL ratio MPXPLL ratio\n - pixis_reset cf SYSCLK freq COREPLL ratio MPXPLL ratio + pixis_reset cf SYSCLK freq COREPLL ratio MPXPLL ratio\n ); -- 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 5/6] spl: Make CONFIG_SPL_BUILD contain more functionality
On 05/22/2013 08:26:31 PM, Zhang Ying-B40530 wrote: -Original Message- From: Wood Scott-B07421 Sent: Wednesday, May 22, 2013 11:46 PM To: Zhang Ying-B40530 Cc: Wood Scott-B07421; u-boot@lists.denx.de; aflem...@gmail.com; Xie Xiaobo-R63061; Ilya Yanok Subject: Re: [PATCH 5/6] spl: Make CONFIG_SPL_BUILD contain more functionality On 05/21/2013 09:15:08 PM, Zhang Ying-B40530 wrote: diff --git a/include/configs/MPC8313ERDB.h b/include/configs/MPC8313ERDB.h index c28dfe0..a2bdcff 100644 --- a/include/configs/MPC8313ERDB.h +++ b/include/configs/MPC8313ERDB.h @@ -40,7 +40,9 @@ #define CONFIG_SPL_INIT_MINIMAL #define CONFIG_SPL_SERIAL_SUPPORT #define CONFIG_SPL_NAND_SUPPORT +#ifdef CONFIG_SPL_BUILD #define CONFIG_SPL_NAND_MINIMAL +#endif #define CONFIG_SPL_FLUSH_IMAGE #define CONFIG_SPL_TARGETu-boot-with-spl.bin #define CONFIG_SPL_MPC83XX_WAIT_FOR_NAND diff --git a/include/configs/P1022DS.h b/include/configs/P1022DS.h index 8b13b10..5bdd44a 100644 --- a/include/configs/P1022DS.h +++ b/include/configs/P1022DS.h @@ -41,7 +41,9 @@ #define CONFIG_SPL_INIT_MINIMAL #define CONFIG_SPL_SERIAL_SUPPORT #define CONFIG_SPL_NAND_SUPPORT +#ifdef CONFIG_SPL_BUILD #define CONFIG_SPL_NAND_MINIMAL +#endif #define CONFIG_SPL_FLUSH_IMAGE #define CONFIG_SPL_TARGET u-boot-with-spl.bin diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h index 7ed634b..bc48d62 100644 --- a/include/configs/p1_p2_rdb_pc.h +++ b/include/configs/p1_p2_rdb_pc.h @@ -159,7 +159,9 @@ #define CONFIG_SPL_INIT_MINIMAL #define CONFIG_SPL_SERIAL_SUPPORT #define CONFIG_SPL_NAND_SUPPORT +#ifdef CONFIG_SPL_BUILD #define CONFIG_SPL_NAND_MINIMAL +#endif #define CONFIG_SPL_FLUSH_IMAGE #define CONFIG_SPL_TARGETu-boot-with-spl.bin Are you sure this belongs in this patch? [Zhang Ying] Yes, it is necessary. Because CONFIG_SPL_NAND_MINIMAL has been used in the file law.c and tlb.c in this patch. What I mean is that it should probably have been done earlier, when you introduced CONFIG_SPL_NAND_MINIMAL. [Zhang Ying] I can understand you mean. Because the symbol CONFIG_SPL_NAND_MINIMAL has been useless, I think no need to split out a separate patch. OK, it looks like CONFIG_SPL_NAND_MINIMAL was there before your patchset. I think that was an accidental left-over and should have been removed (it was replaced with CONFIG_SPL_NAND_DRIVERS, _BASE, and _ECC). Could you describe what specifically you're using it to mean here? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] SPL: Makefile: Build a separate autoconf.mk for SPL
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 --- Makefile | 19 +-- config.mk |6 ++ 2 files changed, 23 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 6a30e04..e3a87e5 100644 --- a/Makefile +++ b/Makefile @@ -567,6 +567,7 @@ updater: # Explicitly make _depend in subdirs containing multiple targets to prevent # parallel sub-makes creating .depend files simultaneously. depend dep:$(TIMESTAMP_FILE) $(VERSION_FILE) \ + $(obj)include/spl-autoconf.mk \ $(obj)include/autoconf.mk \ $(obj)include/generated/generic-asm-offsets.h \ $(obj)include/generated/asm-offsets.h @@ -632,12 +633,23 @@ $(obj)include/autoconf.mk: $(obj)include/config.h sed -n -f tools/scripts/define2mk.sed $@.tmp \ mv $@.tmp $@ +# Auto-generate the spl-autoconf.mk file (which is included by all makefiles for SPL) +$(obj)include/spl-autoconf.mk: $(obj)include/config.h + @$(XECHO) Generating $@ ; \ + set -e ; \ + : Extract the config macros ; \ + $(CPP) $(CFLAGS) -DCONFIG_SPL_BUILD -DDO_DEPS_ONLY -dM include/common.h | \ + sed -n -f tools/scripts/define2mk.sed $@.tmp \ + mv $@.tmp $@ + $(obj)include/generated/generic-asm-offsets.h: $(obj)include/autoconf.mk.dep \ + $(obj)include/spl-autoconf.mk \ $(obj)lib/asm-offsets.s @$(XECHO) Generating $@ tools/scripts/make-asm-offsets $(obj)lib/asm-offsets.s $@ $(obj)lib/asm-offsets.s: $(obj)include/autoconf.mk.dep \ + $(obj)include/spl-autoconf.mk \ $(src)lib/asm-offsets.c @mkdir -p $(obj)lib $(CC) -DDO_DEPS_ONLY \ @@ -645,11 +657,13 @@ $(obj)lib/asm-offsets.s: $(obj)include/autoconf.mk.dep \ -o $@ $(src)lib/asm-offsets.c -c -S $(obj)include/generated/asm-offsets.h: $(obj)include/autoconf.mk.dep \ + $(obj)include/spl-autoconf.mk \ $(obj)$(CPUDIR)/$(SOC)/asm-offsets.s @$(XECHO) Generating $@ tools/scripts/make-asm-offsets $(obj)$(CPUDIR)/$(SOC)/asm-offsets.s $@ -$(obj)$(CPUDIR)/$(SOC)/asm-offsets.s: $(obj)include/autoconf.mk.dep +$(obj)$(CPUDIR)/$(SOC)/asm-offsets.s: $(obj)include/autoconf.mk.dep \ + $(obj)include/spl-autoconf.mk @mkdir -p $(obj)$(CPUDIR)/$(SOC) if [ -f $(src)$(CPUDIR)/$(SOC)/asm-offsets.c ];then \ $(CC) -DDO_DEPS_ONLY \ @@ -711,7 +725,8 @@ include/license.h: tools/bin2header COPYING unconfig: @rm -f $(obj)include/config.h $(obj)include/config.mk \ $(obj)board/*/config.tmp $(obj)board/*/*/config.tmp \ - $(obj)include/autoconf.mk $(obj)include/autoconf.mk.dep + $(obj)include/autoconf.mk $(obj)include/autoconf.mk.dep \ + $(obj)include/spl-autoconf.mk %_config:: unconfig @$(MKCONFIG) -A $(@:_config=) diff --git a/config.mk b/config.mk index 51b4783..3246c2c 100644 --- a/config.mk +++ b/config.mk @@ -153,7 +153,13 @@ DTC= dtc # # Load generated board configuration +ifeq ($(CONFIG_SPL_BUILD),y) +# Include SPL autoconf +sinclude $(OBJTREE)/include/spl-autoconf.mk +else +# Include normal autoconf sinclude $(OBJTREE)/include/autoconf.mk +endif sinclude $(OBJTREE)/include/config.mk # Some architecture config.mk files need to know what CPUDIR is set to, -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/13] sf: winbond: add W25Q32DW
On Fri, May 24, 2013 at 01:39:51PM -0700, Jagan Teki wrote:
Hi,
Any update on this.
Thanks,
Jagan.
On Thu, May 23, 2013 at 1:15 PM, Jagan Teki jagannadh.t...@gmail.com wrote:
Hi Allen,
On Sun, Mar 17, 2013 at 10:28 AM, Allen Martin amar...@nvidia.com wrote:
Add support for Winbond W25Q32DW 32Mbit part
Signed-off-by: Allen Martin amar...@nvidia.com
---
drivers/mtd/spi/winbond.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index 4418302..3560fcb 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -68,6 +68,11 @@ static const struct winbond_spi_flash_params
winbond_spi_flash_table[] = {
.name = W25Q80,
},
{
+ .id = 0x6016,
+ .nr_blocks = 512,
nr_blocks here should have 64 instead of 512.
please let me know, I will add correction-patch for this.
You're right, it's a 32Mbit part, so nr_blocks should be 64, thanks
for finding this.
-Allen
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 5/7] Adjust Kconfig scripts for use by U-Boot
Hello, Simon.
Please let me ask some more questions.
By applying these series of commits,
U-Boot's config file scheme and Kconfig coexist.
For example, scripts/Makefile.build includes
both auto.conf generated by Kconfig
and autoconf.mk derived from U-boot's config.
-include include/config/auto.conf
-include $(objtree)/include/config/autoconf.mk
I think the redundancy and dirtiness do not matter
if they are temporary.
What I'd like to make clear is our goal.
It is intended to move all U-Boot's config files
to Kconfig over long time and
after that, delete U-Boot's config system.
Is this right?
If the answer is yes, there are some macros
I don't know how to port to Kconfig.
For example,
CONFIG_SYS_BAUDRATE_TABLE is defined like follows.
#define CONFIG_SYS_BAUDRATE_TABLE {9600, 19200, 38400, 57600, 115200}
To my knowledge this macro can not be described by Kconfig.
Do you have any good idea about this?
And also, some config files still include macros without CONFIG_ prefix.
For example, LINUX_BOOT_PARAM_ADDR, PHYS_SDRAM_1, PHYS_SDRAM_2, etc.
Best Regards,
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/13] sf: winbond: add W25Q32DW
On Wed, May 29, 2013 at 5:58 AM, Allen Martin amar...@nvidia.com wrote:
On Fri, May 24, 2013 at 01:39:51PM -0700, Jagan Teki wrote:
Hi,
Any update on this.
Thanks,
Jagan.
On Thu, May 23, 2013 at 1:15 PM, Jagan Teki jagannadh.t...@gmail.com wrote:
Hi Allen,
On Sun, Mar 17, 2013 at 10:28 AM, Allen Martin amar...@nvidia.com wrote:
Add support for Winbond W25Q32DW 32Mbit part
Signed-off-by: Allen Martin amar...@nvidia.com
---
drivers/mtd/spi/winbond.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index 4418302..3560fcb 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -68,6 +68,11 @@ static const struct winbond_spi_flash_params
winbond_spi_flash_table[] = {
.name = W25Q80,
},
{
+ .id = 0x6016,
+ .nr_blocks = 512,
nr_blocks here should have 64 instead of 512.
please let me know, I will add correction-patch for this.
You're right, it's a 32Mbit part, so nr_blocks should be 64, thanks
for finding this.
Thanks for your response.
I just updated on the patch http://patchwork.ozlabs.org/patch/246654/
Please let me know for any issues.
--
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] dfu: dfu and UBI Volumes
Hello Tom, Am 28.05.2013 23:16, schrieb Tom Rini: On Tue, May 28, 2013 at 11:01:09PM +0200, Wolfgang Denk wrote: Dear Tom, In message 20130528172309.GF5829@bill-the-cat you wrote: Of course this can't yet apply to writing files on file systems since the current API in U-Boot misses the append feature, but this could be applied to program raw memory partitions, including UBI images. Correct. We can write a whole UBI image, today, of NAND size, regardless of DDR size. But modifying UBI volumes (so UBIFS or your I don't think so. To write a UBI volume on an existing UBI device, you would use the ubi write command. This translates into a call of ubi_volume_write(char *volume, void *buf, size_t size) which means the size must be known before you start writing; as far as I can tell ubi_volume_write() does not support incremental write operations of individual parts of a volume. OK. A very quick read of ubi_volume_write leads into the guts of the write being in drivers/mtd/ubi/upd.c and it feels like you could actually do the volume write in chunks with ubi_start_update() and ubi_more_update_data() (and maybe some other housekeeping bits). It might take a bit more work since it looks like looks like both functions rely on knowing the size at the start, but that's just to make sure the size will fit in the volume. Yes, I think so too ... seems some work, but not unsolveable ... Hmm.. is it possible to get the filesize over dfu on startup? (I hope so, as it makes no sense to transfer a file, if it does not fit in the partition ... ) bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/7] arm: vf610: Add IOMUX support for Vybrid VF610
Hi, Benoit, diff --git a/arch/arm/imx-common/iomux-v3.c b/arch/arm/imx-common/iomux-v3.c index 7fe5ce7..35880c7 100644 --- a/arch/arm/imx-common/iomux-v3.c +++ b/arch/arm/imx-common/iomux-v3.c @@ -48,8 +48,14 @@ void imx_iomux_v3_setup_pad(iomux_v3_cfg_t pad) if (sel_input_ofs) __raw_writel(sel_input, base + sel_input_ofs); +#ifdef CONFIG_IOMUX_SHARE_CONF_REG Where is this one defined? I don't see it in include/configs/vf610twr.h. [Alison Wang] CONFIG_IOMUX_SHARE_CONF_REG is defined in arch/arm/include/asm/arch-vf610/imx-regs.h. Because this is not a board configuration, it is related to the SOC. Please refer to Stefano's comments below which also could be found in the email on May 15th. Stefano wrote: + +/* MUX mode and PAD ctrl are in one register */ +#define CONFIG_IOMUX_SHARE_CONF_REG NAK. This is not a board configuration, it is related to the SOC. This setup should flow into the related imx-regs.h for this SOC. When you set CONFIG_MVF600, this value should be set automatically. Why not use #ifdef CONFIG_VF610 since this is a platform-dependent code, and not a board-specific config option? [Alison Wang] I use this CONFIG_IOMUX_SHARE_CONF_REG option, because this part of codes not only could be used on VF610 platform, but also could be used on VF620 or other platforms. When it is used on VF620 or others, you could just enable CONFIG_IOMUX_SHARE_CONF_REG in the related imx-regs.h. Otherwise, if ifdef CONFIG_VF610 is used, you need to add #if defined(CONFIG_VF610) || defined(CONFIG_VF620) When this part of codes is also used on VF620. Then when this part of codes is used on VF630 too, this line will be very very long. + if (!(pad_ctrl NO_PAD_CTRL)) + __raw_writel((mux_mode PAD_MUX_MODE_SHIFT) | pad_ctrl, + base + pad_ctrl_ofs); +#else if (!(pad_ctrl NO_PAD_CTRL) pad_ctrl_ofs) __raw_writel(pad_ctrl, base + pad_ctrl_ofs); +#endif } void imx_iomux_v3_setup_multiple_pads(iomux_v3_cfg_t const *pad_list, [...] Apart from that, this patch is OK. Thanks. Best Regards, Alison Wang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/7] arm: vf610: Add Vybrid VF610 CPU support
Hi, Benoit, The hunk below is still missing: doc/README.mxc_ocotp: --- on MXC This IP can be found on the following SoCs: + - Vybrid VF610, - i.MX6. Note that this IP is different from albeit similar to the IPs of the same name [Alison Wang] It is not missing, it is in the 6/7 patch. --- Apart from that, this patch is correct. Best Regards, Alison Wang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/7] arm: vf610: Add Vybrid VF610 CPU support
Hi, Benoit, diff --git a/doc/README.vf610 b/doc/README.vf610 new file mode 100644 index 000..38cf5cf --- /dev/null +++ b/doc/README.vf610 @@ -0,0 +1,10 @@ +U-Boot for Freescale Vybrid VF610 + +This file contains information for the port of U-Boot to the +Freescale Vybrid +VF610 SoC. + +1. CONVENTIONS FOR FUSE ASSIGNMENTS +--- + +1.1 MAC Address: It is stored in fuse bank 4, with the 16 msbs in +word 2 and the +32 lsbs in word 3. The hunk below is still missing: doc/README.mxc_ocotp: --- on MXC This IP can be found on the following SoCs: + - Vybrid VF610, - i.MX6. Note that this IP is different from albeit similar to the IPs of the same name --- I have just noticed that this was actually in 6/7. Why are you putting this into a separate patch? [Alison Wang] Because patch 2/7 is about VF610 CPU support, and doc/README.vf610 is also a document about VF610 SoC. Doc/README.mxc_ocotp is the document about a driver (IP OCOTP), so this driver document should be separated from CPU patch 2/7. Best Regards, Alison Wang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 7/7] arm: vf610: Add basic support for Vybrid VF610TWR board
Hi, Benoit, + +#define CONFIG_CMD_PING +#define CONFIG_CMD_DHCP +#define CONFIG_CMD_MII +#define CONFIG_CMD_NET +#define CONFIG_FEC_MXC +#define CONFIG_MII +#define IMX_FEC_BASE ENET_BASE_ADDR +#define CONFIG_FEC_XCV_TYPERMII +#define CONFIG_FEC_MXC_PHYADDR 0 Why don't you add support for the 2nd FEC? Do you plan to do it later? [Alison Wang] In u-boot, one FEC is enough for user. We do not plan to do it later. +#define CONFIG_PHYLIB +#define CONFIG_PHY_MICREL + +#define CONFIG_BOOTDELAY 3 + +#define CONFIG_SYS_TEXT_BASE 0x3f008000 + +/* Miscellaneous configurable options */ +#define CONFIG_SYS_LONGHELP/* undef to save memory */ +#define CONFIG_SYS_HUSH_PARSER /* use hush command parser */ +#define CONFIG_SYS_PROMPT_HUSH_PS2 +#define CONFIG_SYS_PROMPT Vybrid U-Boot +#undef CONFIG_AUTO_COMPLETE +#define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ +#define CONFIG_SYS_PBSIZE \ + (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16) +#define CONFIG_SYS_MAXARGS 16 /* max number of command args */ +#define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE + +#define CONFIG_CMD_MEMTEST +#define CONFIG_SYS_MEMTEST_START 0x8001 +#define CONFIG_SYS_MEMTEST_END 0x87C0 Please make sure to have runtime-tested this address range with the mtest command since bad mtest addresses are the reason why CONFIG_CMD_MEMTEST has been removed from the default commands. [Alison Wang] Thanks for your reminder, we have tested. Best Regards, Alison Wang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
