Jump to content

martinayotte

Members
  • Posts

    3892
  • Joined

  • Last visited

Posts posted by martinayotte

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

  2.  

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

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

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

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

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

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines