-
Posts
3892 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by martinayotte
-
-
For the 1 core in /proc/cpuinfo, I've just figured out now (I didn't noticed before) that all my newer kernels (4.6.2) on orangepilite/orangepipcplus/orangepiplus2e have only 1 core while older ones 4.6.0+ on orangpipc/orangepione have 4 core. So, maybe a bug introduced recently somehow ...
EDIT : Oh ! looking at the root DTS, there wasn't any of this clock stuff defined in 4.6.0+, and in the 4.6.2 it is defined but only for cpu0. So, I wonder if only duplicating it for cpu1/cpu2/cpu3 will do the job.
-
You probably simply need to install the https://github.com/duxingkei33/orangepi_PC_gpio_pyH3 version first, and then Adafruit's ones.
-
MIPSbian ...
-
p.s. short circuit of C301 is not working (I don't know why)...
As @zador said, a button in parallel with C301, it means that VCC should be applied to C301, not a short with GND.
Anyway, if a GND is applied on Q9 collector, it is good too.
-
Maybe a thin wire can be attach on Q9, but I didn't figure out yet its location. (I will try to narrow it with magnifier)
-
It also looks like that no data are transmitted on the serial port but I have to verify that again
That is the key for debugging success.
You should check what's appearing on this serial in the early boot, you will probably figure out the real reason.
Maybe a bad SDCard, otherwise something else ...
-
Good !
Glad that you've figured out !
-
Depending of the version of your kernel, old ones called Legacy, it is using FEX to define GPIOs and Peripherals pins.
Wit Mainline Kernel, it is using DTS.
Maybe the settings currently are already Ok, did you have an /dev/ttyS3 ?
If not, then those settings need to be tweaked. What is the kernel version you are using ?
Do some search about UART FEX for Legacy.
For Mainline, I think my contribution to DTS is already in all Armbian images.
-
Pin 8/10 ? it should be /dev/ttyS3.
Maybe you will need to tweak FEX or DTS, depending of the kernel you are using.
-
Do you mean the Hardware Serial Port on the Pi header ?
It is not /dev/ttyAMA0, but /dev/ttyS2 and /dev/ttyS3, depending which pins you looking at.
-
Of course, doing plain image backup is troublesome.
But take a look at this thread : http://forum.armbian.com/index.php/topic/1070-install-to-emmc/page-2#entry11374
It is producing a 7z zip file which is smaller.
-
The image for OPi-PC-Plus are located there http://www.armbian.com/orange-pi-pc-plus/
-
Why should you revert to loboris kernel ? it is simply junk to throw away...
You should continue in the Armbian path, even if you are facing pitfalls (those will be easier to fix than loboris ones) ...
-
Well, those are interesting discoveries ...
-
I'm usually running Mainline, but in this case, I've rebooted with a Legacy, the "orangepilite 3.4.112-sun8i" and gave it a try.
It didn't worked with gpio5, but was working perfectly with gpio110.
So, since you got "Device or resource busy" using gpio110, we need more details :
Did you tried gpio110 right after reboot (because it could be "busy" by some other apps) ?
What kind is your board exactly ?
Is your 3.4 coming from Armbian ? (which subversion ?)
EDIT : what "cat /sys/kernel/debug/gpio" is showing ?
-
On this page http://linux-sunxi.org/Xunlong_Orange_Pi_Plus_2, it is mentioned :
Images for Orange Pi Plus should work without problems.
So, if I were you, I would try it out and give us feedback.
-
Try the python library that I'm using since awhile from https://github.com/duxingkei33/orangepi_PC_gpio_pyH3
If it is working for you, we can try to figure out why /sys/class/gpio doesn't.
(BTW, which kernel are you using ?)
-
Maybe you can check if it is follow the method used in Mainline ...
(position of letter in alphabet - 1) * 32 + pin number
So, PD14 will be 3 * 32 +14 = 110
-
OrangePi-Plus or OrangePi-Plus2E ?
Because it is not the same processor ...
(Xunlong have tendancy to confuse us with board's name )
-
As some of you know, I've added patches for eMMC in Mainline 4.6.x kernel DTS yesterday, they are no merged.
But I've almost forgot that u-boot need some patches too. I did them for u-boot DTS, but I'm still facing issues :
The u-boot still doesn't see the eMMC !
U-Boot SPL 2016.05-armbian (Jun 25 2016 - 12:09:52) DRAM: 2048 MiB Card did not respond to voltage select! Could not determine boot source resetting ...
Maybe I've missed something (I'm not very familiar with u-boot)
While using the SDCard u-boot, doing "mmc list" only shows the SDCard itself, no eMMC
I've tried using the u-boot-sunxi-with-spl.bin file that @Ionix, and this one was seeing the eMMC, although it crashed later during kernel, probably for some other reasons.
So, I'm sure there is something else missing in the u-boot build which will require a patch, but I can't figure out yet...
EDIT : Shame on me !
I've forgotten to apply same kind of patch used in Legacy :
+CONFIG_MMC0_CD_PIN="PF6" +CONFIG_MMC_SUNXI_SLOT_EXTRA=2
Now, it is time to debug why kernel crash and reboot, it must related to eMMC too, since the same kernel image is booting fine from SD.
On eMMC, the boot log shows :
[ 5.442574] random: systemd-udevd urandom read with 2 bits of entropy available [ 46.817443] reboot: Restarting system
while same kernel image on SD shows until boot succeed :
[ 5.476294] random: systemd-udevd urandom read with 3 bits of entropy available [ 11.361397] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null) ... ...
So, the "mounting filesystem" fails ...
EDIT2: issue found and manually fixed !
It looks like "nand-sata-install" didn't tweaked the eMMC/boot/boot.cmd which was still pointing to SDCard.
I will tell Igor about that so that he can take a look.
(BTW, all this debugging was done on a OrangePi-Plus2E with 4.6.2 where eMMC appears as /dev/mmcblk2)
-
About HDMI mainline, I don't know and didn't follow everything, but I think some patches have been submitted to linux-sunxi by Jef Moine.
-
Tested with both OrangePi-Lite and OrangePi-Plus2E !
The PR is now sent...
-
I've been working on the rtl8189fs patches for Mainline.
Althouth the source code change between Legacy and Mainline is pretty trivial, preparing good and nice patches becomes a tedious task :
- First, the original patch in Legacy contains tons of DOS file formatted (strange for a Linux driver, shame on Realtek) and even dos2unix failed on some files because of binaries character (probably Chinese), I had to edit many files because I wouldn't "signed-off" such ugly thing. (btw, maybe that dos2unix job should be done one Legacy to make it cleaner)
- It is a quick big patch, but about the same size as the one in Legacy, about 10MB of text file.
- Even after applying the patch, we still need to have some other patches, one for DefConfig in Igor's lib/config and one for DTS which I will work on tomorrow ...
- Then, lots of testing need to be done, especially that I need to figured out that everything is working in the fresh build environment, then a PR will be sent to Igor.
-
I've been working on the rtl8189fs patches for Mainline. I think it is better that I start new thread for it ...
Orange Pi Lite - now available
in Allwinner sunxi
Posted
Do you mean that it is some kind of regression bug introduced recently in u-boot ?
EDIT : searching quickly, I've only find #define CONFIG_ARMV7_PSCI_NR_CPUS 4 in u-boot/v2016.05/u-boot.cfg.