| 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 ...
|
| 73e9db22 | 06-Jul-2018 |
Hannes Schmelzer <oe5hpm@oevsv.at> |
board/BuR/brppt1: implement more flexible boot process
With this commit we do:
- set the bootdelay in all brppt1 defconfigs to 0, this makes
development easier, since we can break into serial conso
board/BuR/brppt1: implement more flexible boot process
With this commit we do:
- set the bootdelay in all brppt1 defconfigs to 0, this makes
development easier, since we can break into serial console.
- move CONFIG_BOOTCOMMAND from header file to defconfig
- introduce b_mode variable for selecting the final boot-target.
This b_mode represents the boot-switch, which can found on most b&r
targets. On the brppt1 this boot-switch is derived from some gpio and
the bootcounter within the RTC block, making it so possible to force
a boot-target (as example for repair-case).
- refactor the environment for booting new flexible way
primary we want to get some bootscr.img within the mass-storage,
this script then loads everything needed for the boot.
For legacy reason we implement the t30lgcy#x boot targets, booting the
already delivered linux-images.
- make space for the cfgscr within mtdparts on brppt1_nand
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 ...
|
| 1d469866 | 06-Jul-2018 |
Hannes Schmelzer <oe5hpm@oevsv.at> |
board/BuR/brppt1: drop dead code (CONFIG_SPL_OS_BOOT)
The falcon mode was never used on this board, there is also no plan to
use it. So drop this dead code.
Signed-off-by: Hannes Schmelzer <oe5hpm@
board/BuR/brppt1: drop dead code (CONFIG_SPL_OS_BOOT)
The falcon mode was never used on this board, there is also no plan to
use it. So drop this dead code.
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 ...
|
| 95963679 | 06-Jul-2018 |
Hannes Schmelzer <oe5hpm@oevsv.at> |
board/BuR/brppt1: drop LCD-support
On this linux target long time ago the OS is using DRM driver for
handling video output, the pre initialization of u-boot and the display
summary screen is obsolet
board/BuR/brppt1: drop LCD-support
On this linux target long time ago the OS is using DRM driver for
handling video output, the pre initialization of u-boot and the display
summary screen is obsolete. With this patch we drop the LCD-support from
thisd board.
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 ...
|
| 193f6fb9 | 09-Jan-2018 |
Hannes Schmelzer <oe5hpm@oevsv.at> |
board/BuR: drop LCDC clock manipulation from board code
The clock selection is done now from the am335x-fb code, so there is no
more need doing this in the board code.
Signed-off-by: Hannes Schmelz
board/BuR: drop LCDC clock manipulation from board code
The clock selection is done now from the am335x-fb code, so there is no
more need doing this in the board code.
Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
show more ...
|