Jump to content

awef

Members
  • Posts

    45
  • Joined

  • Last visited

Posts posted by awef

  1. 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.

  2. 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)

  3. 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?)

  4. 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)

     

  5. 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

  6.  Interestingly enough, hard wiring SD CD to ground and having no SD card will generate constant errors.  Right now, it's a bad idea :P

     

    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 !!
  7. 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.

  8. 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?

  9. 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.7z
    U-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.
  10. 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.

  11. 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


×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines