All Activity

This stream auto-updates     

  1. Past hour
  2. @amirul - can you please try to set the two entries with status = "okay" in the dmc-opp-table section to status = "disabled" in t9-fast and check if this runs more reliable? the opp-table entry now uses the voltage, which worked for you, so that should not be the problem. best wishes - hexdump
  3. would this be similar to the waveshare model? Hmmm, kernel config and DT overlay I assume? I've not tried this. If you have the experience, review the kernel config in our github, and see if you can craft a device tree overlay for it. I have ILI9341 and XPT2046 (same interface) screens lying about for other projects, I may be able to give it a try as well. Were you planning on using the IRQ as well?
  4. rk3328-t9 works for me. rk3328-t9-fast gets random lock-ups
  5. Today
  6. @balbes150 One more question, how does it work to use a new version of u-boot on the disk? Is there a step in the boot process of the u-boot in the NAND, to check and run another u-boot on the disk?
  7. @barish, I was recently trying to debug a similar thing. Do you have "verbosity=1" in /boot/armbianEnv.txt? If so, you're telling the kernel not to log. I set mine to 7 based on a very poor understanding of things I read, and it gives me more log. If you already knew this, then maybe my message will help someone else sometime.
  8. I'm perhaps a little late in contributing to this thread, but after a power outage caused a reboot of mine, I was getting nothing in kernel log just after systemd started in kernel .40. I tried reverting kernel packages, and had failures with linux-image-next-mvebu64_5.83.190502_arm64.deb and linux-image-next-mvebu64_5.84.190508_arm64.deb, but success with .34 (that is, armbian 78.190409) No panic message, just a stop of logging to serial. This weekend, I will try the latest next again and capture the log, maybe someone might find it useful.
  9. I have one from my defunct RockProg64, but it is not been recognise properly from Odroid-N2, so both seems to be incompatible ...
  10. Nope ! It is eMMC part of the parcel shipped by Lisa's HardKernel DEV sample recently received. I maybe going to restore original 4.9.162 to see if such "load average > 10" exist on their image ... (But now I have doubt how I will be able to restore it)
  11. Hi all, I'm running Armbian 4.19 (both stable kernel 5.77 and nightly) on an TinkerBoard S. I'm trying to connect a 3.2inch resistive Touch Display to SPI2. The display works with ili9341 module on SPI2 CS0. I have the touch screen of it on the SPI2@1 (CS1) but no way of getting a module or overlay dts for the ADS7846 TouchScreen. I've seen, there is a generice resisitive-adc-touch module, but I can't get it running. Using the ADS7846 on armbian with AllWinner and several other boards for many years. Works great so far. Any hints, how to get it running in such a way, that it will be there with downstream updates (meaning without having a special kernel for it)? Thanks, kind regards, Olaf
  12. Yesterday
  13. This already works with 5.1 if armbian is still using my kernel patches. All that's needed is putting firmware in /lib/firmware.
  14. Just to add to this: root@rock64:/home/rock64/Desktop# glxgears libGL error: unable to load driver: libGL error: driver pointer missing libGL error: failed to load driver: rockchip but under es2_info: GL_RENDERER: Mali-4 Help?!
  15. What model eMMC is it? Is it a pine one? I've had issues with Odroid eMMC working on pine, but Pine eMMC not working on Odroid or RockPi. Always a simular behaviour of showing initial boot and then hanging. If you've got another. Try it. Mine with problems has V 1.0 written on the underside. Works with some, most not.
  16. Although I have SPI/USB combo working, I've continued investigating about the eMMC ... Now, I'm throwing the towel !!! Just for example, few days ago, I was trying to push image to eMMC using "xzcat theimage.img.zx | dd of=/dev/mmcblk0 bs=100M" and it hangs with "load average > 10" forever. Then I extracted the image, and did "dd if=theimage.img of=/dev/mmcblk0 bs=100M", it success, but the eMMC didn't boot, hanging early after mount ROOTFS. I've suspected corruptions, confirmed with "fsck", so today I tried to restore manually doing "tar cf - <source> | tar xvf", from working USB to eMMC, but again "load average > 10" forever. I did only few directory at a time, fine, the tar finished, but doing "sync", again "load average > 10" forever ... What the F*%K !!! And as cherry on the icecream : this eMMC can't be used with the eMMC/USB adaptor I've coming from RockPro64, although mechanically compatible, and looking at schematic should be also electronically compatible. So, end of the story, I will stay with SPI/USB combo like @balbes150 suggested !
  17. Didn't work for me on Nanopi Neo2 with Bionic Beaver. Any other suggestions?
  18. Not too sure what I'm doing wrong, but none of the latest builds has working network/ethernet working for me. I got version 5.44 working with this dtb.img file that I found here in the thread. I have a cloned M8N OTT TV box with s802, 2gb ram and 100mb ethernet. dtb.img
  19. here is the latest round of my dtb for t9 and h96max+ rk3328 tv boxes - changes since last version: properly enable dmc (i think this allows better memory timing) raise voltage for the 1.392ghz clock (disabled by default) to the values which worked for @amirul as well raise thermal trip points slightly to 85/95/110 degree celsius add a rk3328-t9-fast.dtb which has the 1.392ghz cpu clock and higher memory clocks enabled (the 1.512ghz cpu clock is still disabled by default as its likely not working or too unstable in most cases) the cpu performance ist about 5-10% better than my last t9 dtb for the regular t9 dtb and about 10-15% better than my last t9 dtb for the t9-fast dtb and as such the cpu performance is now about even with the mx10 box one ... i noticed that the usb2 port might be a bit unstable at times, so better use the usb3 port - maybe this is a general problem for rk3328 boards ... best wishes - hexdump rk3328-t9.dts rk3328-t9.dtb rk3328-t9-dtb.diff rk3328-t9-fast.dtb rk3328-t9-fast.dts rk3328-t9-fast-dtb.diff
  20. I got my EspressoBin-V7 yesterday and spent most of today to get it "stable" with Armbian. I haven't succeeded so far, although with your patch @ebin-dev, I got an uptime of almost 10 mins, which is an absolute record for now... I tried 1000-800 and 800-800-Mhz so far. I am running the Armbian provided Debian kernel on it (4.19.20). I tried what @Anders describes above and replace the kernel and dts file, but for me, it doesn't work: The kernel gets stuck at the very beginning [ 0.000000] bootconsole [uart0] enabled was the last message of boot process. Update: I just tried the flash-image-ddr4-1g-1cs-1200_750.bin and this broke u-boot completely. I will have to do a rescue with WtpDownload_linux tomorrow...
  21. I don't have one either, mine is v1, but yes that should be the trick ...
  22. I do not have a Rock64 V3, but out of pure curiosity: Does this do the trick?
  23. I feel for you. I hope it's recoverable. You could try rubbing with a toothbrush and some alcohol on the point where it's shorted. Sometimes it works again after the corrosion has been removed. And if a pad has been damaged you can solder a wire. I've watched many videos of Louis Rossmann with very badly water damaged MacBooks. He fixes them all. But when somebody is good at his job, then they make it look easy... I've been using SBC's a lot while traveling in my not rainproof tent. In every kind of weather. Never had issue's. I'll cross my fingers for the next trip. Cause then the NanoPi M4's going to come along.
  24. Probably, but I didn't tested it. I've only plug one showing "ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)" in "lsusb", and I've also see "btusb" module loaded ... Install "bluez" and running "hciconfig" shows : hci1: Type: Primary Bus: USB BD Address: 00:1A:7D:DA:71:13 ACL MTU: 310:10 SCO MTU: 64:8 UP RUNNING RX bytes:1220 acl:0 sco:0 events:72 errors:0 TX bytes:2788 acl:0 sco:0 commands:72 errors:0
  25. @FlashBurn @spqr Please find the updated bootloader here (u-boot is unchanged; WTMI is updated to 18.12.1) - it should solve the stability issues and it works fine on my V5_0_1 EspressoBin ( The recovery images are also updated: sata-images and uart-images. Could you please test if your EspressoBin ist stable now and if you can apply the pending cpufreq and xtal kernel patch without creating any further issues ?
  26. It was never publicly available AFAIK. However, you can download i.MX8 documentation which has small overview of this core and registers description.
  27. true, would that then "just work"? Well, I ordered one, I'll find out soon(ish)
  28. Interesting find. They seem to talk about filling up a "form" to get more informations, but I can't find that form. Do you know if the hardware decoder documentation is still available on this site ?
  1. Load more activity