Jump to content
  • 0

Espressobin support development efforts

lanefu

Asked by lanefu,

 Share

Question

lanefu

lanefu

Posted
Posted (edited)

 

I'm sooooo close to sharing a WIP for building armbiain for espressobin , but I'm having trouble getting armbian builder to use the file name for the kernel package deb. 

 │ dpkg-deb: building package 'linux-headers-4.4.8-mvebu64' in '../linux-headers-4.4.8-mvebu64_5.27_arm64.deb'.                                                             │  
  │ dpkg-deb: building package 'linux-libc-dev' in '../linux-libc-dev_5.27_arm64.deb'.                                                                                       │  
  │ dpkg-deb: building package 'linux-image-4.4.8-mvebu64' in '../linux-image-4.4.8-mvebu64_5.27_arm64.deb'.                                                                 │  
  │ dpkg-deb: building package 'linux-image-4.4.8-mvebu64-dbg' in '../linux-image-4.4.8-mvebu64-dbg_5.27_arm64.deb'.                                                         │  
  │ dpkg-genchanges: binary-only upload (no source code included)                                                                                                            │  
  └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘  
    


dpkg-deb: error: failed to read archive '/root/output/debs/linux-image-mvebu64_5.27_arm64.deb': No such file or directory

 

What's the cleanest way to have the resulting deb and armbianbuilder line up?

Stuff I've done:

  • made esspressobin.wip board config
  • Made mvebu64 sources config
  • Made mvebu64 Kernel config
  • Made kernel patch to elminate the localversion file
  • assured VERSION_AUTO is disabled in kernel config

 

Files n stuff

esspressobin.wip

Spoiler

# Marvell Armada 37x 1xmPCIe 2xGBE

BOARD_NAME="espressobin"

LINUXFAMILY="mvebu64"

BOOTCONFIG="mvebu_espressobin-88f3720_defconfig"

#BOOTCONFIG="mvebu_armada-37xx"

MODULES="mv_cesa"

MODULES_NEXT="mv_cesa"

CLI_TARGET="jessie,xenial:default,next"

KERNEL_TARGET="default,next"

BUILD_DESKTOP="no"

#

BOARDRATING=""

CHIP="http://docs.armbian.com/Hardware_Other/#marvel-armada-espressobin"

REVIEW="http://forum.armbian.com/index.php/topic/TBD/"

HARDWARE="http://wiki.espressobin.net/tiki-index.php?page=About+ESPRESSObin"

FORUMS="http://forum.armbian.com/index.php/forum/11-other-boards/"

 

mvebu64.conf

Spoiler

ARCH=arm64

KERNEL_IMAGE_TYPE=Image

HAS_UUID_SUPPORT=yes

#OFFSET=2

 

BOOTSCRIPT="boot-marvell.cmd:boot.cmd"

 

BOOTSOURCE=$MAINLINE_UBOOT_SOURCE

BOOTDIR=$MAINLINE_UBOOT_DIR

BOOTBRANCH=tag:v2017.05-rc1

 

 

BOOTENV_FILE='clearfog-default.txt'

HAS_UUID_SUPPORT=yes

 

case $BRANCH in

        default)

        KERNELSOURCE='https://github.com/MarvellEmbeddedProcessors/linux-marvell.git'

        KERNELBRANCH='branch:linux-4.4.8-armada-17.02-espressobin'

        KERNELDIR='linux-marvell'

        DEB_BRANCH=4.4.8

#       CHOSEN_KERNEL=linux-image-linux-4.4.8-armada-17.02-${LINUXFAMILY}

        ;;

 

        next)

        KERNELSOURCE=$MAINLINE_KERNEL_SOURCE

        KERNELBRANCH=$MAINLINE_KERNEL_BRANCH

        KERNELDIR=$MAINLINE_KERNEL_DIR

 

        KERNEL_ALT_GCC='> 6.1'

        ;;

esac

 

## can probaly go slower

CPUMIN=800000

CPUMAX=1200000

GOVERNOR=ondemand

 

 

write_uboot_platform()

{

#       dd if=$1/u-boot.mmc of=$2 bs=512 seek=1 status=noxfer > /dev/null 2>&1

        echo "hey"

}

 

family_tweaks()

{

        chroot $CACHEDIR/$SDCARD /bin/bash -c "apt-get -y -qq remove --auto-remove lirc linux-sound-base alsa-base alsa-utils bluez>/dev/null 2>&1"

}

 
Edited by zador.blood.stained
Renamed to reflect the contents
0
Link to comment
Share on other sites

887 answers to this question

Recommended Posts

  • 0
FlashBurn

FlashBurn

Posted
Posted

I just tried the current bootloader for 1200 MHz and 1000 MHz and the current Buster image (5.6.19) and still don´t get the right frequency :(

 

It now recognizes the maximum frequency right, but if I use 7zip to verify I still don´t have the right frequency :(

 

  • with 1200 MHz bootloader -> 750 MHz
  • with 1000 MHz bootloader -> 800 MHz

Can someone tell me if it works for them or if it is the same as for me?!

0
Link to comment
Share on other sites

Search Before Posting!

  • 0
ebin-dev

ebin-dev

Posted
Posted

The current Armbian buster image with kernel 5.8.6 (thanks to @Igor) works nicely in combination with the current Armbian bootloader - at least with CPU_DDR=800_800 on a V5_0_1 EspressoBin 1GB. 7Zip correctly reports a CPU frequency of 800 MHz: 

root@espressobin:~# cat /proc/version
Linux version 5.8.6-mvebu64 (root@desktop) (aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.33.1.20191209) #20.08.2 SMP PREEMPT Fri Sep 4 22:39:30 CEST 2020

root@espressobin:~# 7za b
7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE)

LE CPU Freq:   794   794   794   794   794   794   794   794

 

I also tried the bootloader with CPU_DDR=1000_800. Armbian launches without issues, cpufreq-info correctly reports the maximum CPU frequency of 1000MHz, but 7zip still reports a CPU frequency of about 800 MHz: 

root@espressobin:~# cat /proc/version
Linux version 5.8.6-mvebu64 (root@desktop) (aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.33.1.20191209) #20.08.2 SMP PREEMPT Fri Sep 4 22:39:30 CEST 2020

root@espressobin:~# cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0 1
  maximum transition latency: 0.97 ms.
  hardware limits: 200 MHz - 1000 MHz
  available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
  current policy: frequency should be within 200 MHz and 1000 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 200 MHz (asserted by call to hardware).
  cpufreq stats: 200 MHz:87.38%, 250 MHz:1.61%, 500 MHz:0.12%, 1000 MHz:10.89%  (309)
analyzing CPU 1:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0 1
  maximum transition latency: 0.97 ms.
  hardware limits: 200 MHz - 1000 MHz
  available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
  current policy: frequency should be within 200 MHz and 1000 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 200 MHz (asserted by call to hardware).
  cpufreq stats: 200 MHz:87.38%, 250 MHz:1.61%, 500 MHz:0.12%, 1000 MHz:10.89%  (309)

root@espressobin:~# 7za b
7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE)
LE CPU Freq:   612   794   794   794   794   794   794   794

 

1
Link to comment
Share on other sites
  • 0
ebin-dev

ebin-dev

Posted
Posted
On 9/5/2020 at 2:31 PM, ebin-dev said:

 

The current Armbian buster image with kernel 5.8.6 (thanks to @Igor) works nicely in combination with the current Armbian bootloader - at least with CPU_DDR=800_800 on a V5_0_1 EspressoBin 1GB. 7Zip correctly reports a CPU frequency of 800 MHz:

 

 

Here are some additional tests with all current Armbian bootloader versions. The current Armbian buster image boots with all of them - none of the bootloader versions leads to crashes or requires a cumbersome recovery (at least on a V5_0_1 EspressoBin 1G - see below).

 

It seems that everything works as expected with CPU_DDR frequencies 600_600 and 800_800.

However, CPU frequency remains at 800 MHz if 1000_800  is loaded  and is even reduced to 750MHz if DDR_Topology 1200_750 is loaded (according to 7zip, but cpufreq-info reports the correct maximum CPU frequency).

 

So - stable operation is established with each of the four DDR_Topologies loaded, but a system with the current bootloader (compiled from Marvells sources) and a current kernel 5.8.6 simply throttle CPU speeds above 800MHz in order to maintain a usable system. I have the impression that this is a feature rather than a bug.

 

