J.M.

  • Posts

    16
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Applications

Posts posted by J.M.

  1. On 6/22/2020 at 4:55 PM, Werner said:

    Let's take the 5.4 example.

    If you follow the current branch it leads us to megi's orangepi-5.4 branch. If you check the Makefile (https://github.com/megous/linux/blob/orange-pi-5.4/Makefile)

    you will notice that the actual version of this branch is 5.4.18. But when you compile the kernel it is actually 5.4.47 or something like that.

    This means these patches come from Armbian. If you check the patch directory for your board family (https://github.com/armbian/build/tree/master/patch/kernel/sunxi-current)

    you can see that the upstream patches are added here. If you need a very specific kernel version remove or rename the patches you do not need.

    So according to this example, if I want a specific kernel version, let's say the latest version at this moment (which is 5.4.114), do I need to add a patch that's rename the Makefile and edit the sublevel to 114 ?

  2. 16 hours ago, NicoD said:

    For that you build with expert=yes
     

     

    I made videos showing how to do this. 

     

    That's a great video, thanks!

    However, something is still wrong, but I can't tell why.

     

    I've cloned the armbian-build, and ran the compile.sh (I'm on the master branch) and did exactly the same as you did in your video (even choose the same board, just for testing), but no matter what is the configuration I choose, I get this message: 

    [ error ] ERROR in function prepare_host [ general.sh:1052 ]
    [ error ] It seems you ignore documentation and run an unsupported build system: bionic 
     

    After reviewing general.sh:1052 , I understand I must compile it on Ubuntu 20.04, right ? (I ran it on Ubuntu 18.04 - same as you did in your video). 

  3. Hi all,

     

    Which branch or tag should I use if I'm willing to work on the latest stable linux version on Banana Pi M1 ?

    How do I choose between legacy / current / dev, and what are the differences between them ?

    Is there some guide that explain these issues ?

     

    If someone is willing to answer by giving an example, then lets assume I want to build from source kernel 5.10.32 on Banana Pi M1. 

    Thanks in advance

  4. Hi,

     

    I'm trying to work with the CedarX/Cedrus Video Engine (running in Allwinner A20). It works smoothly with my patched FFmpeg; for example:

    ffmpeg -f v4l2 -r 30 -pix_fmt nv12 -video_size 1280x720 -i /dev/video0 -vcodec cedrus264 -pix_fmt nv12 -qp 15 -f rtsp -rtsp_transport tcp rtsp://192.168.10.11/live/test

     

    I need to use pixel format RGB24, but as far as I understand, I'm limited to work with NV12 (or NV16) pixel format.

     

    Does this limitation is due to:

    1. My FFmpeg patch (I think not...)
    2. CedarX/Cedrus driver implementation.
    3. Hardware limitation.

     

    Thanks for the help,

    Joseph

  5. Hi,

     

    I'm trying to work with the CedarX/Cedrus Video Engine (on Allwinner A20). It works smoothly with my patched FFmpeg; for example:

    ffmpeg -f v4l2 -r 30 -pix_fmt nv12 -video_size 1280x720 -i /dev/video0 -vcodec cedrus264 -pix_fmt nv12 -qp 15 -f rtsp -rtsp_transport tcp rtsp://192.168.10.11/live/test

     

    I need to use pixel format RGB24, but as far as I understand, I'm limited to work with NV12 (or NV16) pixel format.

     

    Does this limitation is due to:

    1. My FFmpeg patch (I think not...)
    2. CedarX/Cedrus driver implementation.
    3. Hardware limitation.

     

    Thanks for the help,

    Joseph

  6. Hi,

     

    I'm trying to run with a PREEMPT_RT kernel to get a real-time (lowest latency as possible) performance. 

    But in addition to the PREEMPT_RT patch, I want to make sure the system doesn't go to sleep (or using power save modes) to avoid additional wake-ups latencies (that the PREEMPT_RT patch cannot reduce).

    I've reviewed the AXP209 datasheet and tried to understand if I can somehow disable the system from going to sleep, but I didn't find the answer for that. I do know that register 0x31 can control the entrance to sleep mode if we write '1' to bit-3, but I can't prevent other drivers or applications from doing it.

     

    Question:

    Is there a way to disable the option to control the sleep-mode ?

     

    Thanks

  7. After a short break I just want to update that I’ve managed to enable the i2c-3 on boot. The truth is that it was too simple… (later I’ll explain what was the mistake).

    All I’ve needed to do is:

     

    1.  Update the boot device tree (cache/sources/u-boot/v2019.04/arch/arm/dts/sun7i-a20-lamobo-r1.dts) with:

    &i2c3 {
    	pinctrl-names = "default";
    	pinctrl-0 = <&i2c3_pins_a>;
    	status = "okay";
    };
    • I guess that instead of updating the boot device tree, I could also just update /boot/armbianEnv.txt with:
    overlays=i2c3

     

    2. Update Lamobo_R1_deconfig file with:

    CONFIG_I2C0_ENABLE=y
    CONFIG_I2C1_ENABLE=y
    CONFIG_I2C2_ENABLE=y
    CONFIG_I2C3_ENABLE=y
    • When I just added CONFIG_I2C3_ENABLE=y it didn’t work. I didn’t figure why...

    The awkward reason I failed to do it in the beginning was because I’m using a script that updates my board on remote (without using SD card). But when I did the burning with SD - it worked !!

    The difference between the remote burning script and the burning with SD script is that in the remote script I’m not burning all /dev/mmcblk1, but just /dev/mmcblk1p1 and /dev/mmcblk1p2.

    And now I’m only guessing (so you are all welcome to correct my assumption), that the configuration of the i2c on boot is written into mmcblk1boot, and that is why it didn’t work when I used the remote burning script.

     

    Thanks to all for the help and support.

  8. 23 hours ago, martinayotte said:

    But the ".config" I've provided is "default = no i2c", you need to turn most of those to "=y" instead of "is not set" ...

    First I must to correct my mistake:

    I meant that cache/source/u-boot/v2019.04/configs/Lamobo_R1_defconfig and cache/source/u-boot/v2019.04/.config holds the same configuration.

    (I was afraid that maybe my modifications on Lamobo_R1_defconfig doesn't set on .config)

     

    In both Lamobo_R1_defconfig and .config these are my modifications, but the i2c still doesn't work (or presented on the device tree) on u-boot:

    CONFIG_I2C0_ENABLE=y

    CONFIG_I2C1_ENABLE=y

    CONFIG_I2C2_ENABLE=y

    CONFIG_I2C3_ENABLE=y

    CONFIG_I2C4_ENABLE=y

    CONFIG_DM=y
    CONFIG_DM_I2C=y
    CONFIG_DM_I2C_COMPAT=y

    CONFIG_CMD_I2C=y   

     

    I will keep digging, and share my results after solving the issue. I'm sure it will help to someone else in the future.

    Ideas and suggestions are still very welcome (I'm sure it is possible. I'm not the first one that's trying it).

    Thanks !!

  9. On 12/4/2020 at 3:40 PM, martinayotte said:

    Did you checked all the possible configs in your cache/source/u-boot/v2019.04/.config

     

    By default, "grep -i i2c" is showing :

     

    
    # CONFIG_I2C0_ENABLE is not set
    # CONFIG_I2C1_ENABLE is not set
    # CONFIG_I2C2_ENABLE is not set
    # CONFIG_SPL_I2C_SUPPORT is not set
    # CONFIG_CMD_I2C is not set
    # I2C support
    # CONFIG_DM_I2C is not set
    # CONFIG_SYS_I2C_DW is not set
    # CONFIG_SYS_I2C_IMX_LPI2C is not set
    # CONFIG_SYS_I2C_MXC is not set
    # CONFIG_I2C_EDID is not set

     

     

    i did checked it,

    and configs in your cache/source/u-boot/v2019.04/.config

    and cache/sources/u-boot/v2019.04/arch/arm/dts/sun7i-a20-lamobo-r1.dts

    seems to hold the same configuration...

     

    Perhaps I'm not defining the device tree correct at u-boot ? (this is the same as I did to the device tree in linux - and in linux it work)

     

    &i2c3 {
    	pinctrl-names = "default";
    	pinctrl-0 = <&i2c3_pins_a>;
    	status = "okay";
    };

     

    jkjhk

  10. 8 hours ago, martinayotte said:

    Stop U-Boot using <spacebar> during USB can, then do "printenv" command and check the value of "fdtfile"

    Thanks!


    I did it, and I see that: fdtfile=sun7i-a20-lamobo-r1.dtb
    I've also validate it with ${fdtfile} and it prints sun7i-a20-lamobo-r1.dtb

    I noticed that ${efi_fdtfile} prints nothing. Is that ok?
     

    dm tree prints the following:

     Class     Index  Probed  Driver                Name
    -----------------------------------------------------------
     root         0  [ + ]   root_driver           root_driver
     simple_bus   0  [ + ]   generic_simple_bus    |-- soc@1c00000
     phy          0  [ + ]   sun4i_usb_phy         |   |-- phy@1c13400
     usb          0  [ + ]   ehci_generic          |   |-- usb@1c14000
     usb_hub      0  [ + ]   usb_hub               |   |   `-- usb_hub
     usb          1  [ + ]   ohci_generic          |   |-- usb@1c14400
     usb_hub      1  [ + ]   usb_hub               |   |   `-- usb_hub
     usb          2  [ + ]   ehci_generic          |   |-- usb@1c1c000
     usb_hub      2  [ + ]   usb_hub               |   |   `-- usb_hub
     usb_dev_ge   0  [ + ]   usb_dev_generic_drv   |   |       `-- generic_bus_2_dev_2
     clk          0  [ + ]   sun4i_a10_ccu         |   |-- clock@1c20000
     reset        0  [ + ]   sunxi_reset           |   |   `-- reset
     gpio         0  [ + ]   gpio_sunxi            |   |-- pinctrl@1c20800
     gpio         1  [ + ]   gpio_sunxi            |   |   |-- PA
     gpio         2  [ + ]   gpio_sunxi            |   |   |-- PB
     gpio         3  [ + ]   gpio_sunxi            |   |   |-- PC
     gpio         4  [ + ]   gpio_sunxi            |   |   |-- PD
     gpio         5  [ + ]   gpio_sunxi            |   |   |-- PE
     gpio         6  [ + ]   gpio_sunxi            |   |   |-- PF
     gpio         7  [ + ]   gpio_sunxi            |   |   |-- PG
     gpio         8  [ + ]   gpio_sunxi            |   |   |-- PH
     gpio         9  [ + ]   gpio_sunxi            |   |   `-- PI
     serial       0  [ + ]   ns16550_serial        |   |-- serial@1c28000
     serial       1  [   ]   ns16550_serial        |   |-- serial@1c28c00
     serial       2  [   ]   ns16550_serial        |   |-- serial@1c29c00
     eth          0  [ + ]   eth_designware        |   `-- ethernet@1c50000
     clk          1  [ + ]   fixed_rate_clock      |-- clk@1c20050
     clk          2  [ + ]   fixed_rate_clock      |-- clk@0
     clk          3  [   ]   fixed_rate_clock      |-- clk@1
     clk          4  [   ]   fixed_rate_clock      `-- clk@2
    

     

    I  don't see any i2c bus in here.

    However i2c bus give: 

    Bus 0:  twsi0

     

    Is that make sense?

     

  11. 22 hours ago, martinayotte said:

    Be aware that U-Boot and Kernel don't use the same DT file, you need to verify the one used in U-Boot build ...

    Yes, of course. My I've modified the DT file that is located here: ../../../armbian/cache/sources/u-boot/v2019.04/arch/arm/dts/sun7i-a20-lamobo-r1.dts

    Anyway to verify the u-boot does use this DT file ?

  12. On 11/30/2020 at 4:19 AM, sfx2000 said:

     

    Light up a single bus - if you're looking for device detect - otherwise don't do this, and let the kernel sort it once booted with device tree...

     

    What problem are you trying to solve?

    I need to use an external LED device (not the LEDs that are on the board), and I need to be able control this device both from boot and linux (and in order to control this device I'm must enable the i2c3 bus).

    The weird thing is that at the boot stage I do have access to i2c0 bus (which is used to control the AXP209), although I can't see it the device tree with "dm tree" (however i2c0 and i2c3 are defined in "sun7i-a20-lamobo-r1.dts").

     

    Any ideas how to enable the i2c3 bus ?

    (I though about trying to do the same as implemented with i2c0 for the AXP209, but I still didn't figure it out)

  13. On 11/29/2020 at 4:22 PM, martinayotte said:

    Did you added also CONFIG_CMD_I2C=y to recompile U-Boot with I2C related commands ?

    Yes I did, but the compilation still fail. I guess I'm using the wrong configuration.

    However, when I add CONFIG_SPL_DM=y, the compilation seems to work but later fails on:

    u-boot-spl section `.data' will not fit in region `.sram'
    region `.sram' overflowed by 820 bytes

     

    Maybe I should try a different approach.

    I've noticed that if I run "dm tree", I don't see the I2C in the device tree,

    but if I call "i2c bus", I get:

    Bus 0:  twsi0
    and if I call "i2c dev 0", I get: 

    Setting bus to 0
    Valid chip addresses: 34

     

    However, when I call "i2c dev 1" (or 2, or 3...), I get:

    Invalid bus 1

    i2c - I2C sub-system
     

    Something here is weird. I don't see I2C0 (or any other I2C bus) at the device tree, but I do see it with the command "i2c dev 0".

    So why is that I can't see the other bus (1, 2 or 3) with "i2c dev" command ?

  14. Hi,

     

    I'm trying to enable the I2C at the U-BOOT stage, but so for with no success.

    I'm using Lamobo-R1 (Allwinner A20), but I guess that general tips from similar boards (Banana PI etc.) are still very welcome.

     

    I read these posts, and tried what has been suggested here, but with no success :(

    I2C control in u-boot: Orange Pi Zero

    enable i2c at u-boot for NanoPi Neo2

    u-boot with I2C

     

    This is what I've done so far:

    1. I've modified the u-boot device tree to enable the I2C bus (I did the same with the kernel device-tree, and here it does work!!)
    2. I've added to Lamobo_R1_deconfig the next configurations:

      CONFIG_I2C0_ENABLE=y

      CONFIG_I2C1_ENABLE=y

      CONFIG_I2C2_ENABLE=y

      CONFIG_I2C3_ENABLE=y

      CONFIG_I2C4_ENABLE=y

    3. Add new overlays to /boot/armbianEnv.txt: 
      overlays=i2c1 i2c2 i2c3 i2c4
    4. Since it didn't help, I've added the following (as suggested from the posts) to Lamobo_R1_deconfig, but it causes compilations issues - I believe I have a collision between configurations, but I didn't figure out what configuration cause the collision.

               CONFIG_SUNXI=y
               CONFIG_DM=y
               CONFIG_DM_I2C=y
               CONFIG_DM_I2C_COMPAT=y      

     

    * I'm running ARMBIAN 5.98 stable Ubuntu 18.04 LTS 4.19.152-sunxi

     

    Any Ideas, suggestions ?

    Thanks,

    Joseph

  15. Hi, 

     

    I need to use the i2c in the u-boot stage.

    I've added a patch that enables this i2c bus in the device-tree,

    and when I run this command (just for example): sudo i2cset -y 2 0x1b 0x1 0xf

    AFTER the boot stage it seem to work.

    However when I try this command IN THE boot stage, I get: Unknown command 'i2cset' - try 'help'.

    1. I guess I'm trying to use 'i2cset' in a too early stage - any idea how to control the i2c in the u-boot stage or how to make 'i2cset' available at the u-boot stage ?

    2. Since 'i2cset' doesn't work in the u-boot stage, I don't know if the i2c is enabled at this stage (I know it's enabled after boot) - how can I check it ?

     

    Thanks,

    Joseph