-
Posts
3892 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by martinayotte
-
-
I was just looking at DT about this, because if I remember, I didn't had the issue up until recently.
I'm seeing that in the old longsleep DT, it was using 'sun50i-rtc' and in the current it is using 'sun6i-a31-rtc'.
Since I kept also several A64 armbian previous images, I will look into them too.
(I will also check what is the frequency of the occurence, because maybe it happen every 24hrs by reading wrong value from a sync service call. Let see tomorrow ...)
(Another thing I found : the H3 has /dev/rtc and clear trace in dmesg, but not with H5 or A64, no trace at all. But why I don't have the same issue with H5 ?)
-
I found a strange bug and seen it twice in a week :
After few days running, my PineA64 had wrong date, some thing like "Tue Mar 13 20:50:11 EDT 2153".
Trying to restart NTP didn't fix it. Trying to set it manually give me an error :
root@pine64:~# date -s "2017-02-03 00:00:01" date: cannot set date: Invalid argument
Doing an "strace" with it reveal that it can not write system clock :
settimeofday({1486098000, 0}, NULL) = -1 EINVAL (Invalid argument) openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
Doing search on the net, I've found http://nerdbynature.de/s9y/2009/07/22/cannot-set-date-Invalid-argumentand http://www.mail-archive.com/bug-coreutils@gnu.org/msg14103.html, but not real answers other than it is really the kernel that are f*k*ing up with the system clock. And the issue is gone if I simply reboot the board. Really strange ... Especially that it happened only on PineA64 ...
As someone got the similar issue ?
-
Yes, that is the convention that kernel guys are promoting : leaving them disabled, so GPIOs by default, overlays loaded when needed.
-
I don't think so, although I didn't check on the BananaPi-1 schematic, because there are USB pins from SoC (not simple GPIO) that are present on PiZero which doesn't exist on BananaPi-1.
-
If you use newest build images, we now provide some overlays in the /boot/dtb/overlay folder, and your can activate them in /boot/armbianEnv.txt with :
overlays=uart1-enable uart2-enable i2c0 spi0-spidev
-
I don't understand you !!!
Who has "positive attitude" or "negative attitude" here, outside of YOU ...
The hardware design choice of Xunlong about eMMC on OPi0 is NOT an Armbian design choice !!! Armbian has NO relationship with Xunlong except to get some sample board to help community !
As I keep saying, even volunteers have responsibilities- or they are just people running amok
(I'm usually a quiet gentle guy, but here, please @igor, I'm getting out, if he fight, please BAN if forever)
What the FUCK ! As Volunteer, I'm should simply say to you : GET OUT OF OUR FORUM !!! YOU'RE A SICK GUY !!!
EDIT : as I said eailer, STOP complain and become YOURSELF a CONTRIBUTOR !
-
USB Power ? as discussed many times on this forum, microUSB connector and cheap/crappy/dirty cables can't provide enough power to the board.
you can still boot from eMMC and use MicroSD only for data.
-
OPiPC+ is powered using traditional Barrel 4mm x 1.7mm.
Of course, OPiPC+ is twice as big footprint form-factor of OPi0, but 3 USB instead of 1, 2x or 4X DRAM, 8MB eMMC which once initialized with "nand-sata-install", you remove MicroSD forever, reducing BoM cost.
-
@atharmian, I think you are mixing up things when talking about different things : Opi0/CHIP/Onion2 ...
You should maybe contribute instead of doing PM argumentation as been said days ago !
-
My favorite right now is the OPiPC+, eth/wifi/emmc/3usb for $19.95.
-
Right ! ... or STA but on a different network to avoid routing isues ...
-
Or you can get cheaper breakouts such : http://www.ebay.ca/itm/2Pack-5v-USB-A-Type-Female-Breakout-Board-w-2-54mm-Header-/201791328472
-
[ error ] Running this tool on board itself is not supported
You need to cross-compile on a PC equipped with Ubuntu-16.04, or inside a VirtualBox with the same Ubuntu.
-
That is strange !
With the build I did yesterday morning with sunxi64-next-20170125 branch, I was able to mount /dev/sda1 external drive and update its rootfs, and reboot with it as USB-Boot.
What kind of USB drive are you using ?
BTW be aware that some USB dongle such as "058f:6387 Alcor Micro Corp. Flash Drive" are failing in 64 bits SPL-USB-U-Boot, while some MicroSD reader such "14cd:121c Super Top microSD card reader" are working fine.
-
Google will give you answers : https://www.google.ca/#q=linux+add+swap+file
-
Yes, it will boot from USB, even if you have some USB CDC attached, because you have to specify the ' setenv rootdev "/dev/sda1" ' in the boot.cmd and recompile boot.scr
-
Good !
Don't forget that I2C needs some PullUps on the bus if your device doesn't provide it already.
-
The I2C buses are already present in the DT, but "disabled" by default.
You can decompile DTB into DTS, after having done a backup of the DTB, edit it to enabling the buses by changing status "disabled" by "okay", and then recompile DTB for edited DTS.
Or you could use DT Overlay, similar to the following :
// Enable the i2c interface /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target-path = "/aliases"; __overlay__ { /* Path to the i2c controller nodes */ i2c0 = "/soc@01c00000/i2c@01c2b000"; i2c1 = "/soc@01c00000/i2c@01c2b400"; }; }; fragment@1 { target = <&i2c0>; __overlay__ { status = "okay"; }; }; fragment@2 { target = <&i2c1>; __overlay__ { status = "okay"; }; }; };
-
Unfortunately, all those boards are not providing easy access to SPI1, they are provding SPI0 instead.
Even if PA15 is used for LED_STATUS, it is could probably still be used as SPI1_MOSI, since MOSI is "Master-Out-Slave-In".
Of course, this LED maybe will affect speed efficiency, but you can give it a try.
Also, you need to make sure that UART3 is disabled, and finally MUTE is the more difficult to access, since it it the PA16 SPI1_MISO, and should not be used as MUTE output anymore.
-
BTW, recompiling /boot/boot.scr is only needed after changes to /boot/boot.cmd. Changes to /boot/armbianEnv.txt doesn't requires recompiling.
-
If you look at the H3 datasheet, they can not be move around to any other GPIOs ...
Which Orange do you have ? Did you look at the schematic ?
-
I'm not really fluent with FEX since I'm using Mainline since more than 2 years.
But from H3 Datasheet, the SPI1 is using PA13 to PA16 (not PA7 to PA10).
Also, the spi_dev_num = 2, since you have now 2 spidev.
-
Yes, this is the line to tweak :
self.spi.open(1, 0) # Open SPI port 1, slave device (CS) 1
Of couse, your DT or FEX also need to be tweak accordingly.
-
Only the starting pins are correct all the rest are incorrect.
Most of the pins on the zero are on PA registry unlike the "normal" PGXXX
https://raw.githubusercontent.com/duxingkei33/orangepi_PC_gpio_pyH3/master/pyA20/gpio/mapping.h
Since I have not test them all, which pins did you found incorrect ?
We can submit a PR if some correction is needed...
CIFS mount is failed on 5.23
in Allwinner sunxi
Posted
You need to provide option to specify username, look at the man page. Also you can avoid calling mount.cifs directly and use traditional mount :