Re: [PATCH] arch/riscv/dts: Fix uart reg-shift on fu540/fu740 SiFive devices
January 23, 2023 8:08 PM, "Alexander von Gluck IV" wrote: > * Not specifying reg-shift creates a situation where the register > shift is unknown and can only be decoded via special compat > cases. > * The device tree specification states: > "...reg-shift. If unspecified, the default value is 0." > https://devicetree-specification.readthedocs.io/en/latest/chapter4-device-bindings.html > * Since the reg-shift for the SiFive boards is *NOT* 0, it shall > be defined as 2 Groan, ignore this patch. I misread somewhere that the sifive,uart0 was 8250 compatible. It is not, and doesn't use any kind of shift other than registers fitting into struct of unions. I'm herding too many cats. -- Alex
[PATCH] arch/riscv/dts: Fix uart reg-shift on fu540/fu740 SiFive devices
* Not specifying reg-shift creates a situation where the register
shift is unknown and can only be decoded via special compat
cases.
* The device tree specification states:
"...reg-shift. If unspecified, the default value is 0."
https://devicetree-specification.readthedocs.io/en/latest/chapter4-device-bindings.html
* Since the reg-shift for the SiFive boards is *NOT* 0, it shall
be defined as 2
---
arch/riscv/dts/fu540-c000.dtsi | 1 +
arch/riscv/dts/fu740-c000.dtsi | 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/riscv/dts/fu540-c000.dtsi b/arch/riscv/dts/fu540-c000.dtsi
index 7db8610534..0bea8cf1e5 100644
--- a/arch/riscv/dts/fu540-c000.dtsi
+++ b/arch/riscv/dts/fu540-c000.dtsi
@@ -161,6 +161,7 @@
uart0: serial@1001 {
compatible = "sifive,fu540-c000-uart", "sifive,uart0";
reg = <0x0 0x1001 0x0 0x1000>;
+ reg-shift = <2>;
interrupt-parent = <>;
interrupts = <4>;
clocks = < PRCI_CLK_TLCLK>;
diff --git a/arch/riscv/dts/fu740-c000.dtsi b/arch/riscv/dts/fu740-c000.dtsi
index 7b77c13496..19da3709f0 100644
--- a/arch/riscv/dts/fu740-c000.dtsi
+++ b/arch/riscv/dts/fu740-c000.dtsi
@@ -164,6 +164,7 @@
uart0: serial@1001 {
compatible = "sifive,fu740-c000-uart", "sifive,uart0";
reg = <0x0 0x1001 0x0 0x1000>;
+ reg-shift = <2>;
interrupt-parent = <>;
interrupts = <39>;
clocks = < FU740_PRCI_CLK_PCLK>;
@@ -172,6 +173,7 @@
uart1: serial@10011000 {
compatible = "sifive,fu740-c000-uart", "sifive,uart0";
reg = <0x0 0x10011000 0x0 0x1000>;
+ reg-shift = <2>;
interrupt-parent = <>;
interrupts = <40>;
clocks = < FU740_PRCI_CLK_PCLK>;
--
2.39.1
Re: riscv64 regression
January 4, 2023 9:35 AM, "Alex" wrote: > Seeing a regression in functionality across multiple devices. I did a bit of > bisecting, here's the > path: EEh. Just added another data point. The breakage for us happens on the gcc 11.3.0 upgrade of u-boot, not the 12.2.0 upgrade of u-boot. Thu May 5 19:37:22 2022 -0400 working: 03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 11.1.0 broke: 03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 11.3.0 (rebuild) no build: 03b873b4f41010e4f85a72dd59016bb0b123dde1 gcc 12.2.0 unrecognized opcode `csrs sstatus,a5', extension `zicsr' required Wed Oct 12 14:59:51 2022 +0200 broke:e67f34f778baabd76f2e0e645a409fed14d2d156 gcc 12.2.0 (fixes zicsr issue) Mon Dec 19 08:45:26 2022 -0500 broke: 2243922edca9f56a9d5519b9d6e36f5d7a18434d gcc 11.1.0 (gets further) broke: 2243922edca9f56a9d5519b9d6e36f5d7a18434d gcc 12.2.0 (errors out sooner) Maybe the fact that the gcc 11.1.0 u-boot binary boots our EFI loader consistently is just a fluke. I know adding some printf statements into our efi bootloader changes the behavior and solves some memory access errors / Load Access Faults... so probably something with our memory layout? -- Alex
[PATCH] efi_loader (v2): Expose relocated address for gdb debugging purposes
* If users want to debug EFI applications via qemu + GDB, they
need to know the relocated address of the application to
align their symbols to in GDB via add-symbol-file.
* This exposes where EFI applications are relocated to enable
debugging EFI applications via qemu + gdb
* Usage is generally determining the address, then
add-symbol-file (efi loader) (address)
* The address can change, but is generally consistent with
the same qemu version and u-boot binary. (allowing you to
boot once, find the address, then reboot with qemu -s -S
---
include/efi_loader.h | 3 +++
lib/efi_loader/efi_boottime.c | 1 +
lib/efi_loader/efi_image_loader.c | 3 +++
3 files changed, 7 insertions(+)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index f4860e87fc..2ca2bf3adb 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -403,6 +403,7 @@ enum efi_image_auth_status {
* @exit_data_size:exit data size passed to Exit()
* @exit_data: exit data passed to Exit()
* @exit_jmp: long jump buffer for returning from started image
+ * @reloc_addr:relocated address of the image
* @entry: entry address of the relocated image
* @image_type:indicates if the image is an applicition or a
driver
* @auth_status: indicates if the image is authenticated
@@ -413,6 +414,8 @@ struct efi_loaded_image_obj {
efi_uintn_t *exit_data_size;
u16 **exit_data;
struct jmp_buf_data *exit_jmp;
+
+ u64 reloc_addr;
EFIAPI efi_status_t (*entry)(efi_handle_t image_handle,
struct efi_system_table *st);
u16 image_type;
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 20b69699fe..6fac8c576e 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -3057,6 +3057,7 @@ efi_status_t EFIAPI efi_start_image(efi_handle_t
image_handle,
current_image = image_handle;
image_obj->header.type = EFI_OBJECT_TYPE_STARTED_IMAGE;
+ log_info("EFI image relocated to 0x%llx\n", image_obj->reloc_addr);
EFI_PRINT("Jumping into 0x%p\n", image_obj->entry);
ret = EFI_CALL(image_obj->entry(image_handle, ));
diff --git a/lib/efi_loader/efi_image_loader.c
b/lib/efi_loader/efi_image_loader.c
index 773bd0677c..65e5b7e40b 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -906,6 +906,7 @@ efi_status_t efi_load_pe(struct efi_loaded_image_obj
*handle,
ret = EFI_OUT_OF_RESOURCES;
goto err;
}
+ handle->reloc_addr = (u64)efi_reloc;
handle->entry = efi_reloc + opt->AddressOfEntryPoint;
rel_size = opt->DataDirectory[rel_idx].Size;
rel = efi_reloc + opt->DataDirectory[rel_idx].VirtualAddress;
@@ -922,6 +923,8 @@ efi_status_t efi_load_pe(struct efi_loaded_image_obj
*handle,
ret = EFI_OUT_OF_RESOURCES;
goto err;
}
+
+ handle->reloc_addr = (u64)efi_reloc;
handle->entry = efi_reloc + opt->AddressOfEntryPoint;
rel_size = opt->DataDirectory[rel_idx].Size;
rel = efi_reloc + opt->DataDirectory[rel_idx].VirtualAddress;
--
2.35.1
Re: [PATCH] efi_loader: Expose relocated address for gdb debugging purposes
March 24, 2022 12:06 PM, "Heinrich Schuchardt" wrote: > On 3/24/22 17:22, Alexander von Gluck IV wrote: > Do we really always need this output for every invokation of LoadImage()? > > Writing test messages during the runtime of a menu driven program like > the UEFI SCT can be very disturbing. > > Isn't it sufficient to show this output for binaries directly launched > by U-Boot? Ideally this would be exposed strictly for the binaries directly launched, however the bare relocated address isn't exposed outside of the brief usage by LoadImage. I figured that adding a required pointer arg to expose the relocated address might be overkill. using log_debug over log_info was brought up as a good change, but that still suffers the same potential impact. Maybe adding reloc_addr storage to efi_loaded_image_obj would be cleaner? (then digging it up during the efi launch for a quick log_info?) -- Alex
Re: [RFC] Dumping load addresses - bootefi qemu gdb remote debugging
See "[PATCH] efi_loader: Expose relocated address for gdb debugging purposes" This actually solves the problem by exposing (previously hidden) relocated address. Now it's a *LOT* easier to debug u-boot loaded EFI binaries using the exposed address: This is helpful on pretty much every architecture (arm, arm64, riscv64) (gdb) target extended-remote 127.0.0.1:1234 Remote debugging using 127.0.0.1:1234 0x1000 in ?? () (gdb) add-symbol-file u-boot 0xfff66000 add symbol table from file "u-boot" at .text_addr = 0xfff66000 (y or n) y Reading symbols from u-boot... **ADDRESS from this new log_info:** (gdb) add-symbol-file objects/haiku/riscv64/debug_1/system/boot/efi/boot_loader_efi 0xbe6c6000 add symbol table from file "objects/haiku/riscv64/debug_1/system/boot/efi/boot_loader_efi" at .text_addr = 0xbe6c6000 (y or n) y Reading symbols from objects/haiku/riscv64/debug_1/system/boot/efi/boot_loader_efi... (gdb) break platform_start_kernel Breakpoint 1 at 0xbe6ca87c: file ../src/system/boot/platform/efi/start.cpp, line 178. (gdb) c Continuing. Breakpoint 1, platform_start_kernel () at ../src/system/boot/platform/efi/start.cpp:178 178 smp_init_other_cpus(); ^^ success! Thanks to apalos in IRC for helping to identity where to add this! -- Alex March 24, 2022 10:27 AM, "Bin Meng" wrote: > +Heinrich Schuchardt > > On Thu, Mar 24, 2022 at 10:51 PM Alex wrote: > >> Good morning! >> >> So, some time ago I wrote a short guide on how to debug EFI bootloaders >> started >> by u-boot in qemu. >> >> https://www.haiku-os.org/blog/kallisti5/2021-01-17_debugging_riscv-64_bootloader_in_qemu >> >> At the time it worked, however figuring the elf load addresses from u-boot >> was extremely >> difficult and required compiling it with full tracing and taking guesses at >> various EFI: Entry efi_load_image messages until I found the correct address. >> >> Is there an easier way to find the load addresses? If not, a more verbose >> message >> on non-debug builds might be extremely useful here. >> >> "positioning image at address 0xfe6b" or something >> >> using the leveraged kernel_addr_r (0x8400) was not enough. >> >> -- Alex
[PATCH] efi_loader: Expose relocated address for gdb debugging purposes
* If users want to debug EFI applications via qemu + GDB, they
need to know the relocated address of the application to
align their symbols to in GDB via add-symbol-file.
* This exposes where EFI applications are relocated to enable
debugging EFI applications via qemu + gdb
* Usage is generally determining the address, then
add-symbol-file (efi loader) (address)
* The address can change, but is generally consistent with
the same qemu version and u-boot binary. (allowing you to
boot once, find the address, then reboot with qemu -s -S
---
lib/efi_loader/efi_image_loader.c | 4
1 file changed, 4 insertions(+)
diff --git a/lib/efi_loader/efi_image_loader.c
b/lib/efi_loader/efi_image_loader.c
index 773bd0677c..2b8c1ef464 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -906,6 +906,8 @@ efi_status_t efi_load_pe(struct efi_loaded_image_obj
*handle,
ret = EFI_OUT_OF_RESOURCES;
goto err;
}
+ log_info("64-bit EFI image loaded at relocated address %p\n",
efi_reloc);
+
handle->entry = efi_reloc + opt->AddressOfEntryPoint;
rel_size = opt->DataDirectory[rel_idx].Size;
rel = efi_reloc + opt->DataDirectory[rel_idx].VirtualAddress;
@@ -922,6 +924,8 @@ efi_status_t efi_load_pe(struct efi_loaded_image_obj
*handle,
ret = EFI_OUT_OF_RESOURCES;
goto err;
}
+ log_info("32-bit EFI image loaded at relocated address %p\n",
efi_reloc);
+
handle->entry = efi_reloc + opt->AddressOfEntryPoint;
rel_size = opt->DataDirectory[rel_idx].Size;
rel = efi_reloc + opt->DataDirectory[rel_idx].VirtualAddress;
--
2.35.1
Re: riscv64 - SiFive Unmatched regression?
March 17, 2022 1:51 PM, "Alex" wrote: > Hello! > > Running into a potential regression on the SiFive Unmatched. > > All SD cards provisioned using identical known-good steps documented by > u-boot. Please ignore. I was down to bisecting with multiple gcc toolchains building u-boot when I realized one of my (seemingly good) MicroSD cards were refusing to boot in the Unmatched. I swapped cards and things started working as expected. -- Alex
[PATCH] config/sifive_unmatched: add preboot commands
* Opens up u-boot to properly search through USB media for a valid boot media * The MMC on the unmatched is slow, so a model of running the OS from USB or NVMe is a compelling one. (putting just u-boot on the sd card) --- configs/sifive_unmatched_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/sifive_unmatched_defconfig b/configs/sifive_unmatched_defconfig index 38b7acd536..0e02d46f72 100644 --- a/configs/sifive_unmatched_defconfig +++ b/configs/sifive_unmatched_defconfig @@ -11,6 +11,7 @@ CONFIG_TARGET_SIFIVE_UNMATCHED=y CONFIG_ARCH_RV64I=y CONFIG_RISCV_SMODE=y # CONFIG_SPL_USE_ARCH_MEMMOVE is not set +CONFIG_PREBOOT="pci enum; usb start;" CONFIG_DISTRO_DEFAULTS=y CONFIG_FIT=y CONFIG_SPL_LOAD_FIT_ADDRESS=0x8400 -- 2.32.0
Re: [bug?] SiFive Unmatched default boot script update?
August 15, 2021 9:59 AM, "Alexander von Gluck IV" wrote: > Good morning! > > Mainline Haiku is now getting into the kernel on the SiFive Unmatched > board! > > Our current boot process involves running the following from u-boot > to boot Haiku from a USB drive: > > pci enum ; usb start ; run bootcmd_usb0 > > I feel like "pci enum; usb start;" should be default things to do on > the unmatched board if they're not already? If you don't run the commands > above, u-boot finds our EFI bootloader, but the the USB drives don't show > up in our EFI bootloader. > > Given the mmc card on the Unmatched is kind of slow, a model of having > u-boot on the mmc card, and booting from usb drives / nvme feels like > a good one. Digging into this slightly; it looks like the following is needed? diff --git a/configs/sifive_unmatched_defconfig b/configs/sifive_unmatched_defconfig index 38b7acd536..0e02d46f72 100644 --- a/configs/sifive_unmatched_defconfig +++ b/configs/sifive_unmatched_defconfig @@ -11,6 +11,7 @@ CONFIG_TARGET_SIFIVE_UNMATCHED=y CONFIG_ARCH_RV64I=y CONFIG_RISCV_SMODE=y # CONFIG_SPL_USE_ARCH_MEMMOVE is not set +CONFIG_PREBOOT="pci enum; usb start;" CONFIG_DISTRO_DEFAULTS=y CONFIG_FIT=y CONFIG_SPL_LOAD_FIT_ADDRESS=0x8400 That's the same thing the Raspberry Pi 4 does. -- Alex
[bug?] SiFive Unmatched default boot script update?
Good morning! Mainline Haiku is now getting into the kernel on the SiFive Unmatched board! Our current boot process involves running the following from u-boot to boot Haiku from a USB drive: pci enum ; usb start ; run bootcmd_usb0 I feel like "pci enum; usb start;" should be default things to do on the unmatched board if they're not already? If you don't run the commands above, u-boot finds our EFI bootloader, but the the USB drives don't show up in our EFI bootloader. Given the mmc card on the Unmatched is kind of slow, a model of having u-boot on the mmc card, and booting from usb drives / nvme feels like a good one. Thanks! -- Alex
Re: Pull request for UEFI sub-system for efi-2021-04-rc1-3
January 23, 2021 8:39 AM, "Heinrich Schuchardt" wrote: > efi_loader: correct EFI_BLOCK_IO_PROTOCOL.Media.LastBlock (2021-01-23 > 07:56:54 +0100) Confirming that these corrections fix the presented block devices by u-boot EFI to EFI binaries: Before: (nonsensical "last block" which is start + length) Welcome to the Haiku boot loader! platform_add_boot_device: called platform_add_boot_device: .. present: true, logical: false, removeable: false, blocksize: 512, lastblock: 681984 platform_add_boot_device: .. present: true, logical: true, removeable: false, blocksize: 512, lastblock: 679936 platform_add_boot_device: .. present: true, logical: true, removeable: false, blocksize: 512, lastblock: 614400 After: (correct "last block" which is start + length) Welcome to the Haiku boot loader! platform_add_boot_device: called platform_add_boot_device: .. present: true, logical: false, removeable: false, blocksize: 512, lastblock: 681983 platform_add_boot_device: .. present: true, logical: true, removeable: false, blocksize: 512, lastblock: 65535 platform_add_boot_device: .. present: true, logical: true, removeable: false, blocksize: 512, lastblock: 614399 -- Alex
Re: RISCV64 - u-boot FDT control address unset on qemu-riscv64_defconfig ?
August 27, 2020 9:40 AM, "Alexander von Gluck IV" wrote:
> Good morning!
>
> I was looking at booting Haiku's riscv64 EFI bootloader under qemu, and
> noticed several FDT errors:
> .
> .
> Shouldn't ${fdtcontroladdr} be the default fdt address on bootup?
>
> Here's my qemu command:
>
> qemu-system-riscv64 -bios ~/Code/firmware/u-boot/riscv64/qemu/u-boot.bin -M
> virt -device
> virtio-blk-device,drive=hd -drive
> file=~/Code/haiku/generated.riscv64/haiku-mmc.image,format=raw,id=hd -m 1024
Nevermind. I just checked and arm is the same way.
Added a boot.scr loading the fdt at ${fdtcontroladdr}, huzah...
U-Boot 2020.10-rc3 (Aug 27 2020 - 08:30:57 -0500)
CPU: rv64imafdcsu
Model: riscv-virtio,qemu
DRAM: 1 GiB
In:uart@1000
Out: uart@1000
Err: uart@1000
Net: No ethernet found.
Hit any key to stop autoboot: 0
Device 0: QEMU VirtIO Block Device
Type: Hard Disk
Capacity: 428.0 MB = 0.4 GB (876544 x 512)
... is now current device
Scanning virtio 0:1...
Found U-Boot script /boot.scr
1266 bytes read in 2 ms (618.2 KiB/s)
## Executing script at 8810
Haiku u-boot script entry
54 bytes read in 0 ms
uEnv.txt says to look for efi bootloader named EFI/BOOT/BOOTRISCV64.EFI on
virtio 0!
Found EFI/BOOT/BOOTRISCV64.EFI on virtio 0!
Loading bootloader...
595112 bytes read in 1 ms (567.5 MiB/s)
Using internal DTB...
Launching EFI loader...
Scanning disk virtio-blk#0...
Found 2 disks
No EFI system partition
(LOCKUP)
RISCV64 - u-boot FDT control address unset on qemu-riscv64_defconfig ?
Good morning!
I was looking at booting Haiku's riscv64 EFI bootloader under qemu, and noticed
several FDT errors:
Device 0: QEMU VirtIO Block Device
Type: Hard Disk
Capacity: 428.0 MB = 0.4 GB (876544 x 512)
... is now current device
Scanning virtio 0:1...
** Unable to read file / **
Failed to load '/'
Found EFI removable media binary efi/boot/bootriscv64.efi
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Scanning disk virtio-blk#0...
Found 2 disks
No EFI system partition
BootOrder not defined
EFI boot manager: Cannot load any image
595112 bytes read in 4 ms (141.9 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
A quick look showed this default state:
=> fdt list
No FDT memory address configured. Please configure
the FDT address via "fdt addr " command.
Aborting!
Tossing in the default fdtcontroladdr seemed to resolve the issue:
=> fdt addr ${fdtcontroladdr}
=> fdt list
/ {
#address-cells = <0x0002>;
#size-cells = <0x0002>;
compatible = "riscv-virtio";
model = "riscv-virtio,qemu";
flash@2000 {
};
chosen {
};
uart@1000 {
};
test@10 {
};
virtio_mmio@10008000 {
};
virtio_mmio@10007000 {
};
virtio_mmio@10006000 {
};
virtio_mmio@10005000 {
};
virtio_mmio@10004000 {
};
virtio_mmio@10003000 {
};
virtio_mmio@10002000 {
};
virtio_mmio@10001000 {
};
cpus {
};
memory@8000 {
};
soc {
};
};
Shouldn't ${fdtcontroladdr} be the default fdt address on bootup?
Here's my qemu command:
qemu-system-riscv64 -bios ~/Code/firmware/u-boot/riscv64/qemu/u-boot.bin -M
virt -device virtio-blk-device,drive=hd -drive
file=~/Code/haiku/generated.riscv64/haiku-mmc.image,format=raw,id=hd -m 1024
mkimage segfault on MacOS
I know this one is pretty far out there (and not expecting a solution here tbh), mkimage (installed via homebrew) is segfaulting under MacOS X (10.15.3) $ mkimage -A arm -O linux -T kernel -C none -a 0x100 -e 0x110 -n 'Haiku arm loader' -d objects/haiku/arm/release/system/boot/u-boot/boot_loader_u-boot haiku_loader.u-boot Segmentation fault: 11 I went through all the hoops to get gdb working (https://gist.github.com/gravitylow/fb595186ce6068537a6e9da6d8b5b96d) (https://gist.github.com/gravitylow/fb595186ce6068537a6e9da6d8b5b96d), but homebrew doesn't include debug symbols in mkimage :-| (gdb) run -A arm -O linux -T kernel -C none -a 0x100 -e 0x110 -d objects/haiku/arm/release/system/boot/u-boot/boot_loader_u-boot haiku_loader.u-boot Starting program: /usr/local/bin/mkimage -A arm -O linux -T kernel -C none -a 0x100 -e 0x110 -d objects/haiku/arm/release/system/boot/u-boot/boot_loader_u-boot haiku_loader.u-boot [New Thread 0x170b of process 76451] [New Thread 0x2503 of process 76451] warning: unhandled dyld version (16) Thread 2 received signal SIGSEGV, Segmentation fault. 0x7fff6e8ba2be in ?? () (gdb) bt #0 0x7fff6e8ba2be in ?? () #1 0x7ffeefbff8f0 in ?? () #2 0x00010002b000 in ?? () #3 0x04d9 in ?? () #4 0x000100020fb1 in copy_file () #5 0x00010002ca10 in padding_algos () #6 0x7ffeefbff818 in ?? () #7 0x0003 in ?? () #8 0x000100020dec in main () I need to install linux once the Apple T2 chipset driver is upstreamed. :-) Mostly posting this here as an FYI for any future folks who run into it. -- Alex
Re: u-boot 32-bit on Raspberry Pi 4
January 17, 2020 7:59 PM, "Jaehoon Chung" wrote:
> On 1/18/20 10:53 AM, Jaehoon Chung wrote:
>
>> Hi
>>
>> On 1/18/20 9:22 AM, Alexander von Gluck IV wrote:
>>> Has anyone successfully used u-boot on the Raspberry Pi 4 in 32-bit mode?
>>
>> I'm using 32-bit u-boot on RPI4 board with Tizen Platform.
>> You can refer to tizen u-boot git. Also I modified some configurations.
>>
>> https://protect2.fireeye.com/url?k=d4848ff3-8957d64d-d48504bc-0cc47a31ba82-40c2c54dba31c6f3=https:
>> /git.tizen.org/cgit/platform/kernel/u-boot/log/?h=tizen
>>
>> enable_uart=1
>> uart_2ndstage=1
uart_2ndstate=1 helped a lot :-)
I have it figured out now.
I wasn't aware of the change around Raspberry Pi's FDT's needing to
be on the boot partition for start4.elf.
All of our existing bootloader code depends on the FDT embedded
into u-boot. (fdtcontroladdr, see below for our boot.scr)
Does u-boot "pick-up" the FDT from the Pi foundation's start4.elf and place it
at fdtcontroladdr?
test -e mmc 0 uEnv.txt && fatload mmc 0 ${scriptaddr} uEnv.txt && env import -t
${scriptaddr} ${filesize} \
fatload mmc 0 ${kernel_addr_r} haiku_loader.ub \
fatload mmc 0 ${ramdisk_addr_r} haiku_floppyboot.ub \
env exists dtb && fatload mmc 0 ${fdt_addr_r} ${dtb} && fdt
addr ${fdt_addr_r} && bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r} \
fdt addr ${fdtcontroladdr} && bootm ${kernel_addr_r}
${ramdisk_addr_r} ${fdtcontroladdr}"
I thought the FDT embedded into u-boot was the "best way" to get it :-|
-- Alex
u-boot 32-bit on Raspberry Pi 4
Has anyone successfully used u-boot on the Raspberry Pi 4 in 32-bit mode? Building via the following: make rpi_4_32b_defconfig ARCH=arm CROSS_COMPILE=arm-none-eabi- make Booting via: * u-boot.bin on Fat32 partition * start.elf from * config.txt on Fat32 partition kernel=u-boot.bin enable_uart=1 arm_64bit=0 Just a black screen, however, no serial uart output Thanks! -- Alex
Re: [U-Boot] rk3288 (Tinkerboard) not booting【请注意，邮件由u-boot-boun...@lists.denx.de代发】
Just rounding this one out.. I was definitely looking at the wrong uart. After moving to uart2, things are working as expected (minus hdmi output from u-boot) Thanks! -- Alex September 23, 2019 9:27 AM, "Alexander von Gluck IV" wrote: > ACK! I'm on UART1. Mix that with video potentially not working > in u-boot and I think I have my answer. > > I'll test this afternoon. > > (PS, since the Tinker is supposed to be "Raspberry Pi like", why would > u-boot present on UART2 on it while the Raspberry Pi u-boot uses UART1?) > > Thanks for the help! > > -- Alex > > September 23, 2019 9:19 AM, "Jonathan Gray" wrote: > >> On Mon, Sep 23, 2019 at 01:55:32PM +, Alexander von Gluck IV wrote: >> >>> Oh, a difference: >>> >>> $ tools/mkimage -n rk3288 -T rksd -d tpl/u-boot-tpl.bin idbloader.img && \ >>> cat spl/u-boot-spl-dtb.bin >> idbloader.img >>> >>> I'm using the idbloader.img that u-boot automatically spits out. >>> >>> $ tools/mkimage -n rk3288 -T rksd -d tpl/u-boot-tpl.bin idbloader-manual.img >>> Image Type: Rockchip RK32 (SD/MMC) boot image >>> Data Size: 20480 bytes >>> $ cat spl/u-boot-spl-dtb.bin >> idbloader-manual.img >>> >>> However.. the generated idbloader-manual.img from the commands above is >>> identical to idbloader.img >>> that u-boot produces compared with md5sum. >>> >>> Are you writing the following? >>> >>> sudo dd if=idbloader.img of=/dev/sdd seek=64 >>> sudo dd if=u-boot-dtb.img of=/dev/sdd seek=16384 >> >> those files/offsets yes >> >>> (where /dev/sdd is a MicroSD card) >>> >>> These should be enough to get into u-boot at startup... correct? >> >> yes >> >> I am using uart2 >> https://www.asus.com/us/Single-Board-Computer/Tinker-Board >> 32 UART2TX_PWM3 >> 33 UART2RX_PWM2 >> and 30 for ground >> >>> I'm not missing some requirement of u-boot.bin on a FAT32 partition or >>> something? >> >> the tpl/spl and u-boot proper are at raw offsets in this case >> >>> -- Alex >>> >>> September 23, 2019 8:31 AM, "Jonathan Gray" wrote: >>> >>> On Mon, Sep 23, 2019 at 01:06:35PM +, Alexander von Gluck IV wrote: >>> >>> Ok, looking for differences now.. >>> >>> * Older Tinker Board? (I'm not using the Tinker Board S) >>> >>> yes, the original one >>> >>> * Same steps? >>> >>> along the lines of >>> >>> gmake CROSS_COMPILE="arm-none-eabi-" tinker-rk3288_defconfig >>> gmake CROSS_COMPILE="arm-none-eabi-" all >>> tools/mkimage -n rk3288 -T rksd -d tpl/u-boot-tpl.bin idbloader.img && \ >>> cat spl/u-boot-spl-dtb.bin >> idbloader.img >>> >>> * Same config? tinker-rk3288_defconfig? >>> >>> yes >>> >>> * Uart 115200? >>> >>> yes >>> >>> * Any HDMI Video output? >>> >>> no hdmi connected only serial >>> >>> * GCC version? >>> >>> gcc-linaro-6.3.2017.02 binutils 2.27 arm-none-eabi target >>> >>> September 23, 2019 12:34 AM, "Jonathan Gray" wrote: >>> >>> On Mon, Sep 23, 2019 at 01:17:40AM +, Alexander von Gluck IV wrote: >>> >>> Hello! >>> >>> There is no uart output and no video with u-boot master. >>> The board works as expected booting the Asus Armbian image on an SD. >>> >>> At this point i'd be happy to get some u-boot uart output :-) >>> >>> -- Alex >>> >>> uart output works here with the latest master >>> (780a17e814503f71d1b51d578b32bc9c89933183) >>> >>> U-Boot TPL 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20) >>> Trying to boot from BOOTROM >>> Returning to boot ROM... >>> >>> U-Boot SPL 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20 +1000) >>> Trying to boot from MMC1 >>> >>> U-Boot 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20 +1000) >>> >>> Model: Tinker-RK3288 >>> DRAM: 2 GiB >>> MMC: dwmmc@ff0c: 1 >>> Loading Environment from MMC... *** Warning - bad CRC, using default >>> environment >>> >>> In: serial >>> Out: serial >>> Err: serial >>> Model: Tinker-RK3288 >>> rockchip_dnl_key_pressed: adc_channel_single_shot fail! >>> Net: eth0: ethernet@ff29 >>> Hit any key to stop autoboot: 0 >>> switch to partitions #0, OK >>> mmc1 is current device >>> Scanning mmc 1:1... >>> Found EFI removable media binary efi/boot/bootarm.efi >>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >>> Scanning disk dw...@ff0c.blk... >>> Found 3 disks >>> BootOrder not defined >>> EFI boot manager: Cannot load any image >>> 88176 bytes read in 9 ms (9.3 MiB/s) >>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >>> OpenBSD/armv7 BOOTARM 1.6 >>> >>> boot> >>> ___ >>> U-Boot mailing list >>> U-Boot@lists.denx.de >>> https://lists.denx.de/listinfo/u-boot > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rk3288 (Tinkerboard) not booting【请注意，邮件由u-boot-boun...@lists.denx.de代发】
ACK! I'm on UART1. Mix that with video potentially not working in u-boot and I think I have my answer. I'll test this afternoon. (PS, since the Tinker is supposed to be "Raspberry Pi like", why would u-boot present on UART2 on it while the Raspberry Pi u-boot uses UART1?) Thanks for the help! -- Alex September 23, 2019 9:19 AM, "Jonathan Gray" wrote: > On Mon, Sep 23, 2019 at 01:55:32PM +0000, Alexander von Gluck IV wrote: > >> Oh, a difference: >> >> $ tools/mkimage -n rk3288 -T rksd -d tpl/u-boot-tpl.bin idbloader.img && \ >> cat spl/u-boot-spl-dtb.bin >> idbloader.img >> >> I'm using the idbloader.img that u-boot automatically spits out. >> >> $ tools/mkimage -n rk3288 -T rksd -d tpl/u-boot-tpl.bin idbloader-manual.img >> Image Type: Rockchip RK32 (SD/MMC) boot image >> Data Size: 20480 bytes >> $ cat spl/u-boot-spl-dtb.bin >> idbloader-manual.img >> >> However.. the generated idbloader-manual.img from the commands above is >> identical to idbloader.img >> that u-boot produces compared with md5sum. >> >> Are you writing the following? >> >> sudo dd if=idbloader.img of=/dev/sdd seek=64 >> sudo dd if=u-boot-dtb.img of=/dev/sdd seek=16384 > > those files/offsets yes > >> (where /dev/sdd is a MicroSD card) >> >> These should be enough to get into u-boot at startup... correct? > > yes > > I am using uart2 > https://www.asus.com/us/Single-Board-Computer/Tinker-Board > 32 UART2TX_PWM3 > 33 UART2RX_PWM2 > and 30 for ground > >> I'm not missing some requirement of u-boot.bin on a FAT32 partition or >> something? > > the tpl/spl and u-boot proper are at raw offsets in this case > >> -- Alex >> >> September 23, 2019 8:31 AM, "Jonathan Gray" wrote: >> >> On Mon, Sep 23, 2019 at 01:06:35PM +, Alexander von Gluck IV wrote: >> >> Ok, looking for differences now.. >> >> * Older Tinker Board? (I'm not using the Tinker Board S) >> >> yes, the original one >> >> * Same steps? >> >> along the lines of >> >> gmake CROSS_COMPILE="arm-none-eabi-" tinker-rk3288_defconfig >> gmake CROSS_COMPILE="arm-none-eabi-" all >> tools/mkimage -n rk3288 -T rksd -d tpl/u-boot-tpl.bin idbloader.img && \ >> cat spl/u-boot-spl-dtb.bin >> idbloader.img >> >> * Same config? tinker-rk3288_defconfig? >> >> yes >> >> * Uart 115200? >> >> yes >> >> * Any HDMI Video output? >> >> no hdmi connected only serial >> >> * GCC version? >> >> gcc-linaro-6.3.2017.02 binutils 2.27 arm-none-eabi target >> >> September 23, 2019 12:34 AM, "Jonathan Gray" wrote: >> >> On Mon, Sep 23, 2019 at 01:17:40AM +, Alexander von Gluck IV wrote: >> >> Hello! >> >> There is no uart output and no video with u-boot master. >> The board works as expected booting the Asus Armbian image on an SD. >> >> At this point i'd be happy to get some u-boot uart output :-) >> >> -- Alex >> >> uart output works here with the latest master >> (780a17e814503f71d1b51d578b32bc9c89933183) >> >> U-Boot TPL 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20) >> Trying to boot from BOOTROM >> Returning to boot ROM... >> >> U-Boot SPL 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20 +1000) >> Trying to boot from MMC1 >> >> U-Boot 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20 +1000) >> >> Model: Tinker-RK3288 >> DRAM: 2 GiB >> MMC: dwmmc@ff0c: 1 >> Loading Environment from MMC... *** Warning - bad CRC, using default >> environment >> >> In: serial >> Out: serial >> Err: serial >> Model: Tinker-RK3288 >> rockchip_dnl_key_pressed: adc_channel_single_shot fail! >> Net: eth0: ethernet@ff29 >> Hit any key to stop autoboot: 0 >> switch to partitions #0, OK >> mmc1 is current device >> Scanning mmc 1:1... >> Found EFI removable media binary efi/boot/bootarm.efi >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >> Scanning disk dw...@ff0c.blk... >> Found 3 disks >> BootOrder not defined >> EFI boot manager: Cannot load any image >> 88176 bytes read in 9 ms (9.3 MiB/s) >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >> OpenBSD/armv7 BOOTARM 1.6 >> >> boot> >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rk3288 (Tinkerboard) not booting【请注意，邮件由u-boot-boun...@lists.denx.de代发】
Oh, a difference: $ tools/mkimage -n rk3288 -T rksd -d tpl/u-boot-tpl.bin idbloader.img && \ cat spl/u-boot-spl-dtb.bin >> idbloader.img I'm using the idbloader.img that u-boot automatically spits out. $ tools/mkimage -n rk3288 -T rksd -d tpl/u-boot-tpl.bin idbloader-manual.img Image Type: Rockchip RK32 (SD/MMC) boot image Data Size:20480 bytes $ cat spl/u-boot-spl-dtb.bin >> idbloader-manual.img However.. the generated idbloader-manual.img from the commands above is identical to idbloader.img that u-boot produces compared with md5sum. Are you writing the following? sudo dd if=idbloader.img of=/dev/sdd seek=64 sudo dd if=u-boot-dtb.img of=/dev/sdd seek=16384 (where /dev/sdd is a MicroSD card) These should be enough to get into u-boot at startup... correct? I'm not missing some requirement of u-boot.bin on a FAT32 partition or something? -- Alex September 23, 2019 8:31 AM, "Jonathan Gray" wrote: > On Mon, Sep 23, 2019 at 01:06:35PM +, Alexander von Gluck IV wrote: > >> Ok, looking for differences now.. >> >> * Older Tinker Board? (I'm not using the Tinker Board S) > > yes, the original one > >> * Same steps? > > along the lines of > > gmake CROSS_COMPILE="arm-none-eabi-" tinker-rk3288_defconfig > gmake CROSS_COMPILE="arm-none-eabi-" all > tools/mkimage -n rk3288 -T rksd -d tpl/u-boot-tpl.bin idbloader.img && \ > cat spl/u-boot-spl-dtb.bin >> idbloader.img > >> * Same config? tinker-rk3288_defconfig? > > yes > >> * Uart 115200? > > yes > >> * Any HDMI Video output? > > no hdmi connected only serial > >> * GCC version? > > gcc-linaro-6.3.2017.02 binutils 2.27 arm-none-eabi target > >> September 23, 2019 12:34 AM, "Jonathan Gray" wrote: >> >> On Mon, Sep 23, 2019 at 01:17:40AM +, Alexander von Gluck IV wrote: >> >> Hello! >> >> There is no uart output and no video with u-boot master. >> The board works as expected booting the Asus Armbian image on an SD. >> >> At this point i'd be happy to get some u-boot uart output :-) >> >> -- Alex >> >> uart output works here with the latest master >> (780a17e814503f71d1b51d578b32bc9c89933183) >> >> U-Boot TPL 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20) >> Trying to boot from BOOTROM >> Returning to boot ROM... >> >> U-Boot SPL 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20 +1000) >> Trying to boot from MMC1 >> >> U-Boot 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20 +1000) >> >> Model: Tinker-RK3288 >> DRAM: 2 GiB >> MMC: dwmmc@ff0c: 1 >> Loading Environment from MMC... *** Warning - bad CRC, using default >> environment >> >> In: serial >> Out: serial >> Err: serial >> Model: Tinker-RK3288 >> rockchip_dnl_key_pressed: adc_channel_single_shot fail! >> Net: eth0: ethernet@ff29 >> Hit any key to stop autoboot: 0 >> switch to partitions #0, OK >> mmc1 is current device >> Scanning mmc 1:1... >> Found EFI removable media binary efi/boot/bootarm.efi >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >> Scanning disk dw...@ff0c.blk... >> Found 3 disks >> BootOrder not defined >> EFI boot manager: Cannot load any image >> 88176 bytes read in 9 ms (9.3 MiB/s) >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >> OpenBSD/armv7 BOOTARM 1.6 >> >> boot> >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rk3288 (Tinkerboard) not booting【请注意，邮件由u-boot-boun...@lists.denx.de代发】
Ok, looking for differences now.. * Older Tinker Board? (I'm not using the Tinker Board S) * Same steps? * Same config? tinker-rk3288_defconfig? * Uart 115200? * Any HDMI Video output? * GCC version? September 23, 2019 12:34 AM, "Jonathan Gray" wrote: > On Mon, Sep 23, 2019 at 01:17:40AM +0000, Alexander von Gluck IV wrote: > >> Hello! >> >> There is no uart output and no video with u-boot master. >> The board works as expected booting the Asus Armbian image on an SD. >> >> At this point i'd be happy to get some u-boot uart output :-) >> >> -- Alex > > uart output works here with the latest master > (780a17e814503f71d1b51d578b32bc9c89933183) > > U-Boot TPL 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20) > Trying to boot from BOOTROM > Returning to boot ROM... > > U-Boot SPL 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20 +1000) > Trying to boot from MMC1 > > U-Boot 2019.10-rc3-00401-ge23a6e5c43 (Sep 23 2019 - 15:13:20 +1000) > > Model: Tinker-RK3288 > DRAM: 2 GiB > MMC: dwmmc@ff0c: 1 > Loading Environment from MMC... *** Warning - bad CRC, using default > environment > > In: serial > Out: serial > Err: serial > Model: Tinker-RK3288 > rockchip_dnl_key_pressed: adc_channel_single_shot fail! > Net: eth0: ethernet@ff29 > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc1 is current device > Scanning mmc 1:1... > Found EFI removable media binary efi/boot/bootarm.efi > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > Scanning disk dw...@ff0c.blk... > Found 3 disks > BootOrder not defined > EFI boot manager: Cannot load any image > 88176 bytes read in 9 ms (9.3 MiB/s) > libfdt fdt_check_header(): FDT_ERR_BADMAGIC >>> OpenBSD/armv7 BOOTARM 1.6 > > boot> ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rk3288 (Tinkerboard) not booting【请注意，邮件由u-boot-boun...@lists.denx.de代发】
Hello! There is no uart output and no video with u-boot master. The board works as expected booting the Asus Armbian image on an SD. At this point i'd be happy to get some u-boot uart output :-) -- Alex September 22, 2019 8:04 PM, "Kever Yang" wrote: > Hi Alexander, > > The tinker board already enable TPL, so it should be use TPL instead of SPL > with mkimage tool. > > The idbloader should have including both, if the idbloader boot fail, could > you share the boot log? > > Thanks, > - Kever > On 2019/9/23 上午5:22, Alexander von Gluck IV wrote: > >> Using master from git://git.denx.de/u-boot.git >> >> commit 390183b58179ddaf986422f4d9446c596660f7e0 (HEAD -> master, >> origin/master, origin/HEAD) >> Merge: d6c7309f56 79907a4f84 >> Author: Tom Rini >> Date: Sat Sep 21 07:31:23 2019 -0400 >> >> Merge tag 'efi-2019-10-rc4-5' of >> https://gitlab.denx.de/u-boot/custodians/u-boot-efi >>> Pull request for UEFI sub-system for v2019.10-rc4 (5) >>> This patch set fixes errors in the UEFI sub-system and adds a function to >> compare u16 strings which is prerequisite for further patches. >> >> Same error: >> >> $ ./tools/mkimage -n rk3288 -T rksd -d spl/u-boot-spl-dtb.bin out >> Warning: SPL image is too large (size 0xb000) and will not boot >> Error: image verification failed >> >> $ ls -lah spl/u-boot-spl-dtb.bin >> -rw-rw-r-- 1 kallisti5 kallisti5 43K Sep 22 16:17 spl/u-boot-spl-dtb.bin >> >> September 22, 2019 4:03 PM, "Michael Nazzareno Trimarchi" >> wrote: >> >>> Hi >>> >>> Please use the latest uboot. The fixes should be already merged >>> >>> Mcihael >>> >>> On Sun, Sep 22, 2019 at 10:53 PM Alexander von Gluck IV >>> wrote: >> >> Anyone know a way to get a functional u-boot on the rk3288? (Tinkerboard, SD) >> >> The docs seem to recommend: >> $ /tmp/arm-build/tools/mkimage -n rk3288 -T rksd -d >> arm/tinkerboard/u-boot-spl-dtb.bin out >> >> However, that produces: >> Warning: SPL image is too large (size 0xb000) and will not boot >> >> I saw this patch to disable I2C in the SPL to reduce its size: >> https://github.com/xypron/u-boot-patches/blob/df2ceb65fb4cc433aa17304ed9d3d591c14ef5ac/0001-configs- >> inker-rk3288-disable-CONFIG_SPL_I2C_SUPPORT.patch >> >> However, that breaks the build :-| >> >> LD spl/u-boot-spl >> arm-unknown-haiku-ld.bfd: drivers/built-in.o: in function `rk8xx_write': >> /tmp/arm-build/drivers/power/pmic/rk8xx.c:30: undefined reference to >> `dm_i2c_write' >> arm-unknown-haiku-ld.bfd: drivers/built-in.o: in function `rk8xx_read': >> /tmp/arm-build/drivers/power/pmic/rk8xx.c:43: undefined reference to >> `dm_i2c_read' >> make[1]: *** [scripts/Makefile.spl:404: spl/u-boot-spl] Error 1 >> make: *** [Makefile:1762: spl/u-boot-spl] Error 2 >> make: Leaving directory '/tmp/arm-build' >> Disabling SPL Power then results in an error compiling MMC support >> Any alternative methods to getting u-boot running from SD? >> Rockchip devices seem to be kind of complex to get going :-| >> -- Alex >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> https://lists.denx.de/listinfo/u-boot >>> -- >>> | Michael Nazzareno Trimarchi Amarula Solutions BV | >>> | COO - Founder Cruquiuskade 47 | >>> | +31(0)851119172 Amsterdam 1018 AM NL | >>> | [`as] http://www.amarulasolutions.com | >> >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rk3288 (Tinkerboard) not booting
Sorry for spam, reposting with more context :-) $ make clean $ make tinker-rk3288_defconfig $ ARCH=arm CROSS_COMPILE=$TOOLCHAIN/bin/arm-unknown-haiku- make -j2 $ sudo dd if=idbloader.img of=/dev/sdd seek=64 $ sudo dd if=u-boot-dtb.img of=/dev/sdd seek=16384 I can confirm this toolchain successfully builds working u-boots for 4 other 32-bit arm boards. (gcc version 8.3.0 (GCC)) September 22, 2019 5:00 PM, "Alexander von Gluck IV" wrote: > $ sudo dd if=idbloader.img of=/dev/sdd seek=64 > $ sudo dd if=u-boot-dtb.img of=/dev/sdd seek=16384 > > Still nothing. > > September 22, 2019 4:47 PM, "Michael Nazzareno Trimarchi" > wrote: > >> Hi >> >> https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip/commits/master >> >> make idbloader.img >> >> Michael >> >> On Sun, Sep 22, 2019 at 11:22 PM Alexander von Gluck IV >> wrote: > > Using master from git://git.denx.de/u-boot.git > > commit 390183b58179ddaf986422f4d9446c596660f7e0 (HEAD -> master, > origin/master, origin/HEAD) > Merge: d6c7309f56 79907a4f84 > Author: Tom Rini > Date: Sat Sep 21 07:31:23 2019 -0400 > > Merge tag 'efi-2019-10-rc4-5' of > https://gitlab.denx.de/u-boot/custodians/u-boot-efi > > Pull request for UEFI sub-system for v2019.10-rc4 (5) > > This patch set fixes errors in the UEFI sub-system and adds a function to > compare u16 strings which is prerequisite for further patches. > > Same error: > > $ ./tools/mkimage -n rk3288 -T rksd -d spl/u-boot-spl-dtb.bin out > Warning: SPL image is too large (size 0xb000) and will not boot > Error: image verification failed > > $ ls -lah spl/u-boot-spl-dtb.bin > -rw-rw-r-- 1 kallisti5 kallisti5 43K Sep 22 16:17 spl/u-boot-spl-dtb.bin > > September 22, 2019 4:03 PM, "Michael Nazzareno Trimarchi" > wrote: > > Hi > > Please use the latest uboot. The fixes should be already merged > > Mcihael > > On Sun, Sep 22, 2019 at 10:53 PM Alexander von Gluck IV > wrote: > > Anyone know a way to get a functional u-boot on the rk3288? (Tinkerboard, SD) > > The docs seem to recommend: > $ /tmp/arm-build/tools/mkimage -n rk3288 -T rksd -d > arm/tinkerboard/u-boot-spl-dtb.bin out > > However, that produces: > Warning: SPL image is too large (size 0xb000) and will not boot > > I saw this patch to disable I2C in the SPL to reduce its size: > https://github.com/xypron/u-boot-patches/blob/df2ceb65fb4cc433aa17304ed9d3d591c14ef5ac/0001-configs- > inker-rk3288-disable-CONFIG_SPL_I2C_SUPPORT.patch > > However, that breaks the build :-| > > LD spl/u-boot-spl > arm-unknown-haiku-ld.bfd: drivers/built-in.o: in function `rk8xx_write': > /tmp/arm-build/drivers/power/pmic/rk8xx.c:30: undefined reference to > `dm_i2c_write' > arm-unknown-haiku-ld.bfd: drivers/built-in.o: in function `rk8xx_read': > /tmp/arm-build/drivers/power/pmic/rk8xx.c:43: undefined reference to > `dm_i2c_read' > make[1]: *** [scripts/Makefile.spl:404: spl/u-boot-spl] Error 1 > make: *** [Makefile:1762: spl/u-boot-spl] Error 2 > make: Leaving directory '/tmp/arm-build' > Disabling SPL Power then results in an error compiling MMC support > Any alternative methods to getting u-boot running from SD? > Rockchip devices seem to be kind of complex to get going :-| > -- Alex > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > > -- > | Michael Nazzareno Trimarchi Amarula Solutions BV | > | COO - Founder Cruquiuskade 47 | > | +31(0)851119172 Amsterdam 1018 AM NL | > | [`as] http://www.amarulasolutions.com | >> -- >> | Michael Nazzareno Trimarchi Amarula Solutions BV | >> | COO - Founder Cruquiuskade 47 | >> | +31(0)851119172 Amsterdam 1018 AM NL | >> | [`as] http://www.amarulasolutions.com | > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rk3288 (Tinkerboard) not booting
$ sudo dd if=idbloader.img of=/dev/sdd seek=64 $ sudo dd if=u-boot-dtb.img of=/dev/sdd seek=16384 Still nothing. September 22, 2019 4:47 PM, "Michael Nazzareno Trimarchi" wrote: > Hi > > https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip/commits/master > > make idbloader.img > > Michael > > On Sun, Sep 22, 2019 at 11:22 PM Alexander von Gluck IV > wrote: > >> Using master from git://git.denx.de/u-boot.git >> >> commit 390183b58179ddaf986422f4d9446c596660f7e0 (HEAD -> master, >> origin/master, origin/HEAD) >> Merge: d6c7309f56 79907a4f84 >> Author: Tom Rini >> Date: Sat Sep 21 07:31:23 2019 -0400 >> >> Merge tag 'efi-2019-10-rc4-5' of >> https://gitlab.denx.de/u-boot/custodians/u-boot-efi >> >> Pull request for UEFI sub-system for v2019.10-rc4 (5) >> >> This patch set fixes errors in the UEFI sub-system and adds a function to >> compare u16 strings which is prerequisite for further patches. >> >> Same error: >> >> $ ./tools/mkimage -n rk3288 -T rksd -d spl/u-boot-spl-dtb.bin out >> Warning: SPL image is too large (size 0xb000) and will not boot >> Error: image verification failed >> >> $ ls -lah spl/u-boot-spl-dtb.bin >> -rw-rw-r-- 1 kallisti5 kallisti5 43K Sep 22 16:17 spl/u-boot-spl-dtb.bin >> >> September 22, 2019 4:03 PM, "Michael Nazzareno Trimarchi" >> wrote: >> >> Hi >> >> Please use the latest uboot. The fixes should be already merged >> >> Mcihael >> >> On Sun, Sep 22, 2019 at 10:53 PM Alexander von Gluck IV >> wrote: >> >> Anyone know a way to get a functional u-boot on the rk3288? (Tinkerboard, SD) >> >> The docs seem to recommend: >> $ /tmp/arm-build/tools/mkimage -n rk3288 -T rksd -d >> arm/tinkerboard/u-boot-spl-dtb.bin out >> >> However, that produces: >> Warning: SPL image is too large (size 0xb000) and will not boot >> >> I saw this patch to disable I2C in the SPL to reduce its size: >> https://github.com/xypron/u-boot-patches/blob/df2ceb65fb4cc433aa17304ed9d3d591c14ef5ac/0001-configs- >> inker-rk3288-disable-CONFIG_SPL_I2C_SUPPORT.patch >> >> However, that breaks the build :-| >> >> LD spl/u-boot-spl >> arm-unknown-haiku-ld.bfd: drivers/built-in.o: in function `rk8xx_write': >> /tmp/arm-build/drivers/power/pmic/rk8xx.c:30: undefined reference to >> `dm_i2c_write' >> arm-unknown-haiku-ld.bfd: drivers/built-in.o: in function `rk8xx_read': >> /tmp/arm-build/drivers/power/pmic/rk8xx.c:43: undefined reference to >> `dm_i2c_read' >> make[1]: *** [scripts/Makefile.spl:404: spl/u-boot-spl] Error 1 >> make: *** [Makefile:1762: spl/u-boot-spl] Error 2 >> make: Leaving directory '/tmp/arm-build' >> Disabling SPL Power then results in an error compiling MMC support >> Any alternative methods to getting u-boot running from SD? >> Rockchip devices seem to be kind of complex to get going :-| >> -- Alex >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> https://lists.denx.de/listinfo/u-boot >> >> -- >> | Michael Nazzareno Trimarchi Amarula Solutions BV | >> | COO - Founder Cruquiuskade 47 | >> | +31(0)851119172 Amsterdam 1018 AM NL | >> | [`as] http://www.amarulasolutions.com | > > -- > | Michael Nazzareno Trimarchi Amarula Solutions BV | > | COO - Founder Cruquiuskade 47 | > | +31(0)851119172 Amsterdam 1018 AM NL | > | [`as] http://www.amarulasolutions.com | ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rk3288 (Tinkerboard) not booting
Using master from git://git.denx.de/u-boot.git commit 390183b58179ddaf986422f4d9446c596660f7e0 (HEAD -> master, origin/master, origin/HEAD) Merge: d6c7309f56 79907a4f84 Author: Tom Rini Date: Sat Sep 21 07:31:23 2019 -0400 Merge tag 'efi-2019-10-rc4-5' of https://gitlab.denx.de/u-boot/custodians/u-boot-efi Pull request for UEFI sub-system for v2019.10-rc4 (5) This patch set fixes errors in the UEFI sub-system and adds a function to compare u16 strings which is prerequisite for further patches. Same error: $ ./tools/mkimage -n rk3288 -T rksd -d spl/u-boot-spl-dtb.bin out Warning: SPL image is too large (size 0xb000) and will not boot Error: image verification failed $ ls -lah spl/u-boot-spl-dtb.bin -rw-rw-r-- 1 kallisti5 kallisti5 43K Sep 22 16:17 spl/u-boot-spl-dtb.bin September 22, 2019 4:03 PM, "Michael Nazzareno Trimarchi" wrote: > Hi > > Please use the latest uboot. The fixes should be already merged > > Mcihael > > On Sun, Sep 22, 2019 at 10:53 PM Alexander von Gluck IV > wrote: > >> Anyone know a way to get a functional u-boot on the rk3288? (Tinkerboard, SD) >> >> The docs seem to recommend: >> $ /tmp/arm-build/tools/mkimage -n rk3288 -T rksd -d >> arm/tinkerboard/u-boot-spl-dtb.bin out >> >> However, that produces: >> Warning: SPL image is too large (size 0xb000) and will not boot >> >> I saw this patch to disable I2C in the SPL to reduce its size: >> https://github.com/xypron/u-boot-patches/blob/df2ceb65fb4cc433aa17304ed9d3d591c14ef5ac/0001-configs- >> inker-rk3288-disable-CONFIG_SPL_I2C_SUPPORT.patch >> >> However, that breaks the build :-| >> >> LD spl/u-boot-spl >> arm-unknown-haiku-ld.bfd: drivers/built-in.o: in function `rk8xx_write': >> /tmp/arm-build/drivers/power/pmic/rk8xx.c:30: undefined reference to >> `dm_i2c_write' >> arm-unknown-haiku-ld.bfd: drivers/built-in.o: in function `rk8xx_read': >> /tmp/arm-build/drivers/power/pmic/rk8xx.c:43: undefined reference to >> `dm_i2c_read' >> make[1]: *** [scripts/Makefile.spl:404: spl/u-boot-spl] Error 1 >> make: *** [Makefile:1762: spl/u-boot-spl] Error 2 >> make: Leaving directory '/tmp/arm-build' >> Disabling SPL Power then results in an error compiling MMC support >> Any alternative methods to getting u-boot running from SD? >> Rockchip devices seem to be kind of complex to get going :-| >> -- Alex >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> https://lists.denx.de/listinfo/u-boot > > -- > | Michael Nazzareno Trimarchi Amarula Solutions BV | > | COO - Founder Cruquiuskade 47 | > | +31(0)851119172 Amsterdam 1018 AM NL | > | [`as] http://www.amarulasolutions.com | ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] rk3288 (Tinkerboard) not booting
Anyone know a way to get a functional u-boot on the rk3288? (Tinkerboard, SD) The docs seem to recommend: $ /tmp/arm-build/tools/mkimage -n rk3288 -T rksd -d arm/tinkerboard/u-boot-spl-dtb.bin out However, that produces: Warning: SPL image is too large (size 0xb000) and will not boot I saw this patch to disable I2C in the SPL to reduce its size: https://github.com/xypron/u-boot-patches/blob/df2ceb65fb4cc433aa17304ed9d3d591c14ef5ac/0001-configs-tinker-rk3288-disable-CONFIG_SPL_I2C_SUPPORT.patch However, that breaks the build :-| LD spl/u-boot-spl arm-unknown-haiku-ld.bfd: drivers/built-in.o: in function `rk8xx_write': /tmp/arm-build/drivers/power/pmic/rk8xx.c:30: undefined reference to `dm_i2c_write' arm-unknown-haiku-ld.bfd: drivers/built-in.o: in function `rk8xx_read': /tmp/arm-build/drivers/power/pmic/rk8xx.c:43: undefined reference to `dm_i2c_read' make[1]: *** [scripts/Makefile.spl:404: spl/u-boot-spl] Error 1 make: *** [Makefile:1762: spl/u-boot-spl] Error 2 make: Leaving directory '/tmp/arm-build' Disabling SPL Power then results in an error compiling MMC support Any alternative methods to getting u-boot running from SD? Rockchip devices seem to be kind of complex to get going :-| -- Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rpi2: u-boot misaligned operation
June 28, 2019 8:49 PM, "Alexander von Gluck IV" wrote: > June 26, 2019 3:22 AM, "Matthias Brugger" wrote: > >> On 25/06/2019 02:42, Alexander von Gluck IV wrote: >> >>> Was rebuilding u-boot binary for the Raspberry Pi 2 (from master), and ran >>> into the following >>> issue: >>> " >>> U-Boot 2019.07-rc4-00179-g77f6e2dd05 (Jun 24 2019 - 14:25:14 -0500) >>> >>> DRAM: 128 MiB >>> RPI 2 Model B (0xa21041) >>> MMC: sdhci@7e30: 0 >>> Loading Environment from FAT... *** Warning - bad CRC, using default >>> environment >>> >>> mbox: Header response code invalid >>> bcm2835: Could not configure display >>> In: serial >>> Out: vidconsole >>> Err: vidconsole >>> Net: CACHE: Misaligned operation at range [07fdb6e8, 07fdb700] >>> CACHE: Misaligned operation at range [07fdb6e8, 07fdb700] >>> CACHE: Misaligned operation at range [07fdb6e8, 07fdb700] >>> CACHE: Misaligned operation at range [07fdb6e8, 07fdb700] >>> CACHE: Misaligned operation at range [07fdb6e8, 07fdb700] >>> CACHE: Misaligned operation at range [07fdb6e8, 07fdb700] >>> . >>> . >>> . >>> " >>> >>> git commit: 77f6e2dd0551d8a825bab391a1bd6b838874bcd4 >>> Anyone seen this before? >>> >>> Thanks! >> >> Can you try to git-bisect between: >> git bisect good e4afcb2876eeeddd2376c8b07808276b75862498 >> git bisect bad 3950f0f8563acab248214df36053bb6c57b91940 >> >> I suppose that the one I marked as good actually works. :) > > e4afcb2876eeeddd2376c8b07808276b75862498 is actually bad. > 7e2ae620e15ef578b8f2812ec21ec07fae6c1e2f is bad (3 months ago) > 91e1bc53c4b61cd7b871d485f4c136084245e9a2 is bad > > I can't build before 91e1bc53c4b61cd7b871d485f4c136084245e9a2 due to libfdt > incompatibilities :-| > > *however* I found an old u-boot for the rpi2 build in 2017 > (which i'm pretty sure worked) > (ebca2083d3689c77c7d1365f1e6862b55abef8a2) > > U-Boot 2017.11-00023-gebca2083d3 (Nov 17 2017 - 09:00:41 -0600) > > DRAM: 128 MiB > RPI 2 Model B (0xa21041) > MMC: sdhci@7e30: 0 > *** Warning - bad CRC, using default environment > > mbox: Header response code invalid > bcm2835: Could not configure display > In: serial > Out: vidconsole > Err: vidconsole > Net: CACHE: Misaligned operation at range [07fb3f64, 07fb3f80] > CACHE: Misaligned operation at range [07fb3f64, 07fb3f80] > CACHE: Misaligned operation at range [07fb3f64, 07fb3f80] > CACHE: Misaligned operation at range [07fb3f64, 07fb3f80] > CACHE: Misaligned operation at range [07fb3f64, 07fb3f80] > CACHE: Misaligned operation at range [07fb3f64, 07fb3f80] > CACHE: Misaligned operation at range [07fb3f64, 07fb3f80] > > This one was even built with our own toolchain before > we began to rely on host toolchains. > > The big difference in the room is the pre-u-boot loaders > from the pi foundation. We're using their latest: > > https://github.com/raspberrypi/firmware/tree/master/boot > > I reverted bootloader.bin and start.elf from 2017: > https://github.com/raspberrypi/firmware/blob/dc93c7922bb31f20759a94a6e000299da8e331e3/boot/start.elf > https://github.com/raspberrypi/firmware/blob/dc93c7922bb31f20759a94a6e000299da8e331e3/boot/bootcode. > in > > And it now works :-| Raised to the Raspberry Pi folks here: https://github.com/raspberrypi/firmware/issues/1164 Maybe they'll have some insight. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rpi2: u-boot misaligned operation
June 26, 2019 3:22 AM, "Matthias Brugger" wrote: > On 25/06/2019 02:42, Alexander von Gluck IV wrote: > >> Was rebuilding u-boot binary for the Raspberry Pi 2 (from master), and ran >> into the following >> issue: >> " >> U-Boot 2019.07-rc4-00179-g77f6e2dd05 (Jun 24 2019 - 14:25:14 -0500) >> >> DRAM: 128 MiB >> RPI 2 Model B (0xa21041) >> MMC: sdhci@7e30: 0 >> Loading Environment from FAT... *** Warning - bad CRC, using default >> environment >> >> mbox: Header response code invalid >> bcm2835: Could not configure display >> In: serial >> Out: vidconsole >> Err: vidconsole >> Net: CACHE: Misaligned operation at range [07fdb6e8, 07fdb700] >> CACHE: Misaligned operation at range [07fdb6e8, 07fdb700] >> CACHE: Misaligned operation at range [07fdb6e8, 07fdb700] >> CACHE: Misaligned operation at range [07fdb6e8, 07fdb700] >> CACHE: Misaligned operation at range [07fdb6e8, 07fdb700] >> CACHE: Misaligned operation at range [07fdb6e8, 07fdb700] >> . >> . >> . >> " >> >> git commit: 77f6e2dd0551d8a825bab391a1bd6b838874bcd4 >> Anyone seen this before? >> >> Thanks! > > Can you try to git-bisect between: > git bisect good e4afcb2876eeeddd2376c8b07808276b75862498 > git bisect bad 3950f0f8563acab248214df36053bb6c57b91940 > > I suppose that the one I marked as good actually works. :) e4afcb2876eeeddd2376c8b07808276b75862498 is actually bad. 7e2ae620e15ef578b8f2812ec21ec07fae6c1e2f is bad (3 months ago) 91e1bc53c4b61cd7b871d485f4c136084245e9a2 is bad I can't build before 91e1bc53c4b61cd7b871d485f4c136084245e9a2 due to libfdt incompatibilities :-| *however* I found an old u-boot for the rpi2 build in 2017 (which i'm pretty sure worked) (ebca2083d3689c77c7d1365f1e6862b55abef8a2) U-Boot 2017.11-00023-gebca2083d3 (Nov 17 2017 - 09:00:41 -0600) DRAM: 128 MiB RPI 2 Model B (0xa21041) MMC: sdhci@7e30: 0 *** Warning - bad CRC, using default environment mbox: Header response code invalid bcm2835: Could not configure display In:serial Out: vidconsole Err: vidconsole Net: CACHE: Misaligned operation at range [07fb3f64, 07fb3f80] CACHE: Misaligned operation at range [07fb3f64, 07fb3f80] CACHE: Misaligned operation at range [07fb3f64, 07fb3f80] CACHE: Misaligned operation at range [07fb3f64, 07fb3f80] CACHE: Misaligned operation at range [07fb3f64, 07fb3f80] CACHE: Misaligned operation at range [07fb3f64, 07fb3f80] CACHE: Misaligned operation at range [07fb3f64, 07fb3f80] This one was even built with our own toolchain before we began to rely on host toolchains. The big difference in the room is the pre-u-boot loaders from the pi foundation. We're using their latest: https://github.com/raspberrypi/firmware/tree/master/boot I reverted bootloader.bin and start.elf from 2017: https://github.com/raspberrypi/firmware/blob/dc93c7922bb31f20759a94a6e000299da8e331e3/boot/start.elf https://github.com/raspberrypi/firmware/blob/dc93c7922bb31f20759a94a6e000299da8e331e3/boot/bootcode.bin And it now works :-| -- Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] rpi2: u-boot misaligned operation
Was rebuilding u-boot binary for the Raspberry Pi 2 (from master), and ran into the following issue: " U-Boot 2019.07-rc4-00179-g77f6e2dd05 (Jun 24 2019 - 14:25:14 -0500) DRAM: 128 MiB RPI 2 Model B (0xa21041) MMC: sdhci@7e30: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment mbox: Header response code invalid bcm2835: Could not configure display In: serial Out: vidconsole Err: vidconsole Net: CACHE: Misaligned operation at range [07fdb6e8, 07fdb700] CACHE: Misaligned operation at range [07fdb6e8, 07fdb700] CACHE: Misaligned operation at range [07fdb6e8, 07fdb700] CACHE: Misaligned operation at range [07fdb6e8, 07fdb700] CACHE: Misaligned operation at range [07fdb6e8, 07fdb700] CACHE: Misaligned operation at range [07fdb6e8, 07fdb700] . . . " git commit: 77f6e2dd0551d8a825bab391a1bd6b838874bcd4 Anyone seen this before? Thanks! -- Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