It would be highly desirable that GlobalScaleTechnologies comments on these observations or stops advertising Armada 3720 based products as using "Marvell 64bit Dual Core ARM A53 Armada 3700 SOC clocked up to 1.2Ghz".

 

Anyway - I have replaced my EspressoBin some time ago by a more suitable SBC ...

  

DDR_Topology 600_600
root@espressobin:~# 7za b
7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE)
LE CPU Freq:   338   595   595   595   595   595   595   595

DDR_Topology 800_800
root@espressobin:~# 7za b
7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE)
LE CPU Freq:   421   794   789   794   794   793   793   793

DDR_Topology 1000_800
root@espressobin:~# 7za b
7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE)
LE CPU Freq:   789   794   794   794   794   794   793   794

DDR_Topology 1200_750
root@espressobin:~# 7za b
7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE)
LE CPU Freq:   747   748   743   748   748   746   747   747

root@espressobin:~# cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0 1
  maximum transition latency: 0.97 ms.
  hardware limits: 200 MHz - 1.20 GHz
  available frequency steps: 200 MHz, 300 MHz, 600 MHz, 1.20 GHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
  current policy: frequency should be within 200 MHz and 1.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 200 MHz (asserted by call to hardware).
  cpufreq stats: 200 MHz:92.16%, 300 MHz:0.75%, 600 MHz:0.18%, 1.20 GHz:6.91%  (179)
analyzing CPU 1:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0 1
  maximum transition latency: 0.97 ms.
  hardware limits: 200 MHz - 1.20 GHz
  available frequency steps: 200 MHz, 300 MHz, 600 MHz, 1.20 GHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
  current policy: frequency should be within 200 MHz and 1.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 200 MHz (asserted by call to hardware).
  cpufreq stats: 200 MHz:92.16%, 300 MHz:0.75%, 600 MHz:0.18%, 1.20 GHz:6.91%  (179)

 

 

0
Link to comment
Share on other sites
  • 0
barish

barish

Posted
Posted
On 6/15/2020 at 3:48 PM, barish said:

I changed now to the legacy U-Boot (17.10) because it boots very reliably (which is what I need). I am not sure of the negative effects (testing is ongoing) but there is no option for me at the moment. I hope that someone with U-Boot and/or Marvell skills can tell me what changes from 17.10 -> 18.12 led to the unreliable booting. Since it takes place at the start of the WTMI RAM tuning process, I can only assume that there is the rub.

Finally, Globalscale did the trick and pushed the modifications, that they had added to make 17.10 stable for all EspressoBin-Boards, to 18.12 as well. Thanks a lot, Globalscale!!

 

Unfortunately, they did this in their repos and not in the official Marvell repos. I extracted the changes and made a pull request at the Marvell repo. I hope the changes will be merged soon, because I can then use the official Armbian build tools to generate a U-Boot/firmware that flawlessly works with my EspressoBin v7 DDR4 1cs 1GB boards. For now, I compile using the Globalscale repo and got a really stable firmware (tested on three boards for now), I am using the mainline U-Boot (2020.10), too and have no problems – but have not tested this with PCIe periphery (like wifi or SATA adaptors).

2
Link to comment
Share on other sites
  • 0
Pali

Pali

Posted
Posted
On 9/10/2020 at 7:15 PM, ebin-dev said:

Or we are just missing a patch - the real CPU frequency as measured by 7zip seems to correspond to the selected DDR frequency. 

But would that help ? You still require a stable system.

 

@ebin-dev: There is a bug in armada 3720 cpufreq kernel driver which cause that incorrect clock is used for CPU frequency. And this is reason why real measured CPU frequency is only 800 MHz.

Patches for this fixing cpufreq driver are here: https://lore.kernel.org/linux-arm-kernel/20201009125711.0176752a@kernel.org/

 

Could you please test them and check if it fixes that issue on your board?

0
Link to comment
Share on other sites
  • 0
barish

barish

Posted
Posted (edited)

With help from @Pali, I managed to put the Pull Request at the right spot, so when it's accepted, EspressoBin v7 1GB and 2GB will be stable with most current U-Boot and Marvell sources! Unfortunately, I have no board with 2GB, so maybe someone can test it who owns a 2GB v7. Armbian builder is using older branches for stability reasons up to now to compile the U-Boot images – maybe with all the new patches in place, Armbian can also use the newest U-Boot version.

Edit: The Pull Request has just been merged. I will make a PR at Armbian Build to use newest Marvell repo branches.

Edited by barish
addendum
2
Link to comment
Share on other sites
  • 0
Pali

Pali

Posted
Posted

@BenCranston We have sent second version of patches for A3720 which should make 1 GHz mode finally stable. See post https://forum.armbian.com/topic/10429-how-to-make-espressobin-v7-stable/?do=findComment&comment=117511

 

If you want to test them, download all patches from emails via (raw) button near Message-ID: line and then apply them, either via `patch -p1 -i filename` or via `git am filename` (if working you have linux sources checkouted from git).

 

1
Link to comment
Share on other sites
  • 0
Igor

Igor

Posted
Posted
On 11/23/2020 at 2:49 PM, barish said:

Armbian builder is using older branches for stability reasons up to now to compile the U-Boot images – maybe with all the new patches in place, Armbian can also use the newest U-Boot version.


https://github.com/armbian/build/pull/2598
Beta repository (beta.armbian.com in about 30m from now) or manual install, builds 91+ contains those patches. I also switched u-boot but needs testing.

1
Link to comment
Share on other sites
  • 0
BenCranston

BenCranston

Posted
Posted

@Pali Yes!  The patches are working great for me.  I ended up switching to the beta kernel builds and got them that way.  Trying to build the kernel with the Arabian tools and incorporate the patches was beyond me.  I see the cpu actively switching between the various clock rates and the performance test indicate I'm getting 1GHz clock now.  Things have been really stable with no trouble to report.  

0
Link to comment
Share on other sites
  • 0
hrw

hrw

Posted
Posted

I am not a user of Armbian and do not plan to.

 

Wanted to write here and thank to whoever provided UART U-Boot files as I used them to get my EspressoBin v5 running.

 

Now it has mainline U-Boot 2021.01 and works as normal EBBR board. I plan to use OpenWRT on it and use as a router for some time.

 

Few more words: https://marcin.juszkiewicz.com.pl/2021/02/15/ebbr-on-espressobin/

2
Link to comment
Share on other sites
  • 0
Excalibur

Excalibur

Posted
Posted

Follow up on hrw. I was planning to install pimox on ESPRESSObin to run virtual OpenWrt and a docker host, which requires a Debian like host. I coudn't get vanilla aarch64 Debian to boot on the board so I turned to Armbian. To my surprise the board is now moved to not supported status.

 

I ultimately got Debian to boot in EBBR and recorded my steps here in case anyone here also want to switch to a different distro. As for pimox I got it installed but idle memory consumption is around 800M. I have tried to run the board as a NAS via on board SATA and USB 3, which was very sluggish (could be my USB 3 docking station's fault). I'm very sad that the board is so resource limited that a little bit more CPU or memory can definitely make it much more capable. At the moment I flashed OpenWrt and only put one docker service on it, since upgrading OpenWrt requires reflashing SD card.

0
Link to comment
Share on other sites
  • 0
lanefu

lanefu

Posted
  • Author
Posted
6 hours ago, Excalibur said:

To my surprise the board is now moved to not supported status.

 

You can still build images with the armbian build tools, but yeah we need the community to step up and maintain the ebin unfortuantely.

0
Link to comment
Share on other sites
  • 0
Excalibur

Excalibur

Posted
Posted
1 hour ago, Pali said:

 

It should work fine. At least half year ago it worked without any issue. Any specific error?

No error this time but I just prefer to use supported software if possible. If Debian breaks they have to fix it since their image is targeting generic aarch64 and that will be a regression. If Armbian breaks I might be pushed off since the target is not officially supported.

0
Link to comment
Share on other sites
  • 0
Excalibur

Excalibur

Posted
Posted
Just now, Pali said:

aarch64 is supported by debian. Now I checked my espressobin box with debian and it is still working fine, boot without issue. So if it does not work for you, I suggest to report a bug with error log what does not work.

I got it working eventually. Thanks.

0
Link to comment
Share on other sites
  • 0
y52

y52

Posted
Posted

I am upgrading my espressobin v5 board setup with Armbian to v7 board.

Having flashed the u-boot on v7 with 

U-Boot 2018.03-devel-18.12.3-gc9aa92ce70-armbian (Sep 18 2020 - 10:07:21 +0200)

setting the u-boot environments and writing the Armbian image to the USB

Armbian_21.08.1_Espressobin_bullseye_current_5.10.60.img

the board booted as expected, but logged initial errors when initiating the boot from the media:

 

Model: Marvell Armada 3720 Community Board ESPRESSOBin
Net:   eth0: neta@30000 [PRIME]
Hit any key to stop autoboot:  0 
starting USB...
USB0:   Register 2000104 NbrPorts 2
Starting the controller
USB XHCI 1.00
USB1:   USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
/
** File not found /boot.scr **                                 <<< ====
## Executing script at 06d00000
Wrong image format for "source" command        <<< ====
/boot/
1063 bytes read in 25 ms (41 KiB/s)
## Executing script at 06d00000
191 bytes read in 10 ms (18.6 KiB/s)
21496320 bytes read in 108 ms (189.8 MiB/s)
8858893 bytes read in 58 ms (145.7 MiB/s)
** File not found /boot/dtb/marvell/armada-3720-community.dtb **
11127 bytes read in 15 ms (723.6 KiB/s)
## Loading init Ramdisk from Legacy Image at 01100000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    8858829 Bytes = 8.4 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK

 

 

Could anyone prompt if this  " ** File not found /boot.scr ** " is a critical error or it could be fixed?

U-boot environments were set as follows :

Marvell>> setenv boot_targets 'usb sata mmc1 mmc0'
Marvell>> setenv boot_prefixes '/ /boot/'

 

As I am booting from USB, it should be the 1st boot target.

 

boot.scr is in place and has been deployed with the Armbian image. 

# ls -al /boot/boot.scr 
-rw-rw-r-- 1 root root 1063 Aug 26 10:46 /boot/boot.scr

 

What may cause the "** File not found /boot.scr **" ?

 

 

 

The posts from HRW and Excalibur on "Now it has mainline U-Boot 2021.01 and works as normal EBBR board."

were very interesting. It would be worth adding U-Boot 2021.01 to a repository.

Could somebody share his experience upgrading his board with U-Boot 2021.01 and bringing up Armbian?

 

0
Link to comment
Share on other sites
  • 0
Pali

Pali

Posted
Posted
2 minutes ago, y52 said:

Having flashed the u-boot on v7 with 

U-Boot 2018.03-devel-18.12.3-gc9aa92ce70-armbian (Sep 18 2020 - 10:07:21 +0200)

 

This is 5 year old version of U-Boot. Really upgrade to something non-prehistoric. Old version has lot of bugs, so it is not surprise that something does not work as expected.

 

2 minutes ago, y52 said:

It would be worth adding U-Boot 2021.01 to a repository.

 

Note that there is new U-Boot 2022.01 version... But Armbian rejected to update U-Boot + TF-A to recent version (it was needed to only change version in build script), so you need to build and update by yourself. See my post with details, steps are really easy. If you have issues with building, just write and I can help you.

0
Link to comment
Share on other sites
  • 0
y52

y52

Posted
Posted
2 hours ago, y52 said:

** File not found /boot.scr **                                 <<< ====
## Executing script at 06d00000
Wrong image format for "source" command        <<< ====

 

For those, who still rely on Armbian's u-boot build, I've found the origin of the logs error above.

The armbian setenv instructions on https://www.armbian.com/espressobin/ page has 1 line which should be corrected:

setenv boot_prefixes '/ /boot/'

It has 1 slash in excess. and read " setenv boot_prefixes '/boot/' " or be corrected directly in u-boot :

 

Marvell>> setenv boot_prefixes '/boot/'
Marvell>> echo $boot_prefixes

Marvell>> saveenv

 

I suggest that Armbian corrects it on their site as well.

0
Link to comment
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
Answer this question...

×   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...
×
 Share
Go to question listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept