Jump to content

J.M.

Members
  • Posts

    16
  • Joined

  • Last visited

Everything posted by J.M.

  1. 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. 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: My FFmpeg patch (I think not...) CedarX/Cedrus driver implementation. 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: My FFmpeg patch (I think not...) CedarX/Cedrus driver implementation. 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. 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. 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. 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. 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. 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. 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: 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!!) 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 Add new overlays to /boot/armbianEnv.txt: overlays=i2c1 i2c2 i2c3 i2c4 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
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines