Re: [U-Boot] [U-boot] sandbox test script question
Hi, Josh: Thanks a lot! Follwing these steps, I could load itb to memory: 1. sb bind 0 /lionfs 2. ext4load host 0 10 testkernel.itb Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Allow u-boot to run from offset base address
Hi Wolfgang,
On Wed, 11 Jun 2014 06:49:28 +0200, Wolfgang Denk w...@denx.de wrote:
Dear Steve,
In message 53979199.5010...@broadcom.com you wrote:
OK - I think that one of the alternate proposals would be to
conditionally reserve a 32 byte block prior to the _start symbol (in
arch/arm/cpu/armv8/start.S) which would then be filled in by a
post-processing step... This could be implemented by:
Yes, that illustrates the idea. However, this implementation suffers
from the use of an #ifdef where none is actually needed. Instead, you
can create your own source file which defines the header; this could
be then even in it's own segment, say:
your_header.c:
struct your_header {
u_int32[8];
} your_header __attribute__ ((__section__ (.your_hdr)));
All that is needed then is to make the linker place this segment in
front of the text segment.
This avoids an ugly #ifdef, and also modifications in the common code.
Agreed and seconded.
Plus, using a dedicated 'header' section and a separate C source file
for the header makes it automatic that if no input 'header' section
were provided then no output 'header' section would be emitted; IOW,
we would not need two different linker scripts, a single one would be
useable for both 'headerless' and 'headerful' image types.
Also, the alignment constraint should be configurable.
Best regards,
Wolfgang Denk
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] env_mmc: support env partition setup in runtime
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tom, rc3 is out... On 05/30/14 21:56, Tom Rini wrote: On Sun, May 25, 2014 at 10:23:46AM +0300, Igor Grinberg wrote: ping.. On 04/27/14 13:18, Dmitry Lifshitz wrote: Add callback with __weak annotation to allow setup of environment partition number in runtime from a board file. Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il Signed-off-by: Igor Grinberg grinb...@compulab.co.il [...] Pantelis, weren't you going to pick this up? Thanks! Can we please have this in for 2014.07? Thanks! - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTl/xzAAoJEBDE8YO64EfayCkQAJ0UFo/F6DebROHb3fU7u5/J iW1zRT7i1quZU5vnSa5E1I8vJ7O7IdWErrvgD6wweFjy03ueaE/m3uHXhQnNW4NC Kgmfr28wCnlHVEJX0RA7Ei0tTbziZTCgZ5+D7xyya/CH+wpDBXw57609XG/cVwH+ JXhKlDPLOyp74kLxwPWT4jJ8ZA/GEZWL97VGWA62OQI5KEh2lASNCjHm9U5bqLPf 6Jl6F57VEsEWyCzz0DrrNZFHeyxIM45o6aUnwz4BrZAZZ+UwXnRkuVPSwKVGlGYc +TaMjsu3XNV14MtPh5M6tbSs6mpOGHAW20ik0SwT72v4hh7SV4RyWdCY9JbKdKRG 2mEocMs7EFucrNjp0G8YD6U93b9BtTPSpiSnzaBnpECk3GTZQymsSVBn8J4qqoqK Ucp59mrZc5rFJXU+hCWFcGAdGqfUOuIhX6xPLd0AQlfHgswrEqJ7GBEvZEDLOnnk wU68HpNs0tW863BYfdabZnsj5BK51NlqIOAI86zCfywDmdIgtZtse7AtlJD5J9Lt uWLGfxScppTErM8vXRBN/p2YaoCbaLiV/ur/JO4gQNrw5PSPNUUKiooABfHn9HCg 2aABhEiuloslrkgKQKx5TEKT7skVqkbRnzkBD81E/1kasx0o/dEGiADxWiIXdTZw G1PXeefGklZlCjp8/h2I =YCwX -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] enbw_cmc, da850evm_direct_nor, and calimain vectors table misaligned (was: [PATCH] arm: fix a build error with CONFIG_USE_IRQ)
Hi Masahiro, (to: the board maintainers for enbw_cmc, da850evm_direct_nor, and calimain) On Mon, 09 Jun 2014 18:29:26 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hi Albert, You changed the behaviour of three boards, enbw_cmc, da850evm_direct_nor, calimain! Probably they are broken. These boards expects 0x0011 (=CONFIG_SYS_DV_NOR_BOOT_CFG) at the beginning of the image. But since commit 41623c91, that is missing. If you still don't understand, you should checkout 41623c91^ and 41623c91 and compare u-boot.dis. Your description of the effects of my change is correct. However, this raises another question which I would like to see discussed before doing anything about these boards. Taking the last commit where the prefix word was actually emitted (that is, 41623c91^, which is actually 60a4f39f, arm: remove unused _end_vect and _vectors_end symbols), and reading arch/arm/cpu/arm926ejs/start.S, I see that the start of the image looks like this: offset Content +0x prefix word CONFIG_SYS_DV_NOR_BOOT_CFG +0x0004 reset vector +0x0008 undefined instruction vector +0x000c software interrupt vector +0x0010 prefetch abort vector +0x0014 data abort vector +0x0018 unused +0x001c irq vector +0x0020 fiq vector +0x0024 (end of vectors table) And that is /wrong/: the vectors table is misaligned by 4 bytes. Obviously, the boards have been working fine for a long time, because no exception vector was used apparently (or because when exceptions did happen, the error was debugged without the need to analyze the exception). I suspect we could just remove the '.word CONFIG_SYS_DV_NOR_BOOT_CFG' line from the vectors.S file and prepend the word to the image /after/ linking. This, of course, requires confirmation from maintainers. Manfred, Christian, Sudhakar, Heiko: can any one of you let us know the reason for this signature word exactly, and how exactly it is used by the board? Ideally, can you also: - test a current build (which does not have the signature word) and confirm it fails to load); - test the same build with the 4-byte signature manually prepended (this may possibly require padding the image); Best Regards Masahiro Yamada Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/3] lib, list_sort: add list_sort from linux 3.14
from linux 3.14:
commit 455c6fdbd219161bd09b1165f11699d6d73de11c
Author: Linus Torvalds torva...@linux-foundation.org
Date: Sun Mar 30 20:40:15 2014 -0700
Linux 3.14
Needed for the MTD/UBI/UBIFS resync
Just copied the files from Linux, and added in the c-file
the #define __UBOOT__ for adding U-Boot special code. In
this case we use this just for adding including U-Boot
headers.
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Marek Vasut ma...@denx.de
Cc: Sergey Lapin sla...@ossfans.org
Cc: Scott Wood scottw...@freescale.com
Cc: Tom Rini tr...@ti.com
---
- changes for v2:
- none
- changes for v3:
- add in the commit message the description, how this sync with
linux patch was done, as Marek and Tom suggested.
---
include/linux/list_sort.h | 11 ++
lib/Makefile | 1 +
lib/list_sort.c | 298 ++
3 files changed, 310 insertions(+)
create mode 100644 include/linux/list_sort.h
create mode 100644 lib/list_sort.c
diff --git a/include/linux/list_sort.h b/include/linux/list_sort.h
new file mode 100644
index 000..1a2df2e
--- /dev/null
+++ b/include/linux/list_sort.h
@@ -0,0 +1,11 @@
+#ifndef _LINUX_LIST_SORT_H
+#define _LINUX_LIST_SORT_H
+
+#include linux/types.h
+
+struct list_head;
+
+void list_sort(void *priv, struct list_head *head,
+ int (*cmp)(void *priv, struct list_head *a,
+ struct list_head *b));
+#endif
diff --git a/lib/Makefile b/lib/Makefile
index 377ab13..37030a4 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -41,6 +41,7 @@ obj-y += strmhz.o
obj-$(CONFIG_TPM) += tpm.o
obj-$(CONFIG_RBTREE) += rbtree.o
obj-$(CONFIG_BITREVERSE) += bitrev.o
+obj-y += list_sort.o
endif
ifdef CONFIG_SPL_BUILD
diff --git a/lib/list_sort.c b/lib/list_sort.c
new file mode 100644
index 000..81de0a1
--- /dev/null
+++ b/lib/list_sort.c
@@ -0,0 +1,298 @@
+#define __UBOOT__
+#ifndef __UBOOT__
+#include linux/kernel.h
+#include linux/module.h
+#include linux/slab.h
+#else
+#include linux/compat.h
+#include common.h
+#include malloc.h
+#endif
+#include linux/list.h
+#include linux/list_sort.h
+
+#define MAX_LIST_LENGTH_BITS 20
+
+/*
+ * Returns a list organized in an intermediate format suited
+ * to chaining of merge() calls: null-terminated, no reserved or
+ * sentinel head node, prev links not maintained.
+ */
+static struct list_head *merge(void *priv,
+ int (*cmp)(void *priv, struct list_head *a,
+ struct list_head *b),
+ struct list_head *a, struct list_head *b)
+{
+ struct list_head head, *tail = head;
+
+ while (a b) {
+ /* if equal, take 'a' -- important for sort stability */
+ if ((*cmp)(priv, a, b) = 0) {
+ tail-next = a;
+ a = a-next;
+ } else {
+ tail-next = b;
+ b = b-next;
+ }
+ tail = tail-next;
+ }
+ tail-next = a?:b;
+ return head.next;
+}
+
+/*
+ * Combine final list merge with restoration of standard doubly-linked
+ * list structure. This approach duplicates code from merge(), but
+ * runs faster than the tidier alternatives of either a separate final
+ * prev-link restoration pass, or maintaining the prev links
+ * throughout.
+ */
+static void merge_and_restore_back_links(void *priv,
+ int (*cmp)(void *priv, struct list_head *a,
+ struct list_head *b),
+ struct list_head *head,
+ struct list_head *a, struct list_head *b)
+{
+ struct list_head *tail = head;
+
+ while (a b) {
+ /* if equal, take 'a' -- important for sort stability */
+ if ((*cmp)(priv, a, b) = 0) {
+ tail-next = a;
+ a-prev = tail;
+ a = a-next;
+ } else {
+ tail-next = b;
+ b-prev = tail;
+ b = b-next;
+ }
+ tail = tail-next;
+ }
+ tail-next = a ? : b;
+
+ do {
+ /*
+* In worst cases this loop may run many iterations.
+* Continue callbacks to the client even though no
+* element comparison is needed, so the client's cmp()
+* routine can invoke cond_resched() periodically.
+*/
+ (*cmp)(priv, tail-next, tail-next);
+
+ tail-next-prev = tail;
+ tail = tail-next;
+ } while (tail-next);
+
+ tail-next = head;
+ head-prev = tail;
+}
+
+/**
+ * list_sort - sort a list
+ * @priv: private data, opaque to list_sort(), passed to @cmp
+ * @head: the list to sort
+ * @cmp: the elements comparison function
+ *
+ * This function
[U-Boot] [RFC, PATCH v3 0/3] mtd, ubi, ubifs: resync with Linux-3.14
resync mtd, ubi and ubifs subsystem with linux:
commit 455c6fdbd219161bd09b1165f11699d6d73de11c
Author: Linus Torvalds torva...@linux-foundation.org
Date: Sun Mar 30 20:40:15 2014 -0700
Linux 3.14
Main reason for this sync is, we now have UBI fastmap support
in U-Boot.
Tested it on am33xx, imx6 and mpc83xx boards. MAKEALL for arm and powerpc
compiles clean.
Tested UBI fastmap on a board with 512 MiB nand flash. Attach time
from old U-Boot was 2 seconds, reduced with UBI fastmap to 0.2 seconds.
Please test this patchserie!
The patches
lib, rbtree: resync with Linux-3.14
lib, list_sort: add list_sort from linux 3.14
mtd, ubi, ubifs: resync with Linux-3.14
are not checkpatch clean, as they use code from Linux and
I do not want to change this.
Remarks:
- UBI Fastmap is now availiable in U-Boot
activate it with CONFIG_MTD_UBI_FASTMAP
- replace UBI_LINUX in current UBI code from U-Boot with
__UBOOT__ as this define is used in other places in U-Boot
where code from other projects is used.
- move a lot of defines from include/ubi_uboot.h to
include/linux/compat.h, as this is the correcter place for it.
- add usb device to linux device, so usb uses struct device
from linux/compat.h
- onenand changes only compile tested.
- Following Code in drivers/mtd/nand/nand_base.c nand_do_write_ops()
adapted for U-Boot:
+#ifndef __UBOOT__
/* Reject writes, which are not page aligned */
if (NOTALIGNED(to) || NOTALIGNED(ops-len)) {
+else
+ /* Reject writes, which are not page aligned */
+ if (NOTALIGNED(to)) {
+endif
as the original linux code leads in not working use of the env
var filesize. For example a nand write 8000 8 ${filesize}
would not work with it ...
- add CONFIG_MTD_NAND_VERIFY_WRITE from U-Boot code
(only compile tested)
- Documented the config defines in README
- kmalloc now uses memalign for allocating memory. This prevented
crashes when tested ubi/ubifs on imx6 board.
- To produce this patch I did three steps:
- copied the linux source files to U-Boot tree - commit this
- adapt license text in each file - commit this
- make the code again compile clean and working - commit this
Then squashed this three patches to this patch, to not break
bisectability. To make further sync with linux easier, the
above three patches can be found in:
http://git.denx.de/?p=u-boot/u-boot-testing.git;a=shortlog;h=refs/heads/update-mtd%2Bubi-linux-v3.14
This branch is only thought for further linux syncs! Please
do not use this branch for testing this patchseries!
- Hope I get all U-Boot specific changes ... so please, test,
test, test ...
- changes for v2:
- add lib/linux_compat.c as Joerg Krause detected
- changes for v3:
- patch:
Patchwork [U-Boot,RFC,v2,1/4] dm: rename device struct to udevice
http://patchwork.ozlabs.org/patch/351422/
not longer needed, as it found its way into mainline
- add in the commit message the description, how this sync patch
with linux was done, as Marek and Tom suggested.
- rebase with current U-Boot commit
61e76f53708cf082ef9061a140b57df3513b8ba1
Cc: Marek Vasut ma...@denx.de
Cc: Sergey Lapin sla...@ossfans.org
Cc: Scott Wood scottw...@freescale.com
Cc: Wolfgang Denk w...@denx.de
Cc: Joerg Krause jkra...@posteo.de
Heiko Schocher (3):
lib, rbtree: resync with Linux-3.14
lib, list_sort: add list_sort from linux 3.14
mtd, ubi, ubifs: resync with Linux-3.14
README | 61 +
board/prodrive/alpr/nand.c |4 +
board/socrates/nand.c |6 +
board/tqc/tqm8272/nand.c|4 +
common/cmd_ubi.c| 29 +-
common/cmd_ubifs.c |2 +-
drivers/mtd/mtdconcat.c | 230 ++-
drivers/mtd/mtdcore.c | 1112 -
drivers/mtd/mtdcore.h | 23 +
drivers/mtd/mtdpart.c | 521 +-
drivers/mtd/nand/fsl_elbc_nand.c|4 +
drivers/mtd/nand/fsl_ifc_nand.c |4 +
drivers/mtd/nand/fsl_upm.c |4 +
drivers/mtd/nand/mpc5121_nfc.c |4 +
drivers/mtd/nand/mxc_nand.c |8 +
drivers/mtd/nand/nand_base.c| 1897 +++--
drivers/mtd/nand/nand_bbt.c | 296 ++--
drivers/mtd/nand/nand_ids.c | 256 +--
drivers/mtd/nand/nand_util.c|3 +
drivers/mtd/nand/ndfc.c |4 +
drivers/mtd/onenand/onenand_base.c |1 +
drivers/mtd/onenand/onenand_bbt.c |1 -
drivers/mtd/onenand/samsung.c | 10 +-
drivers/mtd/ubi/Makefile|3 +-
drivers/mtd/ubi/attach.c| 1754
drivers/mtd/ubi/build.c | 812 ++---
drivers/mtd/ubi/crc32.c | 13 +-
drivers/mtd/ubi/crc32table.h|2 +-
drivers/mtd/ubi/debug.c | 482 --
drivers/mtd/ubi/debug.h | 178 +-
drivers/mtd/ubi/eba.c | 474 --
[U-Boot] [PATCH v3 1/3] lib, rbtree: resync with Linux-3.14
resync with linux:
commit 455c6fdbd219161bd09b1165f11699d6d73de11c
Author: Linus Torvalds torva...@linux-foundation.org
Date: Sun Mar 30 20:40:15 2014 -0700
Linux 3.14
Needed for the MTD/UBI/UBIFS resync
Just copied the files from Linux, changed the license file header,
and add in the c-file:
+#define __UBOOT__
#include linux/rbtree_augmented.h
+#ifndef __UBOOT__
#include linux/export.h
+#else
+#include ubi_uboot.h
+#endif
so, it compiles for U-Boot.
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Marek Vasut ma...@denx.de
Cc: Sergey Lapin sla...@ossfans.org
Cc: Scott Wood scottw...@freescale.com
Cc: Tom Rini tr...@ti.com
---
- changes for v2:
- none
- changes for v3:
- add in the commit message the description, how this sync patch
with linux was done, as Marek and Tom suggested.
---
include/linux/rbtree.h | 147 +++--
include/linux/rbtree_augmented.h | 220 +
lib/rbtree.c | 684 ---
3 files changed, 698 insertions(+), 353 deletions(-)
create mode 100644 include/linux/rbtree_augmented.h
diff --git a/include/linux/rbtree.h b/include/linux/rbtree.h
index ad892d1..b5994e3 100644
--- a/include/linux/rbtree.h
+++ b/include/linux/rbtree.h
@@ -1,7 +1,7 @@
/*
Red Black Trees
(C) 1999 Andrea Arcangeli and...@suse.de
-
+
* SPDX-License-Identifier:GPL-2.0+
linux/include/linux/rbtree.h
@@ -11,138 +11,89 @@
I know it's not the cleaner way, but in C (not in C++) to get
performances and genericity...
- Some example of insert and search follows here. The search is a plain
- normal search over an ordered tree. The insert instead must be implemented
- int two steps: as first thing the code must insert the element in
- order as a red leaf in the tree, then the support library function
- rb_insert_color() must be called. Such function will do the
- not trivial work to rebalance the rbtree if necessary.
-
-static inline struct page * rb_search_page_cache(struct inode * inode,
-unsigned long offset)
-{
- struct rb_node * n = inode-i_rb_page_cache.rb_node;
- struct page * page;
-
- while (n)
- {
- page = rb_entry(n, struct page, rb_page_cache);
-
- if (offset page-offset)
- n = n-rb_left;
- else if (offset page-offset)
- n = n-rb_right;
- else
- return page;
- }
- return NULL;
-}
-
-static inline struct page * __rb_insert_page_cache(struct inode * inode,
- unsigned long offset,
- struct rb_node * node)
-{
- struct rb_node ** p = inode-i_rb_page_cache.rb_node;
- struct rb_node * parent = NULL;
- struct page * page;
-
- while (*p)
- {
- parent = *p;
- page = rb_entry(parent, struct page, rb_page_cache);
-
- if (offset page-offset)
- p = (*p)-rb_left;
- else if (offset page-offset)
- p = (*p)-rb_right;
- else
- return page;
- }
-
- rb_link_node(node, parent, p);
-
- return NULL;
-}
-
-static inline struct page * rb_insert_page_cache(struct inode * inode,
-unsigned long offset,
-struct rb_node * node)
-{
- struct page * ret;
- if ((ret = __rb_insert_page_cache(inode, offset, node)))
- goto out;
- rb_insert_color(node, inode-i_rb_page_cache);
- out:
- return ret;
-}
+ See Documentation/rbtree.txt for documentation and samples.
*/
#ifndef_LINUX_RBTREE_H
#define_LINUX_RBTREE_H
+#define __UBOOT__
+#ifndef __UBOOT__
+#include linux/kernel.h
+#endif
#include linux/stddef.h
-struct rb_node
-{
- unsigned long rb_parent_color;
-#defineRB_RED 0
-#defineRB_BLACK1
+struct rb_node {
+ unsigned long __rb_parent_color;
struct rb_node *rb_right;
struct rb_node *rb_left;
} __attribute__((aligned(sizeof(long;
/* The alignment might seem pointless, but allegedly CRIS needs it */
-struct rb_root
-{
+struct rb_root {
struct rb_node *rb_node;
};
-#define rb_parent(r) ((struct rb_node *)((r)-rb_parent_color ~3))
-#define rb_color(r) ((r)-rb_parent_color 1)
-#define rb_is_red(r) (!rb_color(r))
-#define rb_is_black(r) rb_color(r)
-#define rb_set_red(r) do { (r)-rb_parent_color = ~1; } while (0)
-#define rb_set_black(r) do { (r)-rb_parent_color |= 1; } while (0)
-
-static inline void rb_set_parent(struct rb_node *rb, struct rb_node *p)
Re: [U-Boot] enbw_cmc, da850evm_direct_nor, and calimain vectors table misaligned
Hello Albert, Am 11.06.2014 09:14, schrieb Albert ARIBAUD: Hi Masahiro, (to: the board maintainers for enbw_cmc, da850evm_direct_nor, and calimain) On Mon, 09 Jun 2014 18:29:26 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hi Albert, You changed the behaviour of three boards, enbw_cmc, da850evm_direct_nor, calimain! Probably they are broken. These boards expects 0x0011 (=CONFIG_SYS_DV_NOR_BOOT_CFG) at the beginning of the image. But since commit 41623c91, that is missing. If you still don't understand, you should checkout 41623c91^ and 41623c91 and compare u-boot.dis. Your description of the effects of my change is correct. However, this raises another question which I would like to see discussed before doing anything about these boards. Taking the last commit where the prefix word was actually emitted (that is, 41623c91^, which is actually 60a4f39f, arm: remove unused _end_vect and _vectors_end symbols), and reading arch/arm/cpu/arm926ejs/start.S, I see that the start of the image looks like this: offset Content +0x prefix word CONFIG_SYS_DV_NOR_BOOT_CFG +0x0004 reset vector +0x0008 undefined instruction vector +0x000c software interrupt vector +0x0010 prefetch abort vector +0x0014 data abort vector +0x0018 unused +0x001c irq vector +0x0020 fiq vector +0x0024 (end of vectors table) And that is /wrong/: the vectors table is misaligned by 4 bytes. Obviously, the boards have been working fine for a long time, because no exception vector was used apparently (or because when exceptions did happen, the error was debugged without the need to analyze the exception). I suspect we could just remove the '.word CONFIG_SYS_DV_NOR_BOOT_CFG' line from the vectors.S file and prepend the word to the image /after/ linking. This, of course, requires confirmation from maintainers. Manfred, Christian, Sudhakar, Heiko: can any one of you let us know the reason for this signature word exactly, and how exactly it is used by the board? Ideally, can you also: See AM18xx Bootloader Application Report: http://www.ti.com/lit/pdf/spraba5 Section 3.1 NOR Boot on page 3ff This word is used to setup some settings ... - test a current build (which does not have the signature word) and confirm it fails to load); - test the same build with the 4-byte signature manually prepended (this may possibly require padding the image); I try to find some time for it ... 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 02/10] exynos: pinmux: fix the gpio names for exynos4x12 mmc
Looks good to me. Acked-by: Jaehoon Chung jh80.ch...@samsung.com On 06/10/2014 08:25 PM, Przemyslaw Marczak wrote: This change fixes the bad gpio configuration for the exynos dwmmc. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Beomho Seo beomho@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com Cc: Jaehoon Chung jh80.ch...@samsung.com --- arch/arm/cpu/armv7/exynos/pinmux.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c b/arch/arm/cpu/armv7/exynos/pinmux.c index 86a0c75..b929486 100644 --- a/arch/arm/cpu/armv7/exynos/pinmux.c +++ b/arch/arm/cpu/armv7/exynos/pinmux.c @@ -704,8 +704,8 @@ static int exynos4x12_mmc_config(int peripheral, int flags) ext_func = S5P_GPIO_FUNC(0x3); break; case PERIPH_ID_SDMMC4: - start = EXYNOS4_GPIO_K00; - start_ext = EXYNOS4_GPIO_K13; + start = EXYNOS4X12_GPIO_K00; + start_ext = EXYNOS4X12_GPIO_K13; func = S5P_GPIO_FUNC(0x3); ext_func = S5P_GPIO_FUNC(0x4); break; ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/10] odroid: add board file for Odroid X2/U3 based on Samsung Exynos4412
Hello Inha, On 06/11/2014 03:33 AM, Inha Song wrote: Hi Przemyslaw, In U3 board, cooling pan is not work. I think, cooling pan setting is need in board_gpio_init(). (X2 board use cooling pan pwr form USB port) best regards, Inha Song. Thank you for testing. I have a board without the cooling fan, but this is a right notice - this feature should be included for this board - and come with next patch set. regards, -- Przemyslaw Marczak Samsung RD Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/10] samsung: misc: set the dfu bootloader setting at boot time.
Hi Inha,
On 06/11/2014 04:03 AM, Inha Song wrote:
Hi Przemyslaw,
I have a question.
dfu_alt_bootloader env is settings successfully
dfu_alt_bootloader=u-boot raw 0x3e 0x800 mmcpart 1
But,
In order to replace bootloader binary in thor mode,
How can I use the dfu_alt_bootloader env?
DFU gadget use dfu_alt_info env for DFU entities configuration.
Is there any patch to support multiple dfu_alt environment, or
dfu_alt_info environment settings to use dfu_alt_bootloader env?
best regards,
Inha Song.
Actually, I didn't finished this at all. It is possible to do this
manually at prompt by setenv dfu_alt_info ${dfu_alt_bootloader},
but this overwrites current alt settings, so it's not so good.
In the next patch set I will add some feature to DFU, since
dfu_alt_bootloader could be treat as one of DFU option.
Thank you again,
--
Przemyslaw Marczak
Samsung RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] AMP of linux on multi core processor and u-boot
Hello All, I have a requirement to have AMP on an multi core processor (i.MX6 freescale) using linux as OS The uboot should download uImage_core0 and uImage_core1 and be able to launch both the kernel Running on core0 and core1 of the processor. We need to make necessary changes to the uboot such that bootm command could be used accordingly Can you help me to achieve this ? With your valuable sugessions ? Thank You, Regards, Misbah ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] AMP implementation
Hello All, I have a requirement to have AMP on an multi core processor (i.MX6 freescale) using linux as OS The uboot should download uImage_core0 and uImage_core1 and be able to launch both the kernel Running on core0 and core1 of the processor. We need to make necessary changes to the uboot such that bootm command could be used accordingly Can you help me to achieve this ? With your valuable sugessions ? Thank You, Regards, Misbah ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6: drop ARM errata 742230
Commit e9fd66defd7e (ARM: mx6: define CONFIG_ARM_ERRATA_742230) enables errata 742230 for imx6, because it helps remove one reboot issue. However, this errata does not really apply on imx6, because Cortex-A9 on imx6 is r2p10 while the errata only applies to revisions r1p0..r2p2. At a later time, commit f71cbfe3ca5d (ARM: Add workaround for Cortex-A9 errata 794072) adds support of errata 794072, which applies to all Cortex-A9 revisions. As the workaround for both errata are exactly same, it makes a lot more sense to select 794072 instead of 742230 for imx6. Since we already enable 794072 for imx6, it's time to drop errata 742230 to avoid confusion. Signed-off-by: Shawn Guo shawn@freescale.com --- include/configs/mx6_common.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h index 8a8920f6cc8a..e4a5cc5be1a6 100644 --- a/include/configs/mx6_common.h +++ b/include/configs/mx6_common.h @@ -17,7 +17,6 @@ #ifndef __MX6_COMMON_H #define __MX6_COMMON_H -#define CONFIG_ARM_ERRATA_742230 #define CONFIG_ARM_ERRATA_743622 #define CONFIG_ARM_ERRATA_751472 #define CONFIG_ARM_ERRATA_794072 -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] USB EHCI problem on NeufBox V6
Hello, I am currently working on a Broadcom BCM63168 SoC board (NeufBox V6). This is a MIPS32 big endian CPU. My goal is to replace the CFERAM stage by U-Boot 2014.01 (I keep the CFEROM for now as it contains a lot of magic). I managed to make U-Boot start on the platform. It can mount an UBIFS file system stored on the NAND chip and load Linux. Now, I would like to add the USB Host support to U-Boot in order to boot from an USB stick. Thus, I tried to make EHCI drivers based on the working Linux ones. The SoC integrates a (supposed) standard EHCI controller. However, I can't start the USB subsystem (using the command usb start) because the USB enumeration process crashes when it sends a GetDescriptor() request to every device but the builtin root hub. When the U-Boot USB calls ehci_submit_async(), the EHCI controller times out (no matter what the timeout delay is). When the ehci_submit_async() function is called another time, a bad cache address (0x) is provided to the function : /* * Invalidate the memory area occupied by buffer * Don't try to fix the buffer alignment, if it isn't properly * aligned it's upper layer's fault so let invalidate_dcache_range() * vow about it. But we have to fix the length as it's actual * transfer length and can be unaligned. This is potentially * dangerous operation, it's responsibility of the calling * code to make sure enough space is reserved. */ invalidate_dcache_range((uint32_t)buffer, ALIGN((uint32_t)buffer + length, ARCH_DMA_MINALIGN)); and everything crashes. By disconnecting every USB hub and device connected to the SoC USB Host peripheral, only the builtin root hub is recognized by the command usb start and U-Boot does not crash. I tried to connect an USB sniffer on the bus (an Ellisys 200) to capture the USB frames. The EHCI timeout occurs when the USB subsystem tries to send a GetDescriptor() request (using ehci_submit_async()). Only bad Start Of Frames are captured by the USB sniffer, and when U-Boot crashes the bad SOF continue to be emitted (I think the EHCI controller is hanged too). I tried to update the drivers/usb U-Boot directory with the one from U-Boot 2014.04 and with the one from the git repository, but the problem could not be solved. Have you got any idea on what can prevent the EHCI controller to communicate with the external USB bus through the SoC root hub ? Best regards, Adrien RICCIARDI ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] enbw_cmc, da850evm_direct_nor, and calimain vectors table misaligned
Hi all, On Wed, Jun 11, 2014 at 9:47 AM, Heiko Schocher h...@denx.de wrote: Hello Albert, Am 11.06.2014 09:14, schrieb Albert ARIBAUD: Hi Masahiro, (to: the board maintainers for enbw_cmc, da850evm_direct_nor, and calimain) On Mon, 09 Jun 2014 18:29:26 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hi Albert, You changed the behaviour of three boards, enbw_cmc, da850evm_direct_nor, calimain! Probably they are broken. These boards expects 0x0011 (=CONFIG_SYS_DV_NOR_BOOT_CFG) at the beginning of the image. But since commit 41623c91, that is missing. If you still don't understand, you should checkout 41623c91^ and 41623c91 and compare u-boot.dis. Your description of the effects of my change is correct. However, this raises another question which I would like to see discussed before doing anything about these boards. Taking the last commit where the prefix word was actually emitted (that is, 41623c91^, which is actually 60a4f39f, arm: remove unused _end_vect and _vectors_end symbols), and reading arch/arm/cpu/arm926ejs/start.S, I see that the start of the image looks like this: offset Content +0x prefix word CONFIG_SYS_DV_NOR_BOOT_CFG +0x0004 reset vector +0x0008 undefined instruction vector +0x000c software interrupt vector +0x0010 prefetch abort vector +0x0014 data abort vector +0x0018 unused +0x001c irq vector +0x0020 fiq vector +0x0024 (end of vectors table) And that is /wrong/: the vectors table is misaligned by 4 bytes. Obviously, the boards have been working fine for a long time, because no exception vector was used apparently (or because when exceptions did happen, the error was debugged without the need to analyze the exception). Probably a bit of both ;-) I don't know much about exceptions, so maybe this is just stupid, but: I had a look at some ARM documentation (and the datasheets of the AM1808 that is used on the calimain board). According to these, the exception vector table of this CPU is located at 0x. I had a look at the memory there, and the content of this table seems to be branches to the ROM bootloader located at 0xfffd. So my question is: Are we actually setting up the ARM's exception table for this device? And if yes, where is this done in the code? I suspect we could just remove the '.word CONFIG_SYS_DV_NOR_BOOT_CFG' line from the vectors.S file and prepend the word to the image /after/ linking. Yes, I think this would be the right way to do it. This, of course, requires confirmation from maintainers. Manfred, Christian, Sudhakar, Heiko: can any one of you let us know the reason for this signature word exactly, and how exactly it is used by the board? Ideally, can you also: See AM18xx Bootloader Application Report: http://www.ti.com/lit/pdf/spraba5 Section 3.1 NOR Boot on page 3ff This word is used to setup some settings ... Exactly. 0x6000 is the start of the NOR flash. 0x0011 as the first word tells the ROM bootloader to use the Direct NOR boot method, i.e. to branch to 0x6004, which is the start of u-boot. u-boot then relocates itself to RAM. - test a current build (which does not have the signature word) and confirm it fails to load); I tested a current build for calimain, and yes, it fails to load. - test the same build with the 4-byte signature manually prepended (this may possibly require padding the image); No, this didn't work, I guess because the relocation offsets are wrong now. I tried to set CONFIG_SYS_TEXT_BASE in include/configs/calimain.h to 0x6004, but this resulted in some strange padding (28 bytes set to 0x00 prepend the u-boot image) which I currently don't understand. Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] What file formats can be loaded and launched by u-boot
Hello All, I have an RTOS compiled for ARM cotex-A9 generating .out file format. How can I use u-boot.bin to download the RTOS image from an SD card FAT32 formatted and launch the RTOS kernel Can you please share your views. Regards, Misbah ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 05/15] dm: Rename struct device_id to udevice_id
On Tue, Jun 10, 2014 at 6:53 PM, Simon Glass s...@chromium.org wrote: It is best to avoid having any occurence of 'struct device' in driver model, so rename to achieve this. Signed-off-by: Simon Glass s...@chromium.org --- Hmm. It's not just a good idea, right? That change is upstream already so this is a compilation requirement now, right? jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v4 3/5] ARMv8/FSL_LSCH3: Add FSL_LSCH3 SoC
Dear York,
My mailing list disabled a few days. Maybe I missed something important.
/*
* Performs a clean invalidation of the entire data cache at all levels
*/
void flush_dcache_all(void)
{
__asm_flush_dcache_all();
+ flush_l3_cache();
}
I thought the L3 cache is not included in the cache hierarchy.
So, how about define it as external cache operations named with outer_cache_*
just like armv7 did?
Best regards,
David
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 15/15] dm: Expand and improve the device lifecycle docs
On Tue, Jun 10, 2014 at 6:53 PM, Simon Glass s...@chromium.org wrote: The lifecycle of a device is an important part of driver model. Add to the existing documentation and clarify it. Reported-by: Jon Loeliger j...@jdl.com Signed-off-by: Simon Glass s...@chromium.org --- Thanks for Jon Loeliger j...@jdl.com for helping with the text and suggesting improvements. (Jon please comment/adjust to help clarify things further) This is way betterer now. Thanks! Nit typo: + e. If the driver provides a ofdata_to_platdata() method, then this is s/a/an/ + + Note: for a U_BOOT_DEVICE() declaration, the platform data is supplied as + a static pointer and is not allocated. For device tree, the platform + data is allocated during activation and freed during dectivation, + typically automatically using platdata_auto_alloc_size. But if that value + is 0 then U-Boot will not do the allocation/freeing and you will need to + do this yourself in your ofdata_to_platdata() and remove() methods. This + difference is tracked by the device's DM_FLAG_ALLOC_PDATA flag. The first sentence in that paragraph confused me because I knew where it was supposed to be headed: namely, the deallocation of the platdata. So when it used the not allocated phrase, I was taken aback. How about something like this instead?: Note: Because the platform data for a U_BOOT_DEVICE() is defined with a static pointer, it is not de-allocated during the remove() method. For a device instantiated using the device tree data, the platform data will be dynamically allocated, and thus needs to be deallocated during the remove() method. If the platdata_auto_alloc_size is non-zero, the deallocation happens automatically within the DM core. However, when platdata_auto_alloc_size is 0, both the allocation (in probe() or preferably ofdata_to_platdata()) and the deallocation in remove() are the responsibility of the driver author. If you'd like: Acked-by: Jon.Loeliger j...@jdl.com Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/15] Collected driver model bug-fixes and docs
On Tue, Jun 10, 2014 at 6:53 PM, Simon Glass s...@chromium.org wrote: This series collects some of the patches from the Tegra GPIO conversion to driver model. That work is still in progress, but the bug fixes and iotracing feature should go into this release I think. Also the documentation improvements may as well follow since the existings docs are proven inadequate. Changes in v5: - Fix a few more typos Hi Simon, Thanks for gathering all these patches. I definitely think they should hit the shiny, new DM repo! Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 10/15] dm: Allow driver model tests only for sandbox
On Tue, Jun 10, 2014 at 6:53 PM, Simon Glass s...@chromium.org wrote: The GPIO tests require the sandbox GPIO driver, so cannot be run on other platforms. Similarly for the 'dm test' command. Signed-off-by: Simon Glass s...@chromium.org --- Ja, gut. Tested-by: Jon Loeliger jon.loeli...@oracle.com jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] WIP for SPI
On Tue, Jun 10, 2014 at 10:54 PM, Simon Glass s...@chromium.org wrote: Hi Jon, I thought I should mention that I spent time on a flight to look at SPI with driver model. I have put the WIP code in branch 'working' in u-boot-dm.git. Note it doesn't work, and is very early. Also note that many of the patches have not been posted - I just want to make it clear what I am up to. Awesome! In doing this I had to sort out the numbering of devices. U-Boot has the concept of SPI bus 2 on its command line, and for now at lest we need to keep that working. So I have added sequence numbers to devices - so a device can be considered 'child number 3' of its parent, for example. The numbers don't need to be sequential. I suppose we could generalise this to GPIOs if it works out. And I think I am saying that we already *have* it generalized for the GPIOs but only if we remove that renumbering function! Consider again that the U_CLASS lookup of a GPIO simply matches versus the range in each uclass data (gpio base and count). That search doesn't care about their order within the UCLASS_GPIO list. (Never mind that the renumbering breaks the association of the device base register and pin ranges as set up by the bind/probe code!) My approach for scanning the SPI bus in the device tree is similar to what I suggested a week or so ago - I took the code from dm_scan_fdt() and put it in a function with a udevice parent and node parameters. It seems to work OK for this simple case. Nice! Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v4 3/5] ARMv8/FSL_LSCH3: Add FSL_LSCH3 SoC
On 06/11/2014 07:05 AM, feng...@phytium.com.cn wrote:
Dear York,
My mailing list disabled a few days. Maybe I missed something important.
/*
* Performs a clean invalidation of the entire data cache at all levels
*/
void flush_dcache_all(void)
{
__asm_flush_dcache_all();
+flush_l3_cache();
}
I thought the L3 cache is not included in the cache hierarchy.
So, how about define it as external cache operations named with outer_cache_*
just like armv7 did?
I have it declared as a weak function. If you think the name needs to change, I
can do so.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] What file formats can be loaded and launched by u-boot
Dear Misbah, In message 005301cf8578$18686be0$493943a0$@k...@tes-dst.com you wrote: I have an RTOS compiled for ARM cotex-A9 generating .out file format. .out is not any known linker output format. Do you mean a.out? It has been ages since I've seen this used the last time - way back in the previous millenium. How can I use u-boot.bin to download the RTOS image from an SD card FAT32 formatted and launch the RTOS kernel In general, you can use objcopy (from the GNU binutils package) to convert into raw binary format. This you can then either load directly, or wrap it using the mkimage tool into either a legacy U-Boot image or a FIT image, which then can be started by U-Boot. 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 : 1. What is the possibility of this being added in the future? In the near future, the probability is close to zero. In the distant future, I'll be dead, and posterity can do whatever they like... :-) - lwall ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] macb: make checkpatch clean
On Tue, May 27, 2014 at 04:07:30PM +0800, Josh Wu wrote: Hi, Dear Andreas On 5/27/2014 4:55 AM, Andreas Bießmann wrote: This also renames the CONFIG_SYS_MACB_xx defines. They are used just local and therefore don't need the CONFIG_SYS_ prefix. Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com This patch looks good to me. Reviewed-by: Josh Wu josh...@atmel.com For clarity, I'm fine with this coming via u-boot-atmel.. -- 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 1/3] net: sh-eth: Add support R7S72100 of rmobile
On Mon, Jun 09, 2014 at 06:58:46AM +0900, Nobuhiro Iwamatsu wrote: Hi, Tom. 2014-06-06 22:37 GMT+09:00 Tom Rini tr...@ti.com: On Fri, Jun 06, 2014 at 11:44:20AM +0900, Nobuhiro Iwamatsu wrote: ping. 2014-01-23 7:52 GMT+09:00 Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com: The R7S72100 of ARM SoC that Renesas manufactured has one Ether port. This has the same IP SH-Ether. This patch adds support of the R7S72100 in SH-Ether. Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com I'm fine with this series coming via the sh tree. Thank you. I will work. BTW, Joe(net custodian) does not have time of maintain net tree? How do we patch for net from now ? I don't want to put words in his mouth, but, at least for driver rather than core changes (and this applies to more than just net), there's a good deal of relevant experience outside of the custodians likely background anyhow. -- 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] Add support for DS1340 RTC
On Mon, Jun 09, 2014 at 09:59:39AM +1200, Darwin Dingel wrote: Implementation is the same as with a DS1337 but with different register addresses. Signed-off-by: Darwin Dingel darwin.din...@alliedtelesis.co.nz Are you going to post patches for a board which sets CONFIG_RTC_DS1340 ? -- 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] sandbox: restore ability to access host fs through standard commands
On 06/10/2014 09:29 PM, Josh Wu wrote:
On 6/11/2014 6:43 AM, Stephen Warren wrote:
Commit 95fac6ab4589 sandbox: Use os functions to read host device tree
removed the ability for get_device_and_partition() to handle the host
device type, and redirect accesses to it to the host filesystem. This
broke some unit tests that use this feature. So, revert that change. The
code added back by this patch is slightly different to pacify checkpatch.
However, we're then left with host being both:
- A pseudo device that accesses the hosts real filesystem.
- An emulated block device, which accesses sectors inside a file stored
on the host.
In order to resolve this discrepancy, rename the pseudo device from host
to hostfs, and adjust the unit-tests for this change.
diff --git a/disk/part.c b/disk/part.c
+/*
+ * Special-case a psuedo block device hostfs, to allow access
to the
+ * host's own filesystem.
+ */
Do we need to change the sb ls help message from 'host' to 'hostfs' as
well?
Yes.
+if (0 == strcmp(ifname, hostfs)) {
+*dev_desc = NULL;
+info-start = = 0;
a typo. one additional '='.
Indeed. I guess I forgot to recompile after fixing checkpatch:-/
diff --git a/test/command_ut.c b/test/command_ut.c
@@ -165,12 +165,12 @@ static int do_ut_cmd(cmd_tbl_t *cmdtp, int flag,
int argc, char * const argv[])
#ifdef CONFIG_SANDBOX
/* File existence */
-HUSH_TEST(e, -e host -
creating_this_file_breaks_uboot_unit_test, n);
-run_command(sb save host -
creating_this_file_breaks_uboot_unit_test 0 1, 0);
-HUSH_TEST(e, -e host -
creating_this_file_breaks_uboot_unit_test, y);
+HUSH_TEST(e, -e hostfs -
creating_this_file_breaks_uboot_unit_test, n);
There still has a odd behavior:
at first, when we run 'sb load host 0 20 /home/env.sh', it will show
'** Bad device host 0 **'
but after use 'sb bind 0 test.img', then above command can work well.
sb load works fine for me on *hostfs*:
= sb ls hostfs - /boot
...
176764 memtest86+.bin
...
= sb load hostfs - 0 /boot/memtest86+.bin
176764 bytes read in 29 ms (5.8 MiB/s)
I'm not sure if sb load on host is expected to work; host is an
emulated block device that works just like any other block device, i.e.
without using the sb comamnd, so I'd expect it to be used with plain
old ls/fatls/extls, load/fatload/ext2load/, ...
IMHO, we need use 'host' and 'hostfs' for different usage. suck like:
'host' interface means host block device that we use 'sb bind'.
'hostfs' interface means host file system
That's what this patch should provide.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v5, 3/4] lib, fdt: move fdtdec_get_int() out of lib/fdtdec.c
On Tue, Jun 10, 2014 at 09:35:51AM +0200, Heiko Schocher wrote: Hello Tom, Am 05.06.2014 21:15, schrieb Tom Rini: On Wed, May 28, 2014 at 11:33:35AM +0200, Heiko Schocher wrote: move fdtdec_get_int() out of lib/fdtdec.c into lib/fdtdec_common.c as this function is also used, if CONFIG_OF_CONTROL is not used. Poped up on the ids8313 board using signed FIT images, and activating CONFIG_SYS_GENERIC_BOARD. Without this patch it shows on boot: No valid FDT found - please append one to U-Boot binary, use u-boot-dtb.bin or define CONFIG_OF_EMBED. For sandbox, use -dfile.dtb With this patch, it boots again with CONFIG_SYS_GENERIC_BOARD enabled. Signed-off-by: Heiko Schocherh...@denx.de Acked-by: Simon Glasss...@chromium.org Cc: Tom Rinitr...@ti.com The problem is that on architectures with old compilers (sparc, blackfin, nds32) this doesn't get discarded due to not being used but instead causes link errors. Can you figure out which option (CONFIG_FIT_SIGNATURE I suspect) drives this need and make sure we include fdtdec_common.o then? Thanks! I look into it ... but I think it is not only one config option, as this code is not FIT specific and used also for code which uses DT ... (maybe CONFIG_OF_CONTROL or CONFIG_FIT_SIGNATURE). That's fine, we can have multiple obj-$(CONFIG_...) += fdtdec_common.o (or rename it to fdtdec_get_int.o?). But.. how is this only a runtime not link time failure? -- 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 v5 05/15] dm: Rename struct device_id to udevice_id
Hi Jon, On 11 June 2014 07:49, Jon Loeliger loeli...@gmail.com wrote: On Tue, Jun 10, 2014 at 6:53 PM, Simon Glass s...@chromium.org wrote: It is best to avoid having any occurence of 'struct device' in driver model, so rename to achieve this. Signed-off-by: Simon Glass s...@chromium.org --- Hmm. It's not just a good idea, right? That change is upstream already so this is a compilation requirement now, right? No, it's just a rename. But I feel that if we have 'struct udevice' we should not have 'struct device_id'. It is just confusing. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] sandbox: restore ability to access host fs through standard commands
From: Stephen Warren swar...@nvidia.com
Commit 95fac6ab4589 sandbox: Use os functions to read host device tree
removed the ability for get_device_and_partition() to handle the host
device type, and redirect accesses to it to the host filesystem. This
broke some unit tests that use this feature. So, revert that change. The
code added back by this patch is slightly different to pacify checkpatch.
However, we're then left with host being both:
- A pseudo device that accesses the hosts real filesystem.
- An emulated block device, which accesses sectors inside a file stored
on the host.
In order to resolve this discrepancy, rename the pseudo device from host
to hostfs, and adjust the unit-tests for this change.
The help sb output is modified to reflect this rename, and state where
the host and hostfs devices should be used.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
V2:
* Fix typo due to fixing checkpatch and not recompiling:-(
* Fix help sb output.
---
common/cmd_sandbox.c | 10 ++
disk/part.c | 19 +++
test/command_ut.c| 8
3 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/common/cmd_sandbox.c b/common/cmd_sandbox.c
index 00982b164dd3..3d9fce7e5548 100644
--- a/common/cmd_sandbox.c
+++ b/common/cmd_sandbox.c
@@ -114,11 +114,13 @@ static int do_sandbox(cmd_tbl_t *cmdtp, int flag, int
argc,
U_BOOT_CMD(
sb, 8, 1, do_sandbox,
Miscellaneous sandbox commands,
- load host dev addr filename [bytes offset] -
+ load hostfs - addr filename [bytes offset] -
load a file from host\n
- sb ls host filename - list files on host\n
- sb save host dev filename addr bytes [offset] -
+ sb ls hostfs - filename- list files on host\n
+ sb save hostfs - filename addr bytes [offset] -
save a file to host\n
sb bind dev [filename] - bind \host\ device to file\n
- sb info [dev]- show device binding info
+ sb info [dev]- show device binding info\n
+ sb commands use the \hostfs\ device. The \host\ device is used\n
+ with standard IO commands such as fatls or ext2load
);
diff --git a/disk/part.c b/disk/part.c
index b3097e32f0eb..baceb19c60c7 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -510,6 +510,25 @@ int get_device_and_partition(const char *ifname, const
char *dev_part_str,
int part;
disk_partition_t tmpinfo;
+ /*
+* Special-case a psuedo block device hostfs, to allow access to the
+* host's own filesystem.
+*/
+ if (0 == strcmp(ifname, hostfs)) {
+ *dev_desc = NULL;
+ info-start = 0;
+ info-size = 0;
+ info-blksz = 0;
+ info-bootable = 0;
+ strcpy((char *)info-type, BOOT_PART_TYPE);
+ strcpy((char *)info-name, Sandbox host);
+#ifdef CONFIG_PARTITION_UUIDS
+ info-uuid[0] = 0;
+#endif
+
+ return 0;
+ }
+
/* If no dev_part_str, use bootdevice environment variable */
if (!dev_part_str || !strlen(dev_part_str) ||
!strcmp(dev_part_str, -))
diff --git a/test/command_ut.c b/test/command_ut.c
index b2666bfc182b..ae6466d0ed83 100644
--- a/test/command_ut.c
+++ b/test/command_ut.c
@@ -165,12 +165,12 @@ static int do_ut_cmd(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
#ifdef CONFIG_SANDBOX
/* File existence */
- HUSH_TEST(e, -e host - creating_this_file_breaks_uboot_unit_test, n);
- run_command(sb save host - creating_this_file_breaks_uboot_unit_test 0
1, 0);
- HUSH_TEST(e, -e host - creating_this_file_breaks_uboot_unit_test, y);
+ HUSH_TEST(e, -e hostfs - creating_this_file_breaks_uboot_unit_test,
n);
+ run_command(sb save hostfs - creating_this_file_breaks_uboot_unit_test
0 1, 0);
+ HUSH_TEST(e, -e hostfs - creating_this_file_breaks_uboot_unit_test,
y);
/* Perhaps this could be replaced by an rm shell command one day */
assert(!os_unlink(creating_this_file_breaks_uboot_unit_test));
- HUSH_TEST(e, -e host - creating_this_file_breaks_uboot_unit_test, n);
+ HUSH_TEST(e, -e hostfs - creating_this_file_breaks_uboot_unit_test,
n);
#endif
#endif
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sandbox: terminate os_dirent_ls() result list
From: Stephen Warren swar...@nvidia.com Each node in the linked-list that os_dirent_ls() returns has its next pointer set only when the next node is created. For the last node in the list, there is no next node, so this never happens, and the next pointer is never initialized. Explicitly initialize the next pointer so that it isn't dangling. Without this, sb ls might crash. Signed-off-by: Stephen Warren swar...@nvidia.com --- arch/sandbox/cpu/os.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c index 57d04a45b22b..2cbd74c7b8fc 100644 --- a/arch/sandbox/cpu/os.c +++ b/arch/sandbox/cpu/os.c @@ -362,6 +362,7 @@ int os_dirent_ls(const char *dirname, struct os_dirent_node **headp) if (!head) head = node; } + node-next = NULL; *headp = head; done: -- 1.8.1.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] sandbox: terminate os_dirent_ls() result list
From: Stephen Warren swar...@nvidia.com
Each node in the linked-list that os_dirent_ls() returns has its next
pointer set only when the next node is created. For the last node in the
list, there is no next node, so this never happens, and the next pointer
is never initialized. Explicitly initialize the next pointer so that it
isn't dangling. Without this, sb ls might crash.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
v2: Initialize node-next when it's created, rather than deferring it to
the end of the loop. This prevents an attempt to initialize node-next
if node was never created, since the loop never ran.
---
arch/sandbox/cpu/os.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 57d04a45b22b..1c4aa3f9bc4c 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -341,6 +341,7 @@ int os_dirent_ls(const char *dirname, struct os_dirent_node
**headp)
ret = -ENOMEM;
goto done;
}
+ next-next = NULL;
strcpy(next-name, entry.d_name);
switch (entry.d_type) {
case DT_REG:
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Aristeus: New Board using I.MX6 and next steps
To the U Boot Mailing list: I have been working for several months as a side project on an I.MX6Q implementation. Based on other work I am doing, I chose the COM Express standard as the form factor. Given the small size of the MX6 compared to the standard, I was able to add several peripherals to the board design (namely a PCIe Switch, a USB Hub, Ethernet Physical layer, and a Video DAC). I am expecting the module's in this week. I have recently been looking back at the U boot README as well as some of the support work that I have done in the last month in preparation for the prototypes. The prototypes still need to be checked out etc before moving forward but the confidence level is very high based on all of the Freescale and other documentation that exists. Once I have checked out the hardware and have a stable U boot board configuration built (mainly based on the SABRE SDP package), I am uncertain to the next steps. I have been following the mailing list for some time and have kept track of several ARM projects that are out there. I know that I will need to check the work, form a patch, etc. I want to make the transition as easy as possible for everyone else and recognize there is probably a lot of work left to build a proper patch and documentation. However, any assistance or way ahead other than what's in the README would be greatly appreciated. R, John ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ubifs: don't self assign values
Hello Heiko,
On wo, 2014-06-11 at 06:28 +0200, Heiko Schocher wrote:
Hello Jeroen,
Am 10.06.2014 23:27, schrieb Jeroen Hofstee:
It seems the code tries to trick the compiler the argument
is actually used. However compilers became too smart too
fool them so easily an now warn. Checking gcc and clang
does not seem to emit a warning. If so it should be decorated
with unused / (void).
cc: Stefan Roeses...@denx.de
Signed-off-by: Jeroen Hofsteejer...@myspectrum.nl
---
fs/ubifs/recovery.c | 1 -
fs/ubifs/scan.c | 1 -
2 files changed, 2 deletions(-)
I posted an update for MTD/UBI/UBIFS with Linux 3.14 here:
[U-Boot] [RFC, PATCH v2 0/4] mtd, ubi, ubifs: resync with Linux-3.14
http://lists.denx.de/pipermail/u-boot/2014-May/180001.html
Could you try this series? There only your change in fs/ubifs/recovery.c
is needed ...
I tried your v3, warnings below. Especially the first one is a bit noisy
since it is in a common header file. The other warnings seem harmless.
and as this code comes from Linux, maybe it is worth
to post this change also for Linux?
perhaps, first trying to silence MAKEALL a bit, so real issues aren't
buried in noise. I will see how it lands and send an updated patch.
Regards,
Jeroen
include/linux/compat.h:77:18: warning: redefinition of typedef 'gfp_t'
is a C11 feature [-Wtypedef-redefinition]
typedef unsigned gfp_t;
^
include/linux/types.h:142:30: note: previous definition is here
typedef unsigned __bitwise__gfp_t;
^
common/cmd_ubi.c:310:11: warning: comparison of unsigned expression 0
is always false [-Wtautological-compare]
if (size 0 || size rsvd_bytes) {
^ ~
drivers/mtd/ubi/vmt.c:797:26: warning: comparison of unsigned expression
0 is always false [-Wtautological-compare]
if (vol-last_eb_bytes 0 ||
~~ ^ ~
fs/ubifs/recovery.c:441:7: warning: explicitly assigning value of
variable of type 'int' to itself [-Wself-assign]
lnum = lnum;
^
fs/ubifs/scan.c:171:7: warning: explicitly assigning value of variable
of type 'int' to itself [-Wself-assign]
lnum = lnum;
^
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fs: ext4: fix writing zero-length files
From: Stephen Warren swar...@nvidia.com
ext4fs_allocate_blocks() always allocates at least one block for a file.
If the file size is zero, this causes total_remaining_blocks to
underflow, which then causes an apparent hang while 2^32 blocks are
allocated.
To solve this, check that total_remaining_blocks is non-zero as part of
the loop condition (i.e. before each loop) rather than at the end of
the loop.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
fs/ext4/ext4_common.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index 1c1172163c09..33d69c9c71f0 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -1380,7 +1380,7 @@ void ext4fs_allocate_blocks(struct ext2_inode *file_inode,
unsigned int no_blks_reqd = 0;
/* allocation of direct blocks */
- for (i = 0; i INDIRECT_BLOCKS; i++) {
+ for (i = 0; total_remaining_blocks i INDIRECT_BLOCKS; i++) {
direct_blockno = ext4fs_get_new_blk_no();
if (direct_blockno == -1) {
printf(no block left to assign\n);
@@ -1390,8 +1390,6 @@ void ext4fs_allocate_blocks(struct ext2_inode *file_inode,
debug(DB %ld: %u\n, direct_blockno, total_remaining_blocks);
total_remaining_blocks--;
- if (total_remaining_blocks == 0)
- break;
}
alloc_single_indirect_block(file_inode, total_remaining_blocks,
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/2] fs: implement size/fatsize/ext4size
From: Stephen Warren swar...@nvidia.com
These commands may be used to determine the size of a file without
actually reading the whole file content into memory. This may be used
to determine if the file will fit into the memory buffer that will
contain it. In particular, the DFU code will use it for this purpose
in the next commit.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
v2: New patch
---
common/cmd_ext4.c | 14 ++
common/cmd_fat.c | 13 +
common/cmd_fs.c| 13 +
fs/ext4/ext4fs.c | 5 +
fs/fat/fat.c | 5 +
fs/fs.c| 43 +++
fs/sandbox/sandboxfs.c | 5 +
include/ext4fs.h | 1 +
include/fat.h | 1 +
include/fs.h | 9 +
include/sandboxfs.h| 1 +
11 files changed, 110 insertions(+)
diff --git a/common/cmd_ext4.c b/common/cmd_ext4.c
index 68b047ba6aed..6d75dd2b89c6 100644
--- a/common/cmd_ext4.c
+++ b/common/cmd_ext4.c
@@ -42,6 +42,12 @@
#include usb.h
#endif
+int do_ext4_size(cmd_tbl_t *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ return do_size(cmdtp, flag, argc, argv, FS_TYPE_EXT);
+}
+
int do_ext4_load(cmd_tbl_t *cmdtp, int flag, int argc,
char *const argv[])
{
@@ -113,6 +119,14 @@ U_BOOT_CMD(ext4write, 6, 1, do_ext4_write,
#endif
+U_BOOT_CMD(
+ ext4size, 4, 0, do_ext4_size,
+ determine a file's size,
+ interface dev[:part] filename\n
+ - Find file 'filename' from 'dev' on 'interface'\n
+ and determine its size.
+);
+
U_BOOT_CMD(ext4ls, 4, 1, do_ext4_ls,
list files in a directory (default /),
interface dev[:part] [directory]\n
diff --git a/common/cmd_fat.c b/common/cmd_fat.c
index fbe33466fcf0..b9d1ad6d790e 100644
--- a/common/cmd_fat.c
+++ b/common/cmd_fat.c
@@ -18,6 +18,19 @@
#include fat.h
#include fs.h
+int do_fat_size(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ return do_size(cmdtp, flag, argc, argv, FS_TYPE_FAT);
+}
+
+U_BOOT_CMD(
+ fatsize,4, 0, do_fat_size,
+ determine a file's size,
+ interface dev[:part] filename\n
+ - Find file 'filename' from 'dev' on 'interface'\n
+ and determine its size.
+);
+
int do_fat_fsload (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
return do_load(cmdtp, flag, argc, argv, FS_TYPE_FAT);
diff --git a/common/cmd_fs.c b/common/cmd_fs.c
index 91a205ac1e69..7aeebc6f2eda 100644
--- a/common/cmd_fs.c
+++ b/common/cmd_fs.c
@@ -20,6 +20,19 @@
#include command.h
#include fs.h
+int do_size_wrapper(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ return do_size(cmdtp, flag, argc, argv, FS_TYPE_ANY);
+}
+
+U_BOOT_CMD(
+ size, 4, 0, do_size_wrapper,
+ determine a file's size,
+ interface dev[:part] filename\n
+ - Find file 'filename' from 'dev' on 'interface'\n
+ and determine its size.
+);
+
int do_load_wrapper(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
return do_load(cmdtp, flag, argc, argv, FS_TYPE_ANY);
diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c
index 417ce7b63bf0..cbdc22026deb 100644
--- a/fs/ext4/ext4fs.c
+++ b/fs/ext4/ext4fs.c
@@ -182,6 +182,11 @@ int ext4fs_exists(const char *filename)
return file_len = 0;
}
+int ext4fs_size(const char *filename)
+{
+ return ext4fs_open(filename);
+}
+
int ext4fs_read(char *buf, unsigned len)
{
if (ext4fs_root == NULL || ext4fs_file == NULL)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 54f42eae0d05..561921fa2d36 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -1243,6 +1243,11 @@ int fat_exists(const char *filename)
return sz = 0;
}
+int fat_size(const char *filename)
+{
+ return do_fat_read_at(filename, 0, NULL, 0, LS_NO, 1);
+}
+
long file_fat_read_at(const char *filename, unsigned long pos, void *buffer,
unsigned long maxsize)
{
diff --git a/fs/fs.c b/fs/fs.c
index 79d432d58fe0..bc57c1d3fb63 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -46,6 +46,11 @@ static inline int fs_exists_unsupported(const char *filename)
return 0;
}
+static inline int fs_size_unsupported(const char *filename)
+{
+ return -1;
+}
+
static inline int fs_read_unsupported(const char *filename, void *buf,
int offset, int len)
{
@@ -77,6 +82,7 @@ struct fstype_info {
disk_partition_t *fs_partition);
int (*ls)(const char *dirname);
int (*exists)(const char *filename);
+ int (*size)(const char *filename);
int (*read)(const char *filename, void *buf, int offset, int len);
int (*write)(const char *filename, void *buf, int offset, int len);
void (*close)(void);
@@ -91,6 +97,7 @@
[U-Boot] [PATCH V2 2/2] dfu: fix some issues with reads/uploads
From: Stephen Warren swar...@nvidia.com
DFU read support appears to rely upon dfu-read_medium() updating the
passed-by-reference len parameter to indicate the remaining size
available for reading.
dfu_read_medium_mmc() never does this, and the implementation of
dfu_read_medium_nand() will only work if called just once; it hard-codes
the value to the total size of the NAND device irrespective of read
offset.
I believe that overloading dfu-read_medium() is confusing. As such,
this patch introduces a new function dfu-get_medium_size() which can
be used to explicitly find out the medium size, and nothing else.
dfu_read() is modified to use this function to set the initial value for
dfu-r_left, rather than attempting to use the side-effects of
dfu-read_medium() for this purpose.
Due to this change, dfu_read() must initially set dfu-b_left to 0, since
no data has been read.
dfu_read_buffer_fill() must also be modified not to adjust dfu-r_left
when simply copying data from dfu-i_buf_start to the upload request
buffer. r_left represents the amount of data left to be read from HW.
That value is not affected by the memcpy(), but only by calls to
dfu-read_medium().
After this change, I can read from either a 4MB or 1.5MB chunk of a 4MB
eMMC boot partion with CONFIG_SYS_DFU_DATA_BUF_SIZE==1MB. Without this
change, attempting to do that would result in DFU read returning no data
at all due to r_left never being set.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
v2:
* Fix dfu_get_medium_size_mmc() to handle DFU_FS_FAT/EXT5 layouts too,
by calling the recently introduced size command.
---
drivers/dfu/dfu.c | 20 -
drivers/dfu/dfu_mmc.c | 59 ++
drivers/dfu/dfu_nand.c | 7 +-
drivers/dfu/dfu_ram.c | 11 +-
include/dfu.h | 3 +++
5 files changed, 79 insertions(+), 21 deletions(-)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index dc09ff6466e6..dab5e7048ed5 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -267,7 +267,6 @@ static int dfu_read_buffer_fill(struct dfu_entity *dfu,
void *buf, int size)
dfu-i_buf += chunk;
dfu-b_left -= chunk;
- dfu-r_left -= chunk;
size -= chunk;
buf += chunk;
readn += chunk;
@@ -313,10 +312,19 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
if (dfu-i_buf_start == NULL)
return -ENOMEM;
- ret = dfu-read_medium(dfu, 0, dfu-i_buf_start, dfu-r_left);
- if (ret != 0) {
- debug(%s: failed to get r_left\n, __func__);
- return ret;
+ dfu-r_left = dfu-get_medium_size(dfu);
+ if (dfu-r_left 0)
+ return dfu-r_left;
+ switch (dfu-layout) {
+ case DFU_RAW_ADDR:
+ case DFU_RAM_ADDR:
+ break;
+ default:
+ if (dfu-r_left = dfu_buf_size) {
+ printf(%s: File too big for buffer\n,
+ __func__);
+ return -EOVERFLOW;
+ }
}
debug(%s: %s %ld [B]\n, __func__, dfu-name, dfu-r_left);
@@ -326,7 +334,7 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
dfu-offset = 0;
dfu-i_buf_end = dfu_get_buf() + dfu_buf_size;
dfu-i_buf = dfu-i_buf_start;
- dfu-b_left = min(dfu_buf_size, dfu-r_left);
+ dfu-b_left = 0;
dfu-bad_skip = 0;
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 63cc876612c9..322bd8c5d2de 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -12,6 +12,8 @@
#include errno.h
#include div64.h
#include dfu.h
+#include ext4fs.h
+#include fat.h
#include mmc.h
static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE)
@@ -113,22 +115,17 @@ static int mmc_file_buffer(struct dfu_entity *dfu, void
*buf, long *len)
static int mmc_file_op(enum dfu_op op, struct dfu_entity *dfu,
void *buf, long *len)
{
+ const char *fsname, *opname;
char cmd_buf[DFU_CMD_BUF_SIZE];
char *str_env;
int ret;
switch (dfu-layout) {
case DFU_FS_FAT:
- sprintf(cmd_buf, fat%s mmc %d:%d 0x%x %s,
- op == DFU_OP_READ ? load : write,
- dfu-data.mmc.dev, dfu-data.mmc.part,
- (unsigned int) buf, dfu-name);
+ fsname = fat;
break;
case DFU_FS_EXT4:
- sprintf(cmd_buf, ext4%s mmc %d:%d 0x%x /%s,
- op == DFU_OP_READ ? load : write,
- dfu-data.mmc.dev,
[U-Boot] [PATCH] dfu: add write error handling
From: Stephen Warren swar...@nvidia.com
Fix calls to dfu_write() and dfu_flush() to detect errors in the I/O
itself. This could happen due to problems with the storage medium, or
simply when trying to write a FAT/ext file that is larger than the buffer
dfu_mmc.c maintains for this purpose.
Signal the error by switching the DFU state/status. This will be picked
up by the DFU client when it sends the next DFU request. Note that errors
can't simply be returned from e.g. dnload_request_complete(), since that
function has no way to pass errors back to the DFU client; a call to
dnload_request_complete() simply means that a USB OUT completed.
This error state/status needs to be cleared when the next DFU client
connects. While there is a DFU_CLRSTATUS request, no DFU client seems to
send this. Hence, clear this when selecting the USB alternate setting on
the USB interface.
Finally, dfu.c relies on a call to dfu_flush() to clear up the internal
state of the write transaction. Now that errors in dfu_write() are
detected, dfu_flush() may no longer be called for every transaction.
Separate out the cleanup code into a new function, and call it whenever
dfu_write() fails, as well as from any call to dfu_flush().
Signed-off-by: Stephen Warren swar...@nvidia.com
---
This probably depends on dfu: fix some issues with reads/uploads,
for context if nothing else.
---
drivers/dfu/dfu.c | 46 --
drivers/usb/gadget/f_dfu.c | 20
2 files changed, 44 insertions(+), 22 deletions(-)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index dab5e7048ed5..1bf66d0613c9 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -147,6 +147,19 @@ static int dfu_write_buffer_drain(struct dfu_entity *dfu)
return ret;
}
+void dfu_write_transaction_cleanup(struct dfu_entity *dfu)
+{
+ /* clear everything */
+ dfu_free_buf();
+ dfu-crc = 0;
+ dfu-offset = 0;
+ dfu-i_blk_seq_num = 0;
+ dfu-i_buf_start = dfu_buf;
+ dfu-i_buf_end = dfu_buf;
+ dfu-i_buf = dfu-i_buf_start;
+ dfu-inited = 0;
+}
+
int dfu_flush(struct dfu_entity *dfu, void *buf, int size, int blk_seq_num)
{
int ret = 0;
@@ -162,23 +175,14 @@ int dfu_flush(struct dfu_entity *dfu, void *buf, int
size, int blk_seq_num)
printf(\nDFU complete %s: 0x%08x\n, dfu_hash_algo-name,
dfu-crc);
- /* clear everything */
- dfu_free_buf();
- dfu-crc = 0;
- dfu-offset = 0;
- dfu-i_blk_seq_num = 0;
- dfu-i_buf_start = dfu_buf;
- dfu-i_buf_end = dfu_buf;
- dfu-i_buf = dfu-i_buf_start;
- dfu-inited = 0;
+ dfu_write_transaction_cleanup(dfu);
return ret;
}
int dfu_write(struct dfu_entity *dfu, void *buf, int size, int blk_seq_num)
{
- int ret = 0;
- int tret;
+ int ret;
debug(%s: name: %s buf: 0x%p size: 0x%x p_num: 0x%x offset: 0x%llx
bufoffset: 0x%x\n,
__func__, dfu-name, buf, size, blk_seq_num, dfu-offset,
@@ -202,6 +206,7 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
if (dfu-i_blk_seq_num != blk_seq_num) {
printf(%s: Wrong sequence number! [%d] [%d]\n,
__func__, dfu-i_blk_seq_num, blk_seq_num);
+ dfu_write_transaction_cleanup(dfu);
return -1;
}
@@ -223,15 +228,18 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int
size, int blk_seq_num)
/* flush buffer if overflow */
if ((dfu-i_buf + size) dfu-i_buf_end) {
- tret = dfu_write_buffer_drain(dfu);
- if (ret == 0)
- ret = tret;
+ ret = dfu_write_buffer_drain(dfu);
+ if (ret) {
+ dfu_write_transaction_cleanup(dfu);
+ return ret;
+ }
}
/* we should be in buffer now (if not then size too large) */
if ((dfu-i_buf + size) dfu-i_buf_end) {
error(Buffer overflow! (0x%p + 0x%x 0x%p)\n, dfu-i_buf,
size, dfu-i_buf_end);
+ dfu_write_transaction_cleanup(dfu);
return -1;
}
@@ -240,12 +248,14 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int
size, int blk_seq_num)
/* if end or if buffer full flush */
if (size == 0 || (dfu-i_buf + size) dfu-i_buf_end) {
- tret = dfu_write_buffer_drain(dfu);
- if (ret == 0)
- ret = tret;
+ ret = dfu_write_buffer_drain(dfu);
+ if (ret) {
+ dfu_write_transaction_cleanup(dfu);
+ return ret;
+ }
}
- return ret;
+ return 0;
}
static int dfu_read_buffer_fill(struct dfu_entity *dfu, void *buf, int size)
diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c
Re: [U-Boot] [PATCH] arm: Allow u-boot to run from offset base address
On 14-06-10 11:45 PM, Albert ARIBAUD wrote:
Hi Wolfgang,
On Wed, 11 Jun 2014 06:49:28 +0200, Wolfgang Denk w...@denx.de wrote:
Dear Steve,
In message 53979199.5010...@broadcom.com you wrote:
OK - I think that one of the alternate proposals would be to
conditionally reserve a 32 byte block prior to the _start symbol (in
arch/arm/cpu/armv8/start.S) which would then be filled in by a
post-processing step... This could be implemented by:
Yes, that illustrates the idea. However, this implementation suffers
from the use of an #ifdef where none is actually needed. Instead, you
can create your own source file which defines the header; this could
be then even in it's own segment, say:
your_header.c:
struct your_header {
u_int32[8];
} your_header __attribute__ ((__section__ (.your_hdr)));
All that is needed then is to make the linker place this segment in
front of the text segment.
This avoids an ugly #ifdef, and also modifications in the common code.
Agreed and seconded.
Plus, using a dedicated 'header' section and a separate C source file
for the header makes it automatic that if no input 'header' section
were provided then no output 'header' section would be emitted; IOW,
we would not need two different linker scripts, a single one would be
useable for both 'headerless' and 'headerful' image types.
Also, the alignment constraint should be configurable.
Best regards,
Wolfgang Denk
Amicalement,
Albert, Wolfgang, et al.
I didn't know about the automatic handling of conditional sections in
the linker script file - Thanks!!!
So if I add a your_header.c as above, then
(1) I need to modify arch/arm/cpu/armv8/u-boot.lds:
. = 0x;
+ . = ALIGN(8);
+ .your_hdr : {
+ KEEP(*(.your_hdr*));
+ }
+
. = ALIGN(8);
.text :
{
(2) then (I believe) I need to modify the Makefile to define the start
address of this new section:
+LDFLAGS_u-boot += --section-start=.your_hdr=CONFIG_YOUR_HEADER_ADDR
(3) and (I believe) I need to modify the OBJCOPYFLAGS (somewhere) in
order to include this new section in the u-boot.bin:
+OBJCOPYFLAGS += -j .your_hdr
(... I don't actually have this working yet; so I suspect more changes
are required ...)
And in the end, (I believe) I am just going to have a block (likely 4096
bytes) prepended to the original u-boot.bin; which I can do today with
no code changes at all
Remember that original design request was effectively a two line change:
+ gd-mon_len += CONFIG_SYS_TEXT_BASE % 4096;
and
+ gd-relocaddr += CONFIG_SYS_TEXT_BASE % 4096;
Regrettably, since this is not going to be accepted, I am abandoning
this change.
Thanks, Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-spi/master
On Sun, Jun 08, 2014 at 11:27:57PM +0530, Jagannadha Sutradharudu Teki wrote: Hi Tom, Please take this PR. thanks! Jagan. The following changes since commit 3e1fa221f94b7ae3389d166882b77f1da5895f22: Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2014-06-05 17:38:30 -0400) are available in the git repository at: git://git.denx.de/u-boot-spi.git master for you to fetch changes up to 1f436a6ddf7eb7f2da1c8df6c13100429baf844a: sf: probe: Fix quad bit set path (2014-06-08 23:12:27 +0530) Andrew Ruder (1): spi: soft_spi: Support NULL din/dout buffers Poddar, Sourav (1): sf: probe: Fix quad bit set path Siva Durga Prasad Paladugu (1): sf: params: Added support for Spansion S25FL512S_512K drivers/mtd/spi/sf_params.c | 1 + drivers/mtd/spi/sf_probe.c | 20 ++-- drivers/spi/soft_spi.c | 18 -- 3 files changed, 23 insertions(+), 16 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/11] bootm: Split out code from cmd_bootm.c
On Mon, Jun 02, 2014 at 10:39:43PM -0600, Simon Glass wrote: This file has code in three different categories: - Command processing - OS-specific boot code - Locating images and setting up to boot Only the first category really belongs in a file called cmd_bootm.c. Leave the command processing code where it is. Split out the OS-specific boot code into bootm_os.c. Split out the other code into bootm.c Header files and extern declarations are tidied but otherwise no code changes are made, to make it easier to review. Signed-off-by: Simon Glass s...@chromium.org Non-trivial to re-apply on top of master, please rebase. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: tegra: fix include guard
cc: Stephen Warren swar...@nvidia.com Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl --- include/configs/tegra-common-ums.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/tegra-common-ums.h b/include/configs/tegra-common-ums.h index 7bd8960..578ca68 100644 --- a/include/configs/tegra-common-ums.h +++ b/include/configs/tegra-common-ums.h @@ -6,7 +6,7 @@ */ #ifndef _TEGRA_COMMON_UMS_H_ -#define _TEGRA_COMMON_UMS_H +#define _TEGRA_COMMON_UMS_H_ #ifndef CONFIG_SPL_BUILD /* USB gadget, and mass storage protocol */ -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: fix include guard
On 06/11/2014 01:53 PM, Jeroen Hofstee wrote: diff --git a/include/configs/tegra-common-ums.h b/include/configs/tegra-common-ums.h #ifndef _TEGRA_COMMON_UMS_H_ -#define _TEGRA_COMMON_UMS_H +#define _TEGRA_COMMON_UMS_H_ Acked-by: Stephen Warren swar...@nvidia.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mtd: OMAP: Enable GPMC prefetch mode
Enable GPMC's prefetch feature for NAND access. This speeds up NAND read
access a lot by pre-fetching contents in the background and reading them
through the FIFO address.
The current implementation has two limitations:
a) it only works for 16bit
b) it only supports read access
Both is easily fixable by someone who has hardware to implement it.
Note that U-Boot code uses non word-aligned buffers to read data into, and
request read lengths that are not multiples of 4, so both partial buffers
(head and tail) have to be addressed.
Tested on AM335x hardware.
Signed-off-by: Daniel Mack zon...@gmail.com
---
doc/README.nand | 5 ++
drivers/mtd/nand/omap_gpmc.c | 115 +-
include/linux/mtd/omap_gpmc.h | 6 ++-
3 files changed, 123 insertions(+), 3 deletions(-)
diff --git a/doc/README.nand b/doc/README.nand
index 70cf768..6459f2a 100644
--- a/doc/README.nand
+++ b/doc/README.nand
@@ -292,6 +292,11 @@ Platform specific options
Thus BCH16 can be supported on 4K page NAND.
+CONFIG_NAND_OMAP_PREFETCH
+ On OMAP platforms that use the GPMC controller (CONFIG_NAND_OMAP_GPMC),
+ this options enables the code that uses the prefetch mode to speed up
+ read operations.
+
NOTE:
=
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index 1acf06b..e2d57bd 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -446,6 +446,113 @@ static int omap_correct_data_bch(struct mtd_info *mtd,
uint8_t *dat,
return (err) ? err : error_count;
}
+#ifdef CONFIG_NAND_OMAP_GPMC_PREFETCH
+
+#define PREFETCH_CONFIG1_CS_SHIFT 24
+#define PREFETCH_FIFOTHRESHOLD_MAX 0x40
+#define PREFETCH_FIFOTHRESHOLD(val)((val) 8)
+#define PREFETCH_STATUS_COUNT(val) (val 0x3fff)
+#define PREFETCH_STATUS_FIFO_CNT(val) ((val 24) 0x7F)
+#define ENABLE_PREFETCH(1 7)
+
+/**
+ * omap_prefetch_enable - configures and starts prefetch transfer
+ * @fifo_th: fifo threshold to be used for read/ write
+ * @count: number of bytes to be transferred
+ * @is_write: prefetch read(0) or write post(1) mode
+ */
+static int omap_prefetch_enable(int fifo_th, unsigned int count, int is_write)
+{
+ uint32_t val;
+
+ if (fifo_th PREFETCH_FIFOTHRESHOLD_MAX)
+ return -EINVAL;
+
+ if (readl(gpmc_cfg-prefetch_control))
+ return -EBUSY;
+
+ /* Set the amount of bytes to be prefetched */
+ writel(count, gpmc_cfg-prefetch_config2);
+
+ val = (cs PREFETCH_CONFIG1_CS_SHIFT) | (is_write 1) |
+ PREFETCH_FIFOTHRESHOLD(fifo_th) | ENABLE_PREFETCH;
+ writel(val, gpmc_cfg-prefetch_config1);
+
+ /* Start the prefetch engine */
+ writel(1, gpmc_cfg-prefetch_control);
+
+ return 0;
+}
+
+/**
+ * omap_prefetch_reset - disables and stops the prefetch engine
+ */
+static void omap_prefetch_reset(void)
+{
+ writel(0, gpmc_cfg-prefetch_control);
+ writel(0, gpmc_cfg-prefetch_config1);
+}
+
+static int __read_prefetch_aligned(struct nand_chip *chip, uint32_t *buf, int
len)
+{
+ int ret;
+ uint32_t cnt;
+
+ ret = omap_prefetch_enable(PREFETCH_FIFOTHRESHOLD_MAX, len, 0);
+ if (ret 0)
+ return ret;
+
+ do {
+ int i;
+
+ cnt = readl(gpmc_cfg-prefetch_status);
+ cnt = PREFETCH_STATUS_FIFO_CNT(cnt);
+
+ for (i = 0; i cnt / 4; i++) {
+ *buf++ = readl(CONFIG_SYS_NAND_BASE);
+ len -= 4;
+ }
+ } while (len);
+
+ omap_prefetch_reset();
+
+ return 0;
+}
+
+static void omap_nand_read_prefetch8(struct mtd_info *mtd, uint8_t *buf, int
len)
+{
+ int ret;
+ uint32_t head, tail;
+ struct nand_chip *chip = mtd-priv;
+
+ /*
+* If the destination buffer is unaligned, start with reading
+* the overlap byte-wise.
+*/
+ head = ((uint32_t) buf) % 4;
+ if (head) {
+ nand_read_buf(mtd, buf, head);
+ buf += head;
+ len -= head;
+ }
+
+ /*
+* Only transfer multiples of 4 bytes in a pre-fetched fashion.
+* If there's a residue, care for it byte-wise afterwards.
+*/
+ tail = len % 4;
+
+ ret = __read_prefetch_aligned(chip, (uint32_t *) buf, len - tail);
+ if (ret 0) {
+ /* fallback in case the prefetch engine is busy */
+ nand_read_buf(mtd, buf, len);
+ } else if (tail) {
+ buf += len - tail;
+ nand_read_buf(mtd, buf, tail);
+ }
+}
+#endif /* CONFIG_NAND_OMAP_GPMC_PREFETCH */
+
/**
* omap_read_page_bch - hardware ecc based page read function
* @mtd: mtd info structure
@@ -883,11 +990,15 @@ int board_nand_init(struct nand_chip *nand)
if (err)
return err;
-#ifdef
[U-Boot] [PATCH 0/2] OMAP/GPMC: speed up NAND read access
Hi, I spent some time looking into boot times of AM335x platforms. One big improvement I made came with adding support for GPMC prefetch mode, which gave a speed-up of NAND reads of roughly factor 2. This is what patch #1 does. Note that this is currently limited to read operations in 8-bit mode, but I believe it could be easily extended to 16-bit operations if anyone has hardware to test it on. Using the engine for write mode speed improvements should also be doable, but I didn't spend time on it yet. That can be added as a separate patch later. Patch #2 decreases the GPMC memory map window size from 256MiB to 16MiB. Admittedly, I'm not quite sure about the reason, but a read from offset 0 in this memory area will freeze U-Boot instantly if the size is configured to 256MiB. As contents of the FIFO are accessed in a pseudo-mode from offset 0 anyway, it doesn't really matter. What I also did to further speed up my boot was to tweak the GPMC parameters for the NAND chip on our boards, but that's not part of this patch set, and probably deserves a little more cleanup. Test results and feedback very welcome. Thanks, Daniel Daniel Mack (2): mtd: OMAP: Enable GPMC prefetch mode ARM: omap-common: gpmp: decrease memory region size to 16MiB arch/arm/cpu/armv7/omap-common/mem-common.c | 2 +- doc/README.nand | 5 ++ drivers/mtd/nand/omap_gpmc.c| 115 +++- include/linux/mtd/omap_gpmc.h | 6 +- 4 files changed, 124 insertions(+), 4 deletions(-) -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i2c: kona: Resolve Kona I2C driver issue
On 14-05-26 12:33 PM, Steve Rae wrote:
- i2c mw command hangs (with some compilers)
Signed-off-by: Steve Rae s...@broadcom.com
---
drivers/i2c/kona_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/kona_i2c.c b/drivers/i2c/kona_i2c.c
index 0b1715a..5eab338 100644
--- a/drivers/i2c/kona_i2c.c
+++ b/drivers/i2c/kona_i2c.c
@@ -663,7 +663,7 @@ static int kona_i2c_read(struct i2c_adapter *adap, uchar
chip, uint addr,
static int kona_i2c_write(struct i2c_adapter *adap, uchar chip, uint addr,
int alen, uchar *buffer, int len)
{
- struct i2c_msg msg[0];
+ struct i2c_msg msg[1];
unsigned char msgbuf0[64];
unsigned int i;
struct bcm_kona_i2c_dev *dev = kona_get_dev(adap);
I am hoping to get this into v2014.07
Thanks in advance, Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: spl: fix include guard
cc: Tom Rini tr...@ti.com Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl --- arch/arm/include/asm/arch-keystone/spl.h | 2 +- arch/arm/include/asm/arch-sunxi/spl.h| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/include/asm/arch-keystone/spl.h b/arch/arm/include/asm/arch-keystone/spl.h index 7012ea7..a7102d5 100644 --- a/arch/arm/include/asm/arch-keystone/spl.h +++ b/arch/arm/include/asm/arch-keystone/spl.h @@ -5,7 +5,7 @@ * SPDX-License-Identifier:GPL-2.0+ */ #ifndef _ASM_ARCH_SPL_H_ -#define _ASM_SPL_H_ +#define _ASM_ARCH_SPL_H_ #define BOOT_DEVICE_SPI2 diff --git a/arch/arm/include/asm/arch-sunxi/spl.h b/arch/arm/include/asm/arch-sunxi/spl.h index ff871bc..acbec46 100644 --- a/arch/arm/include/asm/arch-sunxi/spl.h +++ b/arch/arm/include/asm/arch-sunxi/spl.h @@ -7,7 +7,7 @@ * SPDX-License-Identifier:GPL-2.0+ */ #ifndef_ASM_ARCH_SPL_H_ -#define_ASM_SPL_H_ +#define_ASM_ARCH_SPL_H_ #define BOOT_DEVICE_NONE 0 #define BOOT_DEVICE_XIP1 -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: omap-common: gpmp: decrease memory region size to 16MiB
That memory area is not used except for the first location, so it doesn't
matter. However, with the length configured to 256MiB, U-Boot crased when
accessing contents of the map.
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/cpu/armv7/omap-common/mem-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap-common/mem-common.c
b/arch/arm/cpu/armv7/omap-common/mem-common.c
index 944ef84..3595806 100644
--- a/arch/arm/cpu/armv7/omap-common/mem-common.c
+++ b/arch/arm/cpu/armv7/omap-common/mem-common.c
@@ -99,7 +99,7 @@ void gpmc_init(void)
M_NAND_GPMC_CONFIG6,
0
};
- u32 size = GPMC_SIZE_256M;
+ u32 size = GPMC_SIZE_16M;
u32 base = CONFIG_SYS_NAND_BASE;
#elif defined(CONFIG_CMD_ONENAND)
const u32 gpmc_regs[GPMC_MAX_REG] = { ONENAND_GPMC_CONFIG1,
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for DS1340 RTC
Hi Tom, Tom Rini wrote On Mon, Jun 09, 2014 at 09:59:39AM +1200, Darwin Dingel wrote: Implementation is the same as with a DS1337 but with different register addresses. Signed-off-by: Darwin Dingel lt; darwin.dingel@.co gt; Are you going to post patches for a board which sets CONFIG_RTC_DS1340 ? No. Just the RTC support. --- Darwin -- View this message in context: http://u-boot.10912.n7.nabble.com/PATCH-Add-support-for-DS1340-RTC-tp181823p182071.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
Re: [U-Boot] [PATCH 03/11] bootm: Split out code from cmd_bootm.c
Hi Tom, On 11 June 2014 13:48, Tom Rini tr...@ti.com wrote: On Mon, Jun 02, 2014 at 10:39:43PM -0600, Simon Glass wrote: This file has code in three different categories: - Command processing - OS-specific boot code - Locating images and setting up to boot Only the first category really belongs in a file called cmd_bootm.c. Leave the command processing code where it is. Split out the OS-specific boot code into bootm_os.c. Split out the other code into bootm.c Header files and extern declarations are tidied but otherwise no code changes are made, to make it easier to review. Signed-off-by: Simon Glass s...@chromium.org Non-trivial to re-apply on top of master, please rebase. Thanks! Yes I have this locally, and will resend once I've retested. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tegra20: display: fix checking of return value
The calling code seems a bit in doubt about the return
value of fdtdec_lookup_phandle. Since it returns a negative
value on error (and fdt_node_offset_by_phandle as well),
check for that.
cc: Wei Ni w...@nvidia.com
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
---
arch/arm/cpu/armv7/tegra20/display.c:331:26: warning: comparison
of constant 0 with boolean expression is always false
[-Wtautological-constant-out-of-range-compare]
if (!config-panel_node 0) {
~~~ ^ ~
NOT tested on hw.
---
arch/arm/cpu/armv7/tegra20/display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/tegra20/display.c
b/arch/arm/cpu/armv7/tegra20/display.c
index 488f0c6..fd77f3f 100644
--- a/arch/arm/cpu/armv7/tegra20/display.c
+++ b/arch/arm/cpu/armv7/tegra20/display.c
@@ -328,7 +328,7 @@ static int tegra_display_decode_config(const void *blob,
rgb = fdt_subnode_offset(blob, node, rgb);
config-panel_node = fdtdec_lookup_phandle(blob, rgb, nvidia,panel);
- if (!config-panel_node 0) {
+ if (config-panel_node 0) {
debug(%s: Cannot find panel information\n, __func__);
return -1;
}
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Allow u-boot to run from offset base address
Dear Steve,
In message 5398a640.3050...@broadcom.com you wrote:
So if I add a your_header.c as above, then
(1) I need to modify arch/arm/cpu/armv8/u-boot.lds:
. = 0x;
+ . = ALIGN(8);
+ .your_hdr : {
+ KEEP(*(.your_hdr*));
+ }
+
. = ALIGN(8);
.text :
{
ALIGN(8) looks pretty much bogus to me?
Quoting the ld docs:
'ALIGN(ALIGN)'
'ALIGN(EXP,ALIGN)'
Return the location counter ('.') or arbitrary expression aligned
to the next ALIGN boundary. The single operand 'ALIGN' doesn't
change the value of the location counter--it just does arithmetic
on it. The two operand 'ALIGN' allows an arbitrary expression to
be aligned upwards ('ALIGN(ALIGN)' is equivalent to 'ALIGN(.,
ALIGN)').
Here is an example which aligns the output '.data' section to the
next '0x2000' byte boundary after the preceding section and sets a
variable within the section to the next '0x8000' boundary after the
input sections:
SECTIONS { ...
.data ALIGN(0x2000): {
*(.data)
variable = ALIGN(0x8000);
}
... }
The first use of 'ALIGN' in this example specifies the location of
a section because it is used as the optional ADDRESS attribute of a
section definition (*note Output Section Address::). The second
use of 'ALIGN' is used to defines the value of a symbol.
Are you sure you do not ant to hae an ALIGN(4096) there?
(2) then (I believe) I need to modify the Makefile to define the start
address of this new section:
+LDFLAGS_u-boot += --section-start=.your_hdr=CONFIG_YOUR_HEADER_ADDR
Why?
(3) and (I believe) I need to modify the OBJCOPYFLAGS (somewhere) in
order to include this new section in the u-boot.bin:
+OBJCOPYFLAGS += -j .your_hdr
Why?
And in the end, (I believe) I am just going to have a block (likely 4096
bytes) prepended to the original u-boot.bin; which I can do today with
no code changes at all
Well, we don't chaneg any code here, right? Just the linker script.
It's this, or some other script. But the linker is the standard way
to create a linked image with the correct memory map, so this is the
right place...
Remember that original design request was effectively a two line change:
Yes, indeed But a pretty much bogus one.
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
Wisdom is one of the few things that looks bigger the further away it
is. - Terry Pratchett, _Witches Abroad_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/t208x: update t2080qds/t2080rdb for errata A-007186
On 05/15/2014 04:24 AM, Shengzhou Liu wrote: As errata A-007186, we need to use the alternate serdes protocol instead of those impacted protocols. - add support for serdes protocols: 0x1b, 0x50, 0x5e, 0x64, 0x6a, 0xd2, 0x67, 0x70. - update t2080_rcw.cfg to adapt to new rcw_66_15 for t2080qds and t2080rdb. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- Applied to u-boot-mpc85xx. Sorry for the late notice. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v3] powerpc/t4qds: Add alternate serdes protocols to align with A-007186
On 05/15/2014 07:52 PM, shh@gmail.com wrote: From: Shaohui Xie shaohui@freescale.com A-007186: SerDes PLL is calibrated at reset. It is possible for jitter to increase and cause the PLL to unlock when the temperature delta from the time the PLL is calibrated exceeds +56C/-66C when using X VDD of 1.35 V (or +70C/-80C when using XnVDD of 1.5 V). No issues are seen with LC VCO. Only the protocols using Ring VCOs are impacted. Workaround: For all 1.25/2.5/5 GHz protocols, use LC VCO instead of Ring VCO, this need to use alternate serdes protocols. The alternate option has the same functionality as the original option; the only difference being LC VCO rather than Ring VCO. Signed-off-by: Shaohui Xie shaohui@freescale.com --- changes for V3: update t4_rcw.cfg. changes for V2: refined commit message. Applied to u-boot-mpc85xx. Sorry for the late notice. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] powerpc/t4rdb: Add alternate serdes protocols to align with A-007186
On 05/19/2014 10:34 PM, Chunhe Lan wrote: A-007186: SerDes PLL is calibrated at reset. It is possible for jitter to increase and cause the PLL to unlock when the temperature delta from the time the PLL is calibrated exceeds +56C/-66C when using X VDD of 1.35 V (or +70C/-80C when using XnVDD of 1.5 V). No issues are seen with LC VCO. The protocols only using Ring VCOs are impacted. Workaround: For all 1.25/2.5/5 GHz protocols, use LC VCO instead of Ring VCO, this need to use alternate serdes protocols. Alternate option has the same functionality as the original option; the only difference being LC VCO rather than Ring VCO. Signed-off-by: Chunhe Lan chunhe@freescale.com --- Applied to u-boot-mpc85xx. Sorry for the late notice. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/t2080qds: some update for ddr
On 05/19/2014 09:08 PM, Shengzhou Liu wrote: - add support for 2nd DIMM slot. - make it work with DIMM which is less than 2GB. Verified with two 2GB UDIMM MT9JSF25672AZ-2G1K1 in two DIMM slots. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- Applied to u-boot-mpc85xx. Sorry for the late notice. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/espi: remove 80us delay to improve transfer performance
On 05/20/2014 07:25 PM, Hou Zhiqiang wrote: Replace 80 mircoseconds delay with polling flag ESPI_EV_TXE. Signed-off-by: Hou Zhiqiang b48...@freescale.com --- Applied to u-boot-mpc85xx. Sorry for the late notice. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] powerpc/t2080: add serdes2 protocol 0x27
On 05/22/2014 02:24 AM, Shengzhou Liu wrote: Add a new serdes2 protocol 0x27. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- Applied to u-boot-mpc85xx. Sorry for the late notice. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] unsigned int for gpio
Hello Simon, in commit 95a260a9 dm: Enable gpio command to support driver model Now that named GPIO banks are supported, along with a way of obtaining the status of a GPIO (input or output), we can provide an enhanced GPIO command for driver model. Where the driver provides its own operation for obtaining the GPIO state, this is used, otherwise a generic version is sufficient. you made the following change: - int gpio; + unsigned int gpio; This breaks the code after it though: /* turn the gpio name into a gpio number */ gpio = name_to_gpio(str_gpio); if (gpio 0) goto show_usage; And causes warnings with clang like: common/cmd_gpio.c:159:11: warning: comparison of unsigned expression 0 is always false [-Wtautological-compare] if (gpio 0) ^ ~ Do you recall why it is made unsigned? Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/mpc85xx: Add workaround to enable TDM on T1040
On 06/05/2014 06:19 AM, Sandeep Singh wrote: This is a workaround for 32 bit hardware limitation of TDM. T1040 has 36 bit physical addressing, TDM DMAC register are 32 bit wide but need to store address of CCSR space which lies beyond 32 bit address range. This workaround creats a LAW to enable access of TDM DMA to CCSR by mapping CCSR to overlap with DDR. A hole of 16M is created in memory using device tree. This workaround law is set only if tdm is defined in hwconfig. Also disable POST tests and add LIODN for TDM Signed-off-by: Sandeep Singh sand...@freescale.com Cc: York Sun york...@freescale.com --- Applied to u-boot-mpc85xx. Sorry for the late notice. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/serdes: Add the workaround for erratum A-007186
On 05/28/2014 01:48 AM, Shaveta Leekha wrote: SerDes PLL is calibrated at reset. When the junction temperature delta from the time the PLL is calibrated exceeds +56C/-66C, jitter may increase and can cause PLL to unlock. This workaround overwrite the SerDes registers with new values, to calibrate SerDes registers. These values are known to work fine for all temperature ranges. This workaround is valid for B4, T4 and T2 platforms, so added in their config. Signed-off-by: Shaveta Leekha shav...@freescale.com Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com --- Applied to u-boot-mpc85xx. Sorry for the late notice. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH]powerpc/B4420: Fixed incomplete handling for 0x9d serdes2
On 05/30/2014 11:38 AM, Poonam Aggrwal wrote: Crossbars and IDT were not getting configured for Serdes2 protocol 0x9d for B4420. Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Shaveta Leekha shav...@freescale.com --- Applied to u-boot-mpc85xx. Sorry for the late notice. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/espi: remove 80us delay to improve transfer performance
On 05/20/2014 07:25 PM, Hou Zhiqiang wrote: Replace 80 mircoseconds delay with polling flag ESPI_EV_TXE. Signed-off-by: Hou Zhiqiang b48...@freescale.com --- Applied to u-boot-mpc85xx. Sorry for the late notice. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] dfu: allow backend to specify a maximum buffer size
From: Stephen Warren swar...@nvidia.com
CONFIG_SYS_DFU_DATA_BUF_SIZE may be large to allow for FAT/ext layouts
to transfer large files. However, this means that individual write
operations will take a long time. Allow backends to specify a maximum
buffer size, so that each write operation is limited to a smaller data
block. This prevents the DFU protocol from timing out when e.g. writing
to SPI flash. I would guess that NAND might benefit from setting this
value too, but I can't test that.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
drivers/dfu/dfu.c | 13 -
drivers/usb/gadget/f_thor.c | 5 +++--
include/dfu.h | 3 ++-
3 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 26d3b44e40f5..b8d382d9b5df 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -82,7 +82,7 @@ unsigned long dfu_get_buf_size(void)
return dfu_buf_size;
}
-unsigned char *dfu_get_buf(void)
+unsigned char *dfu_get_buf(struct dfu_entity *dfu)
{
char *s;
@@ -92,6 +92,8 @@ unsigned char *dfu_get_buf(void)
s = getenv(dfu_bufsiz);
dfu_buf_size = s ? (unsigned long)simple_strtol(s, NULL, 16) :
CONFIG_SYS_DFU_DATA_BUF_SIZE;
+ if (dfu-max_buf_size dfu_buf_size dfu-max_buf_size)
+ dfu_buf_size = dfu-max_buf_size;
dfu_buf = memalign(CONFIG_SYS_CACHELINE_SIZE, dfu_buf_size);
if (dfu_buf == NULL)
@@ -194,10 +196,10 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int
size, int blk_seq_num)
dfu-offset = 0;
dfu-bad_skip = 0;
dfu-i_blk_seq_num = 0;
- dfu-i_buf_start = dfu_get_buf();
+ dfu-i_buf_start = dfu_get_buf(dfu);
if (dfu-i_buf_start == NULL)
return -ENOMEM;
- dfu-i_buf_end = dfu_get_buf() + dfu_buf_size;
+ dfu-i_buf_end = dfu_get_buf(dfu) + dfu_buf_size;
dfu-i_buf = dfu-i_buf_start;
dfu-inited = 1;
@@ -318,7 +320,7 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
__func__, dfu-name, buf, size, blk_seq_num, dfu-i_buf);
if (!dfu-inited) {
- dfu-i_buf_start = dfu_get_buf();
+ dfu-i_buf_start = dfu_get_buf(dfu);
if (dfu-i_buf_start == NULL)
return -ENOMEM;
@@ -342,7 +344,7 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
dfu-i_blk_seq_num = 0;
dfu-crc = 0;
dfu-offset = 0;
- dfu-i_buf_end = dfu_get_buf() + dfu_buf_size;
+ dfu-i_buf_end = dfu_get_buf(dfu) + dfu_buf_size;
dfu-i_buf = dfu-i_buf_start;
dfu-b_left = 0;
@@ -398,6 +400,7 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char *s,
int alt,
strcpy(dfu-name, st);
dfu-alt = alt;
+ dfu-max_buf_size = 0;
/* Specific for mmc device */
if (strcmp(interface, mmc) == 0) {
diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c
index 28f215e07c6e..c5f10a054d95 100644
--- a/drivers/usb/gadget/f_thor.c
+++ b/drivers/usb/gadget/f_thor.c
@@ -142,7 +142,8 @@ static long long int download_head(unsigned long long total,
int *cnt)
{
long long int rcv_cnt = 0, left_to_rcv, ret_rcv;
- void *transfer_buffer = dfu_get_buf();
+ struct dfu_entity *dfu_entity = dfu_get_entity(alt_setting_num);
+ void *transfer_buffer = dfu_get_buf(dfu_entity);
void *buf = transfer_buffer;
int usb_pkt_cnt = 0, ret;
@@ -205,7 +206,7 @@ static long long int download_head(unsigned long long total,
static int download_tail(long long int left, int cnt)
{
struct dfu_entity *dfu_entity = dfu_get_entity(alt_setting_num);
- void *transfer_buffer = dfu_get_buf();
+ void *transfer_buffer = dfu_get_buf(dfu_entity);
int ret;
debug(%s: left: %llu cnt: %d\n, __func__, left, cnt);
diff --git a/include/dfu.h b/include/dfu.h
index 21390aa9b7b3..d5562dcb37d1 100644
--- a/include/dfu.h
+++ b/include/dfu.h
@@ -91,6 +91,7 @@ struct dfu_entity {
void*dev_private;
enum dfu_device_typedev_type;
enum dfu_layout layout;
+ unsigned long max_buf_size;
union {
struct mmc_internal_data mmc;
@@ -138,7 +139,7 @@ void dfu_trigger_reset(void);
int dfu_get_alt(char *name);
bool dfu_reset(void);
int dfu_init_env_entities(char *interface, char *devstr);
-unsigned char *dfu_get_buf(void);
+unsigned char *dfu_get_buf(struct dfu_entity *dfu);
unsigned char *dfu_free_buf(void);
unsigned long dfu_get_buf_size(void);
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
[U-Boot] [PATCH 3/4] dfu: add free_entity() to struct dfu_entity
From: Stephen Warren swar...@nvidia.com
This allows the backend to free any resources allocated during the
relevant dfu_fill_entity_*() call. This will soon be used by the
SF backend.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
drivers/dfu/dfu.c | 3 +++
include/dfu.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index b8d382d9b5df..897dfab77be6 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -401,6 +401,7 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char *s,
int alt,
dfu-alt = alt;
dfu-max_buf_size = 0;
+ dfu-free_entity = NULL;
/* Specific for mmc device */
if (strcmp(interface, mmc) == 0) {
@@ -427,6 +428,8 @@ void dfu_free_entities(void)
list_for_each_entry_safe_reverse(dfu, p, dfu_list, list) {
list_del(dfu-list);
+ if (dfu-free_entity)
+ dfu-free_entity(dfu);
t = dfu;
}
if (t)
diff --git a/include/dfu.h b/include/dfu.h
index d5562dcb37d1..43814b38ec6d 100644
--- a/include/dfu.h
+++ b/include/dfu.h
@@ -110,6 +110,8 @@ struct dfu_entity {
int (*flush_medium)(struct dfu_entity *dfu);
unsigned int (*poll_timeout)(struct dfu_entity *dfu);
+ void (*free_entity)(struct dfu_entity *dfu);
+
struct list_head list;
/* on the fly state */
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] dfu: add SF backend
From: Stephen Warren swar...@nvidia.com
This allows SPI Flash to be programmed using DFU.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
drivers/dfu/Makefile | 1 +
drivers/dfu/dfu.c| 3 ++
drivers/dfu/dfu_sf.c | 139 +++
include/dfu.h| 22
4 files changed, 165 insertions(+)
create mode 100644 drivers/dfu/dfu_sf.c
diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile
index def628dcdcc4..5cc535efdd47 100644
--- a/drivers/dfu/Makefile
+++ b/drivers/dfu/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_DFU_FUNCTION) += dfu.o
obj-$(CONFIG_DFU_MMC) += dfu_mmc.o
obj-$(CONFIG_DFU_NAND) += dfu_nand.o
obj-$(CONFIG_DFU_RAM) += dfu_ram.o
+obj-$(CONFIG_DFU_SF) += dfu_sf.o
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 897dfab77be6..6cd3fbb58ae4 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -413,6 +413,9 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char *s,
int alt,
} else if (strcmp(interface, ram) == 0) {
if (dfu_fill_entity_ram(dfu, devstr, s))
return -1;
+ } else if (strcmp(interface, sf) == 0) {
+ if (dfu_fill_entity_sf(dfu, devstr, s))
+ return -1;
} else {
printf(%s: Device %s not (yet) supported!\n,
__func__, interface);
diff --git a/drivers/dfu/dfu_sf.c b/drivers/dfu/dfu_sf.c
new file mode 100644
index ..91f6df220b1d
--- /dev/null
+++ b/drivers/dfu/dfu_sf.c
@@ -0,0 +1,139 @@
+/*
+ * Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include malloc.h
+#include errno.h
+#include div64.h
+#include dfu.h
+#include spi_flash.h
+
+static long dfu_get_medium_size_sf(struct dfu_entity *dfu)
+{
+ return dfu-data.sf.size;
+}
+
+static int dfu_read_medium_sf(struct dfu_entity *dfu, u64 offset, void *buf,
+ long *len)
+{
+ return spi_flash_read(dfu-data.sf.dev, offset, *len, buf);
+}
+
+static int dfu_write_medium_sf(struct dfu_entity *dfu,
+ u64 offset, void *buf, long *len)
+{
+ int ret;
+
+ ret = spi_flash_erase(dfu-data.sf.dev, offset, *len);
+ if (ret)
+ return ret;
+
+ ret = spi_flash_write(dfu-data.sf.dev, offset, *len, buf);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int dfu_flush_medium_sf(struct dfu_entity *dfu)
+{
+ return 0;
+}
+
+static unsigned int dfu_polltimeout_sf(struct dfu_entity *dfu)
+{
+ return DFU_DEFAULT_POLL_TIMEOUT;
+}
+
+static void dfu_free_entity_sf(struct dfu_entity *dfu)
+{
+ spi_flash_free(dfu-data.sf.dev);
+}
+
+static struct spi_flash *parse_dev(char *devstr)
+{
+ unsigned int bus;
+ unsigned int cs;
+ unsigned int speed = CONFIG_SF_DEFAULT_SPEED;
+ unsigned int mode = CONFIG_SF_DEFAULT_MODE;
+ char *s, *endp;
+ struct spi_flash *dev;
+
+ s = strsep(devstr, :);
+ if (!s || !*s || (bus = simple_strtoul(s, endp, 0), *endp)) {
+ printf(Invalid SPI bus %s\n, s);
+ return NULL;
+ }
+
+ s = strsep(devstr, :);
+ if (!s || !*s || (cs = simple_strtoul(s, endp, 0), *endp)) {
+ printf(Invalid SPI chip-select %s\n, s);
+ return NULL;
+ }
+
+ s = strsep(devstr, :);
+ if (s *s) {
+ speed = simple_strtoul(s, endp, 0);
+ if (*endp || !speed) {
+ printf(Invalid SPI speed %s\n, s);
+ return NULL;
+ }
+ }
+
+ s = strsep(devstr, :);
+ if (s *s) {
+ mode = simple_strtoul(s, endp, 0);
+ if (*endp || mode 3) {
+ printf(Invalid SPI mode %s\n, s);
+ return NULL;
+ }
+ }
+
+ dev = spi_flash_probe(bus, cs, speed, mode);
+ if (!dev) {
+ printf(Failed to create SPI flash at %d:%d:%d:%d\n,
+ bus, cs, speed, mode);
+ return NULL;
+ }
+
+ return dev;
+}
+
+int dfu_fill_entity_sf(struct dfu_entity *dfu, char *devstr, char *s)
+{
+ char *st;
+
+ dfu-data.sf.dev = parse_dev(devstr);
+ if (!dfu-data.sf.dev)
+ return -ENODEV;
+
+ dfu-dev_type = DFU_DEV_SF;
+ dfu-max_buf_size = dfu-data.sf.dev-sector_size;
+
+ st = strsep(s, );
+ if (!strcmp(st, raw)) {
+ dfu-layout = DFU_RAW_ADDR;
+ dfu-data.sf.start = simple_strtoul(s, s, 16);
+ s++;
+ dfu-data.sf.size = simple_strtoul(s, s, 16);
+ } else {
+ printf(%s: Memory layout (%s) not supported!\n, __func__, st);
+ spi_flash_free(dfu-data.sf.dev);
+ return -1;
+ }
+
+ dfu-get_medium_size = dfu_get_medium_size_sf;
+ dfu-read_medium =
[U-Boot] [PATCH 1/4] dfu: defer parsing of device string to IO backend
From: Stephen Warren swar...@nvidia.com
Devices are not all identified by a single integer. To support
this, defer the parsing of the device string to the IO backed, so that
it can apply the appropriate rules.
SPI devices are specified as controller:chip_select. SPI/SF support will
be added soon.
MMC devices can also be specified as controller[.hwpart][:partition] in
many commands, although we don't support that syntax in DFU.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
common/cmd_dfu.c | 3 +--
drivers/dfu/dfu.c | 20 ++--
drivers/dfu/dfu_mmc.c | 21 -
drivers/dfu/dfu_nand.c | 2 +-
drivers/dfu/dfu_ram.c | 2 +-
include/dfu.h | 22 +-
6 files changed, 38 insertions(+), 32 deletions(-)
diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c
index 433bddd5d2bd..2633b30e556f 100644
--- a/common/cmd_dfu.c
+++ b/common/cmd_dfu.c
@@ -24,8 +24,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
int ret, i = 0;
- ret = dfu_init_env_entities(interface, simple_strtoul(devstring,
- NULL, 10));
+ ret = dfu_init_env_entities(interface, devstring);
if (ret)
goto done;
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 1bf66d0613c9..26d3b44e40f5 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -44,7 +44,7 @@ static int dfu_find_alt_num(const char *s)
return ++i;
}
-int dfu_init_env_entities(char *interface, int dev)
+int dfu_init_env_entities(char *interface, char *devstr)
{
const char *str_env;
char *env_bkp;
@@ -57,7 +57,7 @@ int dfu_init_env_entities(char *interface, int dev)
}
env_bkp = strdup(str_env);
- ret = dfu_config_entities(env_bkp, interface, dev);
+ ret = dfu_config_entities(env_bkp, interface, devstr);
if (ret) {
error(DFU entities configuration failed!\n);
return ret;
@@ -389,26 +389,25 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
}
static int dfu_fill_entity(struct dfu_entity *dfu, char *s, int alt,
- char *interface, int num)
+ char *interface, char *devstr)
{
char *st;
- debug(%s: %s interface: %s num: %d\n, __func__, s, interface, num);
+ debug(%s: %s interface: %s dev: %s\n, __func__, s, interface, devstr);
st = strsep(s, );
strcpy(dfu-name, st);
- dfu-dev_num = num;
dfu-alt = alt;
/* Specific for mmc device */
if (strcmp(interface, mmc) == 0) {
- if (dfu_fill_entity_mmc(dfu, s))
+ if (dfu_fill_entity_mmc(dfu, devstr, s))
return -1;
} else if (strcmp(interface, nand) == 0) {
- if (dfu_fill_entity_nand(dfu, s))
+ if (dfu_fill_entity_nand(dfu, devstr, s))
return -1;
} else if (strcmp(interface, ram) == 0) {
- if (dfu_fill_entity_ram(dfu, s))
+ if (dfu_fill_entity_ram(dfu, devstr, s))
return -1;
} else {
printf(%s: Device %s not (yet) supported!\n,
@@ -434,7 +433,7 @@ void dfu_free_entities(void)
alt_num_cnt = 0;
}
-int dfu_config_entities(char *env, char *interface, int num)
+int dfu_config_entities(char *env, char *interface, char *devstr)
{
struct dfu_entity *dfu;
int i, ret;
@@ -457,7 +456,8 @@ int dfu_config_entities(char *env, char *interface, int num)
for (i = 0; i dfu_alt_num; i++) {
s = strsep(env, ;);
- ret = dfu_fill_entity(dfu[i], s, alt_num_cnt, interface, num);
+ ret = dfu_fill_entity(dfu[i], s, alt_num_cnt, interface,
+ devstr);
if (ret)
return -1;
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 322bd8c5d2de..72fa03eedaec 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -27,7 +27,7 @@ static int mmc_access_part(struct dfu_entity *dfu, struct mmc
*mmc, int part)
if (part == mmc-part_num)
return 0;
- ret = mmc_switch_part(dfu-dev_num, part);
+ ret = mmc_switch_part(dfu-data.mmc.dev_num, part);
if (ret) {
error(Cannot switch to partition %d\n, part);
return ret;
@@ -40,7 +40,7 @@ static int mmc_access_part(struct dfu_entity *dfu, struct mmc
*mmc, int part)
static int mmc_block_op(enum dfu_op op, struct dfu_entity *dfu,
u64 offset, void *buf, long *len)
{
- struct mmc *mmc = find_mmc_device(dfu-dev_num);
+ struct mmc *mmc = find_mmc_device(dfu-data.mmc.dev_num);
u32 blk_start, blk_count, n = 0;
int ret, part_num_bkp = 0;
@@ -67,15 +67,15 @@ static int mmc_block_op(enum dfu_op op,
Re: [U-Boot] [U-Boot, 1/2] Makefile: fix clang warnings due to clang support
On Fri, May 30, 2014 at 03:45:27PM +0200, Jeroen Hofstee wrote: Building u-boot tools with clang as a host compiler e.g. on FreeBSD with `gmake HOSTCC=clang CONFIG_USE_PRIVATE_LIBGCC=y tools` leads to many warnings [1] for every compiler invocation since commit 598e2d33. Part of mentioned commit imports linux patches: - kbuild: LLVMLinux: Adapt warnings for compilation with clang - kbuild: LLVMLinux: Add Kbuild support for building kernel with Clang No version of clang supports the gcc fno-delete-null-pointer-checks though, but it is only passed to clang. Gcc does not have the clang specific Qunused-arguments for the target. Furthermore several warnings are disabled which aren't encountered in u-boot. Since such a build has worked for quite some time and works after removing these changes, just remove the clang specific handling to restore normal building with clang as hostcc. [1] Actual warnings --- GEN include/autoconf.mk.dep arm-freebsd-gcc: unrecognized option '-Qunused-arguments' HOSTCC scripts/basic/fixdep clang: warning: argument unused during compilation: '-fno-delete-null-pointer-checks' cc: Masahiro Yamada yamad...@jp.panasonic.com Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2] tools: include u-boot version of sha256.h
On Fri, May 30, 2014 at 03:45:28PM +0200, Jeroen Hofstee wrote: When building tools the u-boot specific sha256.h is required, but the host version of sha256.h is used when present. This leads to build errors on FreeBSD which does have a system sha256.h include. Like libfdt_env.h explicitly include u-boot's sha256.h. cc: Simon Glass s...@chromium.org Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl Acked-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 01/14] ti: am335x: Fix the U-Boot binary output
On Mon, Jun 02, 2014 at 10:04:44PM -0600, Simon Glass wrote: This should include the hash so that image_binary_size is really at the end of the image, and not some 300 bytes earlier. Signed-off-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 02/14] cm_t335: Fix the U-Boot binary output
On Mon, Jun 02, 2014 at 10:04:45PM -0600, Simon Glass wrote: Correct the binary output so that image_binary_size is really at the end of the image. Signed-off-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 03/14] mx31ads: Fix the U-Boot binary output
On Mon, Jun 02, 2014 at 10:04:46PM -0600, Simon Glass wrote: Correct the binary output so that image_binary_size is really at the end of the image. Signed-off-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 07/14] fdt: Add DEV_TREE_BIN option to specify a device tree binary file
On Mon, Jun 02, 2014 at 10:04:50PM -0600, Simon Glass wrote: In some cases, an externally-built device tree binary is required to be attached to U-Boot. An example is when using image signing, since in that case the .dtb file must include the public keys. Add a DEV_TREE_BIN option to the Makefile, and update the documentation. Usage is something like: make DEV_TREE_BIN=boot/am335x-boneblack-pubkey.dtb Signed-off-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 05/14] am33xx/omap: Allow cache enable for all Sitara/OMAP
On Mon, Jun 02, 2014 at 10:04:48PM -0600, Simon Glass wrote: Enable the cache for all devices, unless CONFIG_SYS_DCACHE_OFF is defined. This speeds up the Beaglebone Black boot considerable. (Tested only on Beaglebone Black with SD card boot) Signed-off-by: Simon Glass s...@chromium.org Applied to u-boot/master (and tested on am43xx evm as well), thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 06/14] hash: Export the function to show a hash
On Mon, Jun 02, 2014 at 10:04:49PM -0600, Simon Glass wrote: This function is useful for displaying a hash value, so export it. Signed-off-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 08/14] fdt: Update functions which write to an FDT to return -ENOSPC
On Mon, Jun 02, 2014 at 10:04:51PM -0600, Simon Glass wrote: When writing values into an FDT it is possible that there will be insufficient space. If the caller gets a useful error then it can potentially deal with the situation. Adjust these functions to return -ENOSPC when the FDT is full. Signed-off-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 12/14] am33xx/omap: Enable CONFIG_OF_CONTROL
On Mon, Jun 02, 2014 at 10:04:55PM -0600, Simon Glass wrote: Add support for device tree control and add device tree files for the beaglebone black initially. Signed-off-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 11/14] arm: ti: Increase malloc size to 16MB for armv7 boards
On Mon, Jun 02, 2014 at 10:04:54PM -0600, Simon Glass wrote: The current size of 1MB is not enough use to use DFU. Increase it for ARMv7 boards, all of which should have 32MB or more SDRAM. With this change it is possible to do 'dfu mmc 0' on a Beaglebone Black. Signed-off-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 09/14] Improve error handling in fit_common
On Mon, Jun 02, 2014 at 10:04:52PM -0600, Simon Glass wrote: Make the error handling common, and make sure the file is always closed on error. Rename the parameter to be more description and add comments. Signed-off-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 10/14] mkimage: Automatically make space in FDT when full
On Mon, Jun 02, 2014 at 10:04:53PM -0600, Simon Glass wrote: When adding hashes or signatures, the target FDT may be full. Detect this and automatically try again after making 1KB of space. Signed-off-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 07/14] fdt: Add DEV_TREE_BIN option to specify a device tree binary file
On Tue, Jun 10, 2014 at 02:59:23PM +0900, Masahiro Yamada wrote: Hi Simon, On Mon, 2 Jun 2014 22:04:50 -0600 Simon Glass s...@chromium.org wrote: In some cases, an externally-built device tree binary is required to be attached to U-Boot. An example is when using image signing, since in that case the .dtb file must include the public keys. I do not want to expand this argument, but I am not sure if DTB stands for device tree binary. linux/Documentation often refer it as device tree blob, while linux/Documentation/devicetree/booting-without-of.txt says device tree block. Add a DEV_TREE_BIN option to the Makefile, and update the documentation. Is it possible to rename it without mentioning _BIN or _BLOB ? For example, DTB_PATH=... or EXT_DTB=... or some other variable name you like. Yes. diff --git a/Makefile b/Makefile index ece622f..92819bf 100644 --- a/Makefile +++ b/Makefile @@ -867,7 +867,7 @@ MKIMAGEFLAGS_u-boot.kwb = -n $(srctree)/$(CONFIG_SYS_KWD_CONFIG:%=%) \ MKIMAGEFLAGS_u-boot.pbl = -n $(srctree)/$(CONFIG_SYS_FSL_PBL_RCW:%=%) \ -R $(srctree)/$(CONFIG_SYS_FSL_PBL_PBI:%=%) -T pblimage -u-boot.img u-boot.kwb u-boot.pbl: u-boot.bin FORCE +u-boot.img u-boot.kwb u-boot.pbl: u-boot$(if $(CONFIG_OF_SEPARATE),-dtb,).bin FORCE $(call if_changed,mkimage) The second comma in '(if $(CONFIG_OF_SEPARATE),-dtb,)' is redundant. This is duplicating the same image as u-boot-dtb.img Your way is that u-boot.img includes DTB in some time and doesn't in the other. I am not sure which way is better. But we don't need two rules to generate the equivalent image. If you go along with this change, I think it's OK with me. Please consider removing below in that case: ifeq ($(CONFIG_SPL_FRAMEWORK),y) ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb.img endif and u-boot-dtb.img: u-boot-dtb.bin FORCE $(call if_changed,mkimage) ... as a follow up (I want to get this in already). Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v3,13/14] am33xx/omap: Enable FIT support
On Mon, Jun 02, 2014 at 10:04:56PM -0600, Simon Glass wrote: Enable booting a FIT containing a kernel/device tree. Signed-off-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 14/14] am33xx/omap: Add a new board to enable verified boot
On Mon, Jun 02, 2014 at 10:04:57PM -0600, Simon Glass wrote: Enable verified boot functionality for a new am335x_boneblack_vboot target. Signed-off-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/14] Minor improvements to secure boot and enable on beaglebone
On Mon, Jun 02, 2014 at 10:04:43PM -0600, Simon Glass wrote: This series fixes a few problems that have come up since the secure boot series was merged: - A recent commit broken the assumption that u-boot.bin ends at a known address (thus making things appended to U-Boot inaccessible from the code). This is fixed for Beaglebone and a few other boards. A new test is added to the Makefile to ensure that it does not break again. All boards have been tested to make sure the problem does not appear elsewhere. - A way is needed to provide an externally-build device tree binary for U-Boot. This allows signing to happen outside the U-Boot build system. - The .img files generated by an OMAP build need to include the FDT if one is appended. - Adding signatures to an FDT can cause the FDT to run out of space. The fix is to regenerate the FDT from scratch with different dtc parameters, so pretty painful. Instead, we automatically expand the FDT. The last commit enables verified boot on a Beaglebone Black with a special configuration. Use 'am335x_boneblack_vboot' for this. This will soon disable support for legacy images. Changes in v3: - Add new patch to ensure the hash section is inside the image for cm_t335 - Add new patch to ensure the hash section is inside the image for mx31ads - Rebase to master and update commit message - Fix typo in commit message - Add new patch to improve error handling in fit_common - Rebase to master - Also enable LZO and timestamps, plus increase the maximum kernel size - Use verified boot only on a new board - am335x_boneblack_vboot Changes in v2: - Add new patch to ensure the hash section is inside the image for am335x - Add new patch to check u-boot.bin size against symbol table - Update to cover all omap devices - Adjust for kbuild changes - Fix line over 80cols - Move device tree files into arch/arm/dts Note that I applied this directly to master since it's largely TI boards or generic code, I hope you don't mind Albert. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESEND, 1/3] Check run_command() return code properly
On Thu, Jun 05, 2014 at 08:07:56PM +0200, Thomas Betker wrote: run_command() returns 0 for success, 1 for failure. Fix places which assume that failure is indicated by a negative return code. Signed-off-by: Thomas Betker thomas.bet...@rohde-schwarz.com Acked-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org Tested-by: Stefan Roese s...@denx.de Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,RESEND,3/3] Use run_command_repeatable()
On Thu, Jun 05, 2014 at 08:07:58PM +0200, Thomas Betker wrote: Replace run_command() by run_command_repeatable() in places which depend on the return code to indicate repeatability. Signed-off-by: Thomas Betker thomas.bet...@rohde-schwarz.com Acked-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] kbuild: export HOSTCXX and HOSTCXXFLAGS
On Fri, Jun 06, 2014 at 10:15:27AM +0900, Masahiro Yamada wrote: Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,RESEND,2/3] Add run_command_repeatable()
On Thu, Jun 05, 2014 at 08:07:57PM +0200, Thomas Betker wrote: run_command() returns 0 on success and 1 on error. However, there are some invocations which expect 0 or 1 for success (not repeatable or repeatable) and -1 for error; add run_command_repeatable() for this purpose. Signed-off-by: Thomas Betker thomas.bet...@rohde-schwarz.com Acked-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] disk: part_dos.c: Add a PBR check when MBR checking fails
On Fri, Jun 06, 2014 at 03:48:26PM +1200, Darwin Dingel wrote: Bug: SDCard with a messed up partition but still has a FAT signature intact is readable in Linux but unreadable in uboot with 'fatls'. Fix: When partition info checking fails, there is no checking for a FAT signature (DOS_PBR) which will fail 'fatls'. FAT signature checking is done when no valid partition is found in partition table. If FAT signature is found, the disk will be read as PBR and continue processing. Signed-off-by: Darwin Dingel darwin.din...@alliedtelesis.co.nz Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] .gitignore: drop *.dts.tmp pattern
On Fri, Jun 06, 2014 at 08:18:37PM +0900, Masahiro Yamada wrote: This pattern was added by commit cc4f427b to ignore the intermidiate file for generating DTB. When Kbuild was introduced, dts/Makefile was totally re-written. This ignore pattern is already useless. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2] .gitignore: move *.exe pattern to the top gitignore for Cygwin
On Fri, Jun 06, 2014 at 08:46:45PM +0900, Masahiro Yamada wrote: GCC on Cygwin generates executables with .exe extension, for example: scripts/basic/fixdep.exe scripts/docproc.exe To ignore them, *.exe pattern should be moved from tools/.gitignore to ./.gitignore Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] docs: driver-model: Fix spelling
On Sat, Jun 07, 2014 at 10:35:55AM +1200, Chris Packham wrote: Signed-off-by: Chris Packham judge.pack...@gmail.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] m68k: Fix warnings with gcc 4.6
On Sat, Jun 07, 2014 at 10:07:58PM -0600, Simon Glass wrote: Most of the warnings seem to be related to using 'int' for size_t. Change this and fix up the remaining warnings and problems. For bootm, the warning was masked by others, and there is an actual bug in the code. Signed-off-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] kbuild, tools: generate wrapper C sources automatically by Makefile
On Fri, Jun 06, 2014 at 02:04:32PM +0900, Masahiro Yamada wrote: There are many source files shared between U-boot image and tools. Instead of adding a lot of dummy wrapper files that just include the corresponding file in lib/ or common/ directory, Makefile should automatically generate them. The original inspiration for this came from scripts/Makefile.asm-generic of Linux Kernel. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Acked-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] kbuild: remove unnecessary adjustment for Cygwin
On Fri, Jun 06, 2014 at 08:46:44PM +0900, Masahiro Yamada wrote: SFX = .exe was originally added for Cygwin environment. It is true that GCC on Cygwin spits executables with .exe extention. For example, gcc -o foo foo.c will generate foo.exe, not foo. But GNU make is also nicely adjusted for Cygwin. For example, foo: foo.c gcc -o $@ $ will compare the timestamp between foo.exe and foo.c. You do not have to tweak Makefiles like this: foo$(SFX): foo.c gcc -o $@ $ And make clean works as well without adjustment for Cygwin because the command rm foo on Cygwin will delete both foo and foo.exe. In conclusion, makefiles do not need special care for Cygwin. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,3/3] ext4: correctly zero filename
On Mon, Jun 09, 2014 at 03:29:00PM +0200, Jeroen Hofstee wrote: Since ALLOC_CACHE_ALIGN_BUFFER declares a char* for filename sizeof(filename) is not the size of the buffer. Use the already known length instead. cc: Uma Shankar uma.shan...@samsung.com cc: Manjunatha C Achar a.manjuna...@samsung.com cc: Marek Vasut marek.va...@gmail.com Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl Acked-by: Marek Vasut ma...@denx.de Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] common: hash: zero end the string instead of the pointer
On Mon, Jun 09, 2014 at 11:02:02AM +0200, Jeroen Hofstee wrote: if algo-digest_size is zero nothing is set in the str_output buffer. An attempt is made to zero end the buffer, but the pointer to the buffer is set to zero instead. I am unaware if it causes any actual problems, but solves the following warning: common/hash.c:217:13: warning: expression which evaluates to zero treated as a null pointer constant of type 'char *' [-Wnon-literal-null-conversion] str_ptr = '\0'; ^~~~ cc: Simon Glass s...@chromium.org Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] cosmetic: Whitespace fix
On Tue, Jun 10, 2014 at 04:06:52PM +0300, Vasili Galka wrote: Signed-off-by: Vasili Galka vvv...@gmail.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
