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?

Sorry, no. Does your boot log suggest, that the box even tries to access the SPI-flash? Or does it not matter, what you have written to the SPI?

, yes that is not really unexpected. But I think, we still can get some information from it. (BTW, I will not be able to contribute very much in the next few days)

Meanwhile I downloaded the 12GB-GPL-Package from WD and it contains a lot of stuff. I suppose one of the DTB's with the WD-prefix could be usable for @ShaRose. The rest of the kernel-4.1.17-tree should not be that helpful. I will add them to my kernel repo, but maybe you can test it before. The second interesting thing could be the bootloader-folder, but I still have to digest it.

Can You upload this? I‘d like to take a look.

I think, that looks good! Please try to find the further information in the forums of zidoo and bananapi-w2, there is more than one thread about it. I will assist, if you need help when I am back home.

Wow, your solder skills are some levels above mine . The funny thing is, that I could x-ray my box. Who told you that ? Maybe I do it next week. I am not at my PC atm, so I am not exactly shure from memory, but you need to write some kind (the correct) hwsetting.bin at the start of the SPI and then this magical drvboot.bin.exe-thing (name is probably incorrect). There are two versions for emmc and SPI. I tried it on my lake1 (obviously emmc), but due to the encryption the box refused to boot (very early, when hwsetting should get loaded). You might be right with your assumption, the uu3-1 is the switch to USB. As your box has SPI (?), this would mean no automagically fallback to SPI. Can you reach the SPI-prompt with ctrl-q (or so)?

Hmm, interesting ... sounds reasonable . Can you test, if you can fatload from an USB3-stick (maybe you can already answer this)? If I read your post correctly, you used a USB2-stick? Meanwhile I will take a look, if I find traces of your terminal input in the u-boot-sources.

Yes it should, the question is, if it reliably does. For instance I could not figure out, why fatload does not work in the first u-boot-loader on my lake1. Another interesting folder in the repo mentioned above is this one: https://github.com/BPI-SINOVOIP/BPI-W2-bsp/tree/master/u-boot-rt/examples/flash_writer It seems, that the loader for SPI-flash is created here, but for obvious reasons I can not test it. As crazy at it sounds, currently I am under the impression, that the only profound way to bring linux to these realtek-boxes would be to solder spi-flash on it and then find a way to build a sufficient loader. But of course I am aware, that this might be a totally wrong idea. BTW, I just revisited parts of the 4.9.-kernel-repo and had to find (again), that parts of the code are different to the linux-master-tree (of 4.9.y), although they are not marked with #ifdef RTK_... or similar things. That does not make things easier

Yes, I think so. In theory it could be possible to build this stuff from the repo of the banana-pi-folks and, as the source code is there, upgrade the code base to a newer u-boot. But this will very likely not happen in practice for several reasons. The platform suffers from poor (nearly no) documentation and the amount of work to even try this, is ridiculously high in contrast to the expected result. I will continue to upgrade the the 4.9.y-repo (as this is not that much work) and report , if I really find something new.

Thank you for the info. Hmmm, this is with (boot-selector) SW4 in position 1 ... i guess? BTW, shipping from china seems to take a while at the moment. Still no new SPI-chips to test.