jernej Posted October 6, 2016 Posted October 6, 2016 Do you have access to A64 hardware already? No, I was thinking about buying it, but then I said to myself that I should concentrate on one platform and try to squeeze the max. One very unatractive feature of A64 is U-Boot. I started to hate BSP U-Boot as soon as I integrated it first time in OpenELEC. While there is some mainline support for A64, AFAIK it is not meant to boot BSP kernel. I guess some work would be needed for that. Second issue is mali driver, but probably it is also solvable. However, I'm looking forward for H5, despite high probability of above issues. 0 Quote
tkaiser Posted October 6, 2016 Author Posted October 6, 2016 However, I'm looking forward for H5, despite high probability of above issues. Hehe, I've other issues with H5 (no PMIC --> no battery --> no UPS support). Anyway: Please get in touch with Igor, IIRC he talked to Tsvetan/Olimex about Olinu..A64 samples. One of those on your desk seems the best use case. If that's not happening I would love to send one of the fresh Pine64+ to you. BTW: I really hope that Allwinner is not too innovative and all the community work done now on A64 can be used for H5 later. Edit: small parcel with Pine64+, Wi-Fi/BT module and LCD on the way to @jernej, I'm not able to answer any LCD related questions any more 0 Quote
tkaiser Posted October 7, 2016 Author Posted October 7, 2016 Small note: Since TL Lim said he will send an LCD to me, I just had a look what seems to be necessary to support the LCD in Linux (ayufan's commits from Sep 11, 2016 here). Looks like the usual adjustments we know from Allwinner BSP since ages (this time in DT and not in fex any more) In the meantime the 'breaking news' that using an LCD together with an Allwinner device requires defining how to use it the usual way also arrived at Pine64 forum (really great news since just a few weeks ago they've been told by the 'moderator elite' to get the LCD working first 'the Mali' would be needed and it would take at least 2 weeks of hard work and other BS). I added some suggestions: https://github.com/MackPI/Pine64LinuxLCD/issues/1 1 Quote
pfeerick Posted October 8, 2016 Posted October 8, 2016 In the meantime the 'breaking news' that using an LCD together with an Allwinner device requires defining how to use it the usual way also arrived at Pine64 forum Don't you mean the news that had been previously broken by you a month or five earlier, and had been promptly ignored and ridiculed? :-O What can I say... things take a while in pine64 land? :-D You'll be unsurprised to hear that the Ethernet problem with that other user was indeed masked by the PoE adapter... so he seems to have that curse-ed GbE gremlin. 0 Quote
tkaiser Posted October 8, 2016 Author Posted October 8, 2016 Don't you mean the news that had been previously broken by you a month or five earlier, and had been promptly ignored and ridiculed? :-O What can I say... things take a while in pine64 land? :-D The problem is that the 'moderator elite' over there (a couple of them at least) created their own micro reality not taking into account that A64 is one of many tablet SoCs from the same vendor called Allwinner. Using Allwinner's BSP (board support package, an awful mix of Linux and Android sources and ugly scripts to combine everything to a smelly 'LiveSuit image' with broken partition map) with A64 is nearly the same as with A83T or A20 or A10 and of course LCD configuration is also the same (look at the timestamps here -- if anyone ever wants to use a different LCD with Pine64 there you get the idea how to calculate values). With A64 BSP Allwinner still supported defining everything in fex files (I put an example online when the first A64 BSP variant was leaked 10 months ago) but since they're using kernel 3.10 starting with A64 they alternatively allow also defining all this stuff as DT (device tree). Logic/behaviour is the same as known since ages. Why shouldn't a tablet SoC not be able to use a f*cking LCD?! It's made for no other reason! Longsleep was the first who tried to get this horrible BSP stuff working with 'generic Linux' and for obvious reasons he chose to get rid of the fex stuff right away. But LCDs connected to Pine64 can be used with BSP kernel since he published his first simpleimage approaches (and that means almost half a year ago). By defining parameters as it has been done from day one (nothing has changed here since 2013). BTW: At the same time longsleep also looked into HDMI situation and decided to develop sunxi-disp-tool for A64 to switch between different HDMI modes on the fly. Thankfully he also added a mode to configure HDMI resolution as it is done on the older sunxi SoCs (A10, A20). By adding disp.screen0_output_mode and/or disp.screen1_output_mode (most Allwinner tablet SoCs support more than 1 display) to kernel cmdline and calling sunxi-disp-tool in the boot process which reads /proc/cmdline and then sets HDMI resolution before a desktop environment would be started. What happened with this knowledge? It's gone since the way to adjust HDMI resolution is mentioned in longsleep's description for his own original Ubuntu image but missing in every other 3rd party image or the crappy ones made available through wiki.pine64.org. Supressing documentation means destroying developer's work. And this happened with every OS image available on wiki.pine64.org or pine64.pro (see also the bottom of this rant) And now people think they have to get rid off sunxi-disp-tool to be able to use an LCD instead of using the tool correctly (defining the LCD as display 0 in .dtb and optionally use HDMI as display 1 -- simply remove/adjust disp.screenX_output_mode in uEnv.txt or boot.scr and you're done). The whole 'history' of dealing with simple 'problems' is just absurd when looking over at pine64.org due to lack of documentation, clean instructions and allowing strange people to spread BS all the time while also allowing them to censor others posts (especially those mentioning that these guys are part of if not the problem). Why did they provide crappy Linux images and still do not even mention longsleep's original Ubuntu image? Why do they provide so called 'DD images' for RemixOS/Android in several sizes (all too large since they don't fit on every SD card of the specific size) instead of providing small Android/RemixOS images that expand their data partition on first boot (as the community Android 7.0 implements it now -- these guys are great!). Why do they provide different Android images for HDMI and LCD? It's just adding a TS driver and adjusting settings! And checking for the I2C connected touchscreen controller in u-boot and then use this or that .dtb afterwards like it's already done depending on DRAM size and choosing the correct .dtb for Pine64 or Pine64+ (different Ethernet config). I would love to know the answer. Anyway: If there's some progress regarding HDMI (we still have to deal with the libhdmi blob here!) we will think about A64 HDMI situation with Armbian (maybe using Simon's sunxi-disp-tool in exactly the same way -- then on H3 too where it should work with minor tweaks -- and then on all supported sunxi SoCs display resolution can be defined in a consistent way again). But at the moment Pine64+ is clearly a headless device for us (and there it can really shine if you're not unfortunate enough to got a broken board suffering from the GbE issue) 1 Quote
tkaiser Posted October 9, 2016 Author Posted October 9, 2016 I just wanted to try out installation of Firefox 32-bit on Pine64 to give Igor feedback on this commit using the following 'script': # Add longsleep's PPA and prepare installation of 32-bit software add-apt-repository ppa:longsleep/ubuntu-pine64-flavour-makers dpkg --add-architecture armhf apt-get update # Install XFCE desktop environment # For alternatives see https://github.com/Terra854/pine64-config/tree/master/ubuntu apt-get install xserver-xorg-video-fbturbo sunxi-disp-tool libvdpau-sunxi1 libump libcedrus1 xubuntu-desktop xubuntu-docs # Install HW accelerated video player apt-get install mplayer wget -O /usr/local/bin/mplayer-play.sh https://raw.githubusercontent.com/longsleep/build-pine64-image/master/simpleimage/platform-scripts/mplayer-play.sh chmod 755 /usr/local/bin/mplayer-play.sh # Fix audio issues sed -i 's/load-module module-udev-detect$/& tsched=0/g' /etc/pulse/default.pa # install browsers (32-bit FF since 64-bit version is unstable) apt-get install firefox:armhf chromium-browser # set HDMI resolution through boot.scr sed -i 's/\ mac_addr/ disp.screen0_output_mode=720p60 mac_addr/' /boot/boot.cmd mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr But unfortunately I get no display output at all. I also defined 'hdmi_cts_compatibility = <0x1>;' to try it out with a 2nd screen (DVI) and did an additional sed -i '1isetenv fdtfile pine64-plus-dvi.dtb' /boot/boot.cmd mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr but to no avail. Any ideas? Edit: 'armbianmonitor -u' output: http://sprunge.us/PObS 0 Quote
zador.blood.stained Posted October 9, 2016 Posted October 9, 2016 Any ideas? Are you talking about DVI compatibility issue, fbturbo or display in general? 0 Quote
tkaiser Posted October 9, 2016 Author Posted October 9, 2016 Are you talking about DVI compatibility issue, fbturbo or display in general? The latter. I tried 1080p and 720p and display always reported this specific mode but I get not a single bit of real graphic display. Not even kernel messages while booting. 0 Quote
zador.blood.stained Posted October 9, 2016 Posted October 9, 2016 I built an image today (Pine64 default xenial desktop) and display worked for me (default 1080p via HDMI-VGA converter). There were no boot messages at all (I guess they are on serial console), but I did get a command line prompt and desktop after that. Did you test with sunxi-disp-tool installed? Maybe it didn't work properly in your case? 0 Quote
tkaiser Posted October 10, 2016 Author Posted October 10, 2016 Did you test with sunxi-disp-tool installed? I disabled it but to no avail. Then let a desktop image build that not even booted (problem with partition map or maybe just burning process, I wasn't able to mount the partition on another Linux box too): HELLO! BOOT0 is starting! boot0 commit : 045061a8bb2580cb3fa02e301f52a015040c158f boot0 version : 4.0.0 set pll start set pll end rtc[0] value = 0x00000000 rtc[1] value = 0x00000000 rtc[2] value = 0x00000000 rtc[3] value = 0x00000000 rtc[4] value = 0x00000000 rtc[5] value = 0x00000000 DRAM driver version: V1.1 rsb_send_initseq: rsb clk 400Khz -> 3Mhz PMU: AXP81X ddr voltage = 1500 mv DRAM Type = 3 (2:DDR2,3:DDR3,6:LPDDR2,7:LPDDR3) DRAM clk = 672 MHz DRAM zq value: 003b3bbb DRAM single rank full DQ OK DRAM size = 2048 MB DRAM init ok dram size =2048 card boot number = 0, boot0 copy = 0 card no is 0 sdcard 0 line count 4 [mmc]: mmc driver ver 2015-05-08 20:06 [mmc]: sdc0 spd mode error, 2 [mmc]: Wrong media type 0x00000000 [mmc]: ***Try SD card 0*** [mmc]: HSSDR52/SDR25 4 bit [mmc]: 50000000 Hz [mmc]: 7580 MB [mmc]: ***SD/MMC 0 init OK!!!*** sdcard 0 init ok The size of uboot is 000e4000. sum=41c416da src_sum=41c416da Succeed in loading uboot from sdmmc flash. boot0: start load other image boot0: Loading BL3-1 Loading file 0 at address 0x40000000,size 0x0000a200 success boot0: Loading scp Loading file 2 at address 0x00040000,size 0x00019a00 success set arisc reset to de-assert state Ready to disable icache. ? Configuring SPC Controller NOTICE: BL3-1: v1.0(debug):e9fc343 NOTICE: BL3-1: Built : 11:07:45, Oct 10 2016 INFO: BL3-1: Initializing runtime services INFO: BL3-1: Preparing for EL3 exit to normal world INFO: BL3-1: Next image address = 0x4a000000 INFO: BL3-1: Next image spsr = 0x1d3 U-Boot 2014.07-4-pine64-g55c9c8c-dirty (Oct 10 2016 - 11:07:46) Allwinner Technology uboot commit : 55c9c8c8ac005b1c00ac948386c60c4a741ebaa9 rsb: secure monitor exist [ 0.380]pmbus: ready [ 0.382][ARISC] :arisc initialize [ 0.711][ARISC] :arisc_dvfs_cfg_vf_table: support only one vf_table [SCP] :sunxi-arisc driver begin startup 2 [SCP] :arisc_para size:1a8 [SCP] :arisc version: [v0.1.76] [SCP] :sunxi-arisc driver v1.10 is starting [ 0.838][ARISC] :sunxi-arisc driver startup succeeded [ 0.871]PMU: AXP81X [ 0.874]PMU: AXP81X found bat_vol=339, ratio=100 [ 0.880]PMU: dcdc2 1100 [ 0.883]PMU: cpux 1008 Mhz,AXI=336 Mhz PLL6=600 Mhz,AHB1=200 Mhz, APB1=100Mhz AHB2=300Mhz MBus=400Mhz device_type = 3253, onoff=1 dcdc1_vol = 3300, onoff=1 dcdc2_vol = 1100, onoff=1 dcdc6_vol = 1100, onoff=1 aldo1_vol = 2800, onoff=0 aldo2_vol = 1800, onoff=1 aldo3_vol = 3000, onoff=1 dldo1_vol = 3300, onoff=0 dldo2_vol = 3300, onoff=0 dldo3_vol = 2800, onoff=0 dldo4_vol = 3300, onoff=1 eldo1_vol = 1800, onoff=1 eldo2_vol = 1800, onoff=0 eldo3_vol = 1800, onoff=0 fldo1_vol = 1200, onoff=0 fldo2_vol = 1100, onoff=1 gpio0_vol = 3100, onoff=0 vbus not exist no battery, limit to dc run key detect no key found no uart input DRAM: 2 GiB fdt addr: 0xb6ebf0c0 Relocation Offset is: 75f11000 In: serial Out: serial Err: serial gic: sec monitor mode [ 1.694]start drv_disp_init init_clocks: finish init_clocks. enable power vcc-hdmi-33, ret=0 drv_disp_init finish boot_disp.output_disp=0 boot_disp.output_type=3 boot_disp.output_mode=10 fetch script data boot_disp.auto_hpd fail disp0 device type(4) enable attched ok, mgr0<-->device1, type=4, mode=10 [ 2.068]end workmode = 0,storage type = 1 [ 2.072]MMC: 0 [mmc]: mmc driver ver 2015-06-03 13:50:00 WARNING: Unimplemented Standard Service Call: 0x8000ff05 WARNING: Unimplemented Standard Service Call: 0x8000ff05 WARNING: Unimplemented Standard Service Call: 0x8000ff05 WARNING: Unimplemented Standard Service Call: 0x8000ff05 WARNING: Unimplemented Standard Service Call: 0x8000ff06 WARNING: Unimplemented Standard Service Call: 0x8000ff06 WARNING: Unimplemented Standard Service Call: 0x8000ff06 SUNXI SD/MMC: 0 [mmc]: start mmc_calibrate_delay_unit, don't access device... [mmc]: delay chain cal done, sample: 192(ps) [mmc]: media type 0x0 [mmc]: Wrong media type 0x0 [mmc]: ************Try SD card 0************ [mmc]: host caps: 0x27 [mmc]: MID 03 PSN 49e841fe [mmc]: PNM SL08G -- 0x53-4c-30-38-47 [mmc]: PRV 8.0 [mmc]: MDT m-6 y-2016 [mmc]: speed mode : HSSDR52/SDR25 [mmc]: clock : 50000000 Hz [mmc]: bus_width : 4 bit [mmc]: user capacity : 7580 MB [mmc]: ************SD/MMC 0 init OK!!!************ [mmc]: erase_grp_size : 0x1WrBlk*0x200=0x200 Byte [mmc]: secure_feature : 0x0 [mmc]: secure_removal_type : 0x0 [ 2.311]sunxi flash init ok [mmc]: Has init [ 2.345]---drivers/mmc/mmc.c 2733 mmc_init ** Unable to use mmc 0:1 for loading the env ** Using default environment --------fastboot partitions-------- mbr not exist base bootcmd=run mmcbootcmd bootcmd set setargs_mmc key 0 recovery key high 12, low 10 fastboot key high 6, low 4 no misc partition is found to be run cmd=run mmcbootcmd update dtb dram start update dtb dram end WARNING: Unimplemented Standard Service Call: 0x8000ff05 WARNING: Unimplemented Standard Service Call: 0x8000ff05 WARNING: Unimplemented Standard Service Call: 0x8000ff05 WARNING: Unimplemented Standard Service Call: 0x8000ff05 serial is: ffffffffffffffffffff get Pine64 model from DRAM size DRAM >512M Pine64 model: pine64-plus no battery exist sunxi_bmp_logo_display [mmc]: Has init [ 2.569]---drivers/mmc/mmc.c 2733 mmc_init ** Unrecognized filesystem type ** sunxi bmp info error : unable to open logo file [ 2.582]inter uboot shell Hit any key to stop autoboot: 0 [mmc]: Has init [ 5.698]---drivers/mmc/mmc.c 2733 mmc_init ** File not found /boot/uEnv.txt ** [mmc]: Has init [ 5.723]---drivers/mmc/mmc.c 2733 mmc_init ** Unrecognized filesystem type ** [mmc]: Has init [ 5.733]---drivers/mmc/mmc.c 2733 mmc_init ** File not found /boot/uEnv.txt ** [mmc]: Has init [ 5.759]---drivers/mmc/mmc.c 2733 mmc_init 492 bytes read in 11 ms (43 KiB/s) Booting with script ... ## Executing script at 41000000 Wrong image format for "source" command sunxi# Then back to the interesting stuff (KERNELSOURCE='https://github.com/Icenowy/linux-sunxi/KERNELBRANCH=branch:a64/test/pine64-usb-v3')just to realize that now Ethernet isn't working. Ok, too much hassles already for today! Back in the drawer I'll look into it in a couple of days again... Edit: Re-burning the desktop image was successful! After initial setup and creating a normal user account the DE started Edit 2: And as expected adding longsleep's ppa works and stuff like that also: systemctl stop nodm && sunxi-disp-tool switch -name 720p && systemctl start nodm Edit 3: And now Pine64+ feels like my RPi 2 and 3 (also running Ubuntu Mate): apt-get remove nodm apt-get install xserver-xorg-video-fbturbo libvdpau-sunxi1 libump libcedrus1 ubuntu-mate-core ubuntu-mate-desktop ubuntu-mate-lightdm-theme ubuntu-mate-wallpapers-xenial lightdm Of course Firefox performance sucks unless settings are tweaked (see also here). Edit 4: Forgot to mention: 2D acceleration needs something like this also: cat >/etc/X11/xorg.conf.d/02-fbturbo.conf <<EOF Section "Device" Identifier "Allwinner A10/A13 FBDEV" Driver "fbturbo" Option "fbdev" "/dev/fb0" Option "SwapbuffersWait" "true" EndSection EOF 0 Quote
tkaiser Posted October 10, 2016 Author Posted October 10, 2016 Small update: We started documenting board specific details. Currently only Pine64 is covered and we have not yet decided how to link this stuff from within docs.armbian.com or the download pages. Therefore I simply post the link here: https://github.com/igorpecovnik/lib.docs/blob/master/docs/board_details/pine64.md Edit: Setting up the Pine64+ as access point was pretty straightforward and given that 2.4 GHz band is nearly dead here (way too overcrowded -- +50 Wi-Fi networks) the values aren't that bad (read out from a MacBook in the next room and using default antenna): Current Network Information: Armbian Test AP: PHY Mode: 802.11n BSSID: 36:c3:d2:e5:19:a6 Channel: 13 Country Code: US Network Type: Infrastructure Security: WPA2 Personal Signal / Noise: -59 dBm / -93 dBm Transmit Rate: 39 MCS Index: 4 This is with wlan0 configured as client and managed through NetworkManager and wlan1 used for Armbian's own hostapd (Pine64's Wi-Fi module comes with 2 interfaces). I added the stuff to board documentation above. 0 Quote
tkaiser Posted October 11, 2016 Author Posted October 11, 2016 Another update: the trick to install an armhf Plex Media Server package (made for Synology NAS boxes) works of course also with Armbian: wget -O - https://dev2day.de/pms/dev2day-pms.gpg.key'>https://dev2day.de/pms/dev2day-pms.gpg.key | apt-key add - echo "deb [arch=armhf] https://dev2day.de/pms/ jessie main" >/etc/apt/sources.list.d/pms.list dpkg --add-architecture armhf apt-get update apt-get install binutils:armhf apt-get install --no-install-recommends plexmediaserver-installer Plex Media Server is then available at http://Pine64-IP-Address:32400/web/ and can be configured (especially creating 'optimized versions' since Pine64 is too slow to transcode most video formats on the fly). BTW: Installation will provide an informative message: N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://dev2day.de/pms jessie InRelease' doesn't support architecture 'arm64' But this is not an error message and can simply be ignored. The goal is to install the armhf version since no arm64 flavour is available. Edit: Updated pms.list contents based on Zador's suggestion. 0 Quote
zador.blood.stained Posted October 11, 2016 Posted October 11, 2016 BTW: Installation will provide an informative message: N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://dev2day.de/pms jessie InRelease' doesn't support architecture 'arm64' But this is not an error message and can simply be ignored. The goal is to install the armhf version since no arm64 flavour is available. There is a syntax for sources.list to tell which architectures to use for the repository: deb [arch=armhf] https://dev2day.de/pms/ jessie main 2 Quote
tkaiser Posted October 11, 2016 Author Posted October 11, 2016 There is a syntax for sources.list to tell which architectures to use for the repository: deb [arch=armhf] https://dev2day.de/pms/ jessie main Thanks! Did a purge, re-tried it and now it works flawlessly! 1 Quote
zador.blood.stained Posted October 11, 2016 Posted October 11, 2016 Now setting display resolution in uEnv.txt is supported for Pine64 default kernel: root@pine64:~# cat /boot/uEnv.txt ethaddr=ca:17:10:f7:2b:29 disp_mode=720p60 Available modes are listed in boot script. Al least 720p60 works for me in addition to default 1080p60 2 Quote
zador.blood.stained Posted October 11, 2016 Posted October 11, 2016 I also added DVI compatibility option (disp_dvi_compat=on), untested. 2 Quote
tkaiser Posted October 11, 2016 Author Posted October 11, 2016 I also added DVI compatibility option (disp_dvi_compat=on), untested. Tested (works!), documentation adapted and your defaults change fixed Thanks a lot! Now we have a device we officially regard headless with best out-of-the-box support regarding connected displays (ah, not true: LCD support and auto-detection is fortunately missing ) 0 Quote
tkaiser Posted October 16, 2016 Author Posted October 16, 2016 Meanwhile in Pine64 land: http://forum.pine64.org/showthread.php?tid=1166&pid=21382#pid21382 HW accelerated video decoding is available since this commit (2D acceleration works also since half a year) but one moderator still denies that 'HW acceleration' would be available. If you're a Pine64 user and rely on the forum over there you're still simply lost (but maybe the Mali hype just caused serious brain-damage?) BTW: first question was about HW accelerated video encoding. @lex, one of our great community members, provides this here: http://forum.armbian.com/index.php/topic/1855-ffmpeg-with-cedrus-h264-hw-encoder-a64-cmos-camera/ 1 Quote
vintagewaffle Posted October 28, 2016 Posted October 28, 2016 Hey guys, I have a question in regards to the pine64 build. I have created some patches to modify the dts (in sources/u-boot-pine64/master/blobs) to include the changes for the LCD and touch panel. And the u-boot job goes sucessfully and build correct dtbs, but when the actual image is generated, it still ends up having the default dtb's without my changes. What am I missing? 1 Quote
martinayotte Posted October 29, 2016 Posted October 29, 2016 BTW, it seems that the GMAC issue on PineA64 has been narrowed and that a fix has been provided : http://forum.pine64.org/showthread.php?tid=293&pid=21791#pid21791 https://github.com/longsleep/linux-pine64/compare/pine64-hacks-1.2-gmactxonly 0 Quote
@lex Posted October 29, 2016 Posted October 29, 2016 BTW, it seems that the GMAC issue on PineA64 has been narrowed and that a fix has been provided : http://forum.pine64.org/showthread.php?tid=293&pid=21791#pid21791 https://github.com/longsleep/linux-pine64/compare/pine64-hacks-1.2-gmactxonly I have M64 which has similar Gbe issue as Pine64 if not the exact same issue, unfortunately this possible fix did not work on M64. 0 Quote
martinayotte Posted October 29, 2016 Posted October 29, 2016 I have M64 which has similar Gbe issue as Pine64 if not the exact same issue, unfortunately this possible fix did not work on M64. Oh ! this is bad news ! So, maybe it won't work for Pine64 too ... 0 Quote
pfeerick Posted October 30, 2016 Posted October 30, 2016 Oh ! this is bad news ! So, maybe it won't work for Pine64 too ... I think from an update that TL gave a few days ago about progress on identifying the issue that this fixes some of the cases, may not fix all. There may be an issue of either poor soldering or faulty PHY chips in the mix as well - but it seems like they are starting to identify all the different factors that trigger those similar symptoms. I know that for at least one person fiddling with the TX and RX registers in the PHY had no effect for them... so this fix won't help them. I may be wrong, but I think that the Android 5.1.1 just got a similar fix, and at least one report indicated that GbE was now working (where it hadn't been before), but the download speeds were ... poor ... so they'd gone to the previous build (and probably a Fast Eth hack). 0 Quote
@lex Posted October 30, 2016 Posted October 30, 2016 In my case, Fast Ethernet works as usual and a very basic analysis on GbE issue suggest RX does not work most of the times. And i can't say it is a faulty chip or poor soldering even looking at it. 1 Quote
tkaiser Posted November 1, 2016 Author Posted November 1, 2016 I have created some patches to modify the dts (in sources/u-boot-pine64/master/blobs) to include the changes for the LCD and touch panel. Please be aware that we started to discuss the stuff here. Please join the party and simply refer to the necessary changes left, it should then be easy to add a switch to /boot/armbianEnv.txt to switch on LCD/TS when needed. 0 Quote
tkaiser Posted November 1, 2016 Author Posted November 1, 2016 https://github.com/longsleep/linux-pine64/compare/pine64-hacks-1.2-gmactxonly By comparing with TL Lim's statement here I start to wonder how 'phydev, 0x28, 0xd591' and 'phydev, 0x1c, 0xd591' match (only a hex --> dec conversion glitch -- 0x1c == 28 -- or wrong address)? 0 Quote
UnixOutlaw Posted November 8, 2016 Posted November 8, 2016 Awesome - I spent the whole morning reading this thread (and it killed my morning - which is a good thing!). I learned more reading this whole 4 page thread - than in five months hanging around the Pine64 forum - I call that "moderator" a couple of nasty names - Pompous Princess - or Merkin777... Can't believe the amount of bullshit information that "A" hole has steered me wrong with! Thanks for all the insiteful info from contributors on this forum and this thread! 3 Quote
pfeerick Posted November 11, 2016 Posted November 11, 2016 By comparing with TL Lim's statement here I start to wonder how 'phydev, 0x28, 0xd591' and 'phydev, 0x1c, 0xd591' match (only a hex --> dec conversion glitch -- 0x1c == 28 -- or wrong address)? I think it was a conversion glitch - it was supposed to be 0x1C (dec 28). 0 Quote
tkaiser Posted November 11, 2016 Author Posted November 11, 2016 I think it was a conversion glitch - it was supposed to be 0x1C (dec 28). Whatever, it's still a hardware issue that affects a relevant number of boards and Pine Inc's information policy (same with their 'who is allowed to play censor/moderator and fool users in a forum' policy) is a desaster. Such a madness over there, people still struggling with problems known/fixed since decades, still people complaining about Android being broken while it's just that no one informs them that only a few SD cards out there will work correctly with Android (which is the reason every normal Android device out there is shipped with NAND or eMMC -- random IO matters and most SD cards fail here horribly!) and so on. I get a headache the moment I open forum.pine64.org. On a related note: dev samples for the first H5 device around reached linux-sunxi devs yesterday and the day before. This is Orange Pi PC 2 already booting with mainline u-boot and kernel: https://gist.github.com/apritzel/c128b29c601d180d32d68ee4c9ed8f47 Kudos to linux-sunxi devs! 0 Quote
zador.blood.stained Posted November 11, 2016 Posted November 11, 2016 I enabled building accelerated video decoding related stuff for arm64 sunxi configuration (which currently includes only Pine64). Works for me, so we may provide beta desktop images (but we need to provide related packages first). 3 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.