martinayotte
-
Posts
3892 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by martinayotte
-
-
The CONFIG_SYS_CLK_FREQ=480000000 is also defined in orangepi_zero_defconfig, so it is probably a build process issue that doesn't pass the defconfig value to compiler properly ?
EDIT : I've added a printf at the place you've mentioned and it was already the good value, and kernel still hang if I leave the DT stuff.
So, back to "square one" ...
EDIT2 : I've rebuild both OPiOne and OPiLite and they don't have this disease, it is only with OPiZero ...
EDIT3 : I've open this issue https://github.com/igorpecovnik/lib/issues/580to get attention from other Armbian developpers.
-
There are tons on AliExpress/eBay/Amazon. You should chose one that as jumper to become 3.3V compatible.
Be aware also that some are using fake FTD chips, so Windows driver will choke with those.
Workaround such fake chips, is to use one with CH340 or CH341 chips which are chinese chips such as :
-
I modified u-boot to manually set the SoC frequency to 408MHz instead of 1.008GHz, and Linux will boot with the dts without removing the vdd_cpux or operating-points sections.
Where did you do such change ? (because in orangepi_zero_defconfig, it was already set to CONFIG_DRAM_CLK=408)
-
Further investigations : I did a fresh image build without the XR819 patches, using orangepi-4.9.0 branch, and it freeze during boot same way as before.
Last entries of serial log are :
[ OK ] Listening on Syslog Socket. Starting Journal Service... [ OK ] Started Journal Service. [ OK ] Mounted Configuration File System. [ OK ] Mounted FUSE Control File System. [ OK ] Started Apply Kernel Variables. [ OK ] Started Create Static Device Nodes in /dev. Starting udev Kernel Device Manager... [ OK ] Started udev Kernel Device Manager. Starting Copy rules generated while the root was ro... Starting LSB: Tune IDE hard disks... Starting LSB: Set preliminary keymap... [ OK ] Started Copy rules generated while the root was ro. [ OK ] Started LSB: Tune IDE hard disks.I've then took a copy of the sun8i-h3-orangepi-one.dtb from sun8i-emac-wip-v5 branch, and it boot properly.
So, there is definitively something wrong in DTS of the orangepi-4.9.0 branch.
(It is probably not booting on a PiOne either, but I didn't try that yet.)
EDIT : Ok ! it seems to be related with "cpufreq_init", if I remove the cpu0/operating-points/cpu_thermal sections in DTS, it is booting ...
(I remember facing similar issues 6 months ago, but I don't remember what changes were required, missing freq or something like)
-
Yes, those were fixed 6 days ago : https://github.com/megous/linux/commit/4367c1d846552163f65aec11dcbe2659c8cf7128
-
That is good news !
So, I've started trying this out even before PR been merged.
It compiled fine, but boot freeze ...
Early investigation : boot freeze isn't related with xradio, but related with branch switch.
Using DTB from sun8i-emac-wip-v5 branch along with this new build binaries is Ok.
So, something is wrong in DT of orange-pi-4.9 branch for Zero !
More investigations tomorrow ...
-
@TKaiser gave me hint in the other thread.
The problem is that older u-Boot had the FDT file set wrongly to "orangepi-plus" not "orangepi-plus-2e", which make the loading DTB for Plus not for Plus2E.
So, diffing the DTS for Plus2E against PC+ was not revealing any thing, but diffing Plus against Plus2E reveal a big thing :
EMAC wasn't declared the same way ! There was also some GMAC-3V3 missing !
Looking at the schematics for PC+, there wasn't any PD6/EMAC-PWR-EN been used, but in both Plus and Plus2E there is a power switch.
In other words, Plus2E DTS never been completed since EMAC never got power, except if using wrong Plus DTS by pure concidence ...
-
Fixed done and committed as explain in https://forum.armbian.com/index.php/topic/3029-mainline-ethernet-driver-h3/
-
Oh ! Thanks, @TKaiser !
This potentially gave me a clue here : it seems that PD6/EMAC-PWR-EN is used in Plus2E, but not on PCPlus, therefore no power apply if we don't add it to DT.
EDIT : Fix done and committed ...
EDIT2 : For those who are interested, http://www.megafileupload.com/cg8v/orangepiplus2e-20161209.tgz
-
Just to clarify, DT is for Mainline kernels while FEX is for Legacy kernel.
In DT, there is a property named "clock-frequency = <400000>;", so it is pretty easy to change.
For Legacy FEX, I couldn't find any ways to do, so it seems hard coded in drivers/i2c/busses/i2c-sunxi.h
-
Ok ! I've never tried this one.
(But, I hate closed sources stuff anyway)
For running it at startup, the easiest way is to start it in /etc/rc.local (before the "exit 0")
-
As I said, the build I've done a month ago, Oct 27th to be exact, worked, but not the newer one.
We need to figure out which bug has been introduced to be able to fix it.
Until we found it, the only way you can get networking is to use the built-in WiFi of the OPiPlus2E.
EDIT : For those who wish to get my kernel from Oct 27th :
http://www.megafileupload.com/83l9/orangepiplus2e-20161027.tgz
-
Sorry for confusion, I was thinking about SPI and answer too fast.
For I2C, the speed is configured in the DT and/or FEX, I don't think there is any IOCTL parameter for it.
-
My image of last month was using montjoie's sun8i-emac-wip-v5, but few days ago, I've upgraded the kernel+modules (without redoing full image) using orange-pi-4.9 from megous, I didn't faced any issues.
BTW, I've almost forgot to mention, I'm using the built-in WiFi of OPiPlus2E, not the EMAC. Maybe I should try it and report here...
EDIT : Effectively, I have problem with orange-pi-4.9, and fortunately I always keep old image for a while, and I've tried sun8i-emac-wip-v5 from last month, it is working fine.
I will probably revert my eMMC setup back to sun8i-emac-wip-v5.
EDIT2 : Interestingly, I've just verified one of my OPiPC+ which was updated the same day with orange-pi-4.9 too, and EMAC seems to work fine.
(I will have to rebuild a new image for OPiPlus2E to see if it still fail.)
-
I'm running 4.9.x on my OPiPlus2E since more than a month, and it is working properly.
-
ret = ioctl(fd, SPI_IOC_WR_MAX_SPEED_HZ, &speed);
-
pine64 login:
Why do you say that it didn't boot if you've reached the login prompt ?
-
USB-TTL dongle are usually around $0.99 on eBay or AliExpress.
This will really help to figure out the issue, which can be simple, but without any logs, you are walking blindly in the dark.
-
You will probably need to plug an USB-TTL Serial into debug serial port, capture the boot output log and post it here.
-
Sorry, I wasn't the original author of that script.
Although it headed with #!/usr/bin/python3, your issues seems that it is not python3 compatible, try it with python2.7 ...
(Or if you really python3, change the "uppercase" which is now "ascii_uppercase")
EDIT : it is better to change the "uppercase" to "ascii_uppercase", since it works on both python2.7 and python3
-
What do you mean by "virtual USB server" ?
If you mean a server or daemon that expose it local USB to a remote machine, then "usbip" is one, and there are also some commercial ones.
"uspip" can be installed using "apt-get install usbip".
Some docs can be found here : https://www.kernel.org/doc/readme/tools-usb-usbip-README
-
Maybe you should look at "usbip" server and client.
-
When you are doing frequently such calculations and getting bored, you simply use python script to help you out ...
#!/usr/bin/python3 import sys import string def convert(value): value = value.upper() alp = value[1] idx = string.uppercase.index(alp) num = int(value[2:], 10) res = idx * 32 + num return res if __name__ == "__main__": args = sys.argv[1:] if not args: print("Usage: %s <pin>" % sys.argv[0]) sys.exit(1) print("%d" % convert(args[0])) -
I don't know which script is trying to access it using /dev/disk/mmcblk1p1.
If we knew, we could have that fixed ...
Sorry, if my help didn't provide solution.
Boot troubles
in Allwinner sunxi
Posted
Personally, I'm using Mainline Armbian on my Plus2E installed in the eMMC and using it with the WiFi.
But be aware that Eth0 was not working a week ago, and I fixed that issue 5 days ago :
https://github.com/igorpecovnik/lib/commit/b16b7ba91a0fea633a06830f916d2524a7ccaec0
If your image is older than last build using this patch, you can access your board using Eth0, therefore the only way to see if it has booted properly is thru Debug Serial or WiFi, but this WiFi need to be configured first.