08-02-2021, 08:35 AM
(This post was last modified: 08-02-2021, 12:00 PM by thequailman.)
Quote:Your extlinux.conf appears to be hand-rolled rather than generated by (already mentioned by me) u-boot-menu, and it points to /pinebookpro.dtb for the device tree. Unless you did something special to have that file created, your config likely points to a non-existent device tree and very well could result in unbootable system.Yes, it's hand rolled but it works fine. The files are there and it boots, verified using UART.
Quote:Your TIMEOUT is set to 0.5s, in my experience anything less than 1s doesn't boot right for some reason (quirk of u-boot, perhaps?)I'll update the timeout. The dtb part is what may be the problem--u-boot has a dtb file under /usr/lib/u-boot/pinebook-pro-rk3399/rk3399-pinebook-pro.dtb that I've been using. This is probably my issue, I assumed since it shipped with one that I need to use it. I don't do much with ARM but I hand roll all my other Debian setups.
You mentioned you have dtb from experimental, but kernel from bullseye/sid? Not sure what exactly do you mean. Device trees are packaged together with the kernel in Debian, so if you install, e.g., linux-image-5.10.0-8-arm64, among other files it will create directory tree /usr/lib/linux-image-5.10.0-8-arm64/ where you will have, among others, folder rockchip, in which you will have rk3399-pinebook-pro.dtb device tree binary. Now unless you have a separate /boot, you generally don't need to do anything with that file - no copying or symlinks necessary, so long as your /boot/extlinux/extlinux.conf has the line "fdtdir /usr/lib/linux-image-5.10.0-8-arm64/". If you do have separate /boot, installing flash-kernel package should automate copying the appropriate device tree binary to your /boot.
Quote:When you said "I have the u-boot from experimental", do you get early u-boot messages on the screen, before it actually boots the kernel? If you don't, you likely don't have u-boot actually installed - it's a separate step from "apt install", you need to run `sudo u-boot-install-rockchip <eMMC device>` first before your machine will actually use it.
Everything boots OK (verified using UART/SSH to the machine), just the LCD doesn't show anything.
Quote:Finally, as a general comment - always start from the most basic, simplest setup, even when you think you know exactly what you're doing, and leave the defaults in place until you got the most basic default setup working well. While probably not the case here, I can give you plenty examples from my own experience when something as simple as adding an explicitly configured compression method broke things. So don't hand-roll anything until you either fully understand the implications of every parameter, or you got your basic defaults working and you're starting to experiment. And when you do, don't change more than one thing at a time.I'm trying to integrate all of this into my existing amd64 debian flashing setup so I don't have to document the steps I did to get this working, I just kick off the script I have. To that end, yes I am customizing this stuff. The problem with leaving the defaults in place is, there aren't any, unless you're using an image. I'm trying to piece together documentation that is scattered in this forum, in the upstream u-boot, kernel changelogs, and manjaro. It's quite frankly a mess, especially coming from the buttery smooth amd64 boot process. I appreciate your patience here as I try to understand the whys and the hows instead of curl | bash my way through this.
EDIT: Yes, the dtb from the /usr/lib kernel directory fixed it. I seem to get white lines down the screen instead of console/gdm after reboot occasionally though, anyone else experiencing this?
