Jump to content

AndrewDB

Members
  • Posts

    156
  • Joined

  • Last visited

Everything posted by AndrewDB

  1. From the kernel message it seems you have an ath10k-based WiFi module which is unsupported. I think the message "... don't expect anything to work!" is rather self-explanatory, no? Simplest solution if you absolutely need wifi is a $2.70(shipped) USB wifi dongle from AliExpress, based on Realtek 8188eu chip.
  2. andrew@m9cmax4k:~/Benchmarking/Linpack/hpl-2.1/bin/Aarch64$ uptime 13:43:47 up 39 days, 14:22, 1 user, load average: 0.00, 0.01, 0.00 andrew@m9cmax4k:~/Benchmarking/Linpack/hpl-2.1/bin/Aarch64$ uname -a Linux m9cmax4k 4.19.7-aml-s9xxx #5.67 SMP PREEMPT Fri Dec 28 10:16:25 MSK 2018 aarch64 aarch64 aarch64 GNU/Linux 39 days uptime. Ubuntu 18.04 running from eMMC. I practically never have to reboot this box (used as a file server with a USB hard disk), it is that good. As always, I am grateful to Oleg and the entire Armbian development team for their amazingly good work.
  3. That was an excellent tip, thank you very much!
  4. Why can't you natively compile? Both Armbian Debian and Armbian Ubuntu are perfectly able to natively compile chromium.
  5. @ning Thank you very much, I'll add your tip to the HOWTO. @rino Nice work there rino!
  6. Hmmm, exactly the same as me. So it's unlikely that that is causing the problems we are seeing. The only possible explanation is that somehow your git clone operation when you are cloning the libretech github repository is failing (or the baylibre repository). What we can do to check this is that you restart the entire procedure but pause just before running the acs python program, and we compare your version to mine, as well as the entire contents of the fip directory. By any chance are there any errors before you get to that point? Also did you manage to check that the u-boot binary that I sent you can load the kernel ?
  7. I believe that's part of the proprietary tools from Amlogic, so we probably don't have the source. But more importantly, I have no problems running this tool but you do, in exactly the same environment (the container)? Do you have any errors at any point before that? Can you do a "uname -a" inside the container and send me the result?
  8. That is the Panfrost driver. Check these news: https://cgit.freedesktop.org/mesa/mesa/commit/?id=77fea552f69d02497fad8aa4e3a49c424c4b95c0&utm_source=anzwix Someone still has to integrate the Panfrost driver, kernels drivers and an Armbian image to make the whole thing work. Edit: more news from the Panfrost front. See: https://www.phoronix.com/scan.php?page=news_item&px=Mesa-19.1-Panfrost-Taps-DRM Panfrost driver will soon work with kernel DRM driver (I expect in time for kernel 5.1 we'll have a working 3D stack for the T820 GPU in the S912).
  9. Looks good. Did you have any errors this time around?
  10. OK, we have progress: checking the console.txt file which you attached, one can see that you get the u-boot prompt: U-Boot 2019.04-rc2-gcfba74d (Mar 03 2019 - 12:56:05 +0000) libretech-cc DRAM: 2 GiB MMC: mmc@72000: 0, mmc@74000: 1 In: serial Out: serial Err: serial [BL31]: tee size: 0 [BL31]: tee size: 0 Net: Warning: ethernet@c9410000 (eth0) using random MAC address - 22:eb:c8:5c:ae:f9 eth0: ethernet@c9410000 Hit any key to stop autoboot: 0 => If you have a Linux kernel on the same SD card as u-boot you can try booting it. First you load the kernel into RAM, optionally load a ramdisk (uInitrd file), load the Le Potato dtb and then finally boot the kernel. It should work fine. To determine what is going wrong when you try to compile u-boot following my cheat sheet, I need you to post the following file: When you are finished compiling u-boot but before you exit the container, history > compile_history.txt You can then exit the container and use the "lxc file pull ubuntu-uboot-compilation/root/u-boot_dev/u-boot/compile_history.txt" command to retrieve this compile_history.txt file, and then post this compile_history.txt file here. We'll compare it to the cheat sheet and easily find the error. Thank you very much for all your hard work, rino!
  11. Your box uses S912 with Gigabit interface. So you should try all the gxm dtb's, except q200 and q201 which are for 100Mb/s ethernet. Also you can try Armbian versions > 5.44 with meson-gxm-*.dtb's, again except q200 and q201.
  12. Yes, I was going to say that too! Specially for open-source, the Amlogic S9XXX TV boxes and SBC's are vastly superior to the RPi's. Check this FAQ: http://wiki.loverpi.com/faq:sbc:libre-aml-s805x-faq#toc6
  13. Exactly what Oleg wrote. Basically you need a Ubuntu 16.04 rootfs from Armbian 5.37 with the kernel, modules and dtbs from Armbian 5.44. Or there is another alternative: use Armbian 5.44 and create a container with Ubuntu 16.04. Installing LXD on Armbian 5.44 takes 3 minutes at most and installing a container with Ubuntu 16.04 takes another 2 minutes or so. So in 5 minutes you have your Armbian Linux TV box running both Ubuntu 18.04 and 16.04 - thanks to the excellent work of Oleg and the Armbian team.
  14. The point, in case I wasn't clear enough, is that there is zero documentation and zero support from the S9082 vendor, and the development effort to reverse engineer a linux driver for such a chip is ridiculously high. So, no, I don't think there will ever be a driver for the 4.xx/5.xx linux kernels for a totally unsupported chip such as the S9082. Again, if you need Wifi on a box that uses such a chip, use a USB WiFi dongle. Check this thread: https://forum.libreelec.tv/thread/5457-s905x-unknown-wlan-chip/
  15. Yep, those are the GPU kernel driver. But you also need the user space software. That's what the Panfrost people are working on. I believe things are coming along on that front, but nothing is ready right now for integration into an Armbian Ubuntu desktop build, as far as I know. Of course, Armbian Ubuntu desktop works fine on S912 TV boxes, but you just don't have 3D hardware acceleration at the moment, and it could take a year or more for this to happen.
  16. I don't think so. This is a proprietary WiFi chip with zero documentation and zero vendor support. The project you mention is from 2 years ago and as far as I can tell, was abandoned. I actually have three TV boxes with that WiFi chip. It's easier to buy a Realtek WiFi dongle for less than $5 for them if I want. Or if you really want to use that crappy s9082, use a 3.14.29 kernel and the binary driver, but good luck to make it work!
  17. I don't think there is yet an Armbian image for the S912 with full 3D support for the T820 GPU. If you decide to work on integrating full 3D support for Armbian on S912/T820 GPU, I suggest you check the Armbian build process for the Khadas Vim2 and start from there, integrating kernel and user-space drivers one by one.
  18. It's just because of performance expectations. SBC's still have comparatively little RAM to run full-fledged desktops, and NFS latencies would kill any large program load times. On the other hand, if you can run everything from RAM(disk), SBC's have more than enough performance, the reason we have CoreElec, OpenElec, etc... Containers run at the same speed as bare metal so if you have acceptable latencies with NFS, Docker is never a problem.
  19. Just a question: do you just want to boot the kernel from the network, and then use a local file system on SD or USB, or do you want to run Armbian from NFS? I ask this question because I don't really advise you to run Armbian (either Ubuntu or Debian flavors) from NFS, even on a Gigabit network. Now, yes, a properly built u-boot can initialize the Ethernet interface and load the Linux kernel from the network using the PXE protocol, there are a number of references on the Internet that explain how to do this, sfx2000 above has pointed to two websites and a quick search on Google should turn up a few more.
  20. Hi rino, I just went through the standard "cheat sheet" line by line, it took all of 12 minutes to produce the attached u-boot.bin.sd.bin without any errors. If you want to try it again, I believe you probably missed copy-pasting a line along the way. Or if you want to try the attached u-boot image file, just write it to any SD card using the instructions I listed above and test on your Le Potato with a USB serial adapter attached. You should be greeted with a 2019 u-boot! u-boot.bin.sd.bin Edit: I am also attaching the standard "cheat sheet", in case anybody wants to try. As mentioned above, it takes 12 minutes from start to finish to produce a mainline 2019 u-boot for the Le Potato. u-boot_build_cheat_sheet.txt
  21. Hmm... It seems FIPDIR was not set, perhaps you skipped that line? Check your bash history. In any case, you can always exit the container, delete it and restart from a clean sheet.
  22. Just a quick note: I have added a "cheat sheet" to my mainline u-boot build howto, from which the commands can be directly (but not blindly) copy-pasted into a terminal. So the u-boot build process that before took 20 minutes, now takes 15 minutes or so. Again, I would be really, really grateful if anybody could test the instructions in the howto and verify that they produce a fully functional mainline u-boot with all the latest and greatest features for your Le Potato. http://wiki.loverpi.com/faq:sbc:libre-aml-s805x-howto-compile-u-boot Edit: 1) Fixed some typos in the HOWTO and cheat sheet that would prevent the blob signing commands from executing. 2) Most importantly, I have added an experimental cheat sheet that describes the blob build process using a 64-bit (x86-64) aarch64 gcc from January 2017 instead of the presently used 32-bit (i386) compiler from November 2013... Please test first the standard build, then the experimental build processes. They both should result in a fully functional mainline u-boot, but the experimental build process opens a path to avoid using obsolete tools to build u-boot for Amlogic 64-bit SoC's, something I believe will benefit the entire community.
  23. I stand corrected, thank you talraash. And yes, sometimes you have to go and short some pins on the NAND to be able to flash it.
  24. Like for any other Android TV box, before you go writing the NAND, install TWRP and make a complete backup, or test the SD card recovery / USB cable methods first. In other words, test that you can unbrick it before you do anything that might brick it.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines