• Content Count

  • Joined

  • Last visited

 Content Type 


Member Map





Everything posted by jock

  1. jock

    Wayland on ARM SBCs

    I queue for the details about panfrost + updated mesa + wayland (or X11) session. Some basic steps to get an usable setup would be wonderful
  2. FYI, just upgraded to dev kernel 5.2 and thermal trip points are back! root@xt:/home/paolo# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 16:08:41: 600MHz 1.58 20% 3% 12% 0% 4% 0% 62.9°C 0/11 16:08:46: 1608MHz 1.46 12% 2% 8% 0% 1% 0% 62.1°C 0/11
  3. About point #3, your Orange PI PC is not stuck at kernel 3.0. H3 chip is not the fastest nor the newest, but currently is one of the best supported in mainline kernel. There is an enduring work-in-progress for hardware decoding on mainline kernel which is progressing nicely. It looks like LibreElec will soon include some official H3 support. All the main peripherals are working well and 3D acceleration is available. As for desktop replacement, the problem with the H3 is the lacking of the thermal driver, so frequencies of the SoC are set in a conservative fashion in armbian. The experience may suffer from this. You may think to use a small heatsink and drive the SoC to its rated 1.4Ghz and see if it satisfactory for you. IMHO it is not powerful enough for a decent desktop replacement, but you may try and see if it suits your needs.
  4. I'm aware of the bootloader tinkering, but in the armbian download page there are the instructions to wipe the internal eMMC to enable the straight usage of armbian image (and mainline u-boot). If you don't mind to lose the embedded Android, you may try to follow those instructions. BTW: it's better to discuss about this other tv box on the other thread
  5. Sorry, I didn't understand what you mean... If you are looking for dtb files, they are located in /boot/dtb directory on the sdcard. You may try with this image for rk3288-based tv boxes. It's not exactly for the MK902II, but probably it will boot but many devices won't be available, nonetheless it could be a jump start. This is the forum page for discussion:
  6. All DTB files are pretty standard and they are decompiled/converted between binary and source form using the dtc tool. This is sufficient to convert a binary device tree (dtb) to a human readable device tree (dts): dtc -I dtb -O dts <your_dtb_file.dtb> -o <extracted_dts_file.dts> DTS files converted from DTB are not the best way to deal with them, because many human-readable constants and values are converted into hexadecimal values and references to nodes are summed up as integer values (called phandles), where in a real source device tree you get a string reference to the node which is much easier to follow. A quick test you can do is to disable the UHS mode: find in the source device tree the strings starting with "sd-uhs-" and remove them. Make a backup copy of the original DTB file and then convert back the DTS to DTB using dtc. Those strings, when present, tell the sdmmc driver to enable UHS modes that on some devices are troubling. If this quick hack does not work, then the problem requires more attention and knowledge
  7. Another quite complete benchmark, with thermal imaging too
  8. @ljones0 Well, presuming the SD cards you're owning are sane and not counterfeit, it should be that most SD cards are compatible and works ok and maybe a few may have some sort of issues, not the opposite like you're experiencing. It looks to me there is something wrong, possibly in the device tree. The first thing that comes up to my mind is an erroneous configuration of the sdcard pins or UHS mode not properly working, since you're using the Beelink X2 device tree which is not fully suited for your device. It worth mentioning the armbian documentation, and its SD card preparing tips and hints. About the X acceleration, you can get 3D acceleration, but it requires you to compile the Mali kernel module, install the userland Mali drivers and use a working xf86-video-armsoc driver. The armsoc driver packaged with armbian probably does not work with mainline kernel. Here there is some work in progress pull request for an armsoc driver for mainline kernels: PS: the out-of-the-box configuration is still viable for decent 2D performance, but first you have to disable the window manager composition in Settings -> Window Manager Tweaks menu.
  9. @ljones0 Besides, use a proper image writer (like the armbian-advertised BalenaEtcher) when do you burn images on SD card: it will take care to unmount the device, burn the image and verify the image by itself. If you want to use dd, always remember to unmount the mounted SD-card partitions first.
  10. @DRAGO4k Great work, thank you!
  11. Phoronix benchmarked pi4s. Random and incomplete numbers as usual, but performance trends are interesting
  12. The sticker on the PCB also says H3, also the XR819 is the companion WiFi chip from Allwinner... That's definitely an Allwinner chip, most probably an H3 with a minor possibility it is an H2+ (which is almost the same as H3)
  13. Is the same as this?
  14. I'm not really sure you need the two resistors circuit to make the serial adapter work. I mean, if the Arduino Uno has a TTL (which I guess it is) serial, you should be able to connect Arduino TX to Box RX and Arduino RX to Box TX and Arduino GND to Box GND to get the things done. A device tree for your device could be in the wild somewhere, your device does not sound new to me; BTW you should first understand if the device tree is packaged with the kernel and the initramfs in an "Android boot image". file utility should be able to detect if the partition is an Android image. If so, there are tools to extract the files from the archive. The extract-dtb is useful when the device tree is attached at the tail of the kernel image, but nowadays shipping the dtb this way is seldom used.
  15. I can help with great pleasure! I use the rockchip proprietary SPL to do the DDR memory initialization because the box uses LPDDR2 which u-boot is not able to initialize. U-boot configuration produces: the TPL (Third Program Loader, does some clock and memory initialization) the SPL (mainly sets the power hold GPIO pin of PMIC to keep the box turned on) the main u-boot binary The boot process starts with the Rockchip proprietary SPL, which chains to the U-boot SPL, which chains to the main u-boot binary, and then the kernel + initramfs. The u-boot TPL is not used because the rockchip proprietary SPL does the clock and memory initialization. Here you can see how the three blocks are assembled together (the board is xt-q8l-v10) in Armbian. Here there are the patches that can be applied to the stock u-boot (tested and proved to work up to v2018.11). They include xt-q8l-v10-rk3288_defconfig and all the necessary bits to let it appear as a supported device by u-boot.
  16. The "failed to set core voltage" error message should be harmless: I think either the device tree misses the proper reference to the CPU current regulator and/or u-boot is compiled without the support for it. As a result, u-boot is not able to change the voltage to the CPU and thus change its frequency from the default setting. This is common when you use an image which is compiled for a "close" device but not exactly the same. Apart from the messy serial port output, the image for Orange Pi PC seems to be booting u-boot, but then it does not go further because of wrong commands in the initialization script (the "MC" errors), which is although strange because the environment is restored from default. You may try to interrupt u-boot autoboot during countdown and use help and mmc commands to gather some info to understand if the sdcard is really the MMC0 device. BTW, the booting issue is surely a device tree problem
  17. I started working on them around 2013 and software support was already convincing as my company never thought to abandon the RPi platform for our project. The huge problems we encountered turned out to be the power adapters which really caused issues here and there (from random reboots or freezes to USB devices disappearing and not reappearing after reboots). When we switched to the official power adapters (5V 2.0A first, then 5.1V 2.5A later) these kind issues reduced near to zero. Currently the source of most headaches and issues is the nasty firmware which misbehaves when it received corrupted videos, has no load balancing for the two GPU cores, has some contention issues or suddenly reboots the device when the GPUs are taxed. I don't know how many developers are they employing for Linux and neither their position and knowledge about the ecosystem, but they are doing a good job at keeping up. They released their distro one month ago with kernel 4.19 and it looks pretty solid. I guess I misunderstood what "well engineered" he meant. I always intended as the compromise you get from the design and components choice you use to get the final result. Trying to generalize his reasoning, we should say that all the SBCs are not "well engineered" because they don't fit a specialized purpose, which sounds strange to me. RPi have had their compromises and sometimes questionable design choices which I don't like either and because of that I never had and probably never will buy a RPi. Besides that, I was trying to say they are materially solidly built, which is very important if you want to build a business around.
  18. It does not like I'm juggling around concepts at all. We all are here to discuss about Debian Linux and derivatives on ARM devices, so Android is totally outside our realm. The SoCs you cite on Libreelec have still some serious work to get things done for mainline: rockchip is still decoding videos in software, amlogic has no HDMI audio (very useful as a media center... ), allwinner at least seems in better shape and I hope will make through soon. RPi 4 is already well supported by LibreElec: they have a giant picture of the board in their homepage So do you see any point here? When you buy RPi 4 you also buy software support to get LibreElec support up-to-date, not to count mainline linux support, RT patches, etc... Buy cheap (or even expensive) tv boxes and you will hardly get any firmware upgrade. You're quite manipulative, aren't you? You say that's me juggling with concepts but you clearly say bullshit to change arguments. Out-of-the-box RPis are perfectly fine as media centers. Just to make sure you grab it, this is the current LibreElec (a famous media center software) homepage right now: I guess you are short of arguments because you are just talking about a platform you just never really used and have no experience about, but you let your prejudice give dishonest answers to honest questions of honest users. I was trying to let you understand that RPi are engineered and produced to last for a decent amount of years, and so they target a different market than tv boxes which instead are mostly made to sell cheap chinese shit. Nonetheless you can use them as media centers because they are quite suitable.
  19. Of course, but that's an apples-to-oranges comparison. The purposes of the two devices are not the same. It's obvious that if I buy a RPi to use as a tv box, the total cost will be like buying a proper tv box, but indeed an SBC is quite more flexible. You care about documentation when you want to do something serious without losing ages understanding how the hardware works. An example: how much of struggle community needed to get video decoding capabilities for chinese SoCs? How much struggle to get hardware acceleration for 2D/3D tasks? Reverse engineering is now giving back some fruits, after years, because of lack of documentation and openness. Sure they do: the amount of HATs of all kinds available for the RPi is there to confirm this. Also other SBC manufacturers implement their GPIO header using the same RPi scheme for such reason. I got a dozen or more RPi 1 Model B (those with the linear regulator) which are working perfectly well after more than 5 years of 24/7 hard loaded CPU and GPU duties (digital signage, content reproduction), so the durability issues with the RPi are fairy tales aired by people with little or no experience. Out of several hundreds RPi I regularly monitor, just 4 of them came back because they broke: 2 RPi1 model B came back because someone broke the SDcard connector, other 2 RPi2 Model B Rev1.2 (these were made in P.R.C.) had issues with the USB ports. RPi limits and problems are elsewhere than overheating (most SBCs and tv boxes have some kind of "overheating issues") and durability. The purpose of the RPi is being an SBC, with all the capabilities it has. You can use it to code, to teach and learn, for automation tasks, you can even run a business around it as many already did or just use as a media center.
  20. Probably they have such a large userbase of people asking for anything that their standard attitude is to avoid pesky threads and questions at all. Some of the most present engineers get quite nervous often, expecially when there are some critics against the firmware. They get collaborative when you show that you have serious and concrete proposals, otherwise you're lucky if you get a useless response which tells you things you already know. The new device is pretty interesting overall: lot of horsepower, real gigabit, 2x USB3 and 2x USB2 ports, 2x HDMI and the usual set of GPIOs. It would be the dream SBC for 35$ if they have put away their shitty closed source firmware which is also causing tons and tons of headaches. It looks like they are afraid of losing the control over the product they are making: you're free to do anything you want, but they keep the reins of the project in their hand.
  21. Ignoring support and documentation from the board manifacturer, GPIO pins and peripheral buses access, expandability, warranty, construction and international safety certifications... Looking just at the basic horsepower, tell us what tv box can you buy that provides 4 out-of-order A72 cores for 35$?
  22. @martinayotte I dealt with u-boot long time ago with rk3288 and I confirm it is a real PITA. I remember I had the same serial port error. Be sure to have the "chosen" node in root DTS: / { model = "Tinker-RK3288"; compatible = "rockchip,rk3288-tinker", "rockchip,rk3288"; chosen { stdout-path = &uart2; }; }; Also be sure to have the serial node enabled and with u-boot,dm-pre-reloc (or u-boot,dm-spl/u-boot,dm-tpl) tag: &uart2 { status="okay"; u-boot,dm-pre-reloc; }; Then I strongly suggest you to enable the DEBUG logging level that will produce much more verbose. I found it is essential trying to bring up u-boot. I had to manually edit the source code to enable it in some header file because I could not find any documentation about on the internet. Anyway you may take a look in doc/README.log which may suggest the proper way to do it. Beware that it will make the executables much bigger and that could be a problem if there are some size limits.
  23. They are still "kinda open": the BLOB firmware is still there, and the GPU is still in control of everything
  24. With the log you provided it's not easy to understand why your u-boot instance is not booting your kernel. Maybe you can compile u-boot turning on the debug flag, so it will be much more verbose and could be much more helpful.