Staars

I can not answer your question, but in the last few weeks there has been a lot of activity on lkml.org regarding the realtek-platform. Basically „the pro‘s have taken over“ and this is the best thing, that could have happened. I think it is a smart move from realtek to go the „mainline-route“, as it will make their and our lives much easier in the future. But now we need some patience, because every effort outside of the kernel-development is (IMHO) wasted time.

Ahh, I understand. I had hoped, that at least the initial serial output would show some signs of success. BTW, I just test this an my bricked Lake-box and there is nothing new to be seen. (I used the marked solder points from above) Another little update: On LKML there is some new activity regarding new additions to the soc-family directly from realtek, which sounds good to me, even if this is in the very early stages.

Wow, that would be pretty cool! In comparison to your board, I think the solder points with the blue arrows should be connected, right? I strongly believe, that everything is in the u-boot-folder of the repo from the banana-folks. I do not remember the exact name right now, but it was something like drvboot.exe, which we can build (!=which will work ). @danman What do you see on the console, when you use your BOOTSEL? I just want to know, if I am able to replicate this.

Hi, I think that looks promising. As far as I know, the version of u-boot provided by Sinovoip expects a FAT partition with a certain naming scheme for kernel, DTB and audio firmware. Here is a pastebin from a user of their forums, where at least a kernel is loaded: https://pastebin.com/3MPFDLpS I can only provide some guesswork here, because I do not have an bananapi-w2. What is the partition/naming scheme of libreelec? Can you access an USB-stick like described some posts ago from the u-boot-console?

Okay, that was more cumbersome than I had hoped. https://gist.github.com/Staars/d0076df23a70be5179b0fbb3f564d418.js This may completely break everything, but at least it produces a module "gt9xxf_ts.ko". For testing please copy this gist to output/patch in your build environment. Without the actual hardware I will probably not be able to help you any further.

I did a quick check and have to admit, that chances are low to backport this driver to such an old kernel. More than a few function calls initially appear in kernel versions >3.17 and you would have to rewrite a good part of this driver. This might not be impossible, but it is no quickie.

Just a small update on the kernel side. I uploaded all my latest local changes for the kernel tree 4.19.y (= 4.19.55), so you can build it (DEV) from my repo. But don't get too excited, it will not really work. This is only meant for further developing and hopefully some more skilled kernel-hackers can take look. There are some backports (for instance android/staging) and all API-changes were done according to the compiler output and the following internet search, so the process included traces of cargo-cult-programming. Expect stupid bugs here and there. Expected behaviour: A boot-log with surprisingly few errors but the inability to have a root device . The console output will stop and after while you should see a kernel error. Disabling usb or ahci or sd or mmc drivers (or combinations) will change the error slightly. It seems, as if there is always a DMA-problem, but that might be coincidence. I simply do not know, if there is just one wrong line of code somewhere or if the whole construction is lightyears away from working. Happy hacking!

It is captured with an digital x-ray-system using digital image plates. Spatial resolution is limited, we can only zoom digitally. More pictures do not really make sense here.

Now everything is totally clear :

Yes, I see. I tried „screen“ and „miniterm“ on macos and „hypertrm“ (the recommended one from bananapi) on win10. I think @jeanrhum also tried it without success, but I do not know, which terminal he used. I think that this d/g/r-thingie os part of the soc-firmware too, but it might be possible, that a compatible SPI-chip is needed or (additional) a resistor or something has to be added or removed, before the SOC decides to launch this prompt. Keep in mind, that the Lake1 (and some other boxes) do not have a SPI-chip when they leave the factory. They only have the unpopulated connector and maybe there is a missing secret sauce. Anyway, I already have my bricked box prepared and it will get the x-ray-treatment tomorrow (if I do not forget it ). BTW, I wonder what the box expects to find on the usb device at the stage of „uu3-1“?

Yes I can flash, no I can‘t boot. No, I can‘t reach d/g/r using ctrl+q.

I really hope you are right and will gladly change my opinion. In this post: ... you see the bootlog of the bricked box after flashing an Android image (OTP verification) including my incorrect assumption about ‚uu3‘. On the bricked box I can not reach any prompt. It is just the flashing procedure with the windows tools, that works without an error message.

Yes, I have two now. Some posts ago I shortly described, how I bricked the first one. d/g/r needs SPI-flash, which is not populated on the Lake1. The first try, to solder a chip went wrong (probably incompatible chip, maybe a defective one or bad soldering). Now I wait for some weeks for the arrival of new chips (the one I got told from chwe), but somehow it takes a very long time. I think, that your soldering trick will not work with my box. I can flash all sorts of firmware without a problem, but the box complains about an encyption error early in the boot process. That’s why I believe, that a pure emmc-boot is impossible forever on that box. I could send you the data, but I would not recommend it. As long as we are not totally shure, what happens with cross flashing and the SPI-path is not working, it might lead to a bricked box. AFAIK the zidoo boxes are exceptions with their firmware with more unencrypted parts, means I would especially not cross flash a zidoo box (unless you find a believable report, that this works). BTW, technically you can simply flash the (easy to find) lake-firmware on your box with the realtek utility, but again: I DO NOT RECOMMEND THIS BASED ON MY CURRENT KNOWLEDGE.

That is my impression too. I better put my box in my bag for tomorrow now. Yesterday I forgot it. At least we will get a very special product picture My interest in the SPI-solution is based on the hope, to get rid of the encrypted bootloaders. On the Lake1 we would have to keep the partition structure of the emmc as delivered, because the fixed boot process breaks, if anything unplanned happens to the emmc (and not only to a boot partition). So ATM you better not touch the emmc.

🤔, it is a start. slightly off-topic: Is there any use for the SPI-flash on your zidoo, when using it as a TV-box? It seems to get ignored anyway or did I misunderstand something?