selfbg
-
Posts
12 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by selfbg
-
-
-
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
-
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.
-
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?
-
12 hours ago, zador.blood.stained said:
How could this be implemented better in my opinion? Using SPL FIT to store multiple DT files in the FIT image. All hardware differences should be described in DT, some things (like MMC CD pin) could be dropped. SPL FIT framework already has support for customizing logic for selecting DT files (i.e. based on DRAM size for Pine64/Pine64+) so you could use a different function that reads an EEPROM for this.
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. -
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.
-
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?
-
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.
-
So, this is the correct way of enabling the touchscreen?
-
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.
-
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?
[RFC 001] Changes for boards and features implementing
in Armbian build framework
Posted
Yes, but the service will always fail, since there isn't support for H5 protocol in kernel 3.4.