+/* The following table includes the supported baudrates */ +#define CONFIG_SYS_BAUDRATE_TABLE \
- {300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400}
All these configs L2/timer included are already in zynq-common.dtsi. I think I told you to include this file here. If there is something what you don't want to enable for your board then let's fix it but I really don't like to c&p setting which is already written. It is purely duplication for no reason. This file should include zynq-common.dtsi and take configuration from that file. If there is something board specific then we should find a way how to fix this.
this looks like to be the last big challenge to get rid with my new board ;-)
I think you mean zynq-common.h
Yes, you told me using it ... more than one time ... but i'm still very unhappy with this zynq-common.h since it is very overloaded and trimmed to the existing eval-boards.
Maybe we have a chance to split the zynq-common.h up into at least two parts where having at one side all soc-specific stuff (various base-addresses, caching, timer, stack, ....), the bare-minimum and at the other side all "application-specific", meaning distro-default, bootcommand, filenames, boot-devices, load-addresses ...
This would give us the opportunity having boards like the existing eval-boards and boards like mine which loving the bare minimum.
This sounds like c&p thing which should be quite fast. Feel free to do it and we can discuss if this is ok or not. Especially where that split should be and why some macros should be moved there or there. Till now if there was any need we have added #ifndef XXX and redefine it in board file. From u-boot project point of view if there is real need to change these things then we should look at moving them to Kconfig first and current values should be default that you can simply rewrite it.
+/* Environment */ +#define CONFIG_SYS_AUTOLOAD "no"
I have not a problem with listing things like this because it takes time to move things to Kconfig but copying baseaddresses and setting for SPL doesn't make sense.
no glue at the moment. pls a bit more explanation.
Normally when you convert one option to Kconfig then you should fix all boards which takes a lot of time and a lot of effort because multiple targets need to be checked. It is easier just to introduce Kconfig and limit it's scope for certain SoC and let others to extend it till everything is converted and limitation can be removed.
I will be checking that "board" specific macros one by one to see what we can do with it.
Thanks, Michal