Staars

Members
  • Content Count

    70
  • Joined

  • Last visited


Reputation Activity

  1. Like
    Staars got a reaction from chwe in Proof of concept - Realtek 1295   
    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!
  2. Like
    Staars got a reaction from chwe in Proof of concept - Realtek 1295   
    Now everything is totally clear :
     

  3. Like
    Staars reacted to jeanrhum in Proof of concept - Realtek 1295   
    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.
  4. Like
    Staars reacted to danman in Proof of concept - Realtek 1295   
    @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...
  5. Like
    Staars reacted to ShaRose in Proof of concept - Realtek 1295   
    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.
  6. Like
    Staars reacted to danman in Proof of concept - Realtek 1295   
    Wow! Really? This might help you with searching then
    I'll try Ctrl-Q as soon as I'm home.

  7. Like
    Staars reacted to martinayotte in Rock64 v3 and SD-Card problems   
    I don't have one either, mine is v1, but yes that should be the trick ...
  8. Like
    Staars reacted to guidol in [Info] Pihole-lighttpd issue with debian buster   
    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 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 404 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
  9. Like
    Staars reacted to chwe in Proof of concept - Realtek 1295   
    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..
  10. Like
    Staars got a reaction from chwe in Proof of concept - Realtek 1295   
    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?
  11. Like
    Staars got a reaction from chwe in Proof of concept - Realtek 1295   
    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 
     
  12. Like
    Staars got a reaction from AndrewDB in Proof of concept - Realtek 1295   
    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:
     
  13. Like
    Staars reacted to martinayotte in Switching Rockchip64-DEV to 5.0.y ...   
    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 ...
  14. Like
    Staars reacted to jeanrhum in Proof of concept - Realtek 1295   
    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.
  15. Like
    Staars reacted to jeanrhum in Proof of concept - Realtek 1295   
    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!
  16. Like
    Staars reacted to chwe in Daily (tech related) news diet   
    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..
  17. Like
    Staars got a reaction from guidol in Proof of concept - Realtek 1295   
    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. 
  18. Like
    Staars got a reaction from jock in Proof of concept - Realtek 1295   
    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. 
  19. Like
    Staars got a reaction from chwe in Proof of concept - Realtek 1295   
    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. 
  20. Like
    Staars got a reaction from chwe in Proof of concept - Realtek 1295   
    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.
  21. Like
    Staars got a reaction from guidol in Proof of concept - Realtek 1295   
    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.
  22. Like
    Staars got a reaction from jock in Proof of concept - Realtek 1295   
    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:
     
  23. Like
    Staars reacted to Igor in [RFC 001] Changes for boards and features implementing   
    We all know there are several shortcomings which causes mess in the config files and prevent simple implementing of more complex scripting. In order to make build system future proof and to cleanup the exception mess, which is virtually everywhere, I decided to start working on a part of the build system. Now the concept works and it is not that far to be mad if idea is bad
     
    packages/extras was moved into this, then board support package and (for now) Cubietruck and Tinkerboard hacks from config/sources/ All others have to be implement into packages and their scripts. It's one time job and it will be much easier in the future, with new boards or functions.
     
    New board support packages are now broken into unlimited number of packages. Currently there are three main groups and already present logical packages. Most of present are tested and are fully operational. Mostly its copy/past with bug fixed here and there. Perhaps some bugs were made in this process, but in essence system works - for those two boards. Upgrade path is not determined yet - I only focused on packaging and installing. All those packages can be installed from freshly build ones or from the repository. Each package can have their own number and package is rebuild only if number upstream doesn't exists.
     
    This RFC includes preliminary merge of @balbes150 TV boxes fork so it's ATM a bit messy. Cubietruck and Tinkerboard images were tested (Bluetooth briefly, audio need to check again), the rest is not prepared and it requires some manual work. I hope someone else, not just the usual suspects, will help doing this.
     
    I will slowly move forward and keep it mergeable/synced with upstream.
     
    This approach is more or less only a working proposal for changes. IMHO it's better than what we have now but not perfect.

    (WIP) Readme with some more details https://github.com/armbian/build/tree/tvboxes/config/packages
     
    You can try this by adding LIB_TAG="tvboxes"
     
    Edit:
     
    Skeleton is done, images can be build from this branch ... Most but not all of our current families and board specialities has been moved under this packaging system. I tested Cubietruck, RockPro, Tinkerboard. At least they works fine - checked for Bluetooth (TB/CB3) and video acceleration on Cubietruck.

    TBD: adjust changes in armbian-config regarding desktop (nodm is gone, lightdm only with possible autologin) and kernel switching.

    @JMCC Welcome to try adding perhaps Tinkerboard MM script as a new multimedia/something package. What shall be its name? If some 3rd party packages needs to be placed to the repository, put them here: https://github.com/armbian/upload
     
    @gprovost mvebu family is not there yet, but if you got time it should be clear what to do? If not, I wrote lousy docs or scripting is more complicated as before  
     
    @selfbg Added Olimex SOM204. Check when possible.

    @zador.blood.stained Are packages relations alright? I hope they are future proof. Upgrade is planned from armbian-config and is actually optional. Older packages, except boot and kernel are no more.
     
    @tkaiser cpufreq is not overwriting anymore, serial consoles are board property SERIALCON="ttyS0,ttyGS0", board config is reloaded right before packages building. Shell we move hardware-optimisations.sh to per board script? Changes should not affect OMV.
     
    @Staars Z28Pro merged but untested
     
    @lanefu @5kft @TonyMac32 .... check.

    @balbes150 have a lot of work to move his scripting into the build engine. Helping him, testing, fixing, ... @all Check and join if you can.
     
    beta.armbian.com can be switched to this new world order ASAP.

    Expected merge due: 2/2019 ?

    Happy 19!

    Edit by lanefu 7/2019:

    A project #1 has been created on github.   There are several tasks, which will be tracked as issues on the board.
  24. Like
    Staars reacted to Igor in what difference between armium and debian Linux   
    I am not sure if this is what you want to know, but:

    - Debian.org or Ubuntu.com officially does not support any of those boards/boxes,
    - Armbian userspace has many small but vital performance or security adjustments,
    - Armbian fancy some kernel development and a lot of its maintaining. Debian relies on upstream sources for ARM hardware which can be years behind and/or lack of many functions,
    - Armbian userspace is lean, clean but 100% Debian (or Ubuntu) compatible
    - many stock Debian bugs are fixed on the way, "better than original :)"
    - a build system is a central part of this whole ecosystem. You can DIY. Debian much harder.
    - dedicated support forums per boards/boxes
    - plug and play vs. complicated install scenarios on Stock Debian
    - unified development scenarios and user experience vs. mess of different setup instructions scattered all around
     
    I must have forgotten many other important points
  25. Like
    Staars reacted to mdel in Armbian for tv box Z28   
    yes i've heard about the rock64 gbe problem, don't know if it was finally solved (pcb tracks timings), but i don't know about a global rk3328 GMAC interface problem.
    So far i can't fault my z28pro Gbe, it has been running a torrent through vpn with continuous upload of 30-50Mbps and i haven't noticed any problem, nor any dubious log output..
     
    i've done a short 6 min iperf test :
     
    i also transfered approx 750GB of real data to an attached USB drive and about 80MB/s and it didn't fail.
    If it's not a physical hardware issue, and yes the ethernet pcb design on that device is quite insane ( massive gap under the transformer, although strictly following the datasheet recommendation), i must say that all my traffic is going through quality shielded cat6 cables with proper earth.
     
     
    well the z28pro 2G/16G (Gbe, Wifi AC+BT) being often available at or below 40e, i don't think you'll find a Usb3/Gbe device at a lower price.
    I'll leave the dev boards aside although i don't think they are much cheaper and you should at least add the cost of a case and power adapter.