On Wed, Mar 21, 2018 at 10:19 AM, Nuno Dias <nuno.dias@xxxxxxxxx> wrote: > Hi, > > The best option for OrangePi PC is to use Fedora 28 (yes I know is not > released yet, but images are available to test) and because has a > more recent kernel, HDMI works out of the box (no acceleration > thought), right now in my tests everything seams to work fine. That's some what surprising. The support hasn't landed upstream yet in 4.16, although the clocks support has so maybe that's enough to light up the output even though I believe it would more by luck than design. > On Wed, 2018-03-21 at 00:17 +0000, Peter Robinson wrote: >> Hi Fabian, >> >> > As Peter requested :-) >> >> Thanks for this, response and details in line. >> >> > During the last three weeks I attended two conferences. In India we >> > wanted to have actual hardware to allow the participants of the >> > training >> > to do their exercises and the attendees of the crypto currencies >> > village >> > see how it works. >> >> Interesting, is there details about the crypto currencies side of >> this >> somewhere? >> >> > I'm going to split it. Covering the Orange Pi devices here and the >> > Raspberry Pi and the UDOO Neo in another message. >> > >> > I decided to go with three Orange Pi Zero. They are easy to carry >> > around, have a physical NIC, are cheap and with a big powerbank we >> > were >> > able to survive the power outages with are happening from time to >> > time >> > there. >> > >> > Of course, we wanted to run Fedora but I ended up using Armbian. I >> > was >> > using fedora-arm-image-installer to create the cards. >> > >> > # fedora-arm-image-installer \ >> > --image=Fedora-Server-armhfp-27-1.6-sda.raw.xz >> > --target=orangepi_zero --media=/dev/mmcblk0 --resizefs >> > >> > To get some feedback I connected a serial converter to the Orange >> > Pi >> > Zero. The output is visible but minicom doesn't allow me to log in >> > aka >> > doesn't accept any input no matter of minicom's settings. Same >> > result >> > with a different adapter. My guess is that it would work if you >> > know how >> > to do it as in a lot of cases it's the only way to get the details >> > or >> > perform the initial setup. >> >> The serial support here should just work, the AllWinner stuff has >> been >> pretty stable for ages and is basically the same across all devices. >> There have been reports of the Zero working just fine with serial >> consoles. I personally tend to use screen here because minicom's >> general attempts to init modems and the like has caused me problems >> in >> the past. "screen /dev/ttyUSB0 115200" should work, the only time >> I've >> ever had issues with RX and no TX was when then TX was pinned wrong. >> >> I would be very interested in debugging this with you if you have the >> interest. >> >> > According to the serial output the Orange Pi Zero should be >> > available >> > over the network. It doesn't show me its IP address but that's >> > fine. OK, >> > if are not using network which you have some sort of control over >> > it >> > then it would be handy if you get the IP address from the serial >> > output. >> >> Suggestions on how to implement this would be welcome, the server >> image does this already via cockpit. >> >> > In the meantime were three SD card ready with Armbian and I >> > stopped. The >> > reason is simple: Armbian is more plug-and-play than Fedora. The >> > initial >> > configuration can be done over SSH and I don't wanted to waste more >> > time >> > on getting Fedora running without any indication of success. >> >> There's an explicit reason we don't allow ssh before setting >> username/passwords, security. I've heard from another distro on a >> well >> known board which has a passwordless root login to allow config like >> this that their devices have been used in known bot nets. The general >> consenus here is that the best way to stop this is to force usernam >> creation and password setting on the console, else people tend to be >> lazy and leave it at the defaults. We have some functionality here >> with the --addkey= option of arm-image-installer which unlocks the >> root account and adds a ssh key. Suggestions on how to improve this >> experience while keeping a high level of security again would be >> welcome, or details of how armbian does it. >> >> > The next one was an Orange Pi PC. Reason to use was the HDMI output >> > which would make it possible to attach the unit to a projector. >> >> The H3 (all the H-series and A64 SoCs) don't have any level of >> upstream support for HDMI at all. In the 4.13 kernel that shipped >> with >> F-27 this would have been well over 100 non upstream (not even >> accepted upstream) patches to maintain across a number of kernel >> cycles and constantly rebase. Even when they do land upstream, some >> went into 4.16 and a lot more will be in 4.17, with luck this should >> be complete in 4.18, there won't be accelerated graphics to run with >> Workstation because the GPU is MALI and there's not yet an open >> driver >> for it. Best we'll be able to hope for in the medium future here is >> something like XFCE. >> >> > Workstation image instead of Server this time. >> > >> > # fedora-arm-image-installer \ >> > --image=Fedora-Workstation-armhfp-27-1.6-sda.raw.xz \ >> > --target=orangepi_pc --media=/dev/mmcblk0 --resizefs >> > >> > Device starts running, no graphical output. Perhaps broken...no, >> > works >> > fine with Armbian. Perhaps is the screen not playing nice with >> > Fedora. >> > Other screen, same result. >> >> There is no upstream support at all for HDMI, what kernel does >> Armbian >> use? It must be either a heavily patched upstream or a vendor BSP >> kernel. >> >> > Let's test the Orange Mini (that one is approx. the same age as the >> > Orange Pi PC). Same image, different target. After a couple of >> > seconds >> > the LED went on but not HDMI output. >> >> Same, I'm actually got on my list to look at the patch set for HDMI >> to >> give us basic text console output on 4.16 in F-28, I think to do that >> across H3/H5/A64 SoCs we're looking at around 60 patches on top of >> 4.16 across clock/gpu and other areas of the kernel. It's a lot to >> maintain, it's actually more than all our patches for ARM* combined >> ATM but should be mostly gone for 4.17. All those devices should work >> with serial console with network and USB though if that's deemed >> useful. >> >> Peter >> _______________________________________________ >> arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx > -- > Nuno Dias <Nuno.Dias@xxxxxxxxx> _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx
