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.

Now everything is totally clear :
 

Good news! I have found the BOOTSEL pin on my board I connected my logic analyzer to DI pin on SPI header, shorted one suspected pad and saw signals on my analyzer. Then I made a jumper out of 1.27mm pitch pin header and did some fine soldering.
 
Now the question is, what to load to my SPI flash? Does anybody have a full dump from bpi w2 here?

I wrote a short guide how to recover from wiped boot sector https://blog.danman.eu/zidoo-x8-recovery/

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!

Now everything is totally clear :
 

I was under ubuntu using gtkterm.
 
It's nice to see your experiments even if it has been better that realtek and manufacturers published documentations.

@ShaRose, do you have root access on your original system? Can you try:
dd if=/dev/mem bs=1 skip=32505856 count=74410 of=original.dtb (skip and count are translated from hex to dec)
 
@others Meanwhile I was experimenting with the d/g/r> shell. I'm struggling to make ymodem work in minicom but I have some ideas...

I'm currently running binwalk over all the system partitions (Everything but the data) to see if I can find myself an official dtb: mine includes a bunch of stuff that isn't needed due to how it was made, including that serial number I censored out. If I get an official one, I'll see if it can boot, but either way I'll upload it.

Wow! Really? This might help you with searching then
I'll try Ctrl-Q as soon as I'm home.

I don't have one either, mine is v1, but yes that should be the trick ...

Yesterday i did install Armbian_5.86_Aml-s905_Debian_buster_default_5.1.0_20190514.img from @balbes150
on my Sunvell T95KPro (S912).
 
While installing Pihole the Installation does break when trying to start lighttpd.

After checking with journalctl -u lighttpd  it turns out that the file /usr/share/lighttpd/create-mime.assign.pl 
is missing, because in the newer lighttpd-version of debian buster the file has be renamed
to /usr/share/lighttpd/create-mime.conf.pl 
(see also https://discourse.pi-hole.net/t/lighttpd-does-not-start/6207/11 )
 
Pihole doesnt know/use the new name with debian buster, so it fails to start the lighttpd
 
So I did find 2 ways to resolve the problem.
 
First (quick and dirty?) way:
cp /usr/share/lighttpd/create-mime.conf.pl /usr/share/lighttpd/create-mime.assign.pl or ln -s /usr/share/lighttpd/create-mime.conf.pl /usr/share/lighttpd/create-mime.assign.pl
read also:
Pihole breaks lighttpd on Debian Buster #2557
https://github.com/pi-hole/pi-hole/issues/2557
 
the second way (found it at https://forum.kuketz-blog.de/viewtopic.php?t=3067 ) is to edit /etc/lighttpd/lighttpd.conf 
and search for the 2 following lines and comment them out (found the 2nd one at the end of the file):
 
#include_shell "/usr/share/lighttpd/create-mime.assign.pl" #include_shell "cat external.conf 2>/dev/null" and add the follwoing line to the file:
include_shell "/usr/share/lighttpd/create-mime.conf.pl" After saving the file you should be able to restart lighttpd via
sudo /etc/init.d/lighttpd restart or sudo service lighttpd restart or sudo service lighttpd stop sudo service lighttpd start  
BUT second way does not work good with updating or repair-install of pihole, because I think this will set the config-file to the old state
(also for server.error-handler-404)

So maybe the first way will work better while pihole doenst know the new file-name - or you also can do both ways
 
BTW: If you are experience a 400 Bad Request while  only using the IP for getting to the Pihole-Webpage
(and the redirect should ask you if you want to use the /admin page - but it doenst)
then try the follwing small resolution - edit a line in the file /etc/lighttpd/lighttpd.conf
from: server.error-handler-404 = "pihole/index.php" to: server.error-handler-404 = "/pihole/index.php"  
 
lighttpd.conf

well.. that's one which you can solder without trouble.. @TonyMac32 would probably say I'm wrong.. but I would tin the first pad, press the SPI nor on it and remelt it.. once you have an anchor pad.. the rest is easy..

Thanks to all for the recent responses! It helps to keep the motivation above zero and yes, maybe it is time to search for external help.
 
But now the short guide "how to brick such a box":
It was not bad luck but active stupitidy.
Some weeks ago in a mixture of impatience, lack of time and sleep I decided to try out various commands of the u-boot-shell. Before that I had to reflash my box several times, which worked easily and besides I was under the (incorrect) impression, that things like the RPMB were already written to the box by the vendor. That led to a situation of recklessness. 
So I typed in the command:  m m c  k s (I added additional spaces here to avoid dangerous copy-and-paste-actions!!)
The I got:
 
That did not look promising and it turned out to do the bricking.
The good thing is, that you have to actively kill the box and it should not happen so easy.
So the general advice of common sense is valid here too: Do not do things in a hurry, read through every available resource before you press enter button!
 
My last try to recover the box  would be to solder a SPI flash chip onto the PCB and flash it with the REALTEK tool. Can someone provide a hint which chip type could be compatible?

This is only for sake of booting it somehow, but at least:
_ _ _ | | __ _| | _____ / | | | / _` | |/ / _ \ | | | |__| (_| | < __/ | | |_____\__,_|_|\_\___| |_| Welcome to ARMBIAN 5.77 user-built Debian GNU/Linux 9 (stretch) 4.19.16-rtd1295 System load: 2.81 1.25 0.47 Up time: 2 min Memory usage: 5 % of 1932MB IP: CPU temp: 42°C Usage of /: 15% of 7.1G  
This is useful for nothing at the moment (no usb, no net, no straightforward installation method), but I am not yet in the state to give up.
It is a buggy mess at the moment and again I have not uploaded all stuff to my repo.
To reach this pseudo-success, I had to boot with kernel 4.9.y, then let armbian resize the initial image (which does not work with 4.19.y for whatever reason) and then write the 4.19.-kernel and the DTB to the SD-card. So it is a bit of a click-bait 
 

Hi,
 
after reading the very entertaining thread regarding the BPI-W2 and the following opening of the bsp-kernel on github, I became curious and when prices dropped for the Lake-1-TV-Box, I decided to play around with it.
 
Without very much documentation there was a bunch of trial and error and still many things are not absolutely clear to me, but finally I could boot an armbian build today:
_ _ _ | | __ _| | _____ / | | | / _` | |/ / _ \ | | | |__| (_| | < __/ | | |_____\__,_|_|\_\___| |_| Welcome to ARMBIAN 5.68 user-built Ubuntu 18.04.1 LTS 4.9.119-rtd1295 System load: 1.49 0.74 0.31 Up time: 3 min Memory usage: 4 % of 1631MB IP: CPU temp: 46°C Usage of /: 11% of 7.2G [ General system configuration (beta): armbian-config ] New to Armbian? Check the documentation first: https://docs.armbian.com Thank you for choosing Armbian! Support: www.armbian.com  
This is still connected over the serial port and completely untested. I had to use the strange chained double-u-boot and load kernel and dtb manually (from raw sd card sectors), so it is not even close to alpha. But it seems, that this can be improved. 
 
I plan to make a repeatable build config, but do not expect some really usable stuff anytime soon.  The situation with the lack of mainline support was already discussed in the other thread and the future does not look very bright here.
This is more or less a personal playground at the moment. But if anyone is interested, you can leave comments or questions here.
 
Sticky part (updated 03-03-2019):
 
RTD1295-Devices:
      Tested: Lake 1 Home Cloud TV Box
      Untested: Beelink SEA 1, Zidoo X9s, Zidoo X8, Zidoo X10,  Probox2 AVA, WD My Cloud Home, ...
 
All development and tests thus far have been done on the Lake-1-TV-Box. It can not be ruled out, that the other boxes have other u-boot-versions/-configurations.
 
Prerequisites:
Mandatory:
Serial connection soldered to the PCB (to reach the u-boot-shell) and a suitable terminal software. Further information here: https://en.opensuse.org/HCL:Lake1 (I can not confirm that „SD rescan“ does not work. Only „fatls“ and „fatload“ never worked for me, that’s why raw sector reads are used.)
 

 
Recommended:
Access to a Windows-PC, a USB-male-to-male-cable and the knowledge to re-flash the device by yourself.
If you are not comfortable in doing this, DON’T DO IT!!! YOU CAN BRICK YOUR DEVICE FOREVER !!
 
Current installation process (booting from SD-Card):
Build a full-OS-image with armbian selecting „lake1“ from this fork: https://github.com/Staars/build. This will create an image with kernel image and dtb written to sectors before the root partition. The u-boot-build of armbian is not used. Write the image (using etcher) to an SD-card. For the moment we will not touch the eMMC of the target device and therefore will work as non-destructive as possible. This might change in the future and it should be no problem to implement a eMMC-only solution, but at the moment there is no solution in sight, that would let you dual-boot Android and Linux. Create a terminal connection to the serial pins of your target device and intercept the boot process immediately after power up to reach the first u-boot-shell. Now we have to edit the BOOTCMD the following way: env edit bootcmd sd read $kernel_loadaddr 800 954a; sd read $fdt_loadaddr a440 5d; env set bootargs earlycon=uart8250,mmio32,0x98007800 console=ttyS0,115200 noinitrd root=/dev/mmcblk0p1 rootfs=ext4  init=/sbin/init; b2ndbc; bootr env save  
           This is a relatively harmless operation and can be reversed with the insertion of 'bootr' in step 2.
           The Android-installation on the eMMC stays untouched.
 
   4. Now at every boot the device will initialize the SD (which can fail!!), load the image and dtb, change the bootargs and call the second u-boot, which then will (hopefully) boot the kernel. 
 
U-boot:
At the moment u-boot will be build, but not used. Because of bootloader encryption this will likely stay that way. We can build the fsbl-parts, but without the proper encryption the boot stops, when the first part (hw_setting) is loaded. 
A separated u-boot-fork at https://github.com/Staars/u-boot-rtd is used for the armbian build, but that does not really matter. We must use the vendor-u-boot and we can not do real scripting (no RUN-command) but only chaining of commands.
 
Kernel:
The starting point from Sinovoip was labeled 4.9.119, but this is very likely not the whole story. Some parts are even newer and some are probably older, given the fact that git-cherry-picking showed possible updates when used with the stable linux-4.9-branch below tag:4.9.119.
The additional phoenix drivers were partly integrated in the kernel-fork on https://github.com/Staars/linux-kernel-rtd/tree/latest_patched as an extra folder to keep them in one place.
If there should be really an adoption of this platform in the future, it might be a good idea to go the other way around and merge the soc-specific parts into a generic linux-4.9.-fork. This is a bit of work, but it should be possible.
The fork is currently patched to 4.9.174
New kernel fork started at https://github.com/Staars/linux-stable/tree/linux-4.19.y (not 4.20 because of LTS) and armbian build config updated.
 
DTS/DTB:
This is a minimal changed version for the banana-pi w2. 
 
Bluecore.audio:
I do not really know if this (audio firmware?) is useful outside of Android. It is written to the SD-Image (directly behind the DTB), but not loaded.
 
What works:
-SATA-port (incl. booting with /root on SSD with bootarg 'root=/dev/sataa1')
-WLAN (onboard 8821AU), but there are very short freezes every few seconds
-simple software install (i.e. OMV)
-reboot/restart works, but can take some time
-bluetooth
 
What does NOT work:
-bluetooth
-halt/restart
 
Things to do:
-waiting for someone, who confirms, that this is repeatable on other setups
-working on the DTS/DTB
-test Ethernet, USB
-HDMI-in/-out or graphics in general (very low priority for me)
-eMMC-only-install (must check first, where it is safe to write data)
-test 4.19 (functional regression expected)
 
Board_Pics:
 

Just thinking about the task, it remind be all my struggling between the 2 boot mode of Rockchip back in early December :
https://github.com/armbian/build/commit/c3e46a5d863ebc4d00d666b3a19eed00e3d0c17d#diff-ee77e238b43dce4af9e9f0b7d3f9978a
 
Personally, I like more this single u-boot binary using this method #2 !
 
I will see if that can be generalized on every Rockchip ...

I'm currently accessing it through ssh and using a wireless connection. It works well, here is iwconfig result:
wlxa02c36cad0d2 IEEE 802.11 ESSID:"XXXXXXXX" Mode:Managed Frequency:2.412 GHz Access Point: XX:XX:XX:XX:XX:XX Bit Rate=72.2 Mb/s Tx-Power=18 dBm Retry short limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality=61/70 Signal level=-49 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 EDIT: I used armbian-config to set up the wifi.

Hi,
 
I received my box yesterday and was able to build and follow your instructions to get the following system:
 
_ _ _ | | __ _| | _____ / | | | / _` | |/ / _ \ | | | |__| (_| | < __/ | | |_____\__,_|_|\_\___| |_| Welcome to ARMBIAN 5.76 user-built Debian GNU/Linux 9 (stretch) 4.9.157-rtd1295 System load: 1.31 0.91 0.41 Up time: 5 min Memory usage: 3 % of 1636MB IP: CPU temp: 52°C Usage of /: 2% of 58G Great work!

well, I'm quite confident that they don't need 'our help' in those days to look stupid..
 
In case someone asks it's mostly the Austrians and the Germans fault why we can observe greenhouse gases (Boltzmann & Planck). For those wanna lock smarter as they are...  A heretical explanation which 'works' is that every gas consisting more than two atoms is a greenhouse gas (e.g. the famous CO2). To be a greenhouse gas, a gas has to absorb near-IR radiation. If you dive now into quantum physics, only so called vibrational& vibrational-rotational transition which change the dipole moment of a molecule are allowed. If you compare now CO2 (greenhouse gas) and N2 (not a greenhouse gas):

Carbon dioxide has two normal modes (2&3) which end in a change of the dipole moment (and one mode without such a change) whereas Nitrogen gas hasn't such a normal mode (only a symmetric stretch). But before we dive more into smart ass mode... I'm by no mean an expert in quantum mechanics I'm more like Dwayne Johnson in No pain no gain... Luckily, smarter people at Harvard rolled the topic better up that I could do it ever on myself from a quantum mechanical standpoint. Feel free to dive into it:
http://acmg.seas.harvard.edu/people/faculty/djj/book/bookchap7.html
They don't try to make up conclusions which their data doesn't cover.. They just try to explain it for people at least somehow able to understand quantum mechanics basically. Unfortunately there aren't as many 'scientific journalists' around the world to analyze and understand scientific papers to come to the right conclusion. In fact they mostly try to catch up some 'dramatic looking' sentences inside a publication to get some attention assuming that every sentence in a publication is so 'well-crafted' that it must be still valid if you change it a little bit. A *random expert* adds then some other dramatic sentences as well and there you get your 'it's the global warming, stupid'-article..  Small hint, not every scientific publication is on such a high level and it needs a lot of skills to break down such an article to make it understandable for the average joe and still being scientifically correct. Unfortunately it often ends in "reading A, thinking it means B and conclude C".. Maybe we could do better try to explain what our research tries to achieve in a manner that the 'average joe' also partly understands what we're doing... Not every detail, but at least partly..

Just a tiny update. Booting from SSD works as expected:
 
It is not completely free of error messages, but it is quite okay'ish.
 
I will try to update my first post in order to gather the most recent information there. 

Just a tiny update. Booting from SSD works as expected:
 
It is not completely free of error messages, but it is quite okay'ish.
 
I will try to update my first post in order to gather the most recent information there. 

Just a tiny update. Booting from SSD works as expected:
 
It is not completely free of error messages, but it is quite okay'ish.
 
I will try to update my first post in order to gather the most recent information there. 

So, a few days later .....
 
After spending several hours with my box including multiple head-banging on my desk, I found a surprisingly simple solution for an automated boot. But first some infos:
 
1. Many of the RT1295-Boxes seem to have encrypted bootloaders (and kernel images) which makes it close to impossible to build new ones. One notable exception is (according to the firmware images) the Zidoo-line. If I understand correctly, it should be very dangerous to flash a Zidoo-box with another firmware (Lake, Beeling, Probox), because if the filenames containing words like "efuse" have a deeper meaning, then you can never again flash the Zidoo-Firmware. If someone knows more about this topic, I would be very interested to hear about.
 
2. The GitHub-repo from BPI is bizarre, to say the least. They included a bunch of software to build encrypted firmware, which should not be needed for the BPI-W2. I could not get it to work, but maybe some others are able to do it. If someone can succeed, then point 1 shines in another light. At least you can build the dvrboot.bin and dvrboot.exe.bin yourself and I do not understand, why they (the bananapi-guys) describe cumbersome ways in their forum to download all that stuff from somewhere as a binary. I could not test these files on my Lake-1-box because of point 1, so it could be that they do not really work.
 
3. In the end it was relatively simple. In the first u-boot, you can modify and (!!) save the bootcmd and (!!) you can pass multiple commands to it. You have to:
env edit bootcmd then You will be asked for the new value and have to insert:
sd read $kernel_loadaddr 800 954a; sd read $fdt_loadaddr a440 5d; env set bootargs earlycon=uart8250,mmio32,0x98007800 console=ttyS0,115200 noinitrd root=/dev/mmcblk0p1 rootfs=ext4  init=/sbin/init; b2ndbc; bootr Please keep in mind that you have to use my "special" SD-card, where the kernel image and the dtb a written to the blocks 0x800 and 0xa440.
That's it for the moment.
 
If I find something new, I will update this thread. Feel free to ask.

So, a few days later .....
 
After spending several hours with my box including multiple head-banging on my desk, I found a surprisingly simple solution for an automated boot. But first some infos:
 
1. Many of the RT1295-Boxes seem to have encrypted bootloaders (and kernel images) which makes it close to impossible to build new ones. One notable exception is (according to the firmware images) the Zidoo-line. If I understand correctly, it should be very dangerous to flash a Zidoo-box with another firmware (Lake, Beeling, Probox), because if the filenames containing words like "efuse" have a deeper meaning, then you can never again flash the Zidoo-Firmware. If someone knows more about this topic, I would be very interested to hear about.
 
2. The GitHub-repo from BPI is bizarre, to say the least. They included a bunch of software to build encrypted firmware, which should not be needed for the BPI-W2. I could not get it to work, but maybe some others are able to do it. If someone can succeed, then point 1 shines in another light. At least you can build the dvrboot.bin and dvrboot.exe.bin yourself and I do not understand, why they (the bananapi-guys) describe cumbersome ways in their forum to download all that stuff from somewhere as a binary. I could not test these files on my Lake-1-box because of point 1, so it could be that they do not really work.
 
3. In the end it was relatively simple. In the first u-boot, you can modify and (!!) save the bootcmd and (!!) you can pass multiple commands to it. You have to:
env edit bootcmd then You will be asked for the new value and have to insert:
sd read $kernel_loadaddr 800 954a; sd read $fdt_loadaddr a440 5d; env set bootargs earlycon=uart8250,mmio32,0x98007800 console=ttyS0,115200 noinitrd root=/dev/mmcblk0p1 rootfs=ext4  init=/sbin/init; b2ndbc; bootr Please keep in mind that you have to use my "special" SD-card, where the kernel image and the dtb a written to the blocks 0x800 and 0xa440.
That's it for the moment.
 
If I find something new, I will update this thread. Feel free to ask.