jakogut / uboot-orangepi-rk3399

Arch Linux ARM u-boot package for Orange Pi RK3399 and Orange Pi 4
11 stars 6 forks source link

Kernel wont boot #2

Open EndlessEden opened 3 years ago

EndlessEden commented 3 years ago

After figuring out the readme (Please update, it fails to mention needing qemu to run the binaries) cp /usr/bin/qemu-aarch64-static root/bin arch-chroot $OPIMOUNT /bin/qemu-aarch64-static /bin/pacman -U /home/alarm/uboot-orangepi-rk3399-2019.10-1-aarch64.pkg.tar.zst arch-chroot $OPIMOUNT /bin/qemu-aarch64-static /bin/dd if=/boot/idbloader.img of=/dev/sdx seek=64 conv=notrunc arch-chroot $OPIMOUNT /bin/qemu-aarch64-static /bin/dd if=/boot/uboot.img of=/dev/sdx seek=16384 conv=notrunc arch-chroot $OPIMOUNT /bin/qemu-aarch64-static /bin/dd if=/boot/trust.img of=/dev/sdx seek=24576 conv=notrunc

it fails to boot beyond kernel launch (with no errors i can see) Log Below

OPI4_UART.log

jakogut commented 3 years ago

After figuring out the readme (Please update, it fails to mention needing qemu to run the binaries)

@EndlessEden Pull requests are welcome. It looks like you don't have binfmt setup for that arch, which I forgot was necessary when I wrote this. On Arch Linux, installing binfmt-qemu-static from the AUR should suffice.

Are you booting the Orange Pi RK3399, or the Orange Pi 4?

EndlessEden commented 3 years ago

@jakogut

  1. I will look into updating when i have some free time.

  2. ok, im not super familiar with all of this though. any articles on how binfmt and qemu works in this context. im assuming from basic understanding binfmt is registering elf translations with the kernel, to run arm executable's on x86 under qemu? (or am i way off?) - I also assume you mean on the host system and not the target filesystem. this is a first for me.

  3. Orange Pi 4; (non-emmc model).

-Side note, is there any recommended Qemu settings for emulating the RK3399(OPi4)? I wanted to do package building in emulation.

jakogut commented 3 years ago

@EndlessEden For binfmt, you are correct. The host kernel has handlers registered for different architectures which actually run the binary. In this case, QEMU is doing the emulation. I'd refer you to the Debian documentation. Additionally, this article goes into some pretty good detail.

Being that you're using the Orange Pi 4, did you try the orangepi-rk3399 branch, or the orangepi4 branch?

EndlessEden commented 3 years ago

@jakogut Sorry, i didnt notice there was a orangepi4 branch. will build and test, thank you. As per (identical) instructions, I cannot get your release version to work (2019.10-1), it seems to be only for rk3399 (i assume) and not OPi4.

UPDATE1: ive tried cross-compiling, and compiling in qemu-aarch64. I just cannot get this to build with gcc(aarch64-linux-gnu-gcc[10 or 8.2 from 2019/01/31])+arm-none-eabi(10[from archlinux-community repo - x86_64 only] or bin-82 or bin-92[from aur, both x86_64 and aarch64]). All fail with .pmusram will not fit in region PMUSRAM at linking in bl31.elf (as mentioned in this issue: https://github.com/ARM-software/tf-issues/issues/650)

UPDATE2: After speaking with a few others and lots of messing with cross-compiling(using the 8.2-201901 toolchain from arm), and editing the PKGBUILD. i managed to compile the package. Going to test and refine, if it works ill make a pull request with a updated PKGBUILD and readme for your review at your leisure.

UPDATE3: Kernel boots, everything seems ok. Will test updated PKGBUILD on device.

jakogut commented 3 years ago

@EndlessEden I've updated this PKGBUILD to U-boot 2021.01. I see that you've made a PR fixing some issues, would you mind rebasing that?

EndlessEden commented 3 years ago

@jakogut Had a derp moment rebasing, so i nuked my repo, reforked it, and uploaded just my updated pkgbuild. | please review Pull Request #4