Re: [U-Boot] standalone-examples: support custom GCC lib
Hi Jack, On Tue, 16 Jul 2013 14:44:22 +0100, Jack Mitchell m...@communistcode.co.uk wrote: Fighting with compiling u-boot today and dealing with problems related to using a custom built openembedded toolchain, I found the need to specify a custom location for the GCC lib. This is well supported when building u-boot, but my compile was failing in the standalone examples, as there was no support for a custom GCC lib in the standalone examples Makefile. I am no toolchain or u-boot expert, and as such to avoid the firey pits of flamewar hell, this is an RFC ;) ... which wasn't tagged '[RFC]', apparently. :) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to create a library with already built library
Hi Julyberry, On Tue, 16 Jul 2013 15:24:16 -0700 (PDT), Julyberry sen...@gmail.com wrote: Hello, I am new to U-Boot and try to add some codes for implementing some logic as a feature. This entry routine of this new code will be called from main_loop in common. To achieve this, there are some new codes that I am adding to u-boot/lib/libua(new folder) and I also need to link an already built library with my new code. I looked at the existing Makefiles and config.mk in U-Boot source root. It looks like the the following code is used in Makefile. $(LIB): $(obj).depend $(OBJS) $(call cmd_link_o_target, $(OBJS)) However, it seems that the *cmd_link_o_target* routine only takes 1 argument as defined in config.mk. How can I link the already built library with the new library I am creating? Any help will be appreciated. You don't want to link an already built library with a new library. You want to build a target with both libraries in it. Dependencies between the libs will be handled by the linker. So look for the Makefile which contains the line(s) that link the existing library, and duplicate the same lines (possibly conditional) to link in your new library also. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx6qsabrelite: Remove mx6qsabrelite code in favor of nitrogen6x
Hi Fabio, On Mon, 15 Jul 2013 14:29:28 -0300, Fabio Estevam fabio.este...@freescale.com wrote: mx6qsabrelite and nitrogen6q boards are hardware compatible, so let's avoid the code duplication and only use the nitrogen6x source code to make board code maintainance easier. Tested booting a mainline device tree kernel on a mx6qsabrelite board. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Hmm, why does this patch not show on Patchwork? Only its V1 does. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx6qsabrelite: Remove mx6qsabrelite code in favor of nitrogen6x
Hi Albert, On 17/07/2013 09:42, Albert ARIBAUD wrote: Hi Fabio, On Mon, 15 Jul 2013 14:29:28 -0300, Fabio Estevam fabio.este...@freescale.com wrote: mx6qsabrelite and nitrogen6q boards are hardware compatible, so let's avoid the code duplication and only use the nitrogen6x source code to make board code maintainance easier. Tested booting a mainline device tree kernel on a mx6qsabrelite board. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Hmm, why does this patch not show on Patchwork? Only its V1 does. I am struggling for finding it, too. I have already seen a similar case in the past. Otavio remarked that when there is a rename, patchwork is not able to track it (bug in patchwork). Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] standalone-examples: support custom GCC lib
On 17/07/13 08:11, Albert ARIBAUD wrote: Hi Jack, On Tue, 16 Jul 2013 14:44:22 +0100, Jack Mitchell m...@communistcode.co.uk wrote: Fighting with compiling u-boot today and dealing with problems related to using a custom built openembedded toolchain, I found the need to specify a custom location for the GCC lib. This is well supported when building u-boot, but my compile was failing in the standalone examples, as there was no support for a custom GCC lib in the standalone examples Makefile. I am no toolchain or u-boot expert, and as such to avoid the firey pits of flamewar hell, this is an RFC ;) ... which wasn't tagged '[RFC]', apparently. :) Amicalement, The great plans of mice and men, huh? I intended for the RFC tag to go on, but in all my excitement it was forgotten. -- Jack Mitchell (j...@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-boot x86 coreboot
Hi, I would like to run U-boot on x86 emulated QEMU-based environment. I found some info regarding coreboot + U-boot integration, using U-boot as payload, etc. but I was unable to start U-boot. I'm using the 32-bits i686-pc-linux-gnu toolchain and I successfully cross-compiled coreboot and started it on qemu-system-i386. I also configured coreboot to use u-boot (ELF) as payload, but coreboot performs a reset when U-boot should show up after loading. Where could I have some information regarding that? Furthermore, I'm unable to debug anything remotely with gdb; gdb cannot disassemble once connected via target remote localhost:1234. Any hints welcome. Thanks so much. Cheers Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx6qsabrelite: Remove mx6qsabrelite code in favor of nitrogen6x
Hi Stefano, On Wed, 17 Jul 2013 10:04:29 +0200, Stefano Babic sba...@denx.de wrote: Hi Albert, On 17/07/2013 09:42, Albert ARIBAUD wrote: Hi Fabio, On Mon, 15 Jul 2013 14:29:28 -0300, Fabio Estevam fabio.este...@freescale.com wrote: mx6qsabrelite and nitrogen6q boards are hardware compatible, so let's avoid the code duplication and only use the nitrogen6x source code to make board code maintainance easier. Tested booting a mainline device tree kernel on a mx6qsabrelite board. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Hmm, why does this patch not show on Patchwork? Only its V1 does. I am struggling for finding it, too. I have already seen a similar case in the past. Otavio remarked that when there is a rename, patchwork is not able to track it (bug in patchwork). Since we have a clear example (and on the patchwork site where the patchwork folks can dig as deep as they need), we could bring this up to the patchwork list, with the M-IDs of the V1 and V2 patches. I'd rather someone with a handle to the U-Boot mailing list do it, as it may require digging there too. Wolfgang? Stefano Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: at91sam9n12: change EBI IO to high drive mode
As both the DDR SDRAM and NAND flash connect to EBI on at91sam9n12 and share the lower 8 bits data line. If use low drive of the data line, it will cause DDR data access corrupt in lower address, so change the data line to high drive mode This will fix the Linux kernel boot issue when use Lower address Signed-off-by: Bo Shen voice.s...@atmel.com --- board/atmel/at91sam9n12ek/at91sam9n12ek.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/atmel/at91sam9n12ek/at91sam9n12ek.c b/board/atmel/at91sam9n12ek/at91sam9n12ek.c index 3013a42..66c4c1f 100644 --- a/board/atmel/at91sam9n12ek/at91sam9n12ek.c +++ b/board/atmel/at91sam9n12ek/at91sam9n12ek.c @@ -59,7 +59,7 @@ static void at91sam9n12ek_nand_hw_init(void) /* Configure databus */ csa = ~AT91_MATRIX_NFD0_ON_D16; /* nandflash connect to D0~D15 */ /* Configure IO drive */ - csa = ~AT91_MATRIX_EBI_EBI_IOSR_NORMAL; + csa |= AT91_MATRIX_EBI_EBI_IOSR_NORMAL; writel(csa, matrix-ebicsa); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx6qsabrelite: Remove mx6qsabrelite code in favor of nitrogen6x
On 17/07/2013 11:10, Albert ARIBAUD wrote: Hi Stefano, On Wed, 17 Jul 2013 10:04:29 +0200, Stefano Babic sba...@denx.de wrote: Hi Albert, On 17/07/2013 09:42, Albert ARIBAUD wrote: Hi Fabio, On Mon, 15 Jul 2013 14:29:28 -0300, Fabio Estevam fabio.este...@freescale.com wrote: mx6qsabrelite and nitrogen6q boards are hardware compatible, so let's avoid the code duplication and only use the nitrogen6x source code to make board code maintainance easier. Tested booting a mainline device tree kernel on a mx6qsabrelite board. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Hmm, why does this patch not show on Patchwork? Only its V1 does. I am struggling for finding it, too. I have already seen a similar case in the past. Otavio remarked that when there is a rename, patchwork is not able to track it (bug in patchwork). Since we have a clear example (and on the patchwork site where the patchwork folks can dig as deep as they need), we could bring this up to the patchwork list, with the M-IDs of the V1 and V2 patches. A second example was : [PATCH 5/6] mx28evk: Move README file inside board directory This can be found in the ML, but I never found it in patchworks. This patch renamed only a file: diff --git a/doc/README.mx28evk b/board/freescale/mx28evk/README similarity index 100% rename from doc/README.mx28evk rename to board/freescale/mx28evk/README For this reason the disappearing of mx6qsabrelite can be related, because also this patch renames a file. Regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] README.mx28_common: Rename it to README.mxs
Hi Fabio,
On 16/07/2013 17:38, Fabio Estevam wrote:
Hi Stefano,
On Fri, Jul 12, 2013 at 8:49 AM, Marek Vasut ma...@denx.de wrote:
Dear Fabio Estevam,
From: Fabio Estevam fabio.este...@freescale.com
commit 54965b61360 (README: mxs: Introduce README.mxs) should have changed
the file name to README.mxs, as it covers both mx23 and mx28 now.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
doc/{README.mx28_common = README.mxs} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename doc/{README.mx28_common = README.mxs} (100%)
diff --git a/doc/README.mx28_common b/doc/README.mxs
similarity index 100%
rename from doc/README.mx28_common
rename to doc/README.mxs
Acked-by: Marek Vasut ma...@denx.de
Could we have this one applied into 2013.07?
I am not sure why the file rename didn't take effect, as the original
patch handled it:
http://patchwork.ozlabs.org/patch/241363/
mmhh..I think we are too late for it, Tom is putting the release out.
Albert, do you still plan a PR and if yes could you pick up directly
this fix to the documentation ?
Thanks,
Stefano
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] README.mx28_common: Rename it to README.mxs
Hi Stefano,
On Wed, 17 Jul 2013 11:30:04 +0200, Stefano Babic sba...@denx.de
wrote:
Hi Fabio,
On 16/07/2013 17:38, Fabio Estevam wrote:
Hi Stefano,
On Fri, Jul 12, 2013 at 8:49 AM, Marek Vasut ma...@denx.de wrote:
Dear Fabio Estevam,
From: Fabio Estevam fabio.este...@freescale.com
commit 54965b61360 (README: mxs: Introduce README.mxs) should have changed
the file name to README.mxs, as it covers both mx23 and mx28 now.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
doc/{README.mx28_common = README.mxs} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename doc/{README.mx28_common = README.mxs} (100%)
diff --git a/doc/README.mx28_common b/doc/README.mxs
similarity index 100%
rename from doc/README.mx28_common
rename to doc/README.mxs
Acked-by: Marek Vasut ma...@denx.de
Could we have this one applied into 2013.07?
I am not sure why the file rename didn't take effect, as the original
patch handled it:
http://patchwork.ozlabs.org/patch/241363/
mmhh..I think we are too late for it, Tom is putting the release out.
Albert, do you still plan a PR and if yes could you pick up directly
this fix to the documentation ?
Hmm... I have sent out my pull request and I don't plan any before
release now; even if I picked it up, I'd have to PR to Tom for it to
go into 2013.07 -- if Tom agrees. And if he agrees, then it is quicker
that Tom pick it up directly. This is, after all, a simple rename of a
documentation file, with zero impact on functionality.
Thanks,
Stefano
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: at91sam9n12: change EBI IO to high drive mode
Hi Bo, On Wed, 17 Jul 2013 17:14:17 +0800, Bo Shen voice.s...@atmel.com wrote: As both the DDR SDRAM and NAND flash connect to EBI on at91sam9n12 and share the lower 8 bits data line. If use low drive of the data line, it will cause DDR data access corrupt in lower address, so change the data line to high drive mode This will fix the Linux kernel boot issue when use Lower address Wait--does this mean that there is no separate chip selects for NAND and DDR on this SoC? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][DFU] Unification of dfu_alt_info alt settings description + command execution
Hello Lukasz,
Am 16.07.2013 17:35, schrieb Lukasz Majewski:
Dear All,
Since DFU usage at u-boot is spreading to different device types (MMC,
NAND), file systems, raw partitions, ubi, etc, I think that it is a
good moment to unify and structure the form of dfu_alt_info environment
variable.
Full Ack!
Proposed new format for single dfu entity:
NAME | Type | Device | Dev_num | Dev_part | FS | start | size |
where:
Name - name of the alt setting (as seen by dfu-util -l)
Type - description of the image (raw, file, img, command [*])
Device - physical device on which data are stored (mmc, nand, -)
Dev_num - number of the device - it is possible to store data via DFU
on several devices of the same type.
Dev_part - number of partitions on the device.
Should this be number of the partition on the device
You mean here the mtd partition for storing, right?
FS - information about file system on the device (fat,
ext2/ext4, ubi).
start- start offset from the beginning of the Device (byte or LBA
number addressed)
size - maximal number of blocks to be stored on the Device
(expressed with Bytes of LBA number) (protection from
overwriting the whole device)
Example:
Maybe dummy questions ...
NAME | Type | Device | Dev_num | Dev_part | FS | start | size |
--
u-boot | raw | mmc| 0 | - [**] | - | 0x80 | 0x100 |
uImage | file | mmc| 0 | 2| ext4 | - | - |
Is this enough information? Where to store the uImage file on the ext4
partition?
root.img | img | mmc| 0 | 5| - | - | - |
img means here: getting an image and storing it on the mtd partition
Dev_part if start and size are marked with -, beginning
on start of the partition?
Wouldn't it be better to use here mtd partition names instead
numbers for Dev_part?
What if start and size are filled with values for the Type img?
Or is this forbidden for the Type img?
root.img | raw | mmc| 0 | - | - | 0x1000| 0x4000|
u-boot | raw | nand | 0 | - | - | 0x100 | 0x100 |
uImage | file | nand | 0 | 3| ubi | - | - |
s/uImage/rootfs.img ? s/file/img ?
For the FS ubi we need to specify, how to burn this into nand.
I think we have no ubi format command. With ubi write ...
we can only write ubi volumes ... and we want here to burn an ubi image,
which was created with ubinize and contains one or more ubi volumes.
Maybe usecase for updating ubi volumes:
ubivolumename | img | nand | 0 | 3| ubivol | - | - |
If you want to update an ubivolume ...
results in this steps:
- get image per dfu @ img_addr
We need to get here the complete image, as ubi write
cannot write incremental ...
- ubi part get_mtd_partition_name(Dev_part=3) vid_header_offset
^
From where get we this
parameter ...
value in start?
- ubi write img_addr ubivolumename ${filesize}
command | cmd | -| - | - | - | - | - |
[*] - support for sending command via DFU (see below)
[**] - - - indicates that no value is provided for this field.
Despite of that it is mandatory to facilitate parsing.
Please share any possible use cases - for now and for the future. My
goal is to devise dfu_alt_info structure which would work for us for a
long time.
After setting up new format, it would be possible to replace different
dfu command variations (i.e. dfu mmc 0, dfu nand) with only one command
dfu.
DFU extension - Command execution.
As a follow up I plan to add support for sending file filled with
command[s]. This would provide interface for automated tests and
force board to reset itself after emulated reset command from dfu-util
program.
dfu_alt_info = command cmd - - - - - -;
and then on host:
dfu-util -aN -D file_with_commands
The end step would be to extend dfu-util to support -C switch, which
would allow to send u-boot command quoted as text:
dfu-util -aN -C reset
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] arm: at91sam9n12: change EBI IO to high drive mode
Hi Albert, On 07/17/2013 06:10 PM, Albert ARIBAUD wrote: Hi Bo, On Wed, 17 Jul 2013 17:14:17 +0800, Bo Shen voice.s...@atmel.com wrote: As both the DDR SDRAM and NAND flash connect to EBI on at91sam9n12 and share the lower 8 bits data line. If use low drive of the data line, it will cause DDR data access corrupt in lower address, so change the data line to high drive mode This will fix the Linux kernel boot issue when use Lower address Wait--does this mean that there is no separate chip selects for NAND and DDR on this SoC? No. The NAND and DDR has there own chip selects. This is chip specific. If DDR and NAND share data line, if we use low drive for EBI IO, it will cause DDR low memory address content corrupt. For example, if the DDR base address is 0x2000, if we use 0x20008000 as entry address of Linux kernel, then it won't boot up successfully. So, if we need to use low memory address, we need this to fix. Amicalement, Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: at91sam9n12: change EBI IO to high drive mode
Hi Bo, On Wed, 17 Jul 2013 18:27:29 +0800, Bo Shen voice.s...@atmel.com wrote: Hi Albert, On 07/17/2013 06:10 PM, Albert ARIBAUD wrote: Hi Bo, On Wed, 17 Jul 2013 17:14:17 +0800, Bo Shen voice.s...@atmel.com wrote: As both the DDR SDRAM and NAND flash connect to EBI on at91sam9n12 and share the lower 8 bits data line. If use low drive of the data line, it will cause DDR data access corrupt in lower address, so change the data line to high drive mode This will fix the Linux kernel boot issue when use Lower address Wait--does this mean that there is no separate chip selects for NAND and DDR on this SoC? No. The NAND and DDR has there own chip selects. This is chip specific. If DDR and NAND share data line, if we use low drive for EBI IO, it will cause DDR low memory address content corrupt. For example, if the DDR base address is 0x2000, if we use 0x20008000 as entry address of Linux kernel, then it won't boot up successfully. So, if we need to use low memory address, we need this to fix. I understand the symptom. What I don't undestand is how come NAND does not keep its data lines in high impedance when its chip select is inactive, which it is when DDR is being accessed. Best Regards, Bo Shen Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: at91sam9n12: change EBI IO to high drive mode
On Jul 17, 2013, at 6:42 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: I understand the symptom. What I don't undestand is how come NAND does not keep its data lines in high impedance when its chip select is inactive, which it is when DDR is being accessed. Chip selects prevent contention but they do not make the load vanish. A deselected chip is not electrically the same as a non-populated chip, especially at high frequencies. Think of it another way. CMOS pins that are input-only are always high-z but they still must be counted as a load when adding up the fan out seen by the upstream output driver. -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/8] arm: spl: Do not set the stack pointer twice
Because the stack pointer is already set in arch/arm/lib/crt0.S,
we do not need to set it in arch/arm/lib/spl.c.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
arch/arm/lib/spl.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/lib/spl.c b/arch/arm/lib/spl.c
index 301f082..b5a1324 100644
--- a/arch/arm/lib/spl.c
+++ b/arch/arm/lib/spl.c
@@ -41,9 +41,6 @@ gd_t gdata __attribute__ ((section(.data)));
*/
void __weak board_init_f(ulong dummy)
{
- /* Set the stack pointer. */
- asm volatile(mov sp, %0\n : : r(CONFIG_SPL_STACK));
-
/* Clear the BSS. */
memset(__bss_start, 0, __bss_end - __bss_start);
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: spl: Do not set the stack pointer twice
Because the stack pointer is already set in arch/arm/lib/crt0.S,
we do not need to set it in arch/arm/lib/spl.c.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
arch/arm/lib/spl.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/lib/spl.c b/arch/arm/lib/spl.c
index 301f082..b5a1324 100644
--- a/arch/arm/lib/spl.c
+++ b/arch/arm/lib/spl.c
@@ -41,9 +41,6 @@ gd_t gdata __attribute__ ((section(.data)));
*/
void __weak board_init_f(ulong dummy)
{
- /* Set the stack pointer. */
- asm volatile(mov sp, %0\n : : r(CONFIG_SPL_STACK));
-
/* Clear the BSS. */
memset(__bss_start, 0, __bss_end - __bss_start);
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] arm: spl: Do not set the stack pointer twice
Re: [PATCH 2/8] arm: spl: Do not set the stack pointer twice The subject prefix [PATCH 2/8] is wrong. (My misoperation of git format-patch) This is composed of only one patch file. I have just post the correct version. Please delete this thread or just ignore. Sorry for noise. Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] failed to boot an compressed u-boot.bin
Hi, experts: I tried to add a self-compressed header in u-boot.bin on a Cortex-A9 single core platform. Then, i tried to boot it. But failed in board_init_f() function. Has anybody tried to boot a self-compressed u-boot.bin ? Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] failed to boot an compressed u-boot.bin
Hi, experts: Sorry! Not self-compressed, it is self-uncompressed ! -- I tried to add a self-uncompressed header in u-boot.bin on a Cortex-A9 single core platform. Then, i tried to boot it. But failed in board_init_f() function. Has anybody tried to boot a self-uncompressed u-boot.bin ? Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] README.mx28_common: Rename it to README.mxs
Hi Tom, On Wed, Jul 17, 2013 at 7:08 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Could we have this one applied into 2013.07? I am not sure why the file rename didn't take effect, as the original patch handled it: http://patchwork.ozlabs.org/patch/241363/ mmhh..I think we are too late for it, Tom is putting the release out. Albert, do you still plan a PR and if yes could you pick up directly this fix to the documentation ? Hmm... I have sent out my pull request and I don't plan any before release now; even if I picked it up, I'd have to PR to Tom for it to go into 2013.07 -- if Tom agrees. And if he agrees, then it is quicker that Tom pick it up directly. This is, after all, a simple rename of a documentation file, with zero impact on functionality. Could you please apply this patch directly? Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: at91sam9n12: change EBI IO to high drive mode
Hi Michael, On Wed, 17 Jul 2013 07:27:36 -0400, Michael Cashwell mboa...@prograde.net wrote: On Jul 17, 2013, at 6:42 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: I understand the symptom. What I don't undestand is how come NAND does not keep its data lines in high impedance when its chip select is inactive, which it is when DDR is being accessed. Chip selects prevent contention but they do not make the load vanish. A deselected chip is not electrically the same as a non-populated chip, especially at high frequencies. Think of it another way. CMOS pins that are input-only are always high-z but they still must be counted as a load when adding up the fan out seen by the upstream output driver. They must be counted as load alright, I understand this. But that leaves / leads to some questions: - how come the issue never appeared so far? If this is so basic a problem, I would have expected it to show up as soon as the SoC gets frequent use. - doesn't the driving lines' fan-out take this load into account? Again, I would expect a device's drive to be strong enough to overcome a few Hi-Zs, since that's an expected type of load. - why is the issue not symmetric? Techno's CMOS or CMOS-like, I guess, so there is no reason to pull up rather than down. Unless there are pulldowns in the NAND or elsewhere, but then it's not Hi-Z any more. -Mike Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] failed to boot an compressed u-boot.bin
Hi tiger...@viatech.com.cn, On Wed, 17 Jul 2013 19:53:10 +0800, tiger...@viatech.com.cn wrote: Hi, experts: Sorry! Not self-compressed, it is self-uncompressed ! -- I tried to add a self-uncompressed header in u-boot.bin on a Cortex-A9 single core platform. Then, i tried to boot it. But failed in board_init_f() function. Has anybody tried to boot a self-uncompressed u-boot.bin ? Best wishes, IIUC, you then load that header + u-boot.bin in memory and it decompresses itself. At what address does it place the uncompressed load? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] am335x_evm: Add support to boot from NOR.
On 11/07/13 14:06, Mark Jackson wrote: On 18/06/13 13:11, Mark Jackson wrote: On 17/06/13 15:43, Mark Jackson wrote: On 13/05/13 19:28, Tom Rini wrote: From: Steve Kipisz s-kipi...@ti.com NOR requires that s_init be within the first 4KiB of the image so that we can perform the rest of the required pinmuxing to talk with the rest of NOR that we are found on. When NOR_BOOT is set we save our environment in NOR at 512KiB and a redundant copy at 768KiB. We avoid using SPL for this case and u-boot.bin is written directly to the start of NOR. I'm trying to get this up and running our NanoBone platform, but I'm having no success. Just an update ... I now have it working ... yay !! The main (and possibly the *only*) culprit was that SYSBOOT[8] (which selects 8/16bit mode) was being incorrectly influenced by a hardware fault. I have pulled quite a few patches from various places, some of which might not be required. Now I have a working base, I'll work out what is needed on top of Tom's original patch set. Okay ... I've now got NOR booting rebased to master using the patch set below. This doesn't include my board code as that's of no interest until NOR booting is added to the mainline code. Sorry, Tom, I'm no git expert, so I'm not sure how to compare this to your previous patches ... I hope this is useful in some way ?? Tom ... any idea when NOR booting will be merged into the mainline code ? I'm keen to get our NanoBone board support added. Cheers Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] am335x_evm: Add support to boot from NOR.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/17/2013 08:58 AM, Mark Jackson wrote: On 11/07/13 14:06, Mark Jackson wrote: On 18/06/13 13:11, Mark Jackson wrote: On 17/06/13 15:43, Mark Jackson wrote: On 13/05/13 19:28, Tom Rini wrote: From: Steve Kipisz s-kipi...@ti.com NOR requires that s_init be within the first 4KiB of the image so that we can perform the rest of the required pinmuxing to talk with the rest of NOR that we are found on. When NOR_BOOT is set we save our environment in NOR at 512KiB and a redundant copy at 768KiB. We avoid using SPL for this case and u-boot.bin is written directly to the start of NOR. I'm trying to get this up and running our NanoBone platform, but I'm having no success. Just an update ... I now have it working ... yay !! The main (and possibly the *only*) culprit was that SYSBOOT[8] (which selects 8/16bit mode) was being incorrectly influenced by a hardware fault. I have pulled quite a few patches from various places, some of which might not be required. Now I have a working base, I'll work out what is needed on top of Tom's original patch set. Okay ... I've now got NOR booting rebased to master using the patch set below. This doesn't include my board code as that's of no interest until NOR booting is added to the mainline code. Sorry, Tom, I'm no git expert, so I'm not sure how to compare this to your previous patches ... I hope this is useful in some way ?? Tom ... any idea when NOR booting will be merged into the mainline code ? I've been working this week on things, and I'm hopeful about re-posting the series today. The only minor issue I have is that calling save_omap_boot_params and the asm() bits for finishing NOR pinmux seem to conflict and leave me in a bad state. But, since we don't make use of the boot_params info yet in full U-Boot, that's not a blocker to me. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR5pz8AAoJENk4IS6UOR1WVjgP/AjmJE/HMX5MGhR4xUYmr8ae XOJRJmwHhw6Y+nJdiwNwoVJtdA4xQErwtLGJvFvRVqocKJZGJvhHtu0BnnilsAQQ e9eyC4l1kGowSV2HPLVGjkxpgRSSPxo8fGXVw1DBOE12mcAh2U75QvONZwcG6L/w ZW/d1E97pCL0Wfunj6/QA3BJROpzNnRbmGsMpTp+l/2HES7xHwVf5WLl+aUB/Zy7 VtKHc61XUHYLxvGAisaruPZfhJMfT0cCNc7XAB/HvZGYrSX4ed/XVWZr5FouGV42 yx0grjihAfd+JLSN1wIvtSFxdGw/y3fGJ6lOXsBI9D4k07JE7AHniQg4o+VQM6Fw 9/z17d4wm6BR2zwBdSnjek24OTM3bBzGjYkcQHJEwghzyQgglifbX7emDCqvObvb kRidZ8WqHlVbbKi69namInZ1f5tgoFbRlTdpxKpXxEUuArRJQwFoPTWKoVeANJjE ToltaHJa1g9Yqr2fI17Y8K2cjFeEid/64/Yd3LLtJFN22jsFetc1nJj/INkZI1CU QPgB445+eWiZWVae8PUXyaH8CKkMCa4pYilY+l2JQJAG1aCr0yPP7+1706LheQKY 3qjLsb9jCNLoZ/Sn+jZg4VgK3LfDhp0CyVZafeRQbjGfhuqAT3QBdXi9biBN81zl EvoUyWaSmbQkzq53xFs6 =+Uko -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot x86 coreboot
Basically, should the coreboot-x86_config replace the use of coreboot ? Or, is coreboot still necessary? -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Rossier Daniel Sent: mercredi 17 juillet 2013 10:29 To: u-boot@lists.denx.de Subject: [U-Boot] U-boot x86 coreboot Hi, I would like to run U-boot on x86 emulated QEMU-based environment. I found some info regarding coreboot + U-boot integration, using U-boot as payload, etc. but I was unable to start U-boot. I'm using the 32-bits i686-pc-linux-gnu toolchain and I successfully cross- compiled coreboot and started it on qemu-system-i386. I also configured coreboot to use u-boot (ELF) as payload, but coreboot performs a reset when U-boot should show up after loading. Where could I have some information regarding that? Furthermore, I'm unable to debug anything remotely with gdb; gdb cannot disassemble once connected via target remote localhost:1234. Any hints welcome. Thanks so much. Cheers Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] i.MX6 DRAM_RESET documentation
On 07/16/2013 07:28 PM, Liu Hui-R64343 wrote: -Original Message- From: Troy Kisky [mailto:troy.ki...@boundarydevices.com] snip The working code uses a value of 00b for this field. When I changed it to 11b, things broke. In the documentation, this register is defined differently for mx6q vs mv6solo/duallite. The duallite way works for the quad, and either way works for the duallite. board/boundary/nitrogen6x/ddr-setup.cfg:DATA 4, MX6_IOM_DRAM_RESET, 0x000e0030 board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg:DATA 4 0x020e057c 0x00020030 Who's right? And should it depend on quad vs duallite ? Currently, I believe that the duallite documentation is correct for all. Both are not correct. The MMDC owner has known about this doc issue and will Update them later. The correct is: 00 is the only valid data, others will be Reserved. Thank you very much for the concise and definitive reply. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][DFU] Unification of dfu_alt_info alt settings description + command execution
On Wed, 17 Jul 2013 12:26:35 +0200 Heiko Schocher h...@denx.de wrote,
Hi Heiko,
Hello Lukasz,
Am 16.07.2013 17:35, schrieb Lukasz Majewski:
Dear All,
Since DFU usage at u-boot is spreading to different device types
(MMC, NAND), file systems, raw partitions, ubi, etc, I think that
it is a good moment to unify and structure the form of dfu_alt_info
environment variable.
Full Ack!
Proposed new format for single dfu entity:
NAME | Type | Device | Dev_num | Dev_part | FS | start |
size |
where:
Name - name of the alt setting (as seen by dfu-util -l)
Type - description of the image (raw, file, img, command [*])
Device - physical device on which data are stored (mmc, nand, -)
Dev_num - number of the device - it is possible to store data via
DFU on several devices of the same type.
Dev_part - number of partitions on the device.
Should this be number of the partition on the device
No. I made a mistake. It should be partition to which we want to write
You mean here the mtd partition for storing, right?
Yes, number of the partition to store data. The exact address will be
extracted from mtdparts or partitions env variable.
FS - information about file system on the device (fat,
ext2/ext4, ubi).
start- start offset from the beginning of the Device (byte or
LBA number addressed)
size - maximal number of blocks to be stored on the Device
(expressed with Bytes of LBA number) (protection from
overwriting the whole device)
Example:
Maybe dummy questions ...
NAME | Type | Device | Dev_num | Dev_part | FS | start |
size |
--
u-boot | raw | mmc| 0 | - [**] | - | 0x80 |
0x100 | uImage | file | mmc| 0 | 2| ext4 |
- | - |
Is this enough information? Where to store the uImage file on the ext4
partition?
To store uImage file on ext4/fat/ext2 partition it is enough to only
give:
uImage mmc 0 2,
which maps to the following command:
ext4write mmc 0:2 0x4400 /uImage [size]
The file size is taken from number of sent bytes via DFU/USB.
With writing to file system, one need to first store the whole
transmitted data to a buffer and then store the (big) buffer on the
SD/eMMC device.
Since, we aren't supporting seek kind of write to current ext4
implementation at u-boot, the big buffer must be used.
root.img | img | mmc| 0 | 5| - | - |
- |
img means here: getting an image and storing it on the mtd partition
Dev_part if start and size are marked with -, beginning
on start of the partition?
No, here img is for example a rootfs image. When storing it on the
eMMC, it would be better to specify destination partition.
Wouldn't it be better to use here mtd partition names instead
numbers for Dev_part?
I'd prefer to create a new entrance here (Part_name):
NAME | Type | Device | Dev_num | Dev_part | Part_name | FS | start |
size |
I would like to avoid situation with ambiguous fields. One field
shall only serve for one (clear) purpose. When not needed/used - field
shall be marked as -.
What if start and size are filled with values for the Type
img? Or is this forbidden for the Type img?
I think, that each Type shall have predefined set of allowed
attributes:
1. img: Device + Dev num + Dev parts
2. raw: Device + Dev num + start + size
3. file: Device + Dev num + Dev parts + FS
and so on.
root.img | raw | mmc| 0 | - | - | 0x1000|
0x4000|
u-boot | raw | nand | 0 | - | - | 0x100 |
0x100 | uImage | file | nand | 0 | 3| ubi |
- | - |
s/uImage/rootfs.img ? s/file/img ?
NAME: uImage and rootfs.img maps to files sent to board.
The NAME is used thereafter to provide exact name for file system
write (ext4write/ fatwrite).
With DFU the distinction between dfu entities (files, raw images, etc)
is performed via alt settings (-aX switch at dfu-util).
For the FS ubi we need to specify, how to burn this into nand.
I think we have no ubi format command.
Is already ubi format command available at u-boot?
_As a side note:_
I'm now developing proof-of-concept idea of executing set of commands
sent to u-boot by dfu-util [***].
Rationale for this is the lack of ability to reset u-boot after sending
data to u-boot via DFU. dfu-util has -R option, but this seems to reset
usb interface, not the target device.
I will set an env:
setenv dfu dfu mmc 0;${dfu_commands}
Then at dfu itself, I will read commands to be performed. Then I will
set $dfu_commands env and exit from dfu command.
With ubi write ...
we can only write ubi volumes ... and we want here to burn an ubi
image, which was created with ubinize and contains one or more ubi
volumes
Maybe usecase for updating ubi volumes:
ubivolumename | img | nand | 0 | 3| ubivol | -
Re: [U-Boot] [PATCH] README.mx28_common: Rename it to README.mxs
On Fri, Jul 12, 2013 at 01:49:49PM +0200, Marek Vasut wrote:
Dear Fabio Estevam,
From: Fabio Estevam fabio.este...@freescale.com
commit 54965b61360 (README: mxs: Introduce README.mxs) should have changed
the file name to README.mxs, as it covers both mx23 and mx28 now.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
doc/{README.mx28_common = README.mxs} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename doc/{README.mx28_common = README.mxs} (100%)
diff --git a/doc/README.mx28_common b/doc/README.mxs
similarity index 100%
rename from doc/README.mx28_common
rename to doc/README.mxs
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] [PATCH 1/3] bootm: Move fixup_silent_linux() earlier in the bootm stages
On Tue, Jul 16, 2013 at 08:09:59PM -0700, Simon Glass wrote: Before the bootm refactor, fixup_silent_linux() was done only in the monolithic bootm case, not in the subcommand case. With the refactor, it is done always, which is good. Unfortunately it is done too late, since it is the PREP or CMDLINE stages that set up the command line for Linux. Move fixup_silent_linux() into the LOADOS stage, which is where we find out the OS being used, and can thus decide whether to perform this step. 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] Please pull u-boot-mpc85xx.git
On Tue, Jul 16, 2013 at 06:30:20PM -0500, Andy Fleming wrote: arm:samsung:trats:fix: Restore proper orientation of TRATS's LCD panel (2013-07-16 09:20:16 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-mpc85xx.git master for you to fetch changes up to 2a6936059a1f393d828274bf5d33dd54c0a3c882: powerpc/mpc85xx:Disable Debug TLB entry for non-minimal SPL (2013-07-16 17:44:30 -0500) Dirk Eibach (3): Add Atmel I2C tpm Build arch/$ARCH/lib/bootm.o depending on CONFIG_CMD_BOOTM mpc85xx: Add gdsys ControlCenter Digital board Prabhakar Kushwaha (1): powerpc/mpc85xx:Disable Debug TLB entry for non-minimal SPL Reinhard Pfau (2): tpm: add AUTH1 cmds for LoadKey2 and GetPubKey i2c: fsl_i2c: i2c_read(): dont try to write address w/ alen=0 MAINTAINERS |3 +- README| 17 + arch/arm/lib/Makefile |2 +- arch/avr32/lib/Makefile |2 +- arch/m68k/lib/Makefile|2 +- arch/microblaze/lib/Makefile |2 +- arch/mips/lib/Makefile|4 +- arch/nds32/lib/Makefile |3 +- arch/nios2/lib/Makefile |2 +- arch/openrisc/lib/Makefile|2 +- arch/powerpc/cpu/mpc85xx/cpu_init_early.c |4 +- arch/powerpc/lib/Makefile |2 +- arch/sh/lib/Makefile |2 +- arch/sparc/lib/Makefile |3 +- arch/x86/lib/Makefile |2 +- board/gdsys/common/Makefile |1 + board/gdsys/common/dp501.c| 107 +++ board/gdsys/common/dp501.h| 30 + board/gdsys/p1022/Makefile| 37 + board/gdsys/p1022/controlcenterd-id.c | 1224 + board/gdsys/p1022/controlcenterd-id.h | 29 + board/gdsys/p1022/controlcenterd.c| 425 ++ board/gdsys/p1022/ddr.c | 71 ++ board/gdsys/p1022/diu.c | 87 ++ board/gdsys/p1022/law.c | 20 + board/gdsys/p1022/sdhc_boot.c | 63 ++ board/gdsys/p1022/tlb.c | 77 ++ boards.cfg|4 + common/cmd_tpm.c | 100 +++ drivers/i2c/fsl_i2c.c |9 +- drivers/tpm/Makefile |1 + drivers/tpm/tpm_atmel_twi.c | 121 +++ include/configs/controlcenterd.h | 522 include/tpm.h | 174 lib/tpm.c | 351 - 35 files changed, 3486 insertions(+), 19 deletions(-) create mode 100644 board/gdsys/common/dp501.c create mode 100644 board/gdsys/common/dp501.h create mode 100644 board/gdsys/p1022/Makefile create mode 100644 board/gdsys/p1022/controlcenterd-id.c create mode 100644 board/gdsys/p1022/controlcenterd-id.h create mode 100644 board/gdsys/p1022/controlcenterd.c create mode 100644 board/gdsys/p1022/ddr.c create mode 100644 board/gdsys/p1022/diu.c create mode 100644 board/gdsys/p1022/law.c create mode 100644 board/gdsys/p1022/sdhc_boot.c create mode 100644 board/gdsys/p1022/tlb.c create mode 100644 drivers/tpm/tpm_atmel_twi.c create mode 100644 include/configs/controlcenterd.h Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mmc.git
On Tue, Jul 16, 2013 at 07:08:48PM -0500, Andy Fleming wrote: The following changes since commit baa8841d6cc8a8cb79e0aee2fe1b360dacc05aaf: arm:samsung:trats:fix: Restore proper orientation of TRATS's LCD panel (2013-07-16 09:20:16 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-mmc.git master for you to fetch changes up to a61da72bda80e09f36afbc9037a8c8b63b482de4: fsl_esdhc: Touch only relevant sys ctrl bits (2013-07-16 18:44:23 -0500) Alexey Brodkin (1): drivers/mmc/dw_mmc - remove extra arch specific asm/arch/clk.h inclusion Dirk Behme (1): fsl_esdhc: Touch only relevant sys ctrl bits Haijun.Zhang (1): Powerpc: eSDHC: Fix mmc read write err in uboot of T4240QDS board drivers/mmc/dw_mmc.c|1 - drivers/mmc/fsl_esdhc.c |8 2 files changed, 4 insertions(+), 5 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] Please pull u-boot-mpc85xx.git
On Tue, Jul 16, 2013 at 06:30:20PM -0500, Andy Fleming wrote: arm:samsung:trats:fix: Restore proper orientation of TRATS's LCD panel (2013-07-16 09:20:16 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-mpc85xx.git master for you to fetch changes up to 2a6936059a1f393d828274bf5d33dd54c0a3c882: powerpc/mpc85xx:Disable Debug TLB entry for non-minimal SPL (2013-07-16 17:44:30 -0500) Dirk Eibach (3): Add Atmel I2C tpm Build arch/$ARCH/lib/bootm.o depending on CONFIG_CMD_BOOTM mpc85xx: Add gdsys ControlCenter Digital board Prabhakar Kushwaha (1): powerpc/mpc85xx:Disable Debug TLB entry for non-minimal SPL Reinhard Pfau (2): tpm: add AUTH1 cmds for LoadKey2 and GetPubKey i2c: fsl_i2c: i2c_read(): dont try to write address w/ alen=0 MAINTAINERS |3 +- README| 17 + arch/arm/lib/Makefile |2 +- arch/avr32/lib/Makefile |2 +- arch/m68k/lib/Makefile|2 +- arch/microblaze/lib/Makefile |2 +- arch/mips/lib/Makefile|4 +- arch/nds32/lib/Makefile |3 +- arch/nios2/lib/Makefile |2 +- arch/openrisc/lib/Makefile|2 +- arch/powerpc/cpu/mpc85xx/cpu_init_early.c |4 +- arch/powerpc/lib/Makefile |2 +- arch/sh/lib/Makefile |2 +- arch/sparc/lib/Makefile |3 +- arch/x86/lib/Makefile |2 +- board/gdsys/common/Makefile |1 + board/gdsys/common/dp501.c| 107 +++ board/gdsys/common/dp501.h| 30 + board/gdsys/p1022/Makefile| 37 + board/gdsys/p1022/controlcenterd-id.c | 1224 + board/gdsys/p1022/controlcenterd-id.h | 29 + board/gdsys/p1022/controlcenterd.c| 425 ++ board/gdsys/p1022/ddr.c | 71 ++ board/gdsys/p1022/diu.c | 87 ++ board/gdsys/p1022/law.c | 20 + board/gdsys/p1022/sdhc_boot.c | 63 ++ board/gdsys/p1022/tlb.c | 77 ++ boards.cfg|4 + common/cmd_tpm.c | 100 +++ drivers/i2c/fsl_i2c.c |9 +- drivers/tpm/Makefile |1 + drivers/tpm/tpm_atmel_twi.c | 121 +++ include/configs/controlcenterd.h | 522 include/tpm.h | 174 lib/tpm.c | 351 - 35 files changed, 3486 insertions(+), 19 deletions(-) create mode 100644 board/gdsys/common/dp501.c create mode 100644 board/gdsys/common/dp501.h create mode 100644 board/gdsys/p1022/Makefile create mode 100644 board/gdsys/p1022/controlcenterd-id.c create mode 100644 board/gdsys/p1022/controlcenterd-id.h create mode 100644 board/gdsys/p1022/controlcenterd.c create mode 100644 board/gdsys/p1022/ddr.c create mode 100644 board/gdsys/p1022/diu.c create mode 100644 board/gdsys/p1022/law.c create mode 100644 board/gdsys/p1022/sdhc_boot.c create mode 100644 board/gdsys/p1022/tlb.c create mode 100644 drivers/tpm/tpm_atmel_twi.c create mode 100644 include/configs/controlcenterd.h 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 x86 coreboot
Hi Rossier, On Wed, Jul 17, 2013 at 2:29 AM, Rossier Daniel daniel.ross...@heig-vd.chwrote: Hi, I would like to run U-boot on x86 emulated QEMU-based environment. I found some info regarding coreboot + U-boot integration, using U-boot as payload, etc. but I was unable to start U-boot. I'm using the 32-bits i686-pc-linux-gnu toolchain and I successfully cross-compiled coreboot and started it on qemu-system-i386. I also configured coreboot to use u-boot (ELF) as payload, but coreboot performs a reset when U-boot should show up after loading. Where could I have some information regarding that? There are post codes generated in x86 U-Boot which might help with diagnosing this. I have not tried this on QEMU. But I suppose in that environment it might be possible to watch execution and see where it is going wrong. Furthermore, I'm unable to debug anything remotely with gdb; gdb cannot disassemble once connected via target remote localhost:1234. Do you mean it cannot find the source files? Regards, Simon Any hints welcome. Thanks so much. Cheers Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot x86 coreboot
Hi Rossier, On Wed, Jul 17, 2013 at 7:35 AM, Rossier Daniel daniel.ross...@heig-vd.chwrote: Basically, should the coreboot-x86_config replace the use of coreboot ? Or, is coreboot still necessary? Yes coreboot is still necessary - it does the memory init and most of the machine-specific stuff. -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Rossier Daniel Sent: mercredi 17 juillet 2013 10:29 To: u-boot@lists.denx.de Subject: [U-Boot] U-boot x86 coreboot Hi, I would like to run U-boot on x86 emulated QEMU-based environment. I found some info regarding coreboot + U-boot integration, using U-boot as payload, etc. but I was unable to start U-boot. I'm using the 32-bits i686-pc-linux-gnu toolchain and I successfully cross- compiled coreboot and started it on qemu-system-i386. I also configured coreboot to use u-boot (ELF) as payload, but coreboot performs a reset when U-boot should show up after loading. Where could I have some information regarding that? Furthermore, I'm unable to debug anything remotely with gdb; gdb cannot disassemble once connected via target remote localhost:1234. Any hints welcome. Thanks so much. Cheers Daniel Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Dear Marek,
On 07/16/2013 06:44 AM, Marek Vasut wrote:
Dear Fabio Estevam,
On Tue, Jul 16, 2013 at 12:51 AM, Fabio Estevam feste...@gmail.com wrote:
On Mon, Jul 15, 2013 at 12:09 PM, Hector Palacios
hector.palac...@digi.com wrote:
@Fabio: could you manually run the command 'tftp ${loadaddr} file100M'
in your EVK?
Yes, this is what I have been running since the beginning.
If it doesn't fail, could you try running it again after playing with
the environment (setting/printing some variables).
I can't reproduce the problem here.
As I said, this issue appeared with different TFTP servers and is
independent of whether the dcache is or not enabled.
Can you transfer from a PC to another PC via TFTP?
Yes I can.
Another thing of interest would be a 'tcpdump' pcap capture of that connection.
I was initially filtering out only TFTP packets of my wireshark trace and all looked
correct. After taking a second look to the full trace I see now a hint.
Around 7 seconds after starting the TFTP transfer the server is sending an ARP to the
target asking for the owner of the target's IP. The target is receiving this ARP and
apparently responding (at least this is what my debug code shows as it gets into
arp.c:ArpReceive(), case ARPOP_REQUEST and sending a packet), but this ARP reply from
the target is not reaching the network. My sniffer does not capture this reply.
The server resends the ARP request twice more (seconds 8 and 9) to the target and
since it doesn't get a reply then sends a broadcast ARP (seconds 10) asking who has
that IP. Since nobody responds it stops sending data.
The times that it works (and I don't know the magic behind using a numeric address
versus using ${loadaddr} when they have the same value), the ARP replies do reach the
network and the server continues the transmission normally.
Using a v2009 U-Boot, the behaviour is exactly the same, but the target's ARP replies
always reach the network, and the transfers always succeed.
Since Fabio cannot reproduce it I guess it must be a local ghost. :o(
Best regards,
--
Hector Palacios
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] board/ti/am335x/README: Document NAND programming
The AM335x GP EVM ships with NAND. Document programming of the chip
including the redundant locations that the ROM will check.
Signed-off-by: Tom Rini tr...@ti.com
---
board/ti/am335x/README | 25 +
1 file changed, 25 insertions(+)
diff --git a/board/ti/am335x/README b/board/ti/am335x/README
index ccc5e16..3444d7e 100644
--- a/board/ti/am335x/README
+++ b/board/ti/am335x/README
@@ -13,6 +13,31 @@ documented in TI's reference designs:
- AM335x EVM SK
- Beaglebone White
- Beaglebone Black
+'
+NAND
+
+
+The AM335x GP EVM ships with a 256MiB NAND available in most profiles. In
+this example to program the NAND we assume that an SD card has been
+inserted with the files to write in the first SD slot and that mtdparts
+have been configured correctly for the board. As a time saving measure we
+load MLO into memory in one location, copy it into the three locatations
+that the ROM checks for additional valid copies, then load U-Boot into
+memory. We then write that whole section of memory to NAND.
+
+U-Boot # mmc rescan
+U-Boot # env default -f -a
+U-Boot # nand erase.chip
+U-Boot # saveenv
+U-Boot # load mmc 0 8100 MLO
+U-Boot # cp.b 8100 8102 2
+U-Boot # cp.b 8100 8104 2
+U-Boot # cp.b 8100 8106 2
+U-Boot # load mmc 0 8108 u-boot.img
+U-Boot # nand write 8100 0 26
+U-Boot # load mmc 0 ${loadaddr} uImage
+U-Boot # nand erase.part kernel
+U-Boot # nand write ${loadaddr} kernel 50
Falcon Mode
===
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/1] Add NAND to board/ti/am335x/README
The following depends on v2 of the Improve falcon mode and am335x_evm docs series, as that adds the README to start with. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: at91sam9n12: change EBI IO to high drive mode
On Jul 17, 2013, at 9:05 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Michael, On Wed, 17 Jul 2013 07:27:36 -0400, Michael Cashwell mboa...@prograde.net wrote: Chip selects prevent contention but they do not make the load vanish. A deselected chip is not electrically the same as a non-populated chip, especially at high frequencies. Think of it another way. CMOS pins that are input-only are always high-z but they still must be counted as a load when adding up the fan out seen by the upstream output driver. They must be counted as load alright, I understand this. But that leaves / leads to some questions: - how come the issue never appeared so far? If this is so basic a problem, I would have expected it to show up as soon as the SoC gets frequent use. Yes, agreed. It seems something changed. That needs to be understood. - doesn't the driving lines' fan-out take this load into account? Again, I would expect a device's drive to be strong enough to overcome a few Hi-Zs, since that's an expected type of load. Setting the drive strength in the CPU is how fan out is accounted for. (And I've seen similar settings in DDR chip so their drive is right going the other way.) In cases like this where it's adjustable the goal is to use the lowest drive level that covers the fan out. Too high wastes power and generates heat. Too low is unreliable. - why is the issue not symmetric? Techno's CMOS or CMOS-like, I guess, so there is no reason to pull up rather than down. Unless there are pulldowns in the NAND or elsewhere, but then it's not Hi-Z any more. I'm not sure what symmetry you mean. Very weak pulls are normal to avoid floating lines which can cause damage to CMOS inputs. But these are in the 100KΩ range. That shouldn't count more than one load. Strong pulls built into devices are a problem when connected in parallel. But again, it all does beg the question of what changed. -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] i.MX6 DRAM_RESET documentation
On 7/17/2013 7:17 AM, Eric Nelson wrote: On 07/16/2013 07:28 PM, Liu Hui-R64343 wrote: -Original Message- From: Troy Kisky [mailto:troy.ki...@boundarydevices.com] snip The working code uses a value of 00b for this field. When I changed it to 11b, things broke. In the documentation, this register is defined differently for mx6q vs mv6solo/duallite. The duallite way works for the quad, and either way works for the duallite. board/boundary/nitrogen6x/ddr-setup.cfg:DATA 4, MX6_IOM_DRAM_RESET, 0x000e0030 board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg:DATA 4 0x020e057c 0x00020030 Who's right? And should it depend on quad vs duallite ? Currently, I believe that the duallite documentation is correct for all. Both are not correct. The MMDC owner has known about this doc issue and will Update them later. The correct is: 00 is the only valid data, others will be Reserved. Thank you very much for the concise and definitive reply. Yes, thank you. I will send a patch for board/boundary/nitrogen6x/ddr-setup.cfg to match board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg Troy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] nds32: Enable FPU if the version of CPU supported
Some version of Andes core support FPU coprocessor, if this is the case, we should enable it at low level initialization time. Signed-off-by: Kuan-Yu Kuo ken.ku...@gmail.com Cc: Macpaul Lin macp...@gmail.com --- arch/nds32/cpu/n1213/ag101/lowlevel_init.S | 22 ++ arch/nds32/cpu/n1213/ag102/lowlevel_init.S | 22 ++ 2 files changed, 44 insertions(+) diff --git a/arch/nds32/cpu/n1213/ag101/lowlevel_init.S b/arch/nds32/cpu/n1213/ag101/lowlevel_init.S index 55985cf..b4c2b0f 100644 --- a/arch/nds32/cpu/n1213/ag101/lowlevel_init.S +++ b/arch/nds32/cpu/n1213/ag101/lowlevel_init.S @@ -98,6 +98,9 @@ lowlevel_init: led 0x10 jal remap + led 0x1f + jal enable_fpu + led 0x20 ret $r10 @@ -234,6 +237,25 @@ relo_base: 2: ret + /* +* enable_fpu: +* Some of Andes CPU version support FPU coprocessor, if so, +* we should enable it. +*/ +enable_fpu: + mfsr$r0, $CPU_VER /* enable FPU if it exists */ + srli$r0, $r0, 3 + andi$r0, $r0, 1 + beqz$r0, 1f /* skip if no COP */ + mfsr$r0, $FUCOP_EXIST + srli$r0, $r0, 31 + beqz$r0, 1f /* skip if no FPU */ + mfsr$r0, $FUCOP_CTL + ori $r0, $r0, 1 + mtsr$r0, $FUCOP_CTL +1: + ret + .globl show_led show_led: li $r8, (CONFIG_DEBUG_LED) diff --git a/arch/nds32/cpu/n1213/ag102/lowlevel_init.S b/arch/nds32/cpu/n1213/ag102/lowlevel_init.S index d842afa..345f316 100644 --- a/arch/nds32/cpu/n1213/ag102/lowlevel_init.S +++ b/arch/nds32/cpu/n1213/ag102/lowlevel_init.S @@ -114,6 +114,9 @@ lowlevel_init: led 0x20 jal remap + led 0x2f + jal enable_fpu + led 0x30 ret $r10 @@ -289,6 +292,25 @@ relo_base: 2: ret + /* +* enable_fpu: +* Some of Andes CPU version support FPU coprocessor, if so, +* we should enable it. +*/ +enable_fpu: + mfsr$r0, $CPU_VER /* enable FPU if it exists */ + srli$r0, $r0, 3 + andi$r0, $r0, 1 + beqz$r0, 1f /* skip if no COP */ + mfsr$r0, $FUCOP_EXIST + srli$r0, $r0, 31 + beqz$r0, 1f /* skip if no FPU */ + mfsr$r0, $FUCOP_CTL + ori $r0, $r0, 1 + mtsr$r0, $FUCOP_CTL +1: + ret + .globl show_led show_led: li $r8, (CONFIG_DEBUG_LED) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC V1 00/18] Make mv_udc work for i.mx6
On 7/16/2013 8:04 PM, Marek Vasut wrote: Hi Troy, Hi Marek, Can you please base the series on top of my series I posted a while ago [1] ? I feel bad about asking you to, but that series was out earlier and I'm planning to apply it for next MW. Since it is 17 patches, do you have a branch I can pull from ? btw review would be nice ;-) Sure, I'll look through it. This series is based on your u-boot-testing/chipidea branch. After this series, nitrogen6x works with tftpboot to transfer files over usb. But I still cannot enable CONFIG_USB_TTY because of link errors. Ugh, USB TTY is not compatible with the new code, right? I use either netconsole or the right way would be to port g_serial from Linux 2.6.37 . Thanks for the direction. [1] http://patchwork.ozlabs.org/patch/257935/ Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to create a library with already built library
Thanks for the reply. Could you help with find the Makefile where it links the already built library? I tried to modify the main Makefile but it looks it tries to generate the library. Thanks, -- View this message in context: http://u-boot.10912.n7.nabble.com/How-to-create-a-library-with-already-built-library-tp159486p159554.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 RFC V1 00/18] Make mv_udc work for i.mx6
Dear Troy Kisky, On 7/16/2013 8:04 PM, Marek Vasut wrote: Hi Troy, Hi Marek, Can you please base the series on top of my series I posted a while ago [1] ? I feel bad about asking you to, but that series was out earlier and I'm planning to apply it for next MW. Since it is 17 patches, do you have a branch I can pull from ? Use this bundle : http://patchwork.ozlabs.org/bundle/marex/mvudc/ btw review would be nice ;-) Sure, I'll look through it. Thanks! This series is based on your u-boot-testing/chipidea branch. After this series, nitrogen6x works with tftpboot to transfer files over usb. But I still cannot enable CONFIG_USB_TTY because of link errors. Ugh, USB TTY is not compatible with the new code, right? I use either netconsole or the right way would be to port g_serial from Linux 2.6.37 . Thanks for the direction. [1] http://patchwork.ozlabs.org/patch/257935/ Best regards, Marek Vasut Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][DFU] Unification of dfu_alt_info alt settings description + command execution
On Wed, Jul 17, 2013 at 4:34 PM, Lukasz Majewski wrote: _As a side note:_ I'm now developing proof-of-concept idea of executing set of commands sent to u-boot by dfu-util [***]. Rationale for this is the lack of ability to reset u-boot after sending data to u-boot via DFU. dfu-util has -R option, but this seems to reset usb interface, not the target device. Actually, dfu-util -R sends a DFU_DETACH request before performing the USB reset. The reason for this was long unclear to me, until I looked at the uboot dfu code (inherited from openmoko): http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/usb/gadget/f_dfu.c;h=d7ae0c0c6a9f6a95ca3a702d92636eb25e21253c;hb=HEAD#l314 Proprietary extension: 'detach' from idle mode and get back to runtime mode in case of USB Reset. As much as I dislike this, we just can't use every USB bus reset to switch back to runtime mode, since at least the Linux USB stack likes to send a number of resets in a row :( The hack/abuse of sending a DFU_DETACH when in DFU mode is not part of the DFU standard, but dfu-util supports it since openmoko was for long the major target for dfu-util. If you don't need to switch back from DFU mode to runtime mode, maybe you can use this to reset u-boot? Regards, Tormod ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] ddr cfg: DRAM_RESET needs 0x00020030
The old value of 0x000e0030 will cause ethernet timeout issues on the sabrelite and possibly other boards using the KSZ9021. I have no explanation as to why. But this is a correct change, the TRM will be updated to show that 00b is the only valid setting for bits 19-18 of DRAM_RESET. My thanks go to Liu Hui(Jason) for this information. Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com --- board/boundary/nitrogen6x/ddr-setup.cfg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/boundary/nitrogen6x/ddr-setup.cfg b/board/boundary/nitrogen6x/ddr-setup.cfg index c315812..e5f8add 100644 --- a/board/boundary/nitrogen6x/ddr-setup.cfg +++ b/board/boundary/nitrogen6x/ddr-setup.cfg @@ -74,7 +74,7 @@ DATA 4, MX6_IOM_DRAM_RAS, 0x00020030 DATA 4, MX6_IOM_DRAM_SDCLK_0, 0x00020030 DATA 4, MX6_IOM_DRAM_SDCLK_1, 0x00020030 -DATA 4, MX6_IOM_DRAM_RESET, 0x000e0030 +DATA 4, MX6_IOM_DRAM_RESET, 0x00020030 DATA 4, MX6_IOM_DRAM_SDCKE0, 0x3000 DATA 4, MX6_IOM_DRAM_SDCKE1, 0x3000 -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 7/7] ARM: OMAP5-uevm: Add usb device reset API
Add the call back to reset the LAN9730 after
the FEAT_POWER has been called.
Signed-off-by: Dan Murphy dmur...@ti.com
---
v3 - Added this patch to separate the patch series -
http://patchwork.ozlabs.org/patch/258229/
board/ti/omap5_uevm/evm.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index 9add0fd..42253fd 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -31,6 +31,7 @@
#ifdef CONFIG_USB_EHCI
#include usb.h
+#include asm/gpio.h
#include asm/arch/ehci.h
#include asm/ehci-omap.h
@@ -169,4 +170,14 @@ int ehci_hcd_stop(void)
ret = omap_ehci_hcd_stop();
return ret;
}
+
+void usb_hub_reset_devices(int port)
+{
+ /* The LAN9730 needs to be reset after the port power has been set. */
+ if (port == 3) {
+ gpio_direction_output(CONFIG_OMAP_EHCI_PHY1_RESET_GPIO, 0);
+ udelay(10);
+ gpio_direction_output(CONFIG_OMAP_EHCI_PHY1_RESET_GPIO, 1);
+ }
+}
#endif
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/7] omap5: uevm: Change the board name to correct name
Change the board name for the sys info to
5432 uEVM
Signed-off-by: Dan Murphy dmur...@ti.com
---
v3 - No change - http://patchwork.ozlabs.org/patch/258226/
board/ti/omap5_uevm/evm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index 90046e8..00bd72d 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -32,7 +32,7 @@
DECLARE_GLOBAL_DATA_PTR;
const struct omap_sysinfo sysinfo = {
- Board: OMAP5430 EVM\n
+ Board: OMAP5432 uEVM\n
};
/**
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 6/7] USB: usb-hub: Add a weak function for resetting devices
Add a __weak function that can be overridden to reset devices
attached to an ehci devices after the FEAT_POWER has been submitted
Signed-off-by: Dan Murphy dmur...@ti.com
---
v3 - Modified location of the weak function -
http://patchwork.ozlabs.org/patch/258229/
common/usb_hub.c | 12
1 file changed, 12 insertions(+)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 774ba63..c655b75 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -62,6 +62,10 @@
static struct usb_hub_device hub_dev[USB_MAX_HUB];
static int usb_hub_index;
+__weak void usb_hub_reset_devices(int port)
+{
+ return;
+}
static int usb_get_hub_descriptor(struct usb_device *dev, void *data, int size)
{
@@ -444,6 +448,14 @@ static int usb_hub_configure(struct usb_device *dev)
: no );
usb_hub_power_on(hub);
+ /*
+* Reset any devices that may be in a bad state when applying
+* the power. This is a __weak function. Resettig of the devices
+* should occur in the board file of the device.
+*/
+ for (i = 0; i dev-maxchild; i++)
+ usb_hub_reset_devices(i + 1);
+
for (i = 0; i dev-maxchild; i++) {
ALLOC_CACHE_ALIGN_BUFFER(struct usb_port_status, portsts, 1);
unsigned short portstatus, portchange;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 4/7] ARM: OMAP5-uevm: Add USB ehci support for the uEVM
Add the USB ehci support for the OMAP5 uEVM.
Configure the uEVM mux data
Add the flags to build the appropriate modules
Add the usb call backs to initialize the EHCI controller
Signed-off-by: Dan Murphy dmur...@ti.com
---
v3 - Updated per comments and removed reset function -
http://patchwork.ozlabs.org/patch/258231/
board/ti/omap5_uevm/evm.c | 41
board/ti/omap5_uevm/mux_data.h |4 +++-
include/configs/omap5_uevm.h | 22 +
3 files changed, 66 insertions(+), 1 deletion(-)
diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index 00bd72d..bf14cd2 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -29,6 +29,12 @@
#include mux_data.h
+#ifdef CONFIG_USB_EHCI
+#include usb.h
+#include asm/arch/ehci.h
+#include asm/ehci-omap.h
+#endif
+
DECLARE_GLOBAL_DATA_PTR;
const struct omap_sysinfo sysinfo = {
@@ -103,3 +109,38 @@ int board_mmc_init(bd_t *bis)
return 0;
}
#endif
+
+#ifdef CONFIG_USB_EHCI
+static struct omap_usbhs_board_data usbhs_bdata = {
+ .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
+ .port_mode[1] = OMAP_EHCI_PORT_MODE_HSIC,
+ .port_mode[2] = OMAP_EHCI_PORT_MODE_HSIC,
+};
+
+int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor **hcor)
+{
+ int ret;
+ int auxclk;
+
+ auxclk = readl((*prcm)-scrm_auxclk1);
+ /* Request auxilary clock */
+ auxclk |= AUXCLK_ENABLE_MASK;
+ writel(auxclk, (*prcm)-scrm_auxclk1);
+
+ ret = omap_ehci_hcd_init(usbhs_bdata, hccr, hcor);
+ if (ret 0) {
+ printf(Failed to initialize ehci\n);
+ return ret;
+ }
+
+ return 0;
+}
+
+int ehci_hcd_stop(void)
+{
+ int ret;
+
+ ret = omap_ehci_hcd_stop();
+ return ret;
+}
+#endif
diff --git a/board/ti/omap5_uevm/mux_data.h b/board/ti/omap5_uevm/mux_data.h
index a82795d..17de7f5 100644
--- a/board/ti/omap5_uevm/mux_data.h
+++ b/board/ti/omap5_uevm/mux_data.h
@@ -56,7 +56,8 @@ const struct pad_conf_entry core_padconf_array_essential[] = {
{USBD0_HS_DP, (IEN | M0)}, /* USBD0_HS_DP */
{USBD0_HS_DM, (IEN | M0)}, /* USBD0_HS_DM */
{USBD0_SS_RX, (IEN | M0)}, /* USBD0_SS_RX */
-
+ {HSI2_ACWAKE, (PTU | M6)},/* HSI2_ACWAKE */
+ {HSI2_CAFLAG, (PTU | M6)},/* HSI2_CAFLAG */
};
const struct pad_conf_entry wkup_padconf_array_essential[] = {
@@ -64,6 +65,7 @@ const struct pad_conf_entry wkup_padconf_array_essential[] = {
{SR_PMIC_SCL, (PTU | IEN | M0)}, /* SR_PMIC_SCL */
{SR_PMIC_SDA, (PTU | IEN | M0)}, /* SR_PMIC_SDA */
{SYS_32K, (IEN | M0)}, /* SYS_32K */
+ {FREF_CLK1_OUT, (PTD | IEN | M0)},/* FREF_CLK1_OUT */
};
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index 46dacc2..0740a32 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -53,6 +53,28 @@
#define CONFIG_PARTITION_UUIDS
#define CONFIG_CMD_PART
+/* USB UHH support options */
+#define CONFIG_CMD_USB
+#define CONFIG_USB_HOST
+#define CONFIG_USB_EHCI
+#define CONFIG_USB_EHCI_OMAP
+#define CONFIG_USB_STORAGE
+#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3
+#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
+
+#define CONFIG_OMAP_EHCI_PHY1_RESET_GPIO 79
+#define CONFIG_OMAP_EHCI_PHY2_RESET_GPIO 80
+
+/* Enabled commands */
+#define CONFIG_NET_MULTI
+#define CONFIG_CMD_DHCP/* DHCP Support */
+#define CONFIG_CMD_NET /* bootp, tftpboot, rarpboot*/
+#define CONFIG_CMD_NFS /* NFS support */
+
+/* USB Networking options */
+#define CONFIG_USB_HOST_ETHER
+#define CONFIG_USB_ETHER_SMSC95XX
+
#define CONFIG_SYS_PROMPT OMAP5432 uEVM #
#define CONSOLEDEV ttyO2
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/7] ARM: OMAP: USB: Fix linker error when ULPI is not defined
Fix the linker error for missing ulpi_reset when ulpi is not defined
in the board config.
Signed-off-by: Dan Murphy dmur...@ti.com
---
v3 - No updates - http://patchwork.ozlabs.org/patch/258228/
drivers/usb/host/ehci-omap.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 17f2214..bd7191c 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -90,6 +90,7 @@ static void omap_usbhs_hsic_init(int port)
writel(reg, usbtll-channel_conf + port);
}
+#ifdef CONFIG_USB_ULPI
static void omap_ehci_soft_phy_reset(int port)
{
struct ulpi_viewport ulpi_vp;
@@ -99,6 +100,12 @@ static void omap_ehci_soft_phy_reset(int port)
ulpi_reset(ulpi_vp);
}
+#else
+static void omap_ehci_soft_phy_reset(int port)
+{
+ return;
+}
+#endif
inline int __board_usb_init(void)
{
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 5/7] ARM: OMAP5-uevm: Add USB MAC ethernet address
Set the usbethaddr based on the OMAP DIE_ID registers
which should be unique for each processor.
Then set this as the usb ethernet MAC address.
Signed-off-by: Dan Murphy dmur...@ti.com
---
v3 - new patch
board/ti/omap5_uevm/evm.c| 26 ++
include/configs/omap5_uevm.h |2 ++
2 files changed, 28 insertions(+)
diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index bf14cd2..9add0fd 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -33,6 +33,11 @@
#include usb.h
#include asm/arch/ehci.h
#include asm/ehci-omap.h
+
+#define MAX_DEVICE_MAC 20
+#define DIE_ID_REG_BASE (OMAP54XX_L4_CORE_BASE + 0x2000)
+#define DIE_ID_REG_OFFSET 0x200
+
#endif
DECLARE_GLOBAL_DATA_PTR;
@@ -121,6 +126,27 @@ int ehci_hcd_init(int index, struct ehci_hccr **hccr,
struct ehci_hcor **hcor)
{
int ret;
int auxclk;
+ int val[4] = { 0 };
+ int reg;
+ char device_mac[MAX_DEVICE_MAC];
+
+ reg = DIE_ID_REG_BASE + DIE_ID_REG_OFFSET;
+
+ val[0] = readl(reg);
+ val[1] = readl(reg + 0x8);
+ val[2] = readl(reg + 0xC);
+ val[3] = readl(reg + 0x10);
+
+ /* create a fake MAC address from the processor ID code.
+* first byte is 0x02 to signify locally administered.
+*/
+ snprintf(device_mac, MAX_DEVICE_MAC, %02X:%02X:%02X:%02X:%02X:%02X,
+ 0x02, val[3] 0xff, val[2] 0xff, val[1]
0xff,
+ val[0] 0xff, (val[0] 8 0xff));
+
+#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+ setenv(usbethaddr, device_mac);
+#endif
auxclk = readl((*prcm)-scrm_auxclk1);
/* Request auxilary clock */
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index 0740a32..53b86ec 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -79,5 +79,7 @@
#define CONSOLEDEV ttyO2
+#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+
#define CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC 16296
#endif /* __CONFIG_OMAP5_EVM_H */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/7] ARM: OMAP5: USB: Add OMAP5 common USB EHCI information
* Enable the OMAP5 EHCI host clocks * Add OMAP5 EHCI register definitions * Add OMAP5 ES2 host revision Signed-off-by: Dan Murphy dmur...@ti.com --- v3 - Updated per comments - http://patchwork.ozlabs.org/patch/258230/ arch/arm/cpu/armv7/omap5/hw_data.c | 17 arch/arm/include/asm/arch-omap5/clock.h |6 + arch/arm/include/asm/arch-omap5/ehci.h | 43 +++ arch/arm/include/asm/ehci-omap.h|1 + drivers/usb/host/ehci-omap.c|2 +- 5 files changed, 68 insertions(+), 1 deletion(-) create mode 100644 arch/arm/include/asm/arch-omap5/ehci.h diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index 07b1108..b1be748 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -414,6 +414,10 @@ void enable_basic_clocks(void) (*prcm)-cm_l4per_gpio6_clkctrl, (*prcm)-cm_l4per_gpio7_clkctrl, (*prcm)-cm_l4per_gpio8_clkctrl, +#ifdef CONFIG_USB_EHCI_OMAP + (*prcm)-cm_clksel_usb_60mhz, + (*prcm)-cm_l3init_hsusbtll_clkctrl, +#endif 0 }; @@ -425,6 +429,9 @@ void enable_basic_clocks(void) (*prcm)-cm_wkup_wdtimer2_clkctrl, (*prcm)-cm_l4per_uart3_clkctrl, (*prcm)-cm_l4per_i2c1_clkctrl, +#ifdef CONFIG_USB_EHCI_OMAP + (*prcm)-cm_l3init_hsusbhost_clkctrl, +#endif 0 }; @@ -448,6 +455,16 @@ void enable_basic_clocks(void) setbits_le32((*prcm)-cm_wkup_gptimer1_clkctrl, GPTIMER1_CLKCTRL_CLKSEL_MASK); +#ifdef CONFIG_USB_EHCI + /* Enable port 2 and 3 clocks*/ + setbits_le32((*prcm)-cm_l3init_hsusbhost_clkctrl, + USB_HOST_HS_CLKCTRL_MASK); + + /* Enable all 3 usb host ports tll clocks*/ + setbits_le32((*prcm)-cm_l3init_hsusbtll_clkctrl, + USB_TLL_HS_CLKCTRL_MASK); +#endif + do_enable_clocks(clk_domains_essential, clk_modules_hw_auto_essential, clk_modules_explicit_en_essential, diff --git a/arch/arm/include/asm/arch-omap5/clock.h b/arch/arm/include/asm/arch-omap5/clock.h index 4d2765d..3a58337 100644 --- a/arch/arm/include/asm/arch-omap5/clock.h +++ b/arch/arm/include/asm/arch-omap5/clock.h @@ -165,6 +165,12 @@ /* CM_L3INIT_USBPHY_CLKCTRL */ #define USBPHY_CLKCTRL_OPTFCLKEN_PHY_48M_MASK 8 +/* CM_L3INIT_USB_HOST_HS_CLKCTRL */ +#define USB_HOST_HS_CLKCTRL_MASK 0x56C0 + +/* CM_L3INIT_USB_TLL_HS_CLKCTRL */ +#define USB_TLL_HS_CLKCTRL_MASK0x700 + /* CM_MPU_MPU_CLKCTRL */ #define MPU_CLKCTRL_CLKSEL_EMIF_DIV_MODE_SHIFT 24 #define MPU_CLKCTRL_CLKSEL_EMIF_DIV_MODE_MASK (3 24) diff --git a/arch/arm/include/asm/arch-omap5/ehci.h b/arch/arm/include/asm/arch-omap5/ehci.h new file mode 100644 index 000..3921e4a --- /dev/null +++ b/arch/arm/include/asm/arch-omap5/ehci.h @@ -0,0 +1,43 @@ +/* + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com* + * Author: Govindraj R govindraj.r...@ti.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#ifndef _EHCI_H +#define _EHCI_H + +#define OMAP_EHCI_BASE (OMAP54XX_L4_CORE_BASE + 0x64C00) +#define OMAP_UHH_BASE (OMAP54XX_L4_CORE_BASE + 0x64000) +#define OMAP_USBTLL_BASE (OMAP54XX_L4_CORE_BASE + 0x62000) + +/* TLL Register Set */ +#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE(1 3) +#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP(1 2) +#define OMAP_USBTLL_SYSCONFIG_SOFTRESET(1 1) +#define OMAP_USBTLL_SYSCONFIG_CACTIVITY(1 8) +#define OMAP_USBTLL_SYSSTATUS_RESETDONE1 + +#define OMAP_UHH_SYSCONFIG_SOFTRESET 1 +#define OMAP_UHH_SYSSTATUS_EHCI_RESETDONE (1 2) +#define OMAP_UHH_SYSCONFIG_NOIDLE (1 2) +#define OMAP_UHH_SYSCONFIG_NOSTDBY (1 4) + +#define OMAP_UHH_SYSCONFIG_VAL (OMAP_UHH_SYSCONFIG_NOIDLE | \ + OMAP_UHH_SYSCONFIG_NOSTDBY) + +#endif /* _EHCI_H */ diff --git a/arch/arm/include/asm/ehci-omap.h b/arch/arm/include/asm/ehci-omap.h index
[U-Boot] OMAP5 uEVM USB eHCI patch set
This patch set is for the OMAP5 uEVM for the USB eHCI host. This patch set will enable the LAN9730 ethernet IC and the USB3503 usb hub. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] am335x_evm: Make NAND support modular
On 07/09/2013 02:00:06 PM, Justin Waters wrote: Give the user the ability to disable NAND support by defining CONFIG_NO_NAND. This will allow custom hardware to easily support this configuration. Signed-off-by: Justin Waters justin.wat...@timesys.com --- include/configs/am335x_evm.h | 55 -- 1 file changed, 37 insertions(+), 18 deletions(-) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index c5a6d4b..7bcfe2e 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -42,12 +42,39 @@ #define CONFIG_SYS_CACHELINE_SIZE 64 +#ifdef CONFIG_NO_NAND +#undef CONFIG_NAND +#else +#define CONFIG_NAND +#endif Wouldn't it be cleaner to move CONFIG_NAND into boards.cfg, so if you want NAND to be absent, you just add a similar target that doesn't set it? Especially if this is for custom hardware, which ought to get its own board.cfg line. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] am335x_evm: Make NAND support modular
On 07/17/2013 04:05:37 PM, Scott Wood wrote: On 07/09/2013 02:00:06 PM, Justin Waters wrote: Give the user the ability to disable NAND support by defining CONFIG_NO_NAND. This will allow custom hardware to easily support this configuration. Signed-off-by: Justin Waters justin.wat...@timesys.com --- include/configs/am335x_evm.h | 55 -- 1 file changed, 37 insertions(+), 18 deletions(-) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index c5a6d4b..7bcfe2e 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -42,12 +42,39 @@ #define CONFIG_SYS_CACHELINE_SIZE 64 +#ifdef CONFIG_NO_NAND +#undef CONFIG_NAND +#else +#define CONFIG_NAND +#endif Wouldn't it be cleaner to move CONFIG_NAND into boards.cfg, so if you want NAND to be absent, you just add a similar target that doesn't set it? Especially if this is for custom hardware, which ought to get its own board.cfg line. Sigh, as soon as I sent this my mail client decided it would be a good idea to show me the other replies from a couple days ago saying the same thing. I need a new mail client... -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] FW: U-boot x86 coreboot
Hi Simon, -Original Message- From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass Sent: mercredi 17 juillet 2013 17:43 To: Rossier Daniel Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] U-boot x86 coreboot Hi Rossier, On Wed, Jul 17, 2013 at 2:29 AM, Rossier Daniel daniel.ross...@heig-vd.ch wrote: Hi, I would like to run U-boot on x86 emulated QEMU-based environment. I found some info regarding coreboot + U-boot integration, using U-boot as payload, etc. but I was unable to start U-boot. I'm using the 32-bits i686-pc-linux-gnu toolchain and I successfully cross- compiled coreboot and started it on qemu-system-i386. I also configured coreboot to use u-boot (ELF) as payload, but coreboot performs a reset when U-boot should show up after loading. Where could I have some information regarding that? There are post codes generated in x86 U-Boot which might help with diagnosing this. I have not tried this on QEMU. But I suppose in that environment it might be possible to watch execution and see where it is going wrong. Actually, I was able to dig into further details during the execution. U-boot is starting its execution, but in early execution in setup_gdt, the execution of instruction at 0x491 leads to a traps (loading 0x18 to %ds). (see below for details) I don't really see an issue to execute this instruction. (gdb) si 0x0491 in load_ds (segment=3) at cpu.c:61 61 asm volatile(movl %0, %%ds : : r (segment * X86_GDT_ENTRY_SIZE)); (gdb) info reg eax0x18 24 ecx0x19203f20 421543712 edx0x20 32 ebx0x19cf9320 433034016 esp0x19203f10 0x19203f10 ebp0x11dff0 0x11dff0 esi0x7ebdc50132897872 edi0x1223b0 1188784 eip0x4910x491 setup_gdt+135 eflags 0x2 [ ] cs 0x10 16 ss 0x18 24 ds 0x18 24 es 0x18 24 fs 0x18 24 gs 0x18 24 (gdb) info reg pc pc: 0x491 (gdb) x/10i 0x491 = 0x491 setup_gdt+135: mov%eax,%ds 0x493 setup_gdt+137: mov%eax,%es 0x495 setup_gdt+139: mov%eax,%gs 0x497 setup_gdt+141: mov%eax,%ss 0x499 setup_gdt+143: mov$0x20,%al 0x49b setup_gdt+145: mov%eax,%fs 0x49d setup_gdt+147: add$0x8,%esp 0x4a0 setup_gdt+150: pop%ebx 0x4a1 setup_gdt+151: ret 0x4a2 x86_cpu_init_r: call 0x11109d3 cpu_init_interrupts (gdb) si 0xfcb0 in ?? () (gdb) Do you have an idea? By the way, I'm passing the file u-boot in ELF format directly to coreboot as ELF payload. Is it better to wrap the file u-boot.bin to get an ELF? Thanks for your help Daniel Furthermore, I'm unable to debug anything remotely with gdb; gdb cannot disassemble once connected via target remote localhost:1234. Do you mean it cannot find the source files? Regards, Simon Any hints welcome. Thanks so much. Cheers Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] FW: U-boot x86 coreboot
By the way, the issue related to the debugger is that I'm unable to use it with Eclipse CDT (using gdbserver in Qemu). It leads to a seg fault in Qemu. If you have an idea, I would appreciate. Regards Daniel From: s...@google.commailto:s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass Sent: mercredi 17 juillet 2013 17:43 To: Rossier Daniel Cc: u-boot@lists.denx.demailto:u-boot@lists.denx.de Subject: Re: [U-Boot] U-boot x86 coreboot Hi Rossier, On Wed, Jul 17, 2013 at 2:29 AM, Rossier Daniel daniel.ross...@heig-vd.chmailto:daniel.ross...@heig-vd.ch wrote: Hi, I would like to run U-boot on x86 emulated QEMU-based environment. I found some info regarding coreboot + U-boot integration, using U-boot as payload, etc. but I was unable to start U-boot. I'm using the 32-bits i686-pc-linux-gnu toolchain and I successfully cross-compiled coreboot and started it on qemu-system-i386. I also configured coreboot to use u-boot (ELF) as payload, but coreboot performs a reset when U-boot should show up after loading. Where could I have some information regarding that? There are post codes generated in x86 U-Boot which might help with diagnosing this. I have not tried this on QEMU. But I suppose in that environment it might be possible to watch execution and see where it is going wrong. Furthermore, I'm unable to debug anything remotely with gdb; gdb cannot disassemble once connected via target remote localhost:1234. Do you mean it cannot find the source files? Regards, Simon Any hints welcome. Thanks so much. Cheers Daniel ___ U-Boot mailing list U-Boot@lists.denx.demailto:U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] board/ti/am335x/README: Document NAND programming
On 07/17/2013 11:24:30 AM, Tom Rini wrote:
The AM335x GP EVM ships with NAND. Document programming of the chip
including the redundant locations that the ROM will check.
Signed-off-by: Tom Rini tr...@ti.com
---
board/ti/am335x/README | 25 +
1 file changed, 25 insertions(+)
diff --git a/board/ti/am335x/README b/board/ti/am335x/README
index ccc5e16..3444d7e 100644
--- a/board/ti/am335x/README
+++ b/board/ti/am335x/README
@@ -13,6 +13,31 @@ documented in TI's reference designs:
- AM335x EVM SK
- Beaglebone White
- Beaglebone Black
+'
+NAND
+
+
+The AM335x GP EVM ships with a 256MiB NAND available in most
profiles. In
+this example to program the NAND we assume that an SD card has been
+inserted with the files to write in the first SD slot and that
mtdparts
+have been configured correctly for the board. As a time saving
measure we
+load MLO into memory in one location, copy it into the three
locatations
+that the ROM checks for additional valid copies, then load U-Boot
into
+memory. We then write that whole section of memory to NAND.
+
+U-Boot # mmc rescan
+U-Boot # env default -f -a
+U-Boot # nand erase.chip
+U-Boot # saveenv
+U-Boot # load mmc 0 8100 MLO
+U-Boot # cp.b 8100 8102 2
+U-Boot # cp.b 8100 8104 2
+U-Boot # cp.b 8100 8106 2
+U-Boot # load mmc 0 8108 u-boot.img
+U-Boot # nand write 8100 0 26
+U-Boot # load mmc 0 ${loadaddr} uImage
+U-Boot # nand erase.part kernel
+U-Boot # nand write ${loadaddr} kernel 50
You've already done a nand erase.chip... Why do you need to erase
kernel again?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: U-boot x86 coreboot
On Wed, Jul 17, 2013 at 3:20 PM, Rossier Daniel daniel.ross...@heig-vd.chwrote: By the way, the issue related to the debugger is that I'm unable to use it with Eclipse CDT (using gdbserver in Qemu). It leads to a seg fault in Qemu. If you have an idea, I would appreciate. No sorry, I don't use it. Perhaps ask on the Qemu mailing list? It seems like an obvious thing to want to do... - Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] board/ti/am335x/README: Document NAND programming
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/17/2013 05:52 PM, Scott Wood wrote:
On 07/17/2013 11:24:30 AM, Tom Rini wrote:
The AM335x GP EVM ships with NAND. Document programming of the
chip including the redundant locations that the ROM will check.
Signed-off-by: Tom Rini tr...@ti.com --- board/ti/am335x/README
| 25 + 1 file changed, 25
insertions(+)
diff --git a/board/ti/am335x/README b/board/ti/am335x/README
index ccc5e16..3444d7e 100644 --- a/board/ti/am335x/README +++
b/board/ti/am335x/README @@ -13,6 +13,31 @@ documented in TI's
reference designs: - AM335x EVM SK - Beaglebone White -
Beaglebone Black +' +NAND + + +The AM335x GP EVM ships with a
256MiB NAND available in most profiles. In +this example to
program the NAND we assume that an SD card has been +inserted
with the files to write in the first SD slot and that mtdparts
+have been configured correctly for the board. As a time saving
measure we +load MLO into memory in one location, copy it into
the three locatations +that the ROM checks for additional valid
copies, then load U-Boot into +memory. We then write that whole
section of memory to NAND. + +U-Boot # mmc rescan +U-Boot # env
default -f -a +U-Boot # nand erase.chip +U-Boot # saveenv +U-Boot
# load mmc 0 8100 MLO +U-Boot # cp.b 8100 8102 2
+U-Boot # cp.b 8100 8104 2 +U-Boot # cp.b 8100
8106 2 +U-Boot # load mmc 0 8108 u-boot.img +U-Boot #
nand write 8100 0 26 +U-Boot # load mmc 0 ${loadaddr}
uImage +U-Boot # nand erase.part kernel +U-Boot # nand write
${loadaddr} kernel 50
You've already done a nand erase.chip... Why do you need to
erase kernel again?
No, that's just what I get for concatening my instructions too
quickly, thanks!
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJR5xT5AAoJENk4IS6UOR1Wr9sP/RtZpkzON7zC5LIqEQCfVFBj
vJCTQYB0xKaMGgYLpQ2uLy5PH4CgPuy3PTmdVrK1Ooqj2YHTmZpBH7yjTl3VTjxd
nrODm1VLQ1kd3QNC94ftOzv5vvISfV8A1HtS8WeoExAphFrcpaTnbbSfhcMpQfR6
m+fEdfpHDtzgh2dKZPqPC29XqgDkN5RtcH6jDV+ZujjyBMHuxCc1wslwJZSz2WSv
lY1GKCxHiJALZyII4nCaT7tsRGWJWWZziqFzK+XObYZzcN9XKVimqZGe2vSTM4pu
sl+Sddp7j6EzfxY6vSWRTAuRIa0uiGKHuGm+yA52qyP6FznzdtLzdr/eNEOs34Q4
ekz15q6l8F9z4witCm9msDhxbzjD6imfVylgJHiDqpc0LopQj7fNw4e6PQ3wRvjD
WWti5eGmTeMwxdlm7awBFi9RrMTSz2NnhIAHcN59CVqaobxf/MxtIGAJ8IZeqL81
T9U2U8EauR1Ba7KrJWhYH8U6zic1KChZ2GyTn21HH78Px+Vf15M+qv6RGm6im9m/
yBO2aygKQYNwEMMGyjNAI2a0cy31FuZhYl7MbpQufi7oWPDUtobBMBOQz/V7wBa9
I5QcZ7Fqcd6R9QG58ioPcIzTxzMBB0cfrKhYKMiO1lvHbSt7jIKkpnErXl7djiGp
7xh5j6JWedBDdA5xZSad
=M00E
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mkimage: Use board config to get CONFIG_FIT_SIGNATURE value
The value of this config variable is not available to image.h on the host, since the board config is not actually included. Bring this in so that mkimage will be built with image-signing support for sandbox at least. Signed-off-by: Simon Glass s...@chromium.org --- config.mk | 4 1 file changed, 4 insertions(+) diff --git a/config.mk b/config.mk index 81c2584..f71e145 100644 --- a/config.mk +++ b/config.mk @@ -213,6 +213,10 @@ endif # TODO(s...@chromium.org): Is this correct on Mac OS? ifdef CONFIG_FIT_SIGNATURE HOSTLIBS += -lssl -lcrypto + +# This affects include/image.h, but including the board config file +# is tricky, so manually define this options here. +HOSTCFLAGS += -DCONFIG_FIT_SIGNATURE endif ifneq ($(CONFIG_SYS_TEXT_BASE),) -- 1.8.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mkimage: Use board config to get CONFIG_FIT_SIGNATURE value
Hi Tom, On Wed, Jul 17, 2013 at 4:10 PM, Simon Glass s...@chromium.org wrote: The value of this config variable is not available to image.h on the host, since the board config is not actually included. Bring this in so that mkimage will be built with image-signing support for sandbox at least. Signed-off-by: Simon Glass s...@chromium.org This is another bug fix - although I don't have a good explanation for why I didn't seem to need this when I was testing a few weeks ago. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] env_nand.c: support falling back to redundant env when writing
On 06/26/2013 01:25:26 PM, Phil Sutter wrote:
Without this patch, when the currently chosen environment to be
written
has bad blocks, saveenv fails completely. Instead, when there is
redundant environment fall back to the other copy. Environment reading
needs no adjustment, as the fallback logic for incomplete writes
applies
to this case as well.
Signed-off-by: Phil Sutter phil.sut...@viprinet.com
---
common/env_nand.c | 105
--
1 file changed, 46 insertions(+), 59 deletions(-)
Missing description of changes since v2
-#else /* ! CONFIG_ENV_OFFSET_REDUND */
+
+static unsigned char env_flags;
env_nand.c:193:22: warning: 'env_flags' defined but not used
[-Wunused-variable]
(when CONFIG_ENV_OFFSET_REDUND is not defined)
int saveenv(void)
{
int ret = 0;
ALLOC_CACHE_ALIGN_BUFFER(env_t, env_new, 1);
ssize_t len;
char*res;
+ int env_idx;
nand_erase_options_t nand_erase_options;
+ static const struct env_location location[] = {
+ {
+ .name = NAND,
+ .erase_opts = nand_erase_options,
+ .offset = CONFIG_ENV_OFFSET,
+ },
+#ifdef CONFIG_ENV_OFFSET_REDUND
+ {
+ .name = redundant NAND,
+ .erase_opts = nand_erase_options,
+ .offset = CONFIG_ENV_OFFSET_REDUND,
+ },
+#endif
+ };
+
env_nand.c:206:4: error: initializer element is not constant
env_nand.c:206:4: error: (near initialization for
'location[0].erase_opts')
You could make nand_erase_options static, or you could use code to
assign
that field.
Is this code untested, or did you accidentally send an old version?
- puts(Writing to Nand... );
- if (writeenv(CONFIG_ENV_OFFSET, (u_char *)env_new)) {
- puts(FAILED!\n);
- return 1;
+ ret = erase_and_write_env(location[env_idx], (u_char
*)env_new);
env_nand.c:237:2: warning: passing argument 1 of 'erase_and_write_env'
discards 'const' qualifier from pointer target type [enabled by default]
env_nand.c:177:12: note: expected 'struct env_location *' but argument
is
of type 'const struct env_location *'
+#ifdef CONFIG_ENV_OFFSET_REDUND
+ if (ret) {
+ env_idx = (env_idx + 1) 1;
+ ret = erase_and_write_env(location[env_idx],
+ (u_char *)env_new);
Can you print a message here specifically saying that redundancy has
been
lost? I realize that the previous erase_and_write_env will have printed
FAILED, but it'd be nice to be explicit about the consequences.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] dfu, nand, ubi: add partubi alt settings for updating ubi partition
On 07/15/2013 11:54:09 PM, Heiko Schocher wrote:
updating an ubi partition needs a completely erased mtd partition,
see:
http://lists.infradead.org/pipermail/linux-mtd/2011-May/035416.html
So, add partubi alt setting for the dfu_alt_info environment
variable to mark this partition as an ubi partition. In case we
update an ubi partition, we erase after flashing the image into the
partition, the remaining sektors.
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
Cc: Tom Rini tr...@ti.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Marek Vasut ma...@denx.de
Cc: Wolfgang Denk w...@denx.de
---
- This patch is also a good starting point to fix up updating ubi, as
we currently use nand erase for erasing the sektors. This is
not the prefered way for writing an ubi image, see:
http://www.linux-mtd.infradead.org/faq/ubi.html#L_flash_img
This must be fixed ... we have no ubiformat in u-boot, or?
The lack of erase counter preservation is a problem, but the part about
ECC on erased pages is dealt with in U-Boot by the WITH_DROP_FFS flag.
- changes for v2:
- do not use spread = 1 for nand_erase_opts, to prevent
errormessage if there are bad blocks in the erase range.
---
drivers/dfu/dfu.c | 30 +-
drivers/dfu/dfu_nand.c | 26 ++
include/dfu.h | 2 ++
3 Dateien geändert, 57 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 0521752..7ba7026 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -23,6 +23,7 @@
#include errno.h
#include malloc.h
#include mmc.h
+#include nand.h
#include fat.h
#include dfu.h
#include linux/list.h
@@ -176,6 +177,34 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num)
ret = dfu-flush_medium(dfu);
printf(\nDFU complete CRC32: 0x%08x\n, dfu-crc);
+ /* in case of ubi partition, erase rest of the
partition */
+ if (dfu-ubi == 1) {
+ int ret;
+ nand_info_t *nand;
+ /* erase complete partition */
+ nand_erase_options_t opts;
+
+ if (nand_curr_device 0 ||
+ nand_curr_device =
CONFIG_SYS_MAX_NAND_DEVICE ||
+ !nand_info[nand_curr_device].name) {
+printf(%s: invalid nand device\n,
__func__);
+ return -1;
+ }
+
+ nand = nand_info[nand_curr_device];
+
+ memset(opts, 0, sizeof(opts));
+ opts.offset = dfu-data.nand.start +
dfu-offset +
+ dfu-bad_skip;
+ opts.length = dfu-data.nand.start +
+ dfu-data.nand.size -
opts.offset;
+ ret = nand_erase_opts(nand, opts);
+ if (ret != 0) {
+ printf(Failure erase: %d\n, ret);
+ return ret;
+ }
+ }
Instead of separately erasing the remainder of the partition, how about
recognizing up front that it's UBI (or that a full partition erase is
otherwise desired) and erasing the full partition then? Besides being
cleaner, it would be easier to convert to an ubi-aware mechanism.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] usb: Use well-known descriptor sizes when parsing configuration
The existing USB configuration parsing code relies on the descriptors'
own length values when reading through the configuration blob. Since the
size of those descriptors is always well-defined, we should rather use
the known sizes instead of trusting device-provided values to be
correct. Also adds some safety to potential out-of-order descriptors.
Change-Id: I16f69dfdd6793aa0fe930b5148d4521f3e5c3090
Signed-off-by: Julius Werner jwer...@chromium.org
---
common/usb.c | 73 ++--
common/usb_hub.c | 14 ---
2 files changed, 64 insertions(+), 23 deletions(-)
diff --git a/common/usb.c b/common/usb.c
index 55fff5b..ab7bafe 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -341,6 +341,7 @@ static int usb_set_maxpacket(struct usb_device *dev)
/***
* Parse the config, located in buffer, and fills the dev-config structure.
* Note that all little/big endian swapping are done automatically.
+ * (wTotalLength has already been swapped when it was read.)
*/
static int usb_parse_config(struct usb_device *dev,
unsigned char *buffer, int cfgno)
@@ -361,24 +362,39 @@ static int usb_parse_config(struct usb_device *dev,
head-bDescriptorType);
return -1;
}
- memcpy(dev-config, buffer, buffer[0]);
- le16_to_cpus((dev-config.desc.wTotalLength));
+ if (buffer[0] != USB_DT_CONFIG_SIZE)
+ printf(Ignoring invalid USB CFG length (%d)\n, buffer[0]);
+ memcpy(dev-config, buffer, USB_DT_CONFIG_SIZE);
dev-config.no_of_if = 0;
index = dev-config.desc.bLength;
/* Ok the first entry must be a configuration entry,
* now process the others */
head = (struct usb_descriptor_header *) buffer[index];
- while (index + 1 dev-config.desc.wTotalLength) {
+ while (index + 1 dev-config.desc.wTotalLength head-bLength) {
switch (head-bDescriptorType) {
case USB_DT_INTERFACE:
+ if (index + USB_DT_INTERFACE_SIZE
+ dev-config.desc.wTotalLength) {
+ puts(USB IF descriptor overflowed buffer!\n);
+ break;
+ }
if (((struct usb_interface_descriptor *) \
buffer[index])-bInterfaceNumber != curr_if_num) {
/* this is a new interface, copy new desc */
ifno = dev-config.no_of_if;
+ if (ifno = USB_MAXINTERFACES) {
+ puts(Too many USB interfaces!\n);
+ /* try to go on with what we have */
+ return 1;
+ }
if_desc = dev-config.if_desc[ifno];
dev-config.no_of_if++;
- memcpy(if_desc, buffer[index], buffer[index]);
+ if (buffer[index] != USB_DT_INTERFACE_SIZE)
+ printf(Ignoring invalid USB IF length
+(%d)\n, buffer[index]);
+ memcpy(if_desc, buffer[index],
+ USB_DT_INTERFACE_SIZE);
if_desc-no_of_ep = 0;
if_desc-num_altsetting = 1;
curr_if_num =
@@ -392,12 +408,29 @@ static int usb_parse_config(struct usb_device *dev,
}
break;
case USB_DT_ENDPOINT:
+ if (index + USB_DT_ENDPOINT_SIZE
+ dev-config.desc.wTotalLength) {
+ puts(USB EP descriptor overflowed buffer!\n);
+ break;
+ }
+ if (ifno 0) {
+ puts(Endpoint descriptor out of order!\n);
+ break;
+ }
epno = dev-config.if_desc[ifno].no_of_ep;
if_desc = dev-config.if_desc[ifno];
+ if (epno USB_MAXENDPOINTS) {
+ printf(Interface %d has too many endpoints!\n,
+ if_desc-desc.bInterfaceNumber);
+ return 1;
+ }
/* found an endpoint */
if_desc-no_of_ep++;
+ if (buffer[index] != USB_DT_ENDPOINT_SIZE)
+ printf(Ignoring invalid USB EP length (%d)\n,
+ buffer[index]);
Re: [U-Boot] [U-boot] failed to boot an compressed u-boot.bin
Hi, Albert: The DRAM address map is : 0 --- 0x1000 (256MB) on my ARM development board. I configured CONFIG_SYS_TEXT_BASE = 0x03F8 in config.mk when compiling u-boot source code. The self-uncompressed code also put the uncompressed image at 0x03F8 Best wishes, On Wed, 17 Jul 2013 19:53:10 +0800, tiger...@viatech.com.cn wrote: Hi, experts: Sorry! Not self-compressed, it is self-uncompressed ! -- I tried to add a self-uncompressed header in u-boot.bin on a Cortex-A9 single core platform. Then, i tried to boot it. But failed in board_init_f() function. Has anybody tried to boot a self-uncompressed u-boot.bin ? Best wishes, IIUC, you then load that header + u-boot.bin in memory and it decompresses itself. At what address does it place the uncompressed load? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Dear Hector Palacios,
Dear Marek,
On 07/16/2013 06:44 AM, Marek Vasut wrote:
Dear Fabio Estevam,
On Tue, Jul 16, 2013 at 12:51 AM, Fabio Estevam feste...@gmail.com wrote:
On Mon, Jul 15, 2013 at 12:09 PM, Hector Palacios
hector.palac...@digi.com wrote:
@Fabio: could you manually run the command 'tftp ${loadaddr} file100M'
in your EVK?
Yes, this is what I have been running since the beginning.
If it doesn't fail, could you try running it again after playing with
the environment (setting/printing some variables).
I can't reproduce the problem here.
As I said, this issue appeared with different TFTP servers and is
independent of whether the dcache is or not enabled.
Can you transfer from a PC to another PC via TFTP?
Yes I can.
Another thing of interest would be a 'tcpdump' pcap capture of that
connection.
I was initially filtering out only TFTP packets of my wireshark trace and
all looked correct. After taking a second look to the full trace I see now
a hint. Around 7 seconds after starting the TFTP transfer the server is
sending an ARP to the target asking for the owner of the target's IP. The
target is receiving this ARP and apparently responding (at least this is
what my debug code shows as it gets into arp.c:ArpReceive(), case
ARPOP_REQUEST and sending a packet), but this ARP reply from the target is
not reaching the network. My sniffer does not capture this reply.
The server resends the ARP request twice more (seconds 8 and 9) to the
target and since it doesn't get a reply then sends a broadcast ARP
(seconds 10) asking who has that IP. Since nobody responds it stops
sending data.
The times that it works (and I don't know the magic behind using a numeric
address versus using ${loadaddr} when they have the same value), the ARP
replies do reach the network and the server continues the transmission
normally.
Using a v2009 U-Boot, the behaviour is exactly the same, but the target's
ARP replies always reach the network, and the transfers always succeed.
Since Fabio cannot reproduce it I guess it must be a local ghost. :o(
Try a 1:1 connection with a direct cable. Also, try multiple cables ;-)
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][DFU] Unification of dfu_alt_info alt settings description + command execution
Dear Heiko Schocher, Hello Lukasz, Am 16.07.2013 17:35, schrieb Lukasz Majewski: Dear All, Since DFU usage at u-boot is spreading to different device types (MMC, NAND), file systems, raw partitions, ubi, etc, I think that it is a good moment to unify and structure the form of dfu_alt_info environment variable. Full Ack! Proposed new format for single dfu entity: NAME | Type | Device | Dev_num | Dev_part | FS | start | size | where: Name - name of the alt setting (as seen by dfu-util -l) Type - description of the image (raw, file, img, command [*]) Device - physical device on which data are stored (mmc, nand, -) Dev_num - number of the device - it is possible to store data via DFU on several devices of the same type. Dev_part - number of partitions on the device. Should this be number of the partition on the device You mean here the mtd partition for storing, right? FS - information about file system on the device (fat, ext2/ext4, ubi). start- start offset from the beginning of the Device (byte or LBA number addressed) size - maximal number of blocks to be stored on the Device (expressed with Bytes of LBA number) (protection from overwriting the whole device) Example: Maybe dummy questions ... NAME | Type | Device | Dev_num | Dev_part | FS | start | size | -- u-boot | raw | mmc| 0 | - [**] | - | 0x80 | 0x100 | uImage | file | mmc| 0 | 2| ext4 | - | - | Is this enough information? Where to store the uImage file on the ext4 partition? root.img | img | mmc| 0 | 5| - | - | - | img means here: getting an image and storing it on the mtd partition Dev_part if start and size are marked with -, beginning on start of the partition? Wouldn't it be better to use here mtd partition names instead numbers for Dev_part? What if start and size are filled with values for the Type img? Or is this forbidden for the Type img? root.img | raw | mmc| 0 | - | - | 0x1000| 0x4000| u-boot | raw | nand | 0 | - | - | 0x100 | 0x100 | uImage | file | nand | 0 | 3| ubi | - | - | s/uImage/rootfs.img ? s/file/img ? For the FS ubi we need to specify, how to burn this into nand. I think we have no ubi format command. Try nand write.trimffs to write UBI images produced with ubinize . Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/7] omap5: uevm: Change the board name to correct name
Dear Dan Murphy,
Change the board name for the sys info to
5432 uEVM
Signed-off-by: Dan Murphy dmur...@ti.com
Acked-by: Marek Vasut ma...@denx.de
---
v3 - No change - http://patchwork.ozlabs.org/patch/258226/
board/ti/omap5_uevm/evm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index 90046e8..00bd72d 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -32,7 +32,7 @@
DECLARE_GLOBAL_DATA_PTR;
const struct omap_sysinfo sysinfo = {
- Board: OMAP5430 EVM\n
+ Board: OMAP5432 uEVM\n
};
/**
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/7] ARM: OMAP: USB: Fix linker error when ULPI is not defined
Dear Dan Murphy,
Fix the linker error for missing ulpi_reset when ulpi is not defined
in the board config.
Signed-off-by: Dan Murphy dmur...@ti.com
Acked-by: Marek Vasut ma...@denx.de
---
v3 - No updates - http://patchwork.ozlabs.org/patch/258228/
drivers/usb/host/ehci-omap.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 17f2214..bd7191c 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -90,6 +90,7 @@ static void omap_usbhs_hsic_init(int port)
writel(reg, usbtll-channel_conf + port);
}
+#ifdef CONFIG_USB_ULPI
static void omap_ehci_soft_phy_reset(int port)
{
struct ulpi_viewport ulpi_vp;
@@ -99,6 +100,12 @@ static void omap_ehci_soft_phy_reset(int port)
ulpi_reset(ulpi_vp);
}
+#else
+static void omap_ehci_soft_phy_reset(int port)
+{
+ return;
+}
+#endif
inline int __board_usb_init(void)
{
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] ARM-optimized memcpy/memset on SPL build
Hello exports, I found we cannot enable ARM-optimized memset/memcpy in SPL build. For example, I added #define CONFIG_USE_ARCH_MEMSET #define CONFIG_USE_ARCH_MEMCPY into include/configs/omap3_beagle.h and ran make omap3_beagle_config make. Then, undefined reference to `memset' undefined reference to `memcpy' errors occurred. If CONFIG_USE_ARCH_MEMCPY is defined, __HAVE_ARCH_MEMCPY is also defined in arch/arm/include/asm/string.h. So, generic memcpy function in lib/string.c is not compiled. If I see arch/arm/lib/Makefile, we cannot build arch/arm/lib/memcpy.S either on CONFIG_SPL_BUILD=y. This seems to cause undefined reference to memcpy. I found I can fix this problem by modifying arch/arm/lib/Makefile as follows: --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -48,12 +48,13 @@ COBJS-y += sections.o COBJS-y+= bootm.o COBJS-$(CONFIG_OF_LIBFDT) += bootm-fdt.o COBJS-$(CONFIG_SYS_L2_PL310) += cache-pl310.o -SOBJS-$(CONFIG_USE_ARCH_MEMSET) += memset.o -SOBJS-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o else COBJS-$(CONFIG_SPL_FRAMEWORK) += spl.o endif +SOBJS-$(CONFIG_USE_ARCH_MEMSET) += memset.o +SOBJS-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o + COBJS-y+= interrupts.o COBJS-y+= reset.o If this is the correct way of fixing, I can post the patch. But my question is, in the first place if CONFIG_USE_ARCH_MEMSET/MEMCPY macro is necessary or not. Can we always build arch-optimized memset.S/memcpy.S like Linux Kernel ? Although I am not sure how significant the code size is in SPL build, I imagine the arch-optimized memcpy has an advantage when copying a big image like OS Kernel. Comments are welcome. Best Regards, Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] failed to boot an compressed u-boot.bin
Dear tiger...@viatech.com.cn, In message fe7aded5c2218b4786c09cd97dc4c49f99d...@exchbj02.viatech.com.bj you wrote: I configured CONFIG_SYS_TEXT_BASE = 0x03F8 in config.mk when compiling u-boot source code. this has been moved out of config.mk ages ago. How old is your U-Boot version? The self-uncompressed code also put the uncompressed image at 0x03F8 Why don't you use an SPL approach instead? 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 Overdrawn? But I still have checks left! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] ARM: OMAP5-uevm: Add USB MAC ethernet address
Dear Dan Murphy,
Set the usbethaddr based on the OMAP DIE_ID registers
which should be unique for each processor.
Then set this as the usb ethernet MAC address.
Signed-off-by: Dan Murphy dmur...@ti.com
---
v3 - new patch
board/ti/omap5_uevm/evm.c| 26 ++
include/configs/omap5_uevm.h |2 ++
2 files changed, 28 insertions(+)
diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index bf14cd2..9add0fd 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -33,6 +33,11 @@
#include usb.h
#include asm/arch/ehci.h
#include asm/ehci-omap.h
+
+#define MAX_DEVICE_MAC 20
+#define DIE_ID_REG_BASE (OMAP54XX_L4_CORE_BASE + 0x2000)
+#define DIE_ID_REG_OFFSET0x200
+
#endif
DECLARE_GLOBAL_DATA_PTR;
@@ -121,6 +126,27 @@ int ehci_hcd_init(int index, struct ehci_hccr **hccr,
struct ehci_hcor **hcor) {
int ret;
int auxclk;
+ int val[4] = { 0 };
+ int reg;
+ char device_mac[MAX_DEVICE_MAC];
+
+ reg = DIE_ID_REG_BASE + DIE_ID_REG_OFFSET;
+
+ val[0] = readl(reg);
+ val[1] = readl(reg + 0x8);
+ val[2] = readl(reg + 0xC);
+ val[3] = readl(reg + 0x10);
+
+ /* create a fake MAC address from the processor ID code.
+ * first byte is 0x02 to signify locally administered.
+ */
/*
* valid
* multiline
* comment ... has that leading newline on the top. [1]
*/
+ snprintf(device_mac, MAX_DEVICE_MAC, %02X:%02X:%02X:%02X:%02X:%02X,
+ 0x02, val[3] 0xff, val[2] 0xff, val[1]
0xff,
+ val[0] 0xff, (val[0] 8 0xff));
+
+#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+ setenv(usbethaddr, device_mac);
+#endif
Urgh ... this is a big fat NAK. No, just don't do this, please. A kitten will
die if you set variables in the code like this. Another one will die for such a
config option.
You might work around this problem by setting a different env variable (yet I
am
still unhappy to see this) and then in the board environment have a command to
load the USB mac address from that other variable. But do not enforce the mac
address on users.
auxclk = readl((*prcm)-scrm_auxclk1);
/* Request auxilary clock */
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index 0740a32..53b86ec 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -79,5 +79,7 @@
#define CONSOLEDEV ttyO2
+#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+
#define CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC 16296
#endif /* __CONFIG_OMAP5_EVM_H */
[1] http://www.denx.de/wiki/U-Boot/CodingStyle
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/7] USB: usb-hub: Add a weak function for resetting devices
Dear Dan Murphy,
Add a __weak function that can be overridden to reset devices
attached to an ehci devices after the FEAT_POWER has been submitted
Signed-off-by: Dan Murphy dmur...@ti.com
---
v3 - Modified location of the weak function -
http://patchwork.ozlabs.org/patch/258229/
common/usb_hub.c | 12
1 file changed, 12 insertions(+)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 774ba63..c655b75 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -62,6 +62,10 @@
static struct usb_hub_device hub_dev[USB_MAX_HUB];
static int usb_hub_index;
+__weak void usb_hub_reset_devices(int port)
+{
+ return;
+}
static int usb_get_hub_descriptor(struct usb_device *dev, void *data, int
size) {
@@ -444,6 +448,14 @@ static int usb_hub_configure(struct usb_device *dev)
: no );
usb_hub_power_on(hub);
+ /*
+ * Reset any devices that may be in a bad state when applying
+ * the power. This is a __weak function. Resettig of the devices
+ * should occur in the board file of the device.
+ */
+ for (i = 0; i dev-maxchild; i++)
+ usb_hub_reset_devices(i + 1);
+
for (i = 0; i dev-maxchild; i++) {
ALLOC_CACHE_ALIGN_BUFFER(struct usb_port_status, portsts, 1);
unsigned short portstatus, portchange;
We hae like 10 reset hooks in the usb code, this means something just isn't
right. The device doesn't enumerate, right ? Have you tried waiting a little
after releasing the reset and before starting the EHCI ?
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/7] ARM: OMAP5-uevm: Add usb device reset API
Dear Dan Murphy,
Add the call back to reset the LAN9730 after
the FEAT_POWER has been called.
Signed-off-by: Dan Murphy dmur...@ti.com
---
v3 - Added this patch to separate the patch series -
http://patchwork.ozlabs.org/patch/258229/
board/ti/omap5_uevm/evm.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index 9add0fd..42253fd 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -31,6 +31,7 @@
#ifdef CONFIG_USB_EHCI
#include usb.h
+#include asm/gpio.h
#include asm/arch/ehci.h
#include asm/ehci-omap.h
@@ -169,4 +170,14 @@ int ehci_hcd_stop(void)
ret = omap_ehci_hcd_stop();
return ret;
}
+
+void usb_hub_reset_devices(int port)
+{
+ /* The LAN9730 needs to be reset after the port power has been set. */
+ if (port == 3) {
+ gpio_direction_output(CONFIG_OMAP_EHCI_PHY1_RESET_GPIO, 0);
+ udelay(10);
+ gpio_direction_output(CONFIG_OMAP_EHCI_PHY1_RESET_GPIO, 1);
+ }
+}
Do you really need a config option for a board-specific GPIO used in a board
file?
#endif
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] failed to boot an compressed u-boot.bin
Hi, Denk: My code base is based on u-boot-2013.04 . I followed board\samsung\smdkc100\config.mk , and put it into my board related directory. About SPL approach: Did you suggest I put decompressed algorithm code into SPL code instead of adding a self-uncompressed header? Best wishes, In message fe7aded5c2218b4786c09cd97dc4c49f99d...@exchbj02.viatech.com.bj you wrote: I configured CONFIG_SYS_TEXT_BASE = 0x03F8 in config.mk when compiling u-boot source code. this has been moved out of config.mk ages ago. How old is your U-Boot version? The self-uncompressed code also put the uncompressed image at 0x03F8 Why don't you use an SPL approach instead? 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 Overdrawn? But I still have checks left! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] dfu, nand, ubi: add partubi alt settings for updating ubi partition
Hello Scott,
Am 18.07.2013 00:35, schrieb Scott Wood:
On 07/15/2013 11:54:09 PM, Heiko Schocher wrote:
updating an ubi partition needs a completely erased mtd partition,
see:
http://lists.infradead.org/pipermail/linux-mtd/2011-May/035416.html
So, add partubi alt setting for the dfu_alt_info environment
variable to mark this partition as an ubi partition. In case we
update an ubi partition, we erase after flashing the image into the
partition, the remaining sektors.
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
Cc: Tom Rini tr...@ti.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Marek Vasut ma...@denx.de
Cc: Wolfgang Denk w...@denx.de
---
- This patch is also a good starting point to fix up updating ubi, as
we currently use nand erase for erasing the sektors. This is
not the prefered way for writing an ubi image, see:
http://www.linux-mtd.infradead.org/faq/ubi.html#L_flash_img
This must be fixed ... we have no ubiformat in u-boot, or?
The lack of erase counter preservation is a problem, but the part about ECC on
erased pages is dealt with in U-Boot by the WITH_DROP_FFS flag.
Ah, ok!
- changes for v2:
- do not use spread = 1 for nand_erase_opts, to prevent
errormessage if there are bad blocks in the erase range.
---
drivers/dfu/dfu.c | 30 +-
drivers/dfu/dfu_nand.c | 26 ++
include/dfu.h | 2 ++
3 Dateien geändert, 57 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 0521752..7ba7026 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -23,6 +23,7 @@
#include errno.h
#include malloc.h
#include mmc.h
+#include nand.h
#include fat.h
#include dfu.h
#include linux/list.h
@@ -176,6 +177,34 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
ret = dfu-flush_medium(dfu);
printf(\nDFU complete CRC32: 0x%08x\n, dfu-crc);
+ /* in case of ubi partition, erase rest of the partition */
+ if (dfu-ubi == 1) {
+ int ret;
+ nand_info_t *nand;
+ /* erase complete partition */
+ nand_erase_options_t opts;
+
+ if (nand_curr_device 0 ||
+ nand_curr_device = CONFIG_SYS_MAX_NAND_DEVICE ||
+ !nand_info[nand_curr_device].name) {
+ printf(%s: invalid nand device\n, __func__);
+ return -1;
+ }
+
+ nand = nand_info[nand_curr_device];
+
+ memset(opts, 0, sizeof(opts));
+ opts.offset = dfu-data.nand.start + dfu-offset +
+ dfu-bad_skip;
+ opts.length = dfu-data.nand.start +
+ dfu-data.nand.size - opts.offset;
+ ret = nand_erase_opts(nand, opts);
+ if (ret != 0) {
+ printf(Failure erase: %d\n, ret);
+ return ret;
+ }
+ }
Instead of separately erasing the remainder of the partition, how about
recognizing up front that it's UBI (or that a full partition erase is otherwise
desired) and erasing the full partition then? Besides being cleaner, it would
be easier to convert to
an ubi-aware mechanism.
I tried this too, but if I erase the hole partition first (when
a dfu transfer is started) I got:
GADGET DRIVER: usb_dnl_dfu
dfu_write: Wrong sequence number! [7] [0]
dfu_write: Wrong sequence number! [7] [1]
dfu_write: Wrong sequence number! [7] [2]
So, this version needs more investigation ...
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] [RFC][DFU] Unification of dfu_alt_info alt settings description + command execution
Hello Marek, Am 18.07.2013 06:17, schrieb Marek Vasut: Dear Heiko Schocher, Hello Lukasz, Am 16.07.2013 17:35, schrieb Lukasz Majewski: Dear All, Since DFU usage at u-boot is spreading to different device types (MMC, NAND), file systems, raw partitions, ubi, etc, I think that it is a good moment to unify and structure the form of dfu_alt_info environment variable. Full Ack! Proposed new format for single dfu entity: NAME | Type | Device | Dev_num | Dev_part | FS | start | size | where: Name - name of the alt setting (as seen by dfu-util -l) Type - description of the image (raw, file, img, command [*]) Device - physical device on which data are stored (mmc, nand, -) Dev_num - number of the device - it is possible to store data via DFU on several devices of the same type. Dev_part - number of partitions on the device. Should this be number of the partition on the device You mean here the mtd partition for storing, right? FS - information about file system on the device (fat, ext2/ext4, ubi). start- start offset from the beginning of the Device (byte or LBA number addressed) size - maximal number of blocks to be stored on the Device (expressed with Bytes of LBA number) (protection from overwriting the whole device) Example: Maybe dummy questions ... NAME | Type | Device | Dev_num | Dev_part | FS | start | size | -- u-boot | raw | mmc| 0 | - [**] | - | 0x80 | 0x100 | uImage | file | mmc| 0 | 2| ext4 | - | - | Is this enough information? Where to store the uImage file on the ext4 partition? root.img | img | mmc| 0 | 5| - | - | - | img means here: getting an image and storing it on the mtd partition Dev_part if start and size are marked with -, beginning on start of the partition? Wouldn't it be better to use here mtd partition names instead numbers for Dev_part? What if start and size are filled with values for the Type img? Or is this forbidden for the Type img? root.img | raw | mmc| 0 | - | - | 0x1000| 0x4000| u-boot | raw | nand | 0 | - | - | 0x100 | 0x100 | uImage | file | nand | 0 | 3| ubi | - | - | s/uImage/rootfs.img ? s/file/img ? For the FS ubi we need to specify, how to burn this into nand. I think we have no ubi format command. Try nand write.trimffs to write UBI images produced with ubinize . This solves not the erasecounter problem, or? For UBI we need something like this: http://www.linux-mtd.infradead.org/doc/ubi.html#L_flasher_algo But I am not an UBI expert. It is possible I overlook something obvious ... 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] [RFC][DFU] Unification of dfu_alt_info alt settings description + command execution
Hello Lukasz, Am 17.07.2013 16:34, schrieb Lukasz Majewski: On Wed, 17 Jul 2013 12:26:35 +0200 Heiko Schocher h...@denx.de wrote, Hi Heiko, Hello Lukasz, Am 16.07.2013 17:35, schrieb Lukasz Majewski: Dear All, Since DFU usage at u-boot is spreading to different device types (MMC, NAND), file systems, raw partitions, ubi, etc, I think that it is a good moment to unify and structure the form of dfu_alt_info environment variable. Full Ack! Proposed new format for single dfu entity: NAME | Type | Device | Dev_num | Dev_part | FS | start | size | where: Name - name of the alt setting (as seen by dfu-util -l) Type - description of the image (raw, file, img, command [*]) Device - physical device on which data are stored (mmc, nand, -) Dev_num - number of the device - it is possible to store data via DFU on several devices of the same type. Dev_part - number of partitions on the device. Should this be number of the partition on the device No. I made a mistake. It should be partition to which we want to write You mean here the mtd partition for storing, right? Yes, number of the partition to store data. The exact address will be extracted from mtdparts or partitions env variable. Ok. FS - information about file system on the device (fat, ext2/ext4, ubi). start- start offset from the beginning of the Device (byte or LBA number addressed) size - maximal number of blocks to be stored on the Device (expressed with Bytes of LBA number) (protection from overwriting the whole device) Example: Maybe dummy questions ... NAME | Type | Device | Dev_num | Dev_part | FS | start | size | -- u-boot | raw | mmc| 0 | - [**] | - | 0x80 | 0x100 | uImage | file | mmc| 0 | 2| ext4 | - | - | Is this enough information? Where to store the uImage file on the ext4 partition? To store uImage file on ext4/fat/ext2 partition it is enough to only give: uImage mmc 0 2, which maps to the following command: ext4write mmc 0:2 0x4400 /uImage [size] Hmm... and what if I have my uImage in /boot/ ? The file size is taken from number of sent bytes via DFU/USB. Yes. With writing to file system, one need to first store the whole transmitted data to a buffer and then store the (big) buffer on the SD/eMMC device. Ok, same for an ubi image. Since, we aren't supporting seek kind of write to current ext4 implementation at u-boot, the big buffer must be used. Ok, there are places to optimize ;-) root.img | img | mmc| 0 | 5| - | - | - | img means here: getting an image and storing it on the mtd partition Dev_part if start and size are marked with -, beginning on start of the partition? No, here img is for example a rootfs image. When storing it on the eMMC, it would be better to specify destination partition. Wouldn't it be better to use here mtd partition names instead numbers for Dev_part? I'd prefer to create a new entrance here (Part_name): NAME | Type | Device | Dev_num | Dev_part | Part_name | FS | start | size | I would like to avoid situation with ambiguous fields. One field shall only serve for one (clear) purpose. When not needed/used - field shall be marked as -. Ok. but this gives long constructs ... What if start and size are filled with values for the Type img? Or is this forbidden for the Type img? I think, that each Type shall have predefined set of allowed attributes: 1. img: Device + Dev num + Dev parts 2. raw: Device + Dev num + start + size 3. file: Device + Dev num + Dev parts + FS and so on. If we introduce a Part_name this should be also possible: 4. img: Device + Dev num + Part_name 5. file: Device + Dev num + Part_name + FS or? root.img | raw | mmc| 0 | - | - | 0x1000| 0x4000| u-boot | raw | nand | 0 | - | - | 0x100 | 0x100 | uImage | file | nand | 0 | 3| ubi | - | - | s/uImage/rootfs.img ? s/file/img ? NAME: uImage and rootfs.img maps to files sent to board. The NAME is used thereafter to provide exact name for file system write (ext4write/ fatwrite). Ah! If we have to write in a subdirectory, NAME is the fullpath + filename? With DFU the distinction between dfu entities (files, raw images, etc) is performed via alt settings (-aX switch at dfu-util). For the FS ubi we need to specify, how to burn this into nand. I think we have no ubi format command. Is already ubi format command available at u-boot? No. _As a side note:_ I'm now developing proof-of-concept idea of executing set of commands sent to u-boot by dfu-util [***]. Ok. Rationale for this is the lack of ability to reset u-boot after sending data to u-boot via DFU. dfu-util has -R option, but this seems to reset usb interface, not the target device. That answers my next question which comed in my mind ... I
