|
update:
|
update:
slarm64-current-aarch64-base-rootfs-20201003-5.8.15-rockpro64-build-20201014.img.zst.md5 slarm64-current-aarch64-xfce-rootfs-20201003-5.8.15-rockpro64-build-20201014.img.zst slarm64-current-aarch64-xfce-rootfs-20201003-5.8.15-rockpro64-build-20201014.img.zst.md5 |
update:
slarm64-current-aarch64-base-rootfs-20201023-5.9.1-rockpro64-build-20201023.img.zst.md5 slarm64-current-aarch64-xfce-rootfs-20201023-5.9.1-rockpro64-build-20201023.img.zst slarm64-current-aarch64-xfce-rootfs-20201023-5.9.1-rockpro64-build-20201023.img.zst.md5 |
Hi sndwvs,
I just received my rockpro64 this week (my first arm board), and I'm trying out your slarm64 images on a micro sd to try to get slackware up and running on it. It seems that only the images with kernel 4.4.230 (2020-07-11) will run. I've tried the newer 4.4.249 and 5.9.16 images and they both hang at "Booting using the fdt blob at 0x1f00000". I'll link a picture of the boot screen at the end of this post, if it helps. I'm new to running anything on an arm board so I'm not sure the cause but it seems to be a problem with uboot, and working with that is completely new to me. Perhaps you have an idea on what can be done to get a newer image to boot? For now I can run with the 4.4.230 images. Both base and xfce work fine, I just need to figure out what I want to use. That picture of the stuck boot: https://imgur.com/9S1l9BB |
Hi 0XBF,
try rewriting the bootloader to the installed image on the card: Code:
dd if=idbloader.img of=/dev/mmcblk0 seek=64 status=noxferupdate: this is a known (as it turns out the problem). i will update the images. |
update kernel 5.10.11
slarm64-current-aarch64-base-rockpro64-5.10.11-build-20210128.img.zst slarm64-current-aarch64-base-rockpro64-5.10.11-build-20210128.img.zst.sha256 slarm64-current-aarch64-xfce-rockpro64-5.10.11-build-20210128.img.zst slarm64-current-aarch64-xfce-rockpro64-5.10.11-build-20210128.img.zst.sha256 |
Quote:
Downloading the new base image at the moment. Today I'm getting ~50KB/sec so it'll be a little while until I can test things :) |
A little update,
I got your latest "slarm64-current-aarch64-base-rockpro64-5.10.11-build-20210128.img.zst" image downloaded and copied to my sd card and it booted up properly. My usb keyboard plugged into the rockpro64 is working fine too. I was wondering how that would go since those bug reports were talking about breaking usb keyboard support. Thanks for getting those new images up! |
slarm64-current-aarch64-base-rockpro64-4.4.253-build-20210129.img.zst
slarm64-current-aarch64-base-rockpro64-4.4.253-build-20210129.img.zst.sha256 slarm64-current-aarch64-enlightenment-rockpro64-4.4.253-build-20210129.img.zst slarm64-current-aarch64-enlightenment-rockpro64-4.4.253-build-20210129.img.zst.sha256 |
I wasn't sure where to post this: https://www.linuxquestions.org/quest...ml#post6228925
|
to download and then erase the SPI use the method:
Disable SPI (while booting) Quote:
Code:
flash_erase /dev/mtd0 0 0Code:
sf probe |
After erasing SPI Flash, "env default -a ; reset", and finally booting the SD Card with slarm64, I was able to get Linux booted again. Thanks for the information. It's surprisingly difficult to glean any information about u-boot. There are so many versions and platforms that have different u-boot commands. A lot of the information I found was old, incorrect, or missing commands.
|
Is there any chance that the kernel packages, firmware, and source could be refreshed?
|
Quote:
|
| All times are GMT -5. The time now is 02:55 AM. |