Staars

Members
  • Content Count

    38
  • Joined

  • Last visited


Reputation Activity

  1. 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.
  2. 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!
  3. 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..
  4. 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. 
  5. 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. 
  6. 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. 
  7. 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.
  8. 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.
  9. 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.159.
    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)
     
  10. Like
    Staars reacted to Igor in [RFC WIP] 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!
  11. 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
  12. 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.
     
  13. Like
    Staars got a reaction from loly in Armbian for tv box Z28   
    Regarding the Gb-Lan-problems I recognized a declining speed, which occurred quite frequently after some time. And because there were some similar reports for the Rock64 on other sites, I assumed it was a general problem of the RK3328.
    But this might be wrong, because another aspect is, that the LAN-Port on this box is as strong as the grip of the hand of Mr. Burns  . This thing is the most sloppiest Port I've ever seen. You don't feel a click, when you plug the cable in. In the end it is possible, that I only face a mechanical problem here.
     
    Beside that, I think it is a nice little box and if the onboard devices are useable for your needs, it is relatively cheap.
  14. Like
    Staars got a reaction from loly in Armbian for tv box Z28   
    BT should work now on the z28pro.
    Everything is in the repo now and you can make a test build.
  15. Like
    Staars got a reaction from segv in Armbian for tv box Z28   
    Hi,
     
    some progress.
    After installing the latest ayufan-build (0.6.22 xenial) I could update via Wifi-Dongle to kernel 4.15 (from ayufan) and now I have working ethernet. Beside that my box "feels" more stable, at least in the last 10 minutes. But I did not do anything to really stress the system.
    I have a Z28Pro (2/16, V11).