selfbg Posted November 20, 2017 Posted November 20, 2017 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?
zador.blood.stained Posted November 30, 2017 Posted November 30, 2017 Unfortunately this approach has some drawbacks, at least from Armbian perspective. First, it's a quite large patch that has to be adapted to every u-boot release (once every 2 months). Adding this patch means somehow merging several existing board configurations, and dropping this patch in the future means that some boards or board specific features may stop working. Second, I'm pretty sure that u-boot maintainers won't be happy with this approach either. Unfortunately device identification wasn't implemented at board design time like it was done by Hardkernel (soldering different resistors and reading ADC value in u-boot) or by Solid-Run (soldering or not soldering resistors to pull up or down unused GPIO pins and reading them in u-boot). 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.
selfbg Posted December 1, 2017 Author Posted December 1, 2017 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.
zador.blood.stained Posted December 1, 2017 Posted December 1, 2017 1 minute ago, selfbg said: 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? No. MMC CD pin is handled by the SPL, and since we are parsing the u-boot header to get the boot device it is kind of redundant IMO. Other things that you mentioned are handled by the u-boot proper and they can be read from DT in the future, especially since there is a movement to convert existing u-boot drivers to DM and AFAIK non-DM drivers are not accepted anymore. 4 minutes ago, selfbg said: My point is that at current state of u-boot there are too much hard-coded variables. Yes, that's why I said "ideally" - and that's exactly my point regarding upstreaming your current work - in the current state it probably won't be accepted, but moving several existing drivers (USB, SATA, pinctrl?) to DM will take time and dedication.
Recommended Posts