[U-Boot] T1040RDB u-boot chain load u-boot
Hello, I have a u-boot-with-spl-pbl.bin booting off NAND, and now I would like to create another build of u-boot to be chain-loaded, and I would appreciate some assistance. I'm using u-boot tag v2018.05, config T1040RDB_NAND_defconfig as base. Here's what I tried Scenario 1: Checking the defconfig, I see that CONFIG_SYS_TEXT_BASE=0x30001000, so I went ahead and tried: => tftp 30001000 u-boot.bin => go 30001000 ## Starting application at 0x30001000 ... and it hangs Scenario 2: Different load address: => tftp 100 u-boot.bin => go 100 ## Starting application at 0x0100 ... hang Scenario 3: I was thinking that maybe I need to bump the load and text address by 8MB so it does not matches the currently running u-boot (which has CONFIG_SYS_TEXT_BASE=0x30001000), so I applied the following patch: --- a/configs/T1040RDB_NAND_defconfig +++ b/configs/T1040RDB_NAND_defconfig -CONFIG_SYS_TEXT_BASE=0x30001000 +CONFIG_SYS_TEXT_BASE=0x30801000 => tftp 30801000 u-boot.bin => go 30801000 same hang also different address: => tftp 100 u-boot.bin => go 100 ## Starting application at 0x0100 ... Scenario 4: Remove RAMBOOT_PBL from defconfig: -CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL" +CONFIG_SYS_EXTRA_OPTIONS="SPL_FSL_PBL" This results in a binary that is more than 3GB (??) Scenario 4.1: I noticed that CONFIG_SYS_TEXT_BASE affects the size of binary so I thought I can fix this by placing it near RAM end, 4 GB - 8 MB: -CONFIG_SYS_TEXT_BASE=0x30001000 +CONFIG_SYS_TEXT_BASE=0xFF80 -CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL" +CONFIG_SYS_EXTRA_OPTIONS="SPL_FSL_PBL" but the size of u-boot.bin is ~249 MB I also went through, doc/README.ramboot-ppc85xx which describes what I need. Looking over ./arch/powerpc/cpu/mpc85xx/start.S, I see that CCSR relocation is happening but I can't tell to which value, which might explain why I get hangs. I'll have to investigate more. Any ideas are appreciated. Best regards, Nicolae ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] README: fix typo FAT_ENV_DEV_AND_PART
From: Nicolae Rosia The actual define symbol is FAT_ENV_DEVICE_AND_PART Signed-off-by: Nicolae Rosia --- README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README b/README index 00830d7..d6b430a 100644 --- a/README +++ b/README @@ -4115,7 +4115,7 @@ but it can not erase, write this NOR flash by SRIO or PCIE interface. Define this to a string that is the name of the block device. - - FAT_ENV_DEV_AND_PART: + - FAT_ENV_DEVICE_AND_PART: Define this to a string to specify the partition of the device. It can be as following: -- 2.5.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot on qemu vexpress-a9
Hello, On Thu, Oct 27, 2016 at 3:00 PM, Nicolae Rosia wrote: > [0] https://bugs.launchpad.net/qemu/+bug/1579327?comments=all Booting a Linux kernel with -smp 4 works just fine, so I believe the bug is in u-boot. Thanks, Nicolae ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot on qemu vexpress-a9
Hello, I'm trying to run u-boot on qemu machine vexpress-a9 and I get the following weird output and crash: $ qemu-system-arm -M vexpress-a9 -m 1024 -smp 4 -nographic -kernel u-boot U-Boot 2016.11-rc2-00090-g5ac5861-dirty (Oct 27 2016 - 14:46:54 +0300) DRAM: 1 GiB WARNING: Caches not enabled Flash: U-Boot 2016.11-rc2-00090-g5ac5861-dirty (Oct 27 2016 - 14:46:54 +0300) DRAM: 1 GiB WARNING: Caches not enabled Flash: U-Boot 2016.11-rc2-00090-g5ac5861-dirty (Oct 27 2016 - 14:46:54 +0300) DRAM: 1 GiB WARNING: Caches not enabled Flash: U-Boot 2016.11-rc2-00090-g5ac5861-dirty (Oct 27 2016 - 14:46:54 +0300) DRAM: 1 GiB WARNING: Caches not enabled Flash: Bad ram pointer (nil) Aborted (core dumped) I've only tried this on master (5ac5861c4ba851b473e6a24940b412b397627d8d), config vexpress_ca9x4_defconfig, with qemu 2.7.0 and 2.4.1. Since I don't know if this is a u-boot bug or qemu bug, I've also reported this on qemu [0] Best regards, Nicolae Rosia [0] https://bugs.launchpad.net/qemu/+bug/1579327?comments=all ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] power: twl6030: fix code refactoring
Hi, On Sat, Oct 15, 2016 at 8:48 PM, Tom Rini wrote: > I'll take this and do you want to do a follow up to make the file > checkpatch clean? Thanks! Either way works for me, I can do the follow up to make the file checkpatch clean. Thanks, Nicolae ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] power: twl6030: fix code refactoring
Hi, On Fri, Oct 14, 2016 at 4:28 PM, Paul Kocialkowski wrote: > Le jeudi 13 octobre 2016 à 13:47 +0300, Nicolae Rosia a écrit : >> From: Nicolae Rosia >> >> Commit a85362fb3e1fc7833723accddbbae431091d06b8 refactored the code >> but the register read ended up in the wrong if branch. >> Currently, the else branch checks a variable which is always 0. > > Good catch! Sorry for including that regression in the first place, I should > have checked the patch more thoroughly. No worries! > See comment below. > The indentation before &value is inconsistent with what is done in the rest of > the file. I think you should either just move the line as it was or only use > one > extra tab indent for the new line. Since this file breaks the 80 chars limit > in > a few places, I would tend to prefer the former. > checkpatch.pl was complaining, that's why I formatted it. @Tom Rini, can you apply it either way? Best regards, Nicolae ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] power: twl6030: fix code refactoring
From: Nicolae Rosia
Commit a85362fb3e1fc7833723accddbbae431091d06b8 refactored the code
but the register read ended up in the wrong if branch.
Currently, the else branch checks a variable which is always 0.
Signed-off-by: Nicolae Rosia
---
drivers/power/twl6030.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/power/twl6030.c b/drivers/power/twl6030.c
index 05c79be..cd53200 100644
--- a/drivers/power/twl6030.c
+++ b/drivers/power/twl6030.c
@@ -231,9 +231,9 @@ void twl6030_power_mmc_init(int dev_index)
/* Enable P1 output for VMMC */
twl6030_i2c_write_u8(TWL6030_CHIP_PM, TWL6030_VMMC_CFG_STATE,
TWL6030_CFG_STATE_P1 | TWL6030_CFG_STATE_ON);
-
- twl6030_i2c_read_u8(TWL6030_CHIP_PM, TWL6030_PH_STS_BOOT,
&value);
} else if (dev_index == 1) {
+ twl6030_i2c_read_u8(TWL6030_CHIP_PM, TWL6030_PH_STS_BOOT,
+ &value);
/* BOOT2 indicates 1.8V/2.8V VAUX1 for eMMC */
if (value & TWL6030_PH_STS_BOOT2) {
/* 1.8V voltage output for VAUX1 */
--
2.5.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] STM32F7 Discovery hangs on master
Hello, I just tested v2016.11-rc1 on STM32F7 Discovery and it hangs: (gdb) c Continuing. ^C Program received signal SIGTRAP, Trace/breakpoint trap. 0x08000d56 in dram_init () at board/st/stm32f746-disco/stm32f746-disco.c:211 211 FMC_BUSY_WAIT(); (gdb) bt #0 0x08000d56 in dram_init () at board/st/stm32f746-disco/stm32f746-disco.c:211 #1 0x0800d75a in initcall_run_list (init_sequence=init_sequence@entry=0x801b434 ) at lib/initcall.c:31 #2 0x0800614e in board_init_f (boot_flags=) at common/board_f.c:1081 #3 0x0800046a in _main () at arch/arm/lib/crt0.S:93 #4 0x0800046a in _main () at arch/arm/lib/crt0.S:93 Backtrace stopped: previous frame inner to this frame (corrupt stack?) It prints this: U-Boot 2016.11-rc1 (Oct 04 2016 - 19:53:31 +0300) DRAM: 8 MiB or this: U-Boot 2016.11-rc1 (Oct 04 2016 - 19:53:31 +0300) DRAM: Reverting 25c1b1353ce4b8188de6058f9f3b0d5d2dad8230 (not desirable) makes it working again but I can't seem to write anything to the console. Offtopic: How are you developing for this board? I'm using gcc 5_4-2016q3 from [0], st-util [1] which exports a /dev/ttyACM0 UART port I'm using at 115200n8 and gdb connected to st-util gdbserver. Best regards, Nicolae Rosia [0] https://github.com/texane/stlink [1] https://launchpad.net/gcc-arm-embedded ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode
Hello Michal,
I have a minor comment.
On Thu, Apr 28, 2016 at 11:43 AM, Michal Simek wrote:
> Support loading FIT in SPL for RAM bootmode.
> CONFIG_SPL_LOAD_FIT_ADRESS points to address where FIT image is stored
> in memory.
>
> Signed-off-by: Michal Simek
> ---
>
[...]
> + debug("%s: sector %lx, count %lx, buf %lx\n",
> + __func__, sector, count, (ulong)buf);
> + memcpy(buf, (void *)(CONFIG_SPL_LOAD_FIT_ADRESS + sector), count);
s/CONFIG_SPL_LOAD_FIT_ADRESS/CONFIG_SPL_LOAD_FIT_ADDRESS
[...]
> -*/
> - header = (struct image_header *)
> - (CONFIG_SYS_TEXT_BASE - sizeof(struct image_header));
> + header = (struct image_header *)CONFIG_SPL_LOAD_FIT_ADRESS;
s/CONFIG_SPL_LOAD_FIT_ADRESS/CONFIG_SPL_LOAD_FIT_ADDRESS
[...]
Regards,
Nicolae
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] WIP: Example changes to build EFI stub for x86
Hi,
On Wed, Apr 6, 2016 at 6:06 PM, Simon Glass wrote:
> Currently it is not possible to build the 64-bit EFI stub due to changes in
> the build. To prevent future bit rot, we should add target for building
> qemu-x86 as an EFI stub (with U-Boot as a 32-bit payload).
>
> This patch provides some hints.
>
> Reported-by: Nicolae Rosia
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/include/asm/types.h | 12
> configs/qemu-x86_defconfig | 3 +++
> include/efi.h| 2 +-
> lib/efi/efi_stub.c | 6 +++---
> 4 files changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/include/asm/types.h b/arch/x86/include/asm/types.h
> index 766617f..998d70a 100644
> --- a/arch/x86/include/asm/types.h
> +++ b/arch/x86/include/asm/types.h
> @@ -44,11 +44,15 @@ typedef __INT64_TYPE__ s64;
> typedef __UINT64_TYPE__ u64;
> #endif
>
> -#ifdef CONFIG_EFI_STUB_64BIT
> -#define BITS_PER_LONG 64
> -#else
> +/*
> + * This should be defined only when compiling the stub - see the
> + * ecmd_u-boot_payload build rule
> + */
Are you saying that I should take a look at cmd_u-boot_payload in Makefile?
I've looked over it and I don't figure out what I should see.
> +// #ifdef CONFIG_EFI_STUB_64BIT
> +// #define BITS_PER_LONG 64
> +// #else
> #define BITS_PER_LONG 32
> -#endif
> +// #endif
This fixes the compilation warnings
> /* Dma addresses are 32-bits wide. */
>
> typedef u32 dma_addr_t;
> diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
> index bb9c6cd..2a7087f 100644
> --- a/configs/qemu-x86_defconfig
> +++ b/configs/qemu-x86_defconfig
> @@ -32,3 +32,6 @@ CONFIG_VIDEO_VESA=y
> CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
> CONFIG_FRAMEBUFFER_VESA_MODE_111=y
> CONFIG_USE_PRIVATE_LIBGCC=y
> +CONFIG_EFI=y
> +CONFIG_EFI_STUB=y
> +CONFIG_EFI_STUB_64BIT=y
Should we create an example defconfig for efi stub and not modify the
qemu defconfig?
> diff --git a/include/efi.h b/include/efi.h
> index 1dbc3b7..21921f1 100644
> --- a/include/efi.h
> +++ b/include/efi.h
> @@ -278,7 +278,7 @@ struct efi_priv {
> extern char image_base[];
>
> /* Start and end of U-Boot image (for payload) */
> -extern char _binary_u_boot_dtb_bin_start[], _binary_u_boot_dtb_bin_end[];
> +extern char _binary_u_boot_bin_start[], _binary_u_boot_bin_end[];
>
> /**
> * efi_get_sys_table() - Get access to the main EFI system table
> diff --git a/lib/efi/efi_stub.c b/lib/efi/efi_stub.c
> index 8b4bb4e..1814960 100644
> --- a/lib/efi/efi_stub.c
> +++ b/lib/efi/efi_stub.c
> @@ -354,9 +354,9 @@ efi_status_t efi_main(efi_handle_t image, struct
> efi_system_table *sys_table)
> /* The EFI UART won't work now, switch to a debug one */
> use_uart = true;
>
> - memcpy((void *)CONFIG_SYS_TEXT_BASE, _binary_u_boot_dtb_bin_start,
> - (ulong)_binary_u_boot_dtb_bin_end -
> - (ulong)_binary_u_boot_dtb_bin_start);
> + memcpy((void *)CONFIG_SYS_TEXT_BASE, _binary_u_boot_bin_start,
> + (ulong)_binary_u_boot_bin_end -
> + (ulong)_binary_u_boot_bin_start);
>
Thanks, these fixes the compilation errors.
> #ifdef DEBUG
> puts("EFI table at ");
> --
> 2.8.0.rc3.226.g39d4020
>
I'll try to boot test.
Best regards,
Nicolae
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] EFI Stub compilation errors
Hello, I'm trying to build U-Boot as an UEFI Payload, head 4ed6ed3c27a069a00c8a557d606a05276cc4653e, branch master. I did the following: make qemu-x86_defconfig make menuconfig Enable the following: CONFIG_EFI=y EFI_STUB=y EFI_STUB_64BIT=y make I gets lots of warnings ([0]) and the following error: /home/user/workspace/u-boot/lib/efi/efi_stub.c:357: undefined reference to `_binary_u_boot_dtb_bin_start' /home/user/workspace/u-boot/lib/efi/efi_stub.c:357: undefined reference to `_binary_u_boot_dtb_bin_end' Any idea what I'm doing wrong? Best regards, Nicolae [0] make log http://pastebin.com/geb5RqTW ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Variable content dump to memory
On Thu, Mar 24, 2016 at 7:51 PM, James Chargin wrote: [...] > You weren't completely specific about your needs, but assuming you are > wanting to write a U-Boot environment variable to memory, try something like > You're right. I'm trying to do the following: U-Boot# setenv mytext 'This is a long text' U-Boot# printenv mytext mytext=This is a long text and somehow write it to a memory address so I can use it with ext4write. Best regards, Nicolae ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Variable content dump to memory
Hello, I'm trying to write the contents of a variable to a file using ext4write but it requires a memory address as input. Is there an easy way to get the contents of a variable to a particular mem address? Best regards, Nicolae ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
