10 10
tkaiser

Armbian running on Pine64 (and other A64/H5 devices)

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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/

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
10 10