Jump to content

dieselnutjob

  • Posts

    28
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Here is an example of what the output looks like. The true/false column is the result of "=EXACT(C1,D1)", in other words true means that the value is of the unknown device is the same as rk3566-quartz-a and false means that it is different. The magic of the program is that "true" means that in the case of a phandle that the values that are pointed to by the phandle are the same rather than the value of the phandle itself.
  2. I just did a big update to version 4. This version contains quite a lot of the logic of how a dts file is actually compiled. It recursively loads in a specified dts file and then all of the dtsi and .h files that are mentioned and reassembles the whole thing. Then it searches for node labels that are references in nodes and childnodes and automatically converts those node labels into nodes as then would appear in the compiled dtb file. I have tested this with 4.19 rockchip dtb file because that is what I am interested in and it seems to work very well.
  3. version 3 is on github. This version will, if a label uses a different string to the nodename that it refers to, attempt to do a lookup for phandles to the label as will as nodenames. This dramatically cuts down the differences between two similar boards in the dtb files. I don't think that it's perfect and I only tested it on Rockchip 4.19 files, but it's progress.
  4. I have just done a major update to dts2tsv. One of the problems I had is that decompiled dtb files from different places can have misaligned phandle values. Specifically a value might be a either text, a variable (in u32 form) or a pointer to a variable (a phandle). When you look at a number in a value it's not easy to tell whether it's a variable or phandle, and when comparing two dtb files it is likely that they appear to be different, when actually two phandles are pointing at the same thing. If you have original source code for a dts file you can tell whether a value is a u32 or a phandle, however that information is lost when the file is compiled. Additionally if you have two similar devices, one with source code and one without, the one with source code will give you clues about the values in the dtb file from the device without. This new version accepts two different types of file as input now. -s [files] These are source code files, and the program uses it to build a list of which values are variables and which are phandles. -d [files] These are decompiled dtb files. The program will use the -s files to identify which values in the -d files are phandles, and then in each file it will search for values that own that phandle and substitute in the name, in other words what the phandle actually points to. It seems to work quite well. The reason that I wrote this program is that I want to be able to modify source code dts from similar devices to create source code for a device for which I have only decompiled dtb. I want the resultant source code to produce a dtb that is as close as possible to the original vendor dtb, so get it as safe as possible and most likely to boot. Having a comparison tool that tells me how close I am getting and what the differences still are is, I think, useful.
  5. dieselnutjob

    dts2tsv

    Suppose that you have a bunch of dtb/dts files that are known good (like from Linux kernel source). Suppose that you have a dtb file that you ripped out of some new device and probably no source code. This tool will allow to dump all of the parameters (nodes) out of the dtb file and compare it with all of the other ones that you have in a spreadsheet so that you can visualise the differences. See https://github.com/dieselnutjob/dts2tsv
  6. Compile a 4.19.220 kernel for quartz64-a with these instructions:- https://github.com/dieselnutjob/kernel-rk3566/blob/linux-4.19.210/README.md
  7. I have playing with compile.sh CREATE_PATCHES=yes There is a guide here https://zuckerbude.org/armbian-using-create-patches/ I also read this before https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-patches So if someone is a profession developer and understands how to use diff and patch commands, then please understand that I am not, so please help but keep it as newbie as you can. So when I came across this CREATE_PATCHES option I though, ooh that's clever. I can make changes to u-boot or kernel source and it will create the patch files for me, and then I can put those patch files on my github fork of build, or in userpatches or whatever and it will automate the changes. Very clever. I think I have understood that that is what it is for. But what if I have an entire u-boot source folder that someone else from an entirely different Linux distro already did? But which is a patched version of the one that Armbian build is using for some very similar board. So probably the difference isn't that great. Is there a clever way to run compile.sh CREATE_PATCHES and then when it stops to somehow diff the "build/cache/sources/u-boot-rockchip64/stable-4.19-rock3" folder (for example) that it's prompting me to change with the local complete u-boot folder that I already have either locally or on github, make the diff output only copy the changes that the other Linux distro guy did, and then press enter in the compile.sh window so that it kind of reverse engineers all of those diffs and makes an armbian patch file that will automate the whole thing? Is that even realistic or is it just mad and I completely misunderstood or something?
  8. aha maybe it's something to do with these lines [ o.k. ] Cleaning [ u-boot/quartz64-a ] [ o.k. ] Compiling u-boot [ 2017.09 ] [ o.k. ] Compiler version [ aarch64-none-linux-gnu-gcc 9.2.1 ] [ .... ] Checking out to clean sources [ o.k. ] Cleaning [ u-boot/quartz64-a ] [ o.k. ] Started patching process for [ u-boot station-p2-quartz64-a-legacy ] [ o.k. ] Looking for user patches in [ userpatches/u-boot/u-boot-station-p2 ] I need to remove some of 150balbes userpatches I guess
  9. Time for an update. I can compile u-boot for the quartz64. Instructions are here https://github.com/dieselnutjob/u-boot I can modify armbian build to download that same u-boot code and compile it That code is here https://github.com/dieselnutjob/build however when I run compile.sh in build I get this error CFGCHK u-boot.cfg Unsupported u-boot processing configuration! on investigation I found that build/cache/sources/u-boot/quartz64-a/u-boot.cfg is not the same as the u-boot.cfg if I compile u-boot directly from my own source outside of the armbian build scripts. I don't yet understand why.
  10. thanks to mara on the pine64 forum I can now compile u-boot for the Quartz64 from source, tested it and it works. The code is here https://github.com/dieselnutjob/u-boot.git Instructions are here https://github.com/dieselnutjob/u-boot/blob/quartz64-a/README I also have the source code for his kernel for the board. I have put that here https://github.com/dieselnutjob/kernel-rk3566.git but I haven't figured out how to compile it yet.
  11. Is this the source code for this latest image https://github.com/150balbes/build/tree/station-x2 ? or is a different branch? thanks
  12. I just tried the Station-m2 bullseye image on my Quartz64-A It wouldn't boot past initram with an eMMC module as it couldn't find its root partition. I boots on microSD card The HDMI output doesn't display on th Quartz64 To try it you need to dd the image onto a microSD card, then mount it in linux and modify the /boot/extlinux/extlinux.conf file like this:- LABEL Armbian LINUX /boot/Image INITRD /boot/uInitrd FDT /boot/dtb/rockchip/rk3566-quartz64-a.dtb APPEND root=UUID=563b30fb-fd81-42bf-92bf-757c1b1cd11f console=uart8250,mmio32,0xfe660000 console=tty1 console=ttyFIQ0,1500000n8 rootflags=data=writeback rw no_console_suspend consoleblank=0 fsck.fix=yes fsck.repair=yes net.ifnames=0 bootsplash.bootfile=bootsplash.armbian
  13. looking at https://github.com/150balbes/build/blob/station-x2/config/sources/families/rockchip64.conf if [[ $BOARD == station-p2 || $BOARD == station-m2 ]]; then BOOTSOURCE='https://github.com/150balbes/u-boot-rk' BOOTBRANCH='branch:rk356x' BOOTPATCHDIR="u-boot-station-p2" KERNELSOURCE='https://github.com/150balbes/rockchip-kernel' KERNELBRANCH='branch:rk35xx' KERNELPATCHDIR='station-p2-'$BRANCH LINUXCONFIG='linux-station-p2-'$BRANCH LINUXFAMILY=station-p2 else KERNELSOURCE='https://github.com/ayufan-rock64/linux-kernel' KERNELBRANCH='tag:4.4.202-1237-rockchip-ayufan' KERNELPATCHDIR='rockchip64-'$BRANCH fi can anyone tell me where this "station-m2" board name comes from? looking at this file https://github.com/150balbes/build/blob/station-x2/config/boards/station-m2.wip # Rockchip RK3566 BOARD_NAME="Station M2" BOARDFAMILY="rockchip64" BOOTCONFIG="firefly-rk3568_defconfig" KERNEL_TARGET="legacy,current,edge" FULL_DESKTOP="yes" BOOT_LOGO="desktop" BOOT_FDT_FILE="rockchip/rk3566-firefly-roc-pc.dtb" SRC_EXTLINUX="yes" SRC_CMDLINE="console=uart8250,mmio32,0xfe660000 console=tty0" ASOUND_STATE="asound.state.station-m2" IMAGE_PARTITION_TABLE="gpt" the string "station-m2" only appears in the filename "station-m2.wip". Is it the filename itself that gets converted into $BOARD or does it get populated some other way?
  14. The other point is, if you look at the original Armbian code at https://github.com/armbian/build/blob/master/config/sources/families/rockchip64.conf source "${BASH_SOURCE%/*}/include/rockchip64_common.inc" case $BRANCH in legacy) KERNELSOURCE='https://github.com/ayufan-rock64/linux-kernel' KERNELBRANCH='tag:4.4.202-1237-rockchip-ayufan' KERNELDIR='linux-rockchip64' KERNELPATCHDIR='rockchip64-'$BRANCH ;; esac prepare_boot_configuration that in itself depends on the ayufan-rock64 repo. So if it doesn't actually work on a specific board then what are 150balbes or myself supposed to do about it? Who's to say that the ayufan-rock64 repo is any more legitimate than 150balbes? This is, I think, entirely the fault of Rockchip for not providing upto date working code for the RK3566, and by working I mean with an HDMI port that actually works.
  15. I suppose that this is the problem with open source. You can end up with a fork of a fork of a fork and then it's very difficult to merge it back into the original code. In no way do I mean any of this as a criticism of 150balbes. I don't think that any of us get paid for this and probably we all want something that works, and forking the nearest to what works rather than the original project is of course the easiest way to achieve that.
×
×
  • Create New...