Extracted dtb about h96-max-v58-investigation HOT 32 OPEN

Yes it matters. I meant "once the kernel is booted" in that previous statement.

Using fastboot is a properly cromulent way to get quick iterations going. I personally would use fastboot.

There could be some minor details, e.g. the configured state of some devices may differ, but properly behaved drivers in Linux should reset/configure them without any assumptions.

from h96-max-v58-investigation.

Having both dtb is good, it allows diffing what was added by a possible overlay or other fixups by the platform firmware (U-Boot).

Booting stock Linux will probably lack a lot of features. It might be worth investigating existing BSPs floating about for other RK3588 boards, since they will likely implement most of the features.

Relatedly, you have a .config file you can use as a starting point as /proc/config.gz, or even extracting it from the kernel using a script that IIRC is in the kernel tree.

from h96-max-v58-investigation.

I actually stalled out, and hadn't grabbed either DTB. Lot on my plate.

@tri-pole, my next steps were going to be either (1) a tow-boot branch/build for the device or (2) a mobile-nixos branch, similar to my recent openstick branch.

I guess leaning towards the latter and using it to build a fastboot-able rootfs image - it might be easier to get up and running with the existing bootloader on there, without the bsp sources, etc.

bootdisk is interesting looking. too, btw.

from h96-max-v58-investigation.

@colemickens
Building a fastboot-able image and for now using the existing u-boot to do some further exploration seems like a good idea. The version of of u-boot on the box is old, but not ancient (like on many other TV-boxes); it seems to be U-Boot 2017.09 (and it supports both boot.scr and extlinux.conf for Linux booting).

from h96-max-v58-investigation.

With that vintage of a U-Boot, there should be basically no difference in behaviour compared to a more recent equivalent-featured U-Boot for what matters about booting Linux. So yes, it should be just fine.

from h96-max-v58-investigation.

Doesn't it still sort of matter how their u-boot was build, in terms of what things in will try in its boot order? That's mostly the only reason I was thinking about bothering with the fastboot/android rootfs image. I tried to get into a menu, but now I can't remember if I tried over uart or usb, so might warrant another shot.

from h96-max-v58-investigation.

Fastboot probably would've been easier, and I'm kind of coming to appreciate that it's somewhat standardizing how to do this dtb lookup process. But I haven't really made my peace with having to "reflash boot" anytime I want to take a kernel update, so I stubbornly wanted to make this look like my rock5b and most every other nixos device I have (sdm845 not withstanding).

(Random aside, I think the worst case scenario is getting a partial, broken u-boot installed to where you can't enter MaskRom mode, and can't enter RKUSB mode. I think the only way to recover here is to find eMMC CLK and short it to ground while powering on, and I couldn't easily identify it (though I have zero experience in this area).)

But of course, I wiped the thing, built the rk3588_defconfig of u-boot, and the same kernel I am running on my rock5b.

U-boot's config points to rk3588_evb.dtb and then wants extlinux to load that for linux as well, but rk358_evb.dtb doesn't exist in the radxa kernel tree. So after I "install" nixos, I go into the generation's DTB dir and copy rk3588-nvr-demo-v10-android.dtb to rk3588_evb.dtb.

Then I do some awful hack of making a local image file, copying Tow-Boot onto the front, partitioning the tail, loop mounting it, "installing" an aarch64 nixos into it (I think I hacked the extlinux-conf-builder a while back to be able to sort of staticly output a config for itself at build time).

And then flash that whole thing to the emmc with rkdeveloptool wl 0 <img>.

tada... sorta

[cole@aitchninesix1:~]$ uname -a
Linux aitchninesix1 5.10.66 #1-NixOS SMP Tue Jan 1 00:00:00 UTC 1980 aarch64 GNU/Linux

Despite rk3588-nvr-demo-v10-android.dtb being an exact string match for the stock u-boot log stanza... it doesn't seem to be right. The similarly named dtb without "android" seemed to not even really boot the kernel up properly.

• no ethernet (two eth devices seem to appear but not work?)
• usb3 port works though, and I had an ethernet adapter so I can ssh in
• UART RX on the board just doesn't seem to work - I've exhausted the things I can check other than thinking that the pad isn't hooked up, or that the board needs something in the DTS to pull/init RX somehow

next steps for me

take a break from aarch64 land again, keep poking at the radxa discord to see if they have some insight for me:

• does radxa not keep their uboot dtb and linux dtb in sync? if not, why not? Is it just that they get away with binary compatibility and relying on fastboot/dtb(o) mechanisms to do runtime patchup? and I guess that works out?
• is there possibly a fork somewhere with a more accurate version of this DTB for the board?
• action: compare the DTB @tri-pole extracted to the DTSI in the radxa source tree

from h96-max-v58-investigation.

So the stock boot had this kernel+dtb that contained 3 dtbs? two of which have the same filename?

from h96-max-v58-investigation.

does radxa not keep their uboot dtb and linux dtb in sync? if not, why not? Is it just that they get away with binary compatibility and relying on fastboot/dtb(o) mechanisms to do runtime patchup? and I guess that works out?

With vendor BSP, the drivers are written independently, they differ, and this can't happen.

The expectation is that during OS boot stage, a dtb will be loaded. So the for-u-boot FDT is expected to never be used by the operating system. (With vendor BSP, AFAIUI.) To reiterate you will need to load a dtb file for the oeprating system it's a guarantee.

You have to be mindful that vendor BSP operates differently than mainline U-Boot+kernel here.

Also you have to be mindful about the for-U-Boot FDT, which is used by U-Boot for its own drivers, and the for-operating-system FDT, which will be used by the operating system for its own drivers. With mainline U-Boot the device tree align with mainline Linux and use the same semantics. You can use mainline Linux with a BSP U-Boot as long as it loads the for-operating-system device tree first. You can use vendor Linux with mainline U-Boot, as long as it loads the for-operating-system device tree, if its mainline description differs too much. With vendor BSP U-Boot, you will always need to load a for-operating-system device tree when booting an OS.

Now, about loading the device tree. How does U-Boot know which device tree to load? I don't know for sure for vendor BSP, there are multiple schemes possible.

But I suspect there will also be the one from mainline U-Boot: bake into the environment the fdt filename. Which is what e.g. extlinux uses with FDTDIR.

from h96-max-v58-investigation.

I'm going to call "my build of tow-boot built with radxa/u-boot/stable-rock5 sources" Vendor Tow-Boot, if that's not too inaccurate or offensive.

• no confusion about the FDT for u-boot being different than for linux

• normal mechanism by which u-boot selects a FDT from FDTDIR (with extlinux-compat), I'm fairly sure, is based on CONFIG_DEFAULT_DEVICE_TREE but this is ALSO what u-boot uses to pick the DTB to create it's appended u-boot-dtb.bin. which I'm sure is great in mainline where those are probably in sync

• I can't remember if this is a local change, but my extlinux generator uses hardware.deviceTree.name to override the FDT so I work around this already.

• Uboot has EXT_DTB but it's only half-integrated into the ecosystem and confuses the build system by default.

• When I experiment more, I plan to go in hack the tow-boot build to make a custom u-boot-nodtb + vendorkernel_dtb and see if that helps. It seems like that is just built-in to u-boot and then means I don't need to worry about catering to a vendor-bsp-specific mechanism or flow.

• Vendor U-Boot with vendor android images (kernel+mystery dtb) loads a DTB early in the u-boot sequence, and then is able to initialize more devices than... when it wasn't accessible to it anymore. Like the network, particularly. This is an example of my Vendor Tow-Boot booting and you can see it make a few attempts to find a DTB before it does much else.

U-Boot 2017.09 (Jan 01 1980 - 00:00:00 +0000)006-pre [variant: noenv]

Model: Rockchip RK3588 Evaluation Board
PreSerial: 2, raw, 0xfeb50000
DRAM:  7.7 GiB
Sysmem: init
Relocation Offset: edb60000
Relocation fdt: eb9fa5e8 - eb9fecd0
CR: M/C/I
Using default environment

mmc@fe2c0000: 1, mmc@fe2e0000: 0
Bootdev(atags): mmc 0
MMC0: HS200, 200Mhz
PartType: EFI
DM: v2
No misc partition
boot mode: normal
FIT: No boot partition
No resource partition
No resource partition
No resource partition
Failed to load DTB, ret=-19
No find valid DTB, ret=-22
Failed to get kernel dtb, ret=-22
Model: Rockchip RK3588 Evaluation Board
CLK: (sync kernel. arm: enter 1008000 KHz, init 1008000 KHz, kernel 0N/A)
[prints some clocks]
No misc partition
Net:   No ethernet found.
Hit key to stop autoboot('CTRL+C'):  0
MMC: no card present
mmc_init: -123, time 0
switch to partitions #0, OK

from h96-max-v58-investigation.

to be clear, my vendor-tow-boot build is capable of getting into Linux. But I'm stubborn and want ethernet boot for testing/recovery. So I'm specifically looking to:

1. Find a way to get u-boot itself running with the better dtb, probably by appending it to u-boot directly
2. Come up with the better dtb (via decompiling and diffing into a patch, hoping someone sends me a link to a secret branch, etc)

(And maybe there's another u-boot var to discover that allows controlling the default extlinux

from h96-max-v58-investigation.

AFAICT this is coming from the "rkimg" bits in the vendor U-Boot. You probably could take your backup of the partition it loads it from, and run binwalk on it to get a few DTBs out. Then you could run dtc to get a source file, and look at the compatible nodes and find the driver for ethernet, I suppose.

My first instinct would be to search for this:

• https://github.com/radxa/u-boot/blob/75b12f8295f1216d8f871a23fca37d4c990d508d/arch/arm/dts/rk3588.dtsi#L369-L370

Which is disabled by default

• https://github.com/radxa/u-boot/blob/75b12f8295f1216d8f871a23fca37d4c990d508d/arch/arm/dts/rk3588.dtsi#L390

from h96-max-v58-investigation.

I haven't followed the discussion above closely, so I may be a bit out-of-sync here, but there is what I believe to be an appropriate linux-dtb for the rk3588-evb1-lp4-v10 board (which is probably the basis for the h96max v58 board) in the rk3588 kernel tree, see e.g. rk3588-evb1-lp4-v10-linux.dtb inside this build/blob dtb-rockchip-5.10.153-rk3588-flippy.tar.gz

Of course, this doesn't fix you problem of having a "baked-in" dtb in u-boot that has nodes for wired connection so that you can do netboot and stuff...

from h96-max-v58-investigation.

@tri-pole : The other DTB has an identifier that matches what appears in the README, that's why I've been focused on it.

From the stock firmware: Model: Rockchip RK3588 NVR DEMO LP4 V10 Android Board

which also matches the runtime proc device-tree compatible string.

edit: filename rk3588-nvr-demo-v10-android.dts

from h96-max-v58-investigation.

OK. There are also a few dtbs in the blob I referenced with similar names (with nvr in the name) e.g. rk3588-nvr-demo-v10.dtb, rk3588-nvr-demo-v10-ipc-4x-linux.dtb and rk3588-nvr-demo-v10-spi-nand.dtb so probabbly also this version of the board has "official" support now.

from h96-max-v58-investigation.

Note that it's common for products with less care given to them to modify the BSP demo board device tree files, and not change the model name. For example I have a portable emulation console using the RK3566 reporting as an evaluation board on its Android build.

It is important to decompile the dtb and compare.

from h96-max-v58-investigation.

Yup, just wanted to share what I knew. I just figure the string match might hint at it being a smaller diff from a decompiled dtb, but that will require validation.

I haven't compared them thoroughly, but also some of the dts(i) files are slightly newer in the rockchip-linux fork compared to radxas.

from h96-max-v58-investigation.

You might want to dig in the rockchip-linux tree for the kernel version matching the kernel used in the TV box, and find the most recent commit from Rockchip with that version, to compare against.

Since you don't have a source to compare against, it won't be ideal, but you should get more genuine results than if you compared to the most recent changes.

This is something I've done with BSP zip/tarball releases to try and rehydrate some history:

• https://github.com/samueldr/linux/commits/wip/rg353-rehydration--wip?after=5571088abf68d10dd9792c8865d6833f1cd0e2ba+34&branch=wip%2Frg353-rehydration--wip&qualified_name=refs%2Fheads%2Fwip%2Frg353-rehydration--wip

from h96-max-v58-investigation.

I don't think it's that simple though, there's no defconfigs at all for the first appearance of the .66 version, at least in the rockchip repo.

On the other than, the radxa rock5 branch is still on 5.10.66....

from h96-max-v58-investigation.

from skimming though, I just kind of didn't see any changes in the last 6-9+ months that looks terribly relevant

from h96-max-v58-investigation.

Please i need DTB firmware for cracking DSTv channels

from h96-max-v58-investigation.

@fhairbwoi can you maybe open a new issue? I'm not sure exactly what that means.

from h96-max-v58-investigation.

from h96-max-v58-investigation.

No, sorry, I'm not familiar with any of that, nor is it in focus for this project/repo.

from h96-max-v58-investigation.

lol already done :) , reversed dtb and made a clean dts months ago several images already floating arounf
putty.log

from h96-max-v58-investigation.

from h96-max-v58-investigation.

Aw @Shaggy013, you gotta share the goods... Machine model: RK3588 Shaggy013 LP4x V1.2 H96_Max_v58 Board

from h96-max-v58-investigation.

getting closer... Shaggy013/kernel-5.10@18f321a

from h96-max-v58-investigation.

from h96-max-v58-investigation.

@Shaggy013 I ask about u-boot because (1) version seems newer, I was just intrigued, and (2) I want u-boot with proper ethernet driver.

my dream is to u-boot netboot all possible SBCs.

from h96-max-v58-investigation.

it is just default uboot from rockchip and netboot is default broken in that

https://drive.google.com/file/d/1no7p_kyjWw60q9iFS8NMETgIyTRlsGaU/view?usp=share_link

here a android version with if did goog everything working

from h96-max-v58-investigation.

@Shaggy013 do you know how to get RX on the board to accept input over serial? So far the board acts like no input is being sent over serial.

from h96-max-v58-investigation.