Staars

Members
  • Content Count

    54
  • Joined

  • Last visited

About Staars

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. 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.
  2. 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
  3. 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.
  4. 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.
  5. Well, next question, which uboot.bin? The problem (on my lake-box) is, that everything except the second u-boot (2015) is encrypted. So the more important first u-boot (2012) is encrypted and this is the place, where we load the linux kernel and dtb and where fatload fails for me. At least on the Lake 1. In the attachment is the encrypted u-boot-2012.bin, which should not be very useful. If I inspect the Android image for the Zidoo X9S, I can see, that u-boot-2012 is NOT encrypted, but this does not help on the Lake 1, which simply refuses to boot this puppy. I still hope, that I simply overlooked something simple here. uboot.bin
  6. Oh, I just realized, that I only read your very last post (and not the other 3). Do you mean the u-boot.bin file or the u-boot log?
  7. Yes, definitely a club member ! The most interesting part for me is, that you can use „fatload“, which never worked for me on any storage device. Can you shortly describe, how you prepared the usb stick? Maybe I overlooked something and your solution seems to be an improvement. (The other possibility is, that the u-boot on my Lake 1 is not able to do this)
  8. I can only repeat, what jeanrhum said. IMO opinion the chance, that the current image will work is relatively good. These boxes seem to be quite similiar. The different chip versions (lake1 is A, zidoo X8 reports revision B in your post) should be handled in u-boot and the soc drivers. I think in the current state, it does not make sense to upload an image, which must be booted in a rather complicated way. So the hurdle of compiling the image yourself is a little test, if you are worth to be part of the very exclusive club of realtek-1295-linux-users (2 members, I guess) . Good luck and please report success or the lack thereof.
  9. I do not have a Rock64 V3, but out of pure curiosity: Does this https://github.com/mrfixit2001/u-boot-1/commit/cbe59e621f83b54b7b463ad69a568fbae4db04a7 do the trick?
  10. Not much to tell at the moment (and recently I am a bit time constrained): Updated the 4.9.-kernel and checked with debian buster without problems. It may be coincidence, but the slight sluggishness of the WIFI-connection was totally gone today. The update of 4.19.16 to 4.19.41 did not change anything perceptible. I still assume, that something "quite low level" is broken in the DMA-land.
  11. Wow, You have a W2?! Then it should be possible to make an Armbian build for it with minor modifications (the dts is already in the repo) and nowI know how you have figured out the SPI chip type ;). Yes, your early boot log should be very helpful. But no need to hurry, I am a bit short of time atm.
  12. Okay, my first try with the addition of SPI-Flash did not work, which may have many different reasons: 1. The wrong chip. I only had 64mb-chips at hand and ordered the version, that chwe mentioned (winbond 25q128jvsq). 2. Defective chip, bad soldering (did resolder twice)? 3. The need to add or remove a resistor somewhere? 4. A complete misconception on my side, how the things are working on this platform. I did not find any documentation regarding this topic. The early boot log on my bricked device looks like this: C1:80000000 C2 + C3hswitch frequency to 0x00000046 frequency divider is 0x00000080 switch frequency to 0x00000046 frequency divider is 0x00000004 switch to SDR 8 bit switch bus width to 0x00000008 bits success 1 hwsetting size: 00000708 C4 f 5-5 Goto FSBL: 0x10100000 <=============================================> fsbl_main: sys_secure_type = 0x0000DAAA fsbl_main: sys_boot_type = 0x00000002 fsbl_main: sys_boot_enc = 0x00000000 fsbl_main: sys_bisr_done = 0x00000000 OTP verification fail ret = 0x00000095 Return from FSBL(ret = 0x00000095) 00000000C7 C1:80000000 C2 +uu3-1 When I press one of the hidden buttons I get this: C1:80000000 C2 +uu3-1 My assumption was, that '+uu3-1' looks for SPI, but that may be completely wrong. The behaviour before and after soldering was completely identical. I could not reach the SPI-prompt with ctrl-q nor see any positive response with the KYLIN-RECOVERY-TOOL in Win 10. I wait for the new chips.
  13. Thank you, I already ordered some chips and will check, if I got your recommended sort. Then comes the soldering part ...
  14. 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?
  15. It seems, like I hit a wall with my attempts (to port 4.9. to 4.19.). This is simply unknown territory for me and "too low level". As far as I understand, there is a problem with the dma-code and I have no clue how to fix this. Between 4.9 and 4.19 there were some API-changes and you can find realtek-specific code fragments in generic kernel parts, which is the only "documentation" for this topic for me. Here is the current boot log: The board can boot without USB drivers, but that only masks the real problem (I think). Deactivating the AHCI-RTK-driver just leads to another type of crash and I think, this is not the source of failure. But anyway, I learned a thing or two and I do not consider the unsuccessful work of the last few weeks as wasted time. I will try to clean up some things in the 4.9.-branch (basically only the compiler warnings) and return to the plan to do a eMMc-only boot. And I still have to explain, how I bricked my first box ...