| fbc7c7de | 06-Jul-2018 |
Hannes Schmelzer <oe5hpm@oevsv.at> |
board/BuR/brppt1: convert brppt1 boards to driver model
- add a devicetree for each variant (mmc, spi, nand)
- drop unneeded code from board and bur/common
- drop unneeded stuff from config header f
board/BuR/brppt1: convert brppt1 boards to driver model
- add a devicetree for each variant (mmc, spi, nand)
- drop unneeded code from board and bur/common
- drop unneeded stuff from config header files
- minor adaptions to be compliant with driver model (requesting gpio,..)
- harmonize the commandset over all brppt1 targets
Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
show more ...
|
| d63f7130 | 06-Jul-2018 |
Hannes Schmelzer <oe5hpm@oevsv.at> |
board/BuR/common: refactor ft_board_setup(...)
On other OS, not one provided by B&R, it is not guaranteed that there
are factory-settings within a devicetree. So we must not treat the
absence of the
board/BuR/common: refactor ft_board_setup(...)
On other OS, not one provided by B&R, it is not guaranteed that there
are factory-settings within a devicetree. So we must not treat the
absence of them as error.
Further we've the fact that on different version of the device-tree
files there are different namings of the factory-settings, we consider
this with searching for an alternative name.
changing things as following:
- don't treat as error if the bootloader version cannot written into
devicetree.
- since the naming of the factory-settings are different in different
versions of the provided device-tree we search for the alternate name
"/fset"
Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
show more ...
|
| 96cf89f8 | 06-Jul-2018 |
Hannes Schmelzer <oe5hpm@oevsv.at> |
board/BuR/common: fix PMIC mpu-pll setup
If a board-code calls the pmicsetup(u32 mpupll) with a mpupll value
!= 0 it wants to force some frequency with the value provided by mpupll.
Setting up 1 GH
board/BuR/common: fix PMIC mpu-pll setup
If a board-code calls the pmicsetup(u32 mpupll) with a mpupll value
!= 0 it wants to force some frequency with the value provided by mpupll.
Setting up 1 GHz is wrong here.
Nobody did take notice about that yet, since every board calls this
function with zero.
Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
show more ...
|
| 2930941a | 06-Jul-2018 |
Hannes Schmelzer <oe5hpm@oevsv.at> |
board/BuR/common: remove interface Label from summary screen
This interface names may vary over different products, to consider this
fact we replace the interface label "IF1" and "IF2" on the summar
board/BuR/common: remove interface Label from summary screen
This interface names may vary over different products, to consider this
fact we replace the interface label "IF1" and "IF2" on the summary
screen with some more generic wording "MAC1" and "MAC2".
Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
show more ...
|
| e2259704 | 06-Jul-2018 |
Hannes Schmelzer <oe5hpm@oevsv.at> |
board/BuR/common: make CONFIG_LCD optional
Since we're going to drop LCD-support on brppt1 boards, we have to make
this stuff here optional and remove the #error path.
We also move out the ft_board
board/BuR/common: make CONFIG_LCD optional
Since we're going to drop LCD-support on brppt1 boards, we have to make
this stuff here optional and remove the #error path.
We also move out the ft_board_setup(...) from this #ifdef because
there's no relationship with the LCD-code and on the other hand this is
still needed in future even with LCD-support off.
Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
show more ...
|
| dc36b657 | 06-Jul-2018 |
Hannes Schmelzer <oe5hpm@oevsv.at> |
board/BuR/common: drop simple-framebuffer setup
The linux systems running on the brppt1 targets are using modern DRM
drivers since long time ago. Further we are going to drop the LCD
support complet
board/BuR/common: drop simple-framebuffer setup
The linux systems running on the brppt1 targets are using modern DRM
drivers since long time ago. Further we are going to drop the LCD
support completely on this board, so the simple-framebuffer setup
becomes obsolete.
Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
show more ...
|