-
Posts
3892 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by martinayotte
-
-
17 hours ago, Romber said:
You're wrong. I installed clean armbian image.
I doubt since even "screenfetch" isn't part of Armbian images ...
-
22 hours ago, Martin W. said:
Very strange, what has aufs filesystem with RT to do
Nothing special, but maybe ‘struct rw_semaphore’ has changed across kernel versions and ‘owner’ has been removed.
To get AUFS working, maybe it require a fix to RT patches to match that change.
-
2 hours ago, Martin W. said:
fs/aufs/i_op.c: In function ‘au_pin_hdir_set_owner’:
fs/aufs/i_op.c:636:45: error: ‘struct rw_semaphore’ has no member named ‘owner’You can try to compile with "AUFS=no" ...
-
14 hours ago, mhc said:
sends a packet of 26 bits of data.
It looks like you try to achieve interfacing a 26 bits Wiegand keyfob reader ... Right ?
In such case, I would rather dedicate a small MCU such Atmel328 doing this decoding job, and report the result over serial port to the BananaPi.
-
27 minutes ago, orangepower said:
I`m tryng now for 4 hours to boot from fresh made SD card but I always end up on eMMC module.
Rockchip SoCs always have eMMC as boot priority.
So, to boot from SDCard, you need to stop U-Boot from eMMC by pressing <spacebar> several times during startup.
Then, at U-Boot command line, you can type "setenv devnum 1" followed with "run mmc_boot", it will then boot from SD.
-
2 hours ago, jps said:
I can see the module, but it is imposible to communicate with it:
If it been seen on the I2C bus, you can try some library such as the one from Adafruit ...
-
29 minutes ago, xwiggen said:
What's an MR?
"Merge Request", equivalent to PR which is "Pull Request" ...
-
5 hours ago, fri40 said:
I've added three lines in that sun7i makefile block
Probably those dtbo were never been part of the build.
Feel free to send a PR for this Makefile correction ...
-
5 hours ago, hallo1 said:
Sometimes the display will light up and show proper content, but the script will still run into this error after ~3s.
Then, maybe it is I2C speed issue ...
-
25 minutes ago, hallo1 said:
so it is more likely a bug related to kernel.
Did you checked the presence of the device with "i2cdetect" ?
Did you checked the permissions of /dev/i2c-1 and running your test script under proper user/group ?
-
Sorry, I don't see any things which could be obviously wrong ...
-
29 minutes ago, joek said:
i would like to know what is missing here?
Are you using UART2 ? Because UART2 also use PA0/PA1 if enabled ...
-
6 hours ago, Marko Buršič said:
May I upload your patch for pull request?
Which patch ? The one I've post on Dec 6th ? ... Sure !
-
2 hours ago, Narly9999 said:
It surely seems clear that this is an ARMBIAN problem.
Not at all ! You are trying to build something that is not own by Armbian ...
BTW, Jessie is now End-of-Life ...
-
41 minutes ago, Marko Buršič said:
If I understand well, then you may have also a third CS
Right !
-
15 hours ago, Marko Buršič said:
Where <0> is found working experimental, I have no idea what's its meaning
This <0> means to use default hardware spi-cs0, while the second argument to cs-gpios is the new gpio for CS1 ...
-
20 minutes ago, orangepie14 said:
I mean the Orange Pi PC 2 has H3 Board with 2 GB RAM, so I suspect there is not much of a difference between Orange Pi PC and Orange Pi PC 2. If I can purchase the RAM chip of an Orange Pi PC 2 and solder it on to an Orange Pi PC - it should work right?
The RAM chip needs an additional address line from the H3 SoC to decide if it is addressing the upper or lower bank of the memory.
If the OPiPC PCB was designed in function to use 1GB, and didn't provided this additional address line to be compatible with 2GB chips, then this line will be left floating on the chip and can even not be limited to the first 1GB bank, but can even give random memory data depending of if the floating line will be treat as LOW or HIGH depending of the EFI, it will return the wrong data.
-
3 hours ago, orangepie14 said:
I would like to know if I can upgrade the RAM from 1 GB to 2GB ?
The PCB routing doesn't provide the extra address line to allow upgrading RAM ...
-
2 hours ago, redmaze said:
I test in 3 boards... I put a 1KOhm pullup resistor and the port keeps searching and nothing is detected.
Normally, other TWI ports are using 2K pullups, but on both SDA and SCK.
Did you tried with both pullups ?
-
4 minutes ago, redmaze said:
But using PL0/1 the i2c keep searching and nothing is obtained
This is usually symptom of missing pullups !
According to schematic, the TWI0 and TWI1 has pullups provided by the OPiZ+2, but none are provided for S-TWI, you need to add them yourself ...
-
11 minutes ago, redmaze said:
it says "okay"
So, it should work ... Also, "i2cdetect -l" should reveal its presence ...
Maybe it is the attached devices that doesn't respond ...
Do you have PullUps on those ?
-
What "cat /proc/device-tree/soc/i2c@1f02400/status" is reporting ? "okay" or "disabled" ?
Did you tried to change ' pins = "PL0\0PL1"; ' to ' pins = "PL0", "PL1"; ' instead ?
-
15 hours ago, Fred St-Pierre said:
You have more info on how to achieve this? I'd love to be able to use the SPI chip on this board...
I've use a small proto pcb, soldered a female header along with a SMT to DIP adaptor where I soldered the SPI-NOR flash, connect SPI signals to header.
Then, I've compile a Armbian image with user-patch for U-Boot Pine64 DTS, along with an DT overlay for the kernel that provide MTD partition.
To push U-Boot to the flash, I've used "flashcp" from "mtd-utils" package to /dev/mtd0 partition.
-
Most probably that the /boot/armbianEnv.txt is corrupted since it is where "rootdev" is set/overwrite the one defined in /boot/boot.scr ...
property "reset-gpios" not found
in Off-topic
Posted
you should look here in cache/sources/linux-mainline/linux-5.4.y/Documentation/devicetree/bindings/display/