Jump to content

ImmortanJoe

Members
  • Posts

    24
  • Joined

  • Last visited

Everything posted by ImmortanJoe

  1. The Debian Jessie desktop image on the Orange Pi website can be upgraded to Stretch. Wifi partially breaks though. It can see the access points and show signal strength, but nothing happens when trying to connect. Screen resolution seems unchangable. It seems to be a plain Debian. Ie not messed with like some Orange Pi images. So if you really desperately need the legacy kernel that could work. Otherwise, the Armbian release of Stretch is already a nicer option IMHO. xrdp server seems to have problems. Has anyone got it working properly on the Armbian nightly yet? I wanted to see if there was a noticeable performance difference between the "Legacy" Debian Stretch and Mainline Armbian Stretch through RDP. Was Wifi meant to be working on the new nightlies? It doesn't seem to be there. It doesn't bother me. edit: The uptime part of the ssh login script seems to be incorrect. It's grabbing the wrong value.
  2. Yesss... Nighties. Going to try the stretch one out today. My only devices are ARM based so I can't build from source. That was the one good thing about the Sunxi source. With some script tweaking I could build with an ARM host. Has anyone else found the 8GB eMMC to be a little touchy, especially during boot? Not sure if it's hardware or Sunxi kernel related.
  3. I don't know the usual method for rebooting the Allwinner chipsets in Linux. I know the H3 had a register for it, but could also be reset by configuring the mode of the watchdog timer to reset, setting the WDT and letting it trip. Could that work in H6?
  4. So that's what is wrong with it. Strange implementation coupled with difficulties doing some things with the Linux framework. Am I reading it correctly that the PCIe controller has either a banked interface or a potentially rolling window? Hm. Besides odd setup, DMA transactions would still function normally, right?
  5. Is it within the scope of Armbian to attempt support for the MiniPCIe port with the mainline kernel? I didn't give it much thought until I remembered hat there are MiniPCIe to SATA adapters. My bandwidth and time are too low to have been much use for the early stages sorry. Someone else had always tried the newest iteration before I'd finished downloading it.
  6. Been meaning to say this. The OPi3 seems to deafen nearby wireless devices when running the legacy kernel. It disrupts other WiFi devices, BT and my Logitech keyboard and mouse. Re Logitech dongle, if I put it on a long USB extension cable it works. My guess is that WiFi is outputting at maximum all the time, but it is just a guess.
  7. Krachlatte, I hope you don't mind. I'm putting a link to 0.09 in my post. https://github.com/krachlatte/armbian-orangepi3/releases/tag/v0.09
  8. I'm phone posting so I don't have the info in front of me. Just roughly what I did was: Download Debian Jessie Desktop for OPi3 from the OPi download section. Use the Google drive link there. Before closing Drive, find the PDF manual. The website link points to the wrong manual. IIRC the eMMC flashing script name is in the manual. I couldn't find it anywhere else beforehand. Run the script and let the magic happen. There are more steps beforehand but the magic incantation for installation is in the manual.
  9. Hm. My earlier reply didn't stick. Which logs, or parts of them would you like to see? I just started downloading it so it'll be a while.
  10. Reimaged the MicroSD again. This time it worked.
  11. I haven't reimaged the MicroSD yet. It still has the first attempt on it. My OPi3 has Debian Jessie on the eMMC. There's also a SATA HDD plugged in to one of the USB3.0 ports currently, but results were the same without it. I did go and grab the UART output for a boot with and without the Armbian SD in. Here's the early boot results. I'm a little perplexed. SD card in. Trying to boot Armbian: And with the SD card out, just booting Jessie: The Armbian MicroSD is doing something, but I' not totally sure what. Either way, it just boots into Debian Jessie.
  12. As always the question is what you want to do with it I'm typing this on a Pinebook which is fast enough for what I use it for. My Orange Pi Zero is fast enough for file and network services that I use it for. My RPi Zero is fast enough for running RISC OS. It's all down to your use case.
  13. No sorry. I'm 100% ARM based these days. Mostly Armbian and RISC OS on my devices. I'm sure my usage of dd was correct as I use it regularly. However I am painfully aware of a bug in something which otherwise silently causes a register dump to dmesg which can cause corruption issues. I wrote the image remotely nohup via ssh and didn't think to check for success beyond the nohup output file afterwards. I will see if I can try again today. I don't have much direct access right now. Don't concern yourself too much with that right now. I found that the Sunxi OrangePi Jessie Desktop image falls over into some kind of failure register dump mode after reboot. Other Orange Pi devices also seem to have reboot issues so it's hard to say yet whether it's a design failure or a software bug. Usually wit any Orange Pi device I have, I apply the 10 second power cycle rule.
  14. No. I put it on MicroSD. This has highest boot priority. It just went straight through to booting from eMMC. The contents of the MicroSD seemed to be intact. I'll have a better look at the serial output later.
  15. This image should just boot from MicroSD once written with dd, right? The OPi3 is just skipping past it to the eMMC. The contents of the partitions appear to be intact.
  16. I have an Orange Pi 3. I don't mind trying images if it'll help.
  17. That's what I thought. Shame the legacy kernel's video is so badly broken it can't display anything on most monitors. I did see libvdpau-sunxi1 in the apt repository and installed it but it doesn't seem to do anything useful. Thanks for the confirmation. I wasn't sure if my install had broken over time with all the updates or it wasn't supported.
  18. is vdpau supposed to work or exist for the PC2? I've seen conflicting reports. My Armbian doesn't seem to have any trace of it.
  19. Something broke in USB in the last couple of days. I just updated to the nightly kernel etc. and the hub no longer worked. 23.600145] usb 5-1.1: device descriptor read/64, error -110 [ 23.792099] usb 5-1.1: new full-speed USB device number 4 using ohci-platform [ 28.976623] usb 5-1.1: device descriptor read/64, error -110 [ 41.351812] usb 5-1-port1: cannot reset (err = -62) [ 41.357968] usb 5-1-port1: cannot reset (err = -62) [ 41.363228] usb 5-1: USB disconnect, device number 2 [ 41.363800] usb 5-1-port1: cannot reset (err = -62) [ 45.001488] usb 5-1: new low-speed USB device number 7 using ohci-platform [ 45.185479] usb 5-1: device descriptor read/64, error -62 [ 45.481423] usb 5-1: device descriptor read/64, error -62 [ 45.773439] usb 5-1: new low-speed USB device number 8 using ohci-platform [ 45.957500] usb 5-1: device descriptor read/64, error -62 [ 46.253453] usb 5-1: device descriptor read/64, error -62 [ 46.545463] usb 5-1: new low-speed USB device number 9 using ohci-platform [ 46.961541] usb 5-1: device not accepting address 9, error -62 [ 47.145514] usb 5-1: new low-speed USB device number 10 using ohci-platform [ 47.561536] usb 5-1: device not accepting address 10, error -62 [ 47.567592] usb usb5-port1: unable to enumerate USB device The mouse and keyboard worked when directly plugged in.
  20. That's interesting. It seems more stable at least so I'm not complaining. I know I said it before but the Armbian mainline kernel is advancing so well. Congratulations to the people working on it. It's a great achievement. The improvements are really showing. I wish I could help but I can't because of reasons involving what I want to do with the OPi PC. The OPi PC2 works well as a headless build server. However it really needs swap space. I've found when doing big builds using GCC it tends to blow it's RAM budget by 100 - 150MB. I don't know what it swaps out but it doesn't seem to be used, because it stays in swap after the build has finished.
  21. The PC2 has its good points. The mainline kernel is improving constantly. There are still some really weird bugs with xorg, terminal display, and something with memory management, but beyond that it's a solid performer. It seems to have less issues with USB device stability than PC mainline kernel, and although I haven't empirically checked it seems to have lower power consumption than the PC. I say this because The PC or peripherals can get upset, however when I have the exact same peripherals and PSU plugged into the PC2 it's fine. I use my PC2 with Armbian mainline as an aarch64 build server for various projects. Something which my RPi3 was meant to be for when I bought it shortly after release, yet aarch64 is only just starting to appear... Sometimes I use the PC2 as a desktop but the memory use is problematic. It works well serving X apps remotely via ssh though. The official Ubuntu legacy image for PC2 is a train wreck and should be avoided. A DIY distribution of Debian based off the source is a headache. I spent ages editing the scripts to make something that would build. A couple of days later the hard drive crashed. I only just re downloaded the source for the most recent fork. So now I have to start again.
  22. Hi. I signed up because I saw this thread. Not sure of the exact model but I've got an Acer monitor with 1920x1080 native resolution. It works with h3disp at lower resolutions but not with 1080p at any refresh rate. This is via a standard passive HDMI to DVI video adaptor. Various Raspberry Pi models can drive the monitor at 1920x1080 without issue. I tried 1080i. My monitor doesn't seem to understand interlaced and became a digital headache generator. What I have noticed on both my 1600x1200 LCD and 1920x1080 LCD is that the horizontal frequency is 45kHz at the lower resolutions. The 1600x1200 monitor seemed to make a point of telling me the HSync, which does seem a bit high. I have to wonder what the rate is for 1080p Good catch on the pll_video. I'll have to see if dropping the value makes it work next chance I get. e: I just removed a pile of pll_video entries and left 297. 1080p60 works fine now and has an HSync of 68kHz. What seems to be happening is h3disp is failing to remove old pll_video entries when the mode is changed. This is causing the wrong settings to be used. Now I can play around with the Orange Pi PC in the native resolution for one of the monitors at least. I have to ask. It appears the kernel has a heap of mode settings pre-defined in some enums. Why isn't a method available for entering all the values manually via U-Boot or during runtime in Linux? Or is there and I haven't found it.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines