zador.blood.stained

Super moderator
  • Content Count

    3633
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Everything posted by zador.blood.stained

  1. From Armbian documentation (https://docs.armbian.com/User-Guide_Allwinner_overlays/) Most in-circuit and GPIO based interfaces (SPI, I2C, I2S, …) don’t have a mechanism for detecting and identifying devices connected to the bus, so Linux kernel has to be told explicitly about the device and its configuration details. While Device Tree is a way of describing hardware configuration to the kernel, Device Tree overlays are a way for modifying the DT in order to provide the kernel and kernel drivers with details about external devices or to activate interfaces disabled by default. What do we want? We want to add Device Tree overlays for the onboard interfaces and tested external devices so that they appear in future mainline Armbian images. This means that activating this type of hardware will not require recompiling the Device Tree or will require compiling just the overlay file which will be compatible with future kernel updates. What kind of help do we expect? We want people to participate in making and testing overlays for the hardware that they have. Participation requirements: An A10, A20 or H3 board that can boot the current mainline kernel Serial console adapter for getting the u-boot logs if they are needed Extra SD card to use for booting the nightly/beta images I2C, SPI or I2S (only A10 and A20 based boards since I2S driver is not present on H3 yet) device that you can connect to the board and that requires either generic driver (like SPIdev) or a special driver (available in the mainline kernel), with an exception of custom built boards that don't have commercially available compatible alternatives and devices that don't have in-tree kernel drivers. Some generic Linux knowledge (i.e. how to obtain a dmesg log, how to check file contents) At least a basic understanding of the hardware that you have and how does it integrate into Linux. For example I have no idea how to calibrate a resistive touch screen even if I can write a DT overlay for it. Please note that some hardware limitations (i.e. number of SPI chip selects, missing SPI DMA support) may affect possibility of supporting some devices What overlays are already available? Please check the README in the subdirectory for your SoC in the overlays repository: https://github.com/zador-blood-stained/sunxi-DT-overlays-armbian
  2. zador.blood.stained

    testers wanted Testers wanted: sunxi Device Tree overlays

    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/sound/soc/sunxi/sun4i-i2s.c
  3. zador.blood.stained

    Anything like linux-sunxi.org for Rockchip?

    http://opensource.rock-chips.com/wiki_Status_Matrix
  4. zador.blood.stained

    OPI R1 Setup a SPI slave in U-Boot

    I tested it on OPi Zero (basically the same device) with u-boot master branch and it passed the loopback test. defconfig changes: diff --git a/configs/orangepi_zero_defconfig b/configs/orangepi_zero_defconfig index e5a4c1d9fc..39528026a6 100644 --- a/configs/orangepi_zero_defconfig +++ b/configs/orangepi_zero_defconfig @@ -9,10 +9,19 @@ CONFIG_DRAM_ODT_EN=y CONFIG_SPL_SPI_SUNXI=y CONFIG_NR_DRAM_BANKS=1 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set +# CONFIG_USE_BOOTCOMMAND is not set CONFIG_CONSOLE_MUX=y # CONFIG_CMD_FLASH is not set +CONFIG_CMD_SF=y +CONFIG_CMD_SF_TEST=y +CONFIG_CMD_SPI=y CONFIG_DEFAULT_DEVICE_TREE="sun8i-h2-plus-orangepi-zero" +CONFIG_MTD=y +CONFIG_DM_SPI_FLASH=y CONFIG_SUN8I_EMAC=y -CONFIG_USB_OHCI_HCD=y +CONFIG_SPI=y +CONFIG_DM_SPI=y +CONFIG_SOFT_SPI=y CONFIG_USB_EHCI_HCD=y +CONFIG_USB_OHCI_HCD=y CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y DT changes: diff --git a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts index 0bc031fe4c..40b078723d 100644 --- a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts +++ b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts @@ -59,6 +59,8 @@ /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */ ethernet0 = &emac; ethernet1 = &xr819; + spi0 = &softspi0; + spi1 = &softspi1; }; chosen { @@ -89,6 +91,26 @@ gpio = <&pio 0 20 GPIO_ACTIVE_HIGH>; }; + softspi0: soft-spi0 { + compatible = "spi-gpio"; + status = "okay"; + gpio-sck = <&pio 2 2 0>; + gpio-mosi = <&pio 2 0 0>; + gpio-miso = <&pio 2 1 0>; + cs-gpios = <&pio 2 3 0>; + num-chipselects = <1>; + }; + + softspi1: soft-spi1 { + compatible = "spi-gpio"; + status = "okay"; + gpio-sck = <&pio 0 14 0>; + gpio-mosi = <&pio 0 15 0>; + gpio-miso = <&pio 0 16 0>; + cs-gpios = <&pio 0 13 0>; + num-chipselects = <1>; + }; + wifi_pwrseq: wifi_pwrseq { compatible = "mmc-pwrseq-simple"; reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>; Partial console log: => echo loopback wire disconnected loopback wire disconnected => sspi 1:0 16 1234 0000 => echo loopback wire connected loopback wire connected => sspi 1:0 16 1234 1234 => dm tree Class Index Probed Driver Name ----------------------------------------------------------- root 0 [ + ] root_driver root_driver simple_bus 0 [ + ] generic_simple_bus |-- soc mmc 0 [ + ] sunxi_mmc | |-- mmc@1c0f000 blk 0 [ ] mmc_blk | | `-- mmc@1c0f000.blk mmc 1 [ + ] sunxi_mmc | |-- mmc@1c10000 blk 1 [ ] mmc_blk | | `-- mmc@1c10000.blk phy 0 [ + ] sun4i_usb_phy | |-- phy@1c19400 usb 0 [ + ] ehci_generic | |-- usb@1c1a000 usb_hub 0 [ + ] usb_hub | | `-- usb_hub usb 1 [ + ] ohci_generic | |-- usb@1c1a400 usb_hub 1 [ + ] usb_hub | | `-- usb_hub usb 2 [ + ] ehci_generic | |-- usb@1c1b000 usb_hub 2 [ + ] usb_hub | | `-- usb_hub usb 3 [ + ] ohci_generic | |-- usb@1c1b400 usb_hub 3 [ + ] usb_hub | | `-- usb_hub clk 0 [ + ] sun8i_h3_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 eth 0 [ + ] eth_sun8i_emac | |-- ethernet@1c30000 serial 0 [ + ] ns16550_serial | |-- serial@1c28000 gpio 10 [ + ] gpio_sunxi | `-- pinctrl@1f02c00 gpio 11 [ + ] gpio_sunxi | `-- PL spi 0 [ + ] soft_spi |-- soft-spi0 spi_generi 0 [ + ] spi_generic_drv | `-- generic_0:0 spi 1 [ + ] soft_spi |-- soft-spi1 spi_generi 1 [ + ] spi_generic_drv | `-- generic_1:0 clk 1 [ + ] fixed_rate_clock |-- osc24M_clk clk 2 [ + ] fixed_rate_clock |-- osc32k_clk clk 3 [ ] fixed_rate_clock `-- internal-osc-clk =>
  5. zador.blood.stained

    OPI R1 Setup a SPI slave in U-Boot

    There is no SPI driver for H3 in the "main" u-boot (CONFIG_SUN4I_SPI is for older SoCs), but software SPI (CONFIG_SOFT_SPI) should work if configured correctly.
  6. zador.blood.stained

    Improve 'Support over Forum' situation

    I think you meant "expect the user to read and not just mindlessly tick checkboxes that prevent them from posting their question"?
  7. zador.blood.stained

    Need help in understanding a i2c configuration effect

    It's not defined in DT and is created dynamically by the DRM subsystem.
  8. There is an old upstream mainline kernel issue that never was fixed: https://groups.google.com/forum/#!topic/linux-sunxi/Ar9A_OYzk1Q And we can't pull random patches without proper long term testing because they may break more things than they fix.
  9. zador.blood.stained

    Just a test

    First I would change and reword the current implementation - use something like "I understand that not providing requested information will reduce the chance to solve my issue" (current one with the possibility of getting banned doesn't correlate with the forum rules), explain why providing armbianmonitor -u info is needed (I checked a few new new threads and they don't have it), deal with old images that try to upload the info to sprunge.us (i.e. by linking an instructions for updating the script without updating the BSP), ideally deal with the possibility that ix.io may stop to provide its free service one day too, etc. I'll just leave the public download statistics link here. I'm not an expert on hosting prices in EU, but you need to take into account both the storage space and monthly traffic. Edit: clarification - this is daily stats that don't include torrent traffic.
  10. zador.blood.stained

    ERROR in function compile_uboot

    This is not a networking issue but a repository and protocol limitation, as I remember git.denx.de supports shallow clones only via the git:// protocol
  11. zador.blood.stained

    Just a test

    Don't get me wrong, I'm not a fan of the current form implementation, but it's only the first iteration. Since "Technical support" section is mostly used as a bug tracker and we wouldn't be able to support a standalone bug tracker / task management system, adding data collection form to the forum is a step in the right direction.
  12. zador.blood.stained

    Just a test

    Unfortunately "getting information" != "answering the same questions and requesting even the basic info again and again and again". For example, threads like this one would have 1 reply with a simple answer - eMMC CSD checks for revision 8 were fixed more than a year ago. It took 5 posts to confirm that this is the culprit and it is still impossible to tell which kernel version (I mean kernel compilation date) is used due to missing dmesg from "armbianmonitor -u". Funny thing is that this thread was created after the addition of the new information collection form, so we may as well make providing armbianmonitor -u output mandatory with 2 exceptions in dedicated subforums - devices without network connection and devices that failed to boot completely. Applying your knowledge and experience while at the same time learning something new is fun, and it can happen when you are talking with a person who at least tries to understand what he is doing and who respects your time by trying to provide requested (and even more than requested) information. Reading 90% of threads in the "Allwinner H2/H3" section made by people who expect performance and software quality of at least a $200 PC like a J5005 based NUC7 from a $20 board like Orange Pi PC is definitely not fun for me. YMMV. Unfortunately supporting low end (by price) boards attracts their target audience aka people for whom even the Raspberry Pi is too expensive.
  13. It's a good idea, but it still leaves a question of loading u-boot and kernel/script.bin/initrd initially. If SPL doesn't want to boot from available SD card this won't help much... ... unless FEL is used to "bootstrap" the process. Just for experiment I compiled sunxi-fel for Windows and installed libUSB driver in single click with Zadig tool. So we could provide an application/set of scripts for Linux and Windows to do this.
  14. zador.blood.stained

    Improve 'Support over Forum' situation

    Perhaps. @zador.blood.stained? Not sure about this. - the second tab on Github project is called "Issues", not "Discussions" or "all stuff", and it has "Open"/"Closed" statuses more suitable for tracking actual bugs/issues than discussing build script usage - this would make it impossible to easily move framework related discussions from the forum to the right place
  15. zador.blood.stained

    NanoPC T4

    Looks like we got an upstream DT for the T4: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/rockchip?id=e7a095908227fb3ccc86d001d9e13c9ae2bef8e6
  16. zador.blood.stained

    H5 FEL/NFS test mode?

    No. Root on NFS should not be hard by itself (similar to H3, loading u-boot and kernel from SD). FEL support, on the other hand, is not implemented in the mainline u-boot for 64-bit chips, so it requires either using prebuilt u-boot binaries or adding patches to u-boot and rewriting the build script.
  17. zador.blood.stained

    H5 FEL/NFS test mode?

    There is no FEL support for 64-bit targets in the build script.
  18. zador.blood.stained

    Clearfog[Pro]mikroBus UART 5V tolerant

    According to the SoC HW specifications MPP pins are not 5V tolerant.
  19. zador.blood.stained

    Is Mali GPU driver available in Mainline for H3?

    Last time I tried it I didn't get it past the low FPS issue described in this thread. The only documentation I can point is this repository which contains some instructions that may or may not work with the kernel currently available in Armbian.
  20. zador.blood.stained

    Is Mali GPU driver available in Mainline for H3?

    Who is the customer of who here? AFAIK most Chinese makers sell these boards not much above the BOM cost, and even Allwinner tries to cut their cost as much as possible, i.e. by not purchasing Mali driver licenses that are useless for them with Android: https://irclog.whitequark.org/linux-sunxi/2017-12-07#20730568; (timestamp 07:39) It only helps running the kernel-side driver. It still requires a userspace closed-source driver of a specific type (framebuffer, Xorg, Wayland) and applications that can use this driver, i.e. you need a special shim (xf86-video-armsoc) to make use of Mali with X.org.
  21. zador.blood.stained

    board support - general discussion / project aims

    And also Terms of Use / Community guidelines should be linked somewhere in plain sight. Right now it can be accessed when registering, and even there it is not clearly shown as a link. IMO it should be on the top menu row as it is more important than i.e. Privacy policy that exists mostly for legal reasons. Edit: It's also on the bottom bar, but it will be hidden after you click "Accept", looks like by a specific cookie. Edit 2: Now that I'm looking at those (Registration Terms specifically) - they should be a numbered list instead of a bullet list, and we should probably add a new rule "Try to stay on topic defined by the starting post or developer posts in the thread. Off-topic posts that derail the discussion may be hidden, moved or deleted."
  22. zador.blood.stained

    OrangePi One v. 1.1 not booting

    Changing DT will have no effect this early (in SPL), SPL relies on CONFIG_MMC0_CD_PIN configuration option. And at least previous versions printed "mmc: no card present" when trying to access a card with broken CD pin.
  23. zador.blood.stained

    FEL mass storage or writing images directly to eMMC

    As I wrote in the issue, you need zImage and matching uInitrd with a custom premount script from the repository. There are no guides on how exactly to create them. The only thing that makes it easier is that mentioned eMMC CSD revision patch is already included in the Armbian patchset, but this assumes that CSD revision 8 is the problem which is impossible to confirm without kernel logs.
  24. zador.blood.stained

    FEL mass storage or writing images directly to eMMC

    This does not depend on u-boot (and it doesn't have much checks for eMMC revisions anyway). Most likely this could be solved by patching the CSD check: https://github.com/zador-blood-stained/fel-mass-storage/issues/5
  25. zador.blood.stained

    RK3288 device tree overlays

    At least the vanilla mainline u-boot "fdt apply" requires OF_LIBFDT_OVERLAY (which there is set on the per board basis, but it's easier to "select" or "imply" it from ARCH_ROCKCHIP like here: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi/enable-DT-overlays-support.patch