martinayotte Posted April 21, 2017 Posted April 21, 2017 Don't expect such feature like LCD interface to be in working state. A week ago, none of the contributors had any OPiWin to work with. The current build is booting, eth0 is working, but no WiFi yet.
mariuszb Posted April 21, 2017 Posted April 21, 2017 I guess it's not now, but there is a prospect. I think I buy myself such, so far I used OPi PC only.
renaudrenaud Posted May 2, 2017 Posted May 2, 2017 I've got one sample. Is there anything I can do (with my little knowledge) to help about this card?
martinayotte Posted May 2, 2017 Posted May 2, 2017 You can build your own image, but be aware that WiFi isn't working yet ...
constantius Posted May 7, 2017 Posted May 7, 2017 1. in armbian for orange pi win there is no audio in firefox. When i installed qupzilla and gstreamer and phonon library then audio is enable in qupzilla. 2. In armbians for 64 bit procesors H5/A64 different board very often thunderbird does not work ( segmentation fault ) ( core dump ) 3. for kaiser info.; tinkerboard very often hung on in unsespecting way. i cannot say why or where or why is it hunging on. Xfce4 hungs on when i do nothing...... best regards
Igor Posted May 7, 2017 Author Posted May 7, 2017 1. [development kernel] AFAIK there are no audio drivers for this chip in this kernel. You need to write / port them 2. [development kernel] Known (not our) bug for Firefox and I assume Thunderbird has the same problem - 64bit version is crashing, while 32bit works. 3. Tinkerboard has bad power design ... software can't fix that. It's new board and we need some time to find out if there is some other problem than the most obvious one.
constantius Posted May 11, 2017 Posted May 11, 2017 each experimental img image for orangepi win has not booted since 9 of may... I know it is experimental.... but i will be very nice to boot from image.... :-)))
zador.blood.stained Posted May 11, 2017 Posted May 11, 2017 18 minutes ago, constantius said: each experimental img image for orangepi win has not booted since 9 of may... I know it is experimental.... but i will be very nice to boot from image.... :-))) In these cases getting a serial console log is usually nice
Mitch Posted May 12, 2017 Posted May 12, 2017 I have not been seeing any booting issues with the experimental images including the most recent i tried Armbian_5.27.170511_Orangepiwin_Ubuntu_xenial_dev_4.11.0_desktop.img 1
constantius Posted May 12, 2017 Posted May 12, 2017 imge stops boot "kernel starting". Then is only black screen
martinayotte Posted May 12, 2017 Posted May 12, 2017 Don't expect HDMI or Analog Video to work yet ... Too early in Mainline development ! Do you have an Debug Serial USB-TTL attached ? It should reach login prompt. For networking, only the Wired is working, no WiFi yet ...
hoodafukisalice Posted May 19, 2017 Posted May 19, 2017 On 13/5/2017 at 0:08 AM, martinayotte said: Don't expect HDMI or Analog Video to work yet ... Too early in Mainline development ! Do you have an Debug Serial USB-TTL attached ? It should reach login prompt. For networking, only the Wired is working, no WiFi yet ... Dang! No wonder I didn't get past the blank screen after the "Starting kernel" message (over HDMI). The OPI Ubuntu image works, with a bug in HDMI (out) to DVI-D (monitor input) though: messed up the colours. I can take a look at the what folks at OPI did. Am neither a graphics expert, nor do I have a USB-TTL cable though. So I'll go slow about it. I already checked out https://docs.armbian.com/Developer-Guide_Build-Preparation/. Is there someone on this forum who can help me if I get stuck somewhere? Newbie alert; this is my first Pi board and am new to the forum as well.
Igor Posted May 20, 2017 Author Posted May 20, 2017 7 hours ago, Jay said: Is there someone on this forum who can help me if I get stuck somewhere? Build system is well supported and we do provide help if you run into problems. It's in our interest that it works fine, but first try to check documentation and if you can't resolve problems with it, search forum and if nothing useful is found, ask here. UART, double pack, for 2.27USD shipped from trusted seller.
constantius Posted May 29, 2017 Posted May 29, 2017 when do you plan a stable version of armbian for orangepi WIN?
zador.blood.stained Posted May 29, 2017 Posted May 29, 2017 11 minutes ago, radek said: when do you plan a stable version of armbian for orangepi WIN? https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix A64 column For server images at least DVFS (CPUFreq), THS and Ethernet should be supported (light green) in the kernel version lower than current mainline "stable" version at https://www.kernel.org/ Alternatively somebody needs to provide a working and tested configuration for the legacy branch based on Pine64 u-boot and kernel.
makama80 Posted May 30, 2017 Posted May 30, 2017 Don't know if I am asking something stupid but: on aliexpress the OrangePi Win Plus page (link) reports that it is eMMC compatible. I've googled my *ss off, but I can't find if it is possible to mount / install emmc memory myself... Anybody familiar with this?
zador.blood.stained Posted May 30, 2017 Posted May 30, 2017 9 minutes ago, makama80 said: I've googled my *ss off, but I can't find if it is possible to mount / install emmc memory myself... Anybody familiar with this? If you have an infrared soldering station and required consumables (soldering paste and mask) or if you know people that have access to such equipment (i.e. mobile phone and laptop repair workshop) - then it's possible. ... unless you want to do something like here on the last picture https://linux-sunxi.org/Replace_NAND_with_eMMC_howto
constantius Posted June 2, 2017 Posted June 2, 2017 I cant boot any daily issued img armbian server or armbian desktop. I thought that the fault was software which is experimental. Each daily img start booting till start kernel and then i have black screen. computer not boot. Software download from orangepi www is working ok. why i cant boot armbian ? Is it something wrong with my board????? or something wrong is with software?
Mitch Posted June 3, 2017 Posted June 3, 2017 Last time i tried the experimental image it booted fine however the HDMI did not work. I was able to SSH into the board just fine.
TheRND Posted June 4, 2017 Posted June 4, 2017 Am I understand right HDMI output is not working for OPi Win Plus yet? I got "no signal" on display right after "Starting kernel" message. Can I help to make it working? Is there some kind of a complex problem with HDMI, or just no free hands to tackle the things down? Who is moderating Armbian for OPi Win board to talk about it?
zador.blood.stained Posted June 4, 2017 Posted June 4, 2017 52 minutes ago, TheRND said: Can I help to make it working? Is there some kind of a complex problem with HDMI, or just no free hands to tackle the things down? If you can check if resulting DT has proper simplefb bindings and investigate what regulators need to be left enabled for the HDMI to work (and preferrably without asking how to do that) then you could help.
James Kingdon Posted July 13, 2017 Posted July 13, 2017 Just booted an OPi win for the first time and wanted to say thank you to everyone that has contributed to supporting it. I'm looking forward to testing it out and comparing it with an OPi prime and a geekbox. I still get a kick out of seeing a new board boot up with Armbian for the first time
fraveydank Posted August 8, 2017 Posted August 8, 2017 Just FWIW, I recently got one of these (well, the Win Plus, which mainly just has more RAM) for a project I have in mind. The main reason I chose it over an H5 model (which is better supported, AFAICT) is that it has both HDMI and MIPI-DSI outputs; my application wants both a larger HDMI display and a small touch panel. This, presumably, is one of the primary differences between the A line (meant for application processors, incl. smartphones and tablets) and the H line (meant for set top boxes, which generally don't have built in displays). Alas, I don't think there are any compatibly pinned LCD panels out there, so I'll have to work up an adaptor board some time and get a MIPI panel. The other nice thing about the A64 vs. the A31s (which I have in the frankly underwhelming-for-the-price Banana Pi M2) is that it has a Mali GPU, which at least has a chance in hell of being supported in an open distribution. The A64 seems to be the red-headed stepchild of 64-bit devices in Armbian land, but the datasheet indicates that we should be able to make both work simultaneously (the HDMI output uses a separate TCON unit, and the DE documentation indicates that dual-output functionality is intended). Sadly, the current version of Armbian doesn't seem to run the framebuffer on mine, though it does get video briefly in uboot. I'm going on holiday for two weeks starting next week, but I'm hoping to get a little hacking done on it when I get back. I already built a device tree entry for the Mali device which conforms to the newer driver requirements for the H3 on my OPi One, though I haven't finished tweaking the driver to build with 4.11 sources (lots of VM stuff has changed), but I'm hoping to see if we can get some Mali support on a mainline kernel soon because the interaction with HDMI displays is so much nicer on mainline builds.
fraveydank Posted August 8, 2017 Posted August 8, 2017 The other interesting thing that the A64 has is a smartcard reader. There doesn't seem to be an existing driver for this, but the device is quite simple and it looks like the pins are properly exposed on the GPIO port and just need to be remapped. One potential application area I'm looking into is payment terminals, so the smartcard reader would be quite handy there. Add in an SPI-based NFC frontend and you could have quite the neat system...
zador.blood.stained Posted August 8, 2017 Posted August 8, 2017 7 minutes ago, fraveydank said: The main reason I chose it over an H5 model (which is better supported, AFAICT) is that it has both HDMI and MIPI-DSI outputs; my application wants both a larger HDMI display and a small touch panel. Using 2 display outputs at the same time would is complicated and AFAIK it is not implemented yet - neither on the legacy nor on the mainline kernel. 9 minutes ago, fraveydank said: Alas, I don't think there are any compatibly pinned LCD panels out there, so I'll have to work up an adaptor board some time and get a MIPI panel. I would guess that Pine64 displays should be supported if connector pinouts are the same. 9 minutes ago, fraveydank said: The other nice thing about the A64 vs. the A31s (which I have in the frankly underwhelming-for-the-price Banana Pi M2) is that it has a Mali GPU, which at least has a chance in hell of being supported in an open distribution. For non-Android distributions it is mostly useless anyway, even if you could find a compatible 64-bit userspace library for it. So zero chances for "open", it needs a closed source blob in any case. 9 minutes ago, fraveydank said: The other interesting thing that the A64 has is a smartcard reader. Older SoCs like A20 also do have a smartcard block, but still there is no driver for it.
fraveydank Posted August 8, 2017 Posted August 8, 2017 4 minutes ago, zador.blood.stained said: Using 2 display outputs at the same time would is complicated and AFAIK it is not implemented yet - neither on the legacy nor on the mainline kernel. Well, yes, that is assumed. Right now, I don't think either the HDMI or MIPI displays are supported on the true mainline kernel without patches (the matrix says the A64's HDMI is a WIP, while the LCD is a "no". I'm not under any impression that it'll happen overnight. :-) 4 minutes ago, zador.blood.stained said: I would guess that Pine64 displays should be supported if connector pinouts are the same. In general, Xunlong's pinouts aren't the same as anyone's, at least if the CSI headers are any indication. I should probably check before I put the work/$$ into it, though. 4 minutes ago, zador.blood.stained said: For non-Android distributions it is mostly useless anyway, even if you could find a compatible 64-bit userspace library for it. So zero chances for "open", it needs a closed source blob in any case. Define "mostly useless"... I'm looking to write an EGL application that runs on the framebuffers, which doesn't require any of the massive overhead that Android involves. "Open" is a bit of a misnomer, indeed, but we have Mali support on non-mainline 32-bit builds using the binary blobs. I haven't done the research necessary for the 64-bit ones. 4 minutes ago, zador.blood.stained said: Older SoCs like A20 also do have a smartcard block, but still there is no driver for it. Indeed, I'd have to write it. That's not a huge problem, I'm quite used to kernel code, though I haven't written a new Linux module since the 2.4 days... lots of catching up to do.
fraveydank Posted August 8, 2017 Posted August 8, 2017 4 minutes ago, fraveydank said: In general, Xunlong's pinouts aren't the same as anyone's, at least if the CSI headers are any indication. I should probably check before I put the work/$$ into it, though. Verified; it's not even the same connector. The PINEA64 connector seems to be pretty closely related to the 7" LCD they have a module for (it's not exact, but presumably there's an adaptor board in the middle), while the Xunlong one doesn't seem to have anything easily available (though if anyone knows of one, I'd be interested). Easy enough to adapt, though.
zador.blood.stained Posted August 8, 2017 Posted August 8, 2017 1 minute ago, fraveydank said: Well, yes, that is assumed. Right now, I don't think either the HDMI or MIPI displays are supported on the true mainline kernel without patches (the matrix says the A64's HDMI is a WIP, while the LCD is a "no". While it's far from "supported", HDMI output should work via simplefb enabled by u-boot, but I don't think that anybody tried to enable the DSI output in mainline (though Icenowy was able to use the RGB output on the Pinebook which should use pretty much the same display pipeline if I understand it correctly). 4 minutes ago, fraveydank said: Define "mostly useless"... I'm looking to write an EGL application that runs on the framebuffers, which doesn't require any of the massive overhead that Android involves. By "mostly useless" I mean mostly useless for an average user that wants to use a desktop environment (X11 or Wayland). Without a matching binary userspace driver (and by "matching" I mean architecture (armhf vs arm64), API (Wayland, X11, framebuffer) and hardware (Mali400 and matching revision)) you won't be able to use it, and it's not like ARM or Allwinner are willing to provide a full set of these blobs. 11 minutes ago, fraveydank said: "Open" is a bit of a misnomer, indeed, but we have Mali support on non-mainline 32-bit builds using the binary blobs. I haven't done the research necessary for the 64-bit ones. Well, if you call r3p0 UMP version "support", then maybe. AFAIK r5p0 was tested on mainline H3 and H5 too, but again it is limited by the availability of a matching userspace binary and a proper DRM display driver.
fraveydank Posted August 8, 2017 Posted August 8, 2017 My bread and butter day job includes embedded Linux engineering; I may be needing to navigate these avenues soon enough. In any case, I do get full console video from uboot, but it drops to no signal after kicking off the kernel. I haven't investigated much, but the device tree shows the HDMI disabled (and dmesg indicates that its power domain is powered off). I'll see what I can dig up relative to the Pine64 build.
Recommended Posts