Jump to content

selfbg

Members
  • Posts

    12
  • Joined

  • Last visited

Everything posted by selfbg

  1. Yes, but the service will always fail, since there isn't support for H5 protocol in kernel 3.4.
  2. @Igor I've build an image for A20-SOM204 (next), but bluetooth service doesn't load. I guess the code from armbian.build should be moved to armbian.postinst. However I'm not sure how this will work with the existing condition: if [[ $BRANCH != default ]]; then ... fi
  3. I want to override some configurations from $LINUXFAMILY.conf in SOMEBOARD.conf/wip/csc. One way is to provide $SRC/userpatches/sources/$LINUXFAMILY.conf, but I don't like this approach. I want to make these modification permanent. Maybe move the specific configuration from the family file to each board file, but with will not work with big families. Any ideas or comments? Thanks
  4. How is this related to kernel version? The fixup script is executed inside u-boot? Both next and dev branches uses the same u-boot. EDIT: Sorry. I've answer my self.
  5. I've notice today, that fixup scripts are failing, if some parameters are passed. For example: if test -n "${param_spinor_spi_bus}"; then test "${param_spinor_spi_bus}" = "0" && setenv tmp_spi_path "spi@01c05000" test "${param_spinor_spi_bus}" = "1" && setenv tmp_spi_path "spi@01c06000" test "${param_spinor_spi_bus}" = "2" && setenv tmp_spi_path "spi@01c17000" fdt set /soc@01c00000/${tmp_spi_path} status "okay" fdt set /soc@01c00000/${tmp_spi_path}/spiflash status "okay" if test -n "${param_spinor_max_freq}"; then fdt set /soc@01c00000/${tmp_spi_path}/spiflash spi-max-frequency "<${param_spinor_max_freq}>" fi if test "${param_spinor_spi_bus}" = "0" && test "${param_spinor_spi_cs}" = "1"; then fdt set /soc@01c00000/${tmp_spi_path}/spiflash reg "<1>" fi env delete tmp_spi_path fi I get: libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND This is caused because u-boot sets paths without leading zero: => fdt list / / { #address-cells = <0x00000001>; #size-cells = <0x00000001>; interrupt-parent = <0x00000001>; model = "Olimex A20-SOM204-EVB-eMMC"; compatible = "olimex,a20-olimex-som204-evb-emmc", "allwinner,sun7i-a20"; ... soc@1c00000 { }; ... }; => As you can see the path is /soc@1c00000 not /soc@01c00000. Does anyone have noticed this?
  6. I agree that FIT image is the best option. Let's say we drop MMC CD pin. This is no big deal. Then comes USB0 vbus,/drv pins. Lets drop them too. Then SATA pwr pin? My point is that at current state of u-boot there are too much hard-coded variables. Also that there are too much differences between boardX revA, revD, revK, etc... With the help of overlays (it's supported from 2017.11) the work can be reduced, but still don't see how other initialization will be done.
  7. selfbg

    selfbg

  8. For some time there is NAND driver for both SPL and u-boot for Allwinner SoCs. You can check boards/sunxi/README.nand. I'm currently testing this. What I'm thinking is, if this option works fine, should nand-sata-install script to be reworked? Instead of using the old SDK u-boot, mainline spl+u-boot to be packed in the bootloader deb and then written somehow? At this point as I can see only CHIP_pro has this feature enabled.
  9. Hello, I've made patch that should autodetect A20-OLinuXino variant. Currently supported boards by this patch are: A20-OLinuXino-Lime A20-OLinuXino-Lime2 A20-OLinuXino-Micro With their own modifications the count is 14 different configurations. Why this is possible: All boards uses the same DDR freq - 384MHz. The routing is almost the same All the boards have small EEPROM capable of storing the configuration Major differences between the boards includes: 5 different ethernet PHYs Different pins used for USB phys Different pins used for MMC card detect Different pins used for SATA power The procedure is the following: In the SPL the EEPROM is read and verified. If it's OK, the data is stored in the RAM and it's used after the relocation At u-boot start, the memory address is parsed. MMC, USB, SATA and Ethernet are initialized depending on the board. Also depending on the board different .dtb file is passed as fdtfile parameter. Advantages are: One image for all A20-OLinuXino boards Disadvantages User is forced to run some u-boot commands to write configuration in the EEPROM. For example: olimex config write 4614 R 0x1234567. If wrong board id is used this may cause problems with booting and board operation. You can see my branch here. Currently only next branch is "tested". For the default branch the procedure should be basically the same. I'm interested on your opinion? What do you think about this?
  10. Hi, I've tested the images. Manually build micro/lime2 configuration and booted them on board with eMMC. Then transfer file system to eMMC. Both board boot fine from the eMMC. Is this enough? I think other peripherals should behave the same.
  11. So, this is the correct way of enabling the touchscreen?
  12. Hello, I want to use touchscreen on my lcd. To do this I do the following: Compile my own dtbo and load it: /dts-v1/; /plugin/; / { compatible = "allwinner,sun7i-a20"; fragment@0 { target = <&rtp>; __overlay__ { allwinner,ts-attached; }; }; }; Blacklist gpadc modules: blacklist sun4i_gpadc_iio blacklist sun4i_gpadc After reboot the touchscreen is working. However I cannot see what is loading these two modules? Also is there any other way getting working touchscreen? I'm using armbian 5.34 with kernel version 4.13.11.
  13. Hello, I have one question. What about using 2 SPI busses? if test -n "${param_spidev_spi_bus}"; then test "${param_spidev_spi_bus}" = "0" && setenv tmp_spi_path "spi@01c05000" test "${param_spidev_spi_bus}" = "1" && setenv tmp_spi_path "spi@01c06000" test "${param_spidev_spi_bus}" = "2" && setenv tmp_spi_path "spi@01c17000" fdt set /soc@01c00000/${tmp_spi_path} status "okay" fdt set /soc@01c00000/${tmp_spi_path}/spidev status "okay" if test -n "${param_spidev_max_freq}"; then fdt set /soc@01c00000/${tmp_spi_path}/spidev spi-max-frequency "<${param_spidev_max_freq}>" fi if test "${param_spidev_spi_bus}" = "0" && test "${param_spidev_spi_cs}" = "1"; then fdt set /soc@01c00000/${tmp_spi_path}/spidev reg "<1>" fi env delete tmp_spi_path fi With this existing code how I'm supposed to do this? Maybe needs rework?
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines