4dcbccf7 | 17-Oct-2018 |
Denis Zalevskiy <denis.zalevskiy@ge.com> |
board: ge: Move VPD reading to the vpd_reader
Merge functionality duplicated in bx50v3 and mx53ppd: the logic is the same except that process_vpd is called at different phases. Also read_vpd could e
board: ge: Move VPD reading to the vpd_reader
Merge functionality duplicated in bx50v3 and mx53ppd: the logic is the same except that process_vpd is called at different phases. Also read_vpd could end up in error, so there is no VPD data in this case - it shouldn't be processed.
Signed-off-by: Denis Zalevskiy <denis.zalevskiy@ge.com> Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.com>
show more ...
|
f767a4e8 | 15-Oct-2018 |
Dan Cimpoca <dan.I.cimpoca@ge.com> |
board: ge: bx50v3: fix initialization of i2c bus0
I2C bus 0 was not initialized correctly. There is an offset between i2c index and the structure number of pad info. So i2c bus 0 can be in an incons
board: ge: bx50v3: fix initialization of i2c bus0
I2C bus 0 was not initialized correctly. There is an offset between i2c index and the structure number of pad info. So i2c bus 0 can be in an inconsistent state.
This problem become visible on B{4,6}50v3 with the CPUC HW watchdog enabled. Sometimes when the CPUC HW watchdog interrupted the boot process, U-Boot was not able to read VPD from I2C/EEPROM and the system failed to boot up again, because a device connected to that bus was stuck in data transfer state (from previous boot attempt) and there was no method to recover (struct mxc_i2c_bus::idle_bus_fn was not set) courtesy of incorrect initialization.
Signed-off-by: Dan Cimpoca <dan.I.cimpoca@ge.com> Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.com>
show more ...
|
9aa7c157 | 15-Oct-2018 |
Ian Ray <ian.ray@ge.com> |
board: ge: bx50v3: b{4,6}50v3 modeline
The b{4,6}50v3 kernel framebuffer console requires a modeline otherwise the LVDS panel shows garbage.
Signed-off-by: Ian Ray <ian.ray@ge.com> Signed-off-by: F
board: ge: bx50v3: b{4,6}50v3 modeline
The b{4,6}50v3 kernel framebuffer console requires a modeline otherwise the LVDS panel shows garbage.
Signed-off-by: Ian Ray <ian.ray@ge.com> Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.com>
show more ...
|
51a42bea | 25-Apr-2018 |
Ian Ray <ian.ray@ge.com> |
board: ge: bx50v3: remove redundant targets
This replaces TARGET_GE_B{4,6,8}50V3 with common TARGET_GE_BX50V3. The boards are identified automatically at runtime.
Signed-off-by: Ian Ray <ian.ray@ge
board: ge: bx50v3: remove redundant targets
This replaces TARGET_GE_B{4,6,8}50V3 with common TARGET_GE_BX50V3. The boards are identified automatically at runtime.
Signed-off-by: Ian Ray <ian.ray@ge.com> Signed-off-by: Nandor Han <nandor.han@ge.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
show more ...
|
7927ff7a | 25-Apr-2018 |
Ian Ray <ian.ray@ge.com> |
board: ge: bx50v3: use VPD instead of compile-time checks
B{46}50v3s have an internal LCD that needs to be configured, in comparison with B850v3 which has only external displays.
Use VPD instead of
board: ge: bx50v3: use VPD instead of compile-time checks
B{46}50v3s have an internal LCD that needs to be configured, in comparison with B850v3 which has only external displays.
Use VPD instead of `CONFIG_TARGET_GE_B{4,6,8}50V3' compile-time checks to correct initialize video based on the monitor type.
Signed-off-by: Ian Ray <ian.ray@ge.com> Signed-off-by: Nandor Han <nandor.han@ge.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
show more ...
|
5e604e2c | 25-Apr-2018 |
Nandor Han <nandor.han@ge.com> |
board: ge: bx50v3: detect the monitor type by reading VPD earlier
Move the VPD reading earlier in order to establish the monitor type as soon as possible.
The configuration of the specific environm
board: ge: bx50v3: detect the monitor type by reading VPD earlier
Move the VPD reading earlier in order to establish the monitor type as soon as possible.
The configuration of the specific environment variables needs to be done later after the environment is configured.
Signed-off-by: Nandor Han <nandor.han@ge.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
show more ...
|
5ce9a1c8 | 25-Apr-2018 |
Nandor Han <nandor.han@ge.com> |
board: ge: bx50v3: unify two switch statements
Simplify process_vpd() by unifying the switch statements handling product specific configurations.
Signed-off-by: Nandor Han <nandor.han@ge.com> Signe
board: ge: bx50v3: unify two switch statements
Simplify process_vpd() by unifying the switch statements handling product specific configurations.
Signed-off-by: Nandor Han <nandor.han@ge.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
show more ...
|
886678fc | 10-Jan-2018 |
Nandor Han <nandor.han@ge.com> |
board,ge,bx50v3 - rtc time validation
Validate the time at startup: - in case rtc error add to kernel command line RTC_ERROR - clamp date to 1-Jan-2036
Signed-off-by: Nandor Han <nandor.han@ge.co
board,ge,bx50v3 - rtc time validation
Validate the time at startup: - in case rtc error add to kernel command line RTC_ERROR - clamp date to 1-Jan-2036
Signed-off-by: Nandor Han <nandor.han@ge.com> Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
show more ...
|
6d656495 | 10-Jan-2018 |
Martyn Welch <martyn.welch@collabora.co.uk> |
board: ge: bx50v3: Enable hardware watchdog
Enable the hardware watchdog on bx50v3 to cause it to reset in the event the board hangs.
Configure GPIO_9 pin as WDOG1_B so that a watchdog timeout resu
board: ge: bx50v3: Enable hardware watchdog
Enable the hardware watchdog on bx50v3 to cause it to reset in the event the board hangs.
Configure GPIO_9 pin as WDOG1_B so that a watchdog timeout results in a full system reset.
The watchdog is used and reconfigured by systemd approximately 1.7 seconds into boot. Adding a few seconds for U-Boot and a few more seconds as a safety margin.
Note that the PCIe controller is _not_ put back into a safe state prior to board reset. This is a problem if board reset is implemented as CPU reset.
Signed-off-by: Ian Ray <ian.ray@ge.com> Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
show more ...
|
2850645c | 10-Jan-2018 |
Hannu Lounento <hannu.lounento@ge.com> |
board: ge: bx50v3: program MAC address to I210
There are two I210s on the b850v3 and one on the b450v3 and b650v3. One is connected to Marvell 88e6240 which is already programmed.
Follow the flow d
board: ge: bx50v3: program MAC address to I210
There are two I210s on the b850v3 and one on the b450v3 and b650v3. One is connected to Marvell 88e6240 which is already programmed.
Follow the flow documented in doc/README.enetaddr: set the enet[0-9]*addr environment variable and let the driver program the hardware.
The mapping from the driver's index to the environment variable's name is documented in README: Note for Redundant Ethernet Interfaces. It is assumed that eth_devices for the controllers on the board are always indexed in the same order.
The environment variables are removed after programming the hardware because the variables seem to influence MAC addresses also after U-Boot. Specifically the MAC address of FEC (MC interface) would be incorrectly set: 'ethaddr', which maps to the first I210 chip and is set to I210's default address read from the driver by eth_write_hwaddr in eth_legacy.c because the variable is undefined (not set even by bx50v3.c), would result in the eth0 interface's MAC address to be set to I210's default address.
Signed-off-by: Hannu Lounento <hannu.lounento@ge.com> Signed-off-by: Ian Ray <ian.ray@ge.com> Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
show more ...
|
cf678b31 | 10-Jan-2018 |
Martyn Welch <martyn.welch@collabora.co.uk> |
board: ge: bx50v3: move FEC MAC address programming to driver
Instead of programming the hardware directly in the board implementation, follow the flow documented in doc/README.enetaddr: set the ene
board: ge: bx50v3: move FEC MAC address programming to driver
Instead of programming the hardware directly in the board implementation, follow the flow documented in doc/README.enetaddr: set the enet[0-9]*addr environment variable and let the driver program the hardware.
This avoids duplicating the implementation as it already exists in the driver (drivers/net/fec_mxc.c: fec_set_hwaddr).
The mapping from the driver's index to the environment variable's name is documented in README: Note for Redundant Ethernet Interfaces. It is assumed that eth_devices for the controllers on the board are always indexed in the same order, i.e. FEC always has the index 2.
The FEC driver does *not* set the flag Set MAC Address on Transmit (bit set_eth0_mac_address used to do but this is unnecessary as the Linux networking stack fills in the MAC address.
Signed-off-by: Hannu Lounento <hannu.lounento@ge.com> Signed-off-by: Ian Ray <ian.ray@ge.com> Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
show more ...
|