Jump to content

martinayotte

Members
  • Posts

    3892
  • Joined

  • Last visited

Posts posted by martinayotte

  1. Ok ! I passed the main hurdles ... The worst one was that many obsolete time32 helpers that are now definitively gone/erased, but we still need them for out-of-the-tree wifi drivers, so I had to put them back using timekeeping32.patch.

    I will do few more test images for my different Allwinner boards, then I will be ready for commit ...

  2. 44 minutes ago, Pongotto said:

    But I don't understand why if i use the Orange Pi Ubuntu microSD the priority became the microSD.

    Maybe this is because of partition scheme which probably different. Armbian is using a single partition and have a /boot folder which contains kernel/dtb/uinitrd.

    44 minutes ago, Pongotto said:

    I don't have a serial cable to test.

    Any hobbyist should have at least one, they are so cheap ($0.99), and useful for debugging. Personally, I've around 15 of them, so I don't need to disconnect it when debugging another board.

    44 minutes ago, Pongotto said:

    Do you suggest to clean the eMMC before I launch the Armbian microSD?

    If you don't care about losing it current content, Yes, you could erase the U-Boot of the eMMC, at least the first MB, using "dd if=/dev/zero of=/dev/mmcblk2 bs=1024 count=1024"

  3. 5 minutes ago, Pongotto said:

    I'm not very lucky with OPi4 and Armbian this time

    As I said above about eMMC priority is still true for any Rockchip SoC.

    Did you tried using Serial Debug to stop U-Boot and force it to boot from SDCard ?

  4. 7 minutes ago, Pongotto said:

    My board ignores the microSD card.

    What is installed in you eMMC ?

    Because eMMC has priority over SDCard ...

    If the U-Boot currently present in eMMC is able to be stopped by keystroke on Serial Debug port, you can do "mmc list" to figure out the SDCard slot number, and do "setenv devnum <N>" followed by "run mmc_boot", it will then boot from SDCard .

  5. 14 hours ago, shaddow501 said:

    in order to install version 5.6 do I need to set lib.config to the orange-pi-5.6 ?

    Ahahah ! :lol:

    It is not as simple as that ...

    4 hours ago, shaddow501 said:

    I have idea why  moving fast to newer kernels without fixing the issues with the older kernels...

    Why are you come to this conclusion ? Armbian folks are not responsible for all the issues, most comes from upstream ...

  6. 9 hours ago, shaddow501 said:

    You have answered you wanted to help. I think that less work from you since you can see the source and issues you ask for.

     

    If you dont want to help, dont.

    thanks for the support so far.

    I'm happy to help, and I will do, but if you're too lazy to look at output/debug/compilation.log for details and search for "error:" , I won't do it for you !!!

     

    Would you help me to figure out why have troubles of switching Armbian Dev from 5.5.y to 5.6.y ? I've working on that task since more than a week !!!

     

  7. 34 minutes ago, renky said:

    Are there commands such that you can verify if spi has set?

    What do you mean ?

    34 minutes ago, renky said:

    On orange pi one it says crw. On raspberry pi 0 it says crw-rw. A raspberry pi

    0 can flash the flashchip of a thinkpad t400. Can the orange pi one do it, if

    the orange pi one says crw and not crw-rw?

    As long as you are executing as "root", you don't need to have "crw-rw" flags ...

  8. 1 hour ago, Arjan van Vught said:

    Many observations

    Some new ones : I've done tests on my OPiPC2, OPiZeroPlus2, OPi+2E, OPiOne and OPiLite which also don't have a external 32768 crystal, drifts are seen only on H3 but not on H5 ...

    Also, the H3 RTC drift is late/slow compared to H2+ of the OPiZero previously tested which were ahead/fast.

  9. 43 minutes ago, Arjan van Vught said:

    See the remarkable output below

    That strange, you drifts is really bigger than mines, mines are 1 or 2 or 3 seconds per 2 minutes ...
    I've added "hwclock -w" before the loop and get the following results (not that I forgot to add UTC to "date") :

     

     

     


    17:30:39
    12:30:39
    ---------------
    17:32:41
    12:32:39
    ---------------
    17:34:40
    12:34:39
    ---------------
    17:36:43
    12:36:39
    ---------------
    17:38:46
    12:38:39
    ---------------
    17:40:48
    12:40:39
    ---------------
    17:42:51
    12:42:39
    ---------------
    17:44:54
    12:44:39
    ---------------
    17:46:42 <---- drift correction
    12:46:39
    ---------------
    17:48:44
    12:48:39
    ---------------
    17:50:47
    12:50:39
    ---------------
    17:52:50
    12:52:39
    ---------------
    17:54:53
    12:54:39
    ---------------
    17:56:55
    12:56:39
    ---------------
    17:58:43 <---- drift correction
    12:58:39
    ---------------
     

     

     

    Yes, it seems that a background process is doing "hwclock -w" in background, maybe every 12 minutes, as you said, most probably the ntp or chrony service ...

    BTW, I've the same test on my OPi3 which actually has an external crystal, no drifts at all ...

     

  10. 2 hours ago, Arjan van Vught said:

    In fact, this URL is completely obsolete, it is a snapshot of code from 4 years ago ... :P

    The current Mainline is here : https://github.com/torvalds/linux/blob/master/drivers/rtc/rtc-sun6i.c

    But they still don't check the LOSC_AUTO_SWT_STA_REG register ...

     

    EDIT: I've done few tests with measurement at 8 minutes intervals, it is loosing/gaining around 8 seconds / 8 minutes, but since it is both loosing/gaining, overall the average should be good.

  11. 10 minutes ago, Arjan van Vught said:

    Skipping a second here.

    That is not really a good way to test, since your loop is a bit more than 1 second due to execution of previous lines.

    Do a sleep of 120 seconds or even bigger, such 1 hour, and calculate the number of seconds elapse between the two devmem2.

  12. 9 minutes ago, shaddow501 said:

    WHY IS IT SO COMPLICATED TO CREATE PREVIOUS KERNEL,UBOOT and so on? WHY???

    Because it is a snapshot in time, it hard to revert to builds from 8 months ago.

     

    Do you still have that old 5.1.15 images ?

    Would it help if I provided one of my old Pine64 images ? Although it is not BananaPi-M4, maybe it will still boot since it is also an A64 ...

  13. 18 minutes ago, Arjan van Vught said:

    So the check here https://github.com/armbian/linux/blob/sun8i/drivers/rtc/rtc-sunxi.c#L512 is basically wrong. The CTRL tells what has been set, and then AUTO_STA really tells the status.

    You're right ! I don't see those warning in my dmesg ... something fishy there ... But, at least, it still seems to work in my case.

     

    EDIT: Oh ! But rtc-sunxi.c doesn't even look at LOSC_AUTO_SWT_STA_REG, it is only validate that write to SUNXI_LOSC_CTRL_REG was successful ... hmmm !

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines