[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