awef
-
Posts
45 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by awef
-
-
Does anyone know if it's possible to use the docker-shell to patch linux and compile, but NOT make the .img file?
Maybe something like
./compile.sh unpack-linux
./compile.sh apply-patches ALL=THE_SETTINGS
./compile.sh build-kernel
but not make .img
I'm trying to change some network driver settings and want to just copy the new kernel module to my target board instead of flashing the entire SD card.
-
Well for the moment, I went the legacy/fex route and it works fine. I'll have to circle back to this mainline dto thing a bit later. Thanks!
-
Thanks! Will give it a shot!
-
I think one thing I missed earlier is that it might be easier to use docker to compile a new kernel first (off board) since that's how armbian is "originally built" so to speak?
For chip, I'm using a PCM5102 but the interface is "just i2s" with of course it's chip specific settings (wherever those are put in)
-
-
not yet clear on how to use all the above info yet, but I'm looking into it (in case the wizards here have more urgent matters to reply to)
-
-
I just noticed there isn't a i2s/i2s0 overlay for the mainline kernel series:
Linux orangepipcplus 4.14.78-sunxi #412 SMP Fri Oct 26 11:37:04 CEST 2018 armv7l GNU/Linux
https://github.com/armbian/sunxi-DT-overlays/tree/master/sun8i-h3
Is it a simple matter of just adding some text files for DT? Or was i2s intentionally left out because or some conflict for example?
(I had good luck with legacy on Banana Pi Pro a long time ago with fex, so I'm guessing it's a unintended omission?)
-
You probably have a board with a defective SD Card Detect Pin is my guess.
I think the orange pi company doesn't check the card detect pin in their distros, so if you want your board to work, use the default distros rather than armbian for this board.
Otherwise get the board fixed (realistically probably not worth the price of shipping back and forth)
-
Probably the case. The expansion connector 95% just converts pins into pretty shaped connectors that you're familiar with.
-
Thanks for the tip!
-
mostly everything on the expansion board is "brainless", so if it doesn't work, it's probably your main board
-
try playing some audio?
-
Just a FYI
Previously using nmtui-connect and adding a Wifi Config would survive across reboots.
With nightly: Armbian_5.26.170226_Orangepipcplus_Ubuntu_xenial_dev_4.10.0
I find that I must repeatedly use nmtui-connect and even then it creates additional NM connection profiles
# nmcli c
NAME UUID TYPE DEVICE
MyWifi 60caede4-0d67-4e72-9696-6e9f76f9ec0a 802-11-wireless --
MyWifi 1 a4f778ff-e8b9-431c-ad70-98d3e32252bc 802-11-wireless --
No other OS mods (such as /etc/network/interfaces) were made
After nand-sata-install only nmtui-connect was utilized
-
And clearing out that solder bridge... what a pain!
Don't do that!
-
Interestingly enough, hard wiring SD CD to ground and having no SD card will generate constant errors. Right now, it's a bad idea
You will get constant errors
orangepipcplus login: [ 21.186031] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 8, RTO !!
[ 21.199645] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RTO !!
[ 21.209426] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RTO !!
[ 21.219214] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RTO !!
[ 21.228940] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RTO !!
[ 21.238730] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 1, RTO !!
[ 22.385924] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 8, RTO !!
[ 22.396793] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RTO !!
[ 22.404493] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RTO !!
[ 22.412190] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RTO !!
[ 22.419900] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RTO !! -
If Lubuntu and Raspbian use legacy u-boot then most probably it ignores card detect switch (i.e. legacy u-boot on Pine64 still boots fine)
In u-boot and SPL for sunxi devices - no, in kernel - maybe, but card presence can still be detected by polling. But this is a question of describing hardware configuration regardless of its usefullness, so if there is a CD switch of "correct" polarity, it is assumed to work.
Thanks for the info. I temporarily grounded out pin 9 of the SD card slot (pin nearest edge of card slot) and uboot was able to complete.
However, since it was hand-held, the kernel later hung at:
...
Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done.
...
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for root device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Check root= (did the system wait for the right device?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT! UUID=928bf014-2cec-480f-98f2-ae0af0e9a28b does not exist. Dropping to a shell!
Rebooting automatically due to panic= boot argument
[ 67.957787] reboot: Restarting system
So holding CD down a bit longer it later hangs at:
...
Starting Update UTMP about System Runlevel Changes...
[ OK ] Started Update UTMP about System Runlevel Changes.
So I said okay what the heck, let's at least get nand copy going before letting go of CD. So I held CD low until the % progress bar started going and things seem to be progressing along.
Thanks all for the clues. Perhaps in later uboots we can choose to ignore CD... but I think that's a decision best left to the people more closely involved as this is clearly a hardware problem (which happens often enough for OPiPC+ aparrently). Huh... perhaps a more forgiving uboot just for OPiPC+? Bad idea? dunno.
-
This may happen if microSD slot card detection switch is broken (I have the same issue on my Pine64 - I can make it boot by pushing the card to the side when powering on, but I'll probably disable card detect switch or replace the microSD socket in the future). This can be worked around by recompiling the u-boot and changing kernel configuration (fex or DT).
Aha. So in short, the Lubuntu/Rasbian distro uboots don't reference the SD card detect h.switch. But Armbian does (which sounds like a technically good thing to do)
I'm curious, is there a benefit to checking the switch?
Or is it better to perhaps do what they do which is I'm guessing... read and check for success/fail?
-
No luck:
Armbian_5.26.170226_Orangepipcplus_Ubuntu_xenial_dev_4.10.0.img / Armbian_5.26.170226_Orangepipcplus_Ubuntu_xenial_dev_4.10.0.7zU-Boot SPL 2017.01-armbian (Feb 25 2017 - 04:11:39)
DRAM: 1024 MiB
Trying to boot from MMC1MMC: no card present
spl: mmc init failed with error: -123
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###FYI these same SD cards boot fine on other OPiPC+ boards. -
a little easier:
-
Some boards have troubles with early uboot init but this I can only guess since for that I would need to see u-boot console log. There are two things what you can do from here: attach a serial console and see what's going on - where it stops and second: try image from "Night release", which has many imprevements -> https://www.armbian.com/orange-pi-pc-plus
How do I generate this uboot log -> "since for that I would need to see u-boot console log."
I'm grabbing nightly now, so maybe it's auto-enabled.
-
Just a note. I have the same problem with just one of my boards. Here are some logs. I'm downloading nightly now.
https://www.evernote.com/l/AE_Sl4jw96dHSbCCd1bbb-Mml4-CukvFU2Y
-
FYI Replicated this on both the OPi Zero 256 and 512mb version, so it's not a board/model specific issue. Perhaps a SW config issue?
-
Orange Pi Zero - SPI1 - SPI_MOSI - Seems "weak"
SPI_SCLK is Peak-to-Peak 3.3v (no problem)
SPI_MOSI is Peak-to-Peak 165mv (whoa strange! hooked up to the o-scope)
I suspect that MOSI is "dead" in my config since the waveform matches SPI_SCLK almost exactly, so perhaps it's crosstalk or something of that sort.
I think my FEX is good. Anybody else with experience?
Does anyone else experience this problem?
root@orangepizero:/dev# ls -al spi*
crw------- 1 root root 153, 0 Jan 28 12:17 spidev0.0
crw------- 1 root root 153, 1 Jan 28 12:17 spidev1.0
[spi0]
spi_used = 1
spi_cs_bitmap = 1
spi_mosi = port:PC00<3><default><default><default>
spi_miso = port:PC01<3><default><default><default>
spi_sclk = port:PC02<3><default><default><default>
spi_cs0 = port:PC03<3><1><default><default>
[spi1]
spi_used = 1
spi_cs_bitmap = 1
spi_cs0 = port:PA13<2><default><default><default>
spi_sclk = port:PA14<2><default><default><default>
spi_mosi = port:PA15<2><default><default><default>
spi_miso = port:PA16<2><default><default><default>
[spi_devices]
spi_dev_num = 2
[spi_board0]
modalias = "spidev"
max_speed_hz = 33000000
bus_num = 0
chip_select = 0
mode = 0
full_duplex = 1
manual_cs = 0
[spi_board1]
modalias = "spidev"
max_speed_hz = 33000000
bus_num = 1
chip_select = 0
mode = 0
full_duplex = 1
manual_cs = 0
make driver patch - lib/module without full .img?
in Advanced users - Development
Posted
Thank you SteeMan and Werner. I will try out your recommendations.