It is very similar to Aurora 420, even onlp shared object part from
Aurora 620 considered as example when porting support for 420 (see
the diff between 620 and 420 to find differences if necessary).
Main difference in onlp is that we have four LEDs (1 SYS STAT, 2 PSU
and 1 for FAN), 7 thermal (4 for two PSU, 1 for MAC, 1 for front and
1 for rear) and 6 fans (4 for board, 2 for PSU).
New 420, as well as 620 and 720 requires upstream ONIE to install
correctly. Install and boot tested with ONIE "master-201805301609".
Signed-off-by: Sergey Popovich <sergey.popovich@ordnance.co>
Following enhancements come with this change:
o New ASTERION board
o New/updated sysfs interface to:
+ detect rxlos (rxlos1..rxlos4)
+ set tx_disable (tx_disable1..tx_disable4)
+ detect tx_fault (tx_fault1..tx_fault4)
+ read/update sfp_copper eeprom
Signed-off-by: Sergey Popovich <sergey.popovich@ordnance.co>
According to IANA assignments for enterprise Netberg company has number
50424, not 47294. Correct this to match one in ONIE.
Signed-off-by: Sergey Popovich <sergey.popovich@ordnance.co>
fan_count in module instead of defining
by FAN_TYPE_NO_EEPROM/FAN_TYPE_EEPROM before
Add: Orange LED support to common code.
Add: manage_leds_type3 to support future systems
with 12 FAN's in 6 modules and using Orange led instead of Red.
FIX: remove unnecessary LED color2 from led_colors_map
FIX: change FAN LED description for systems with 2 fans pre module
Signed-off-by: Oleksandr Shamray <oleksandrs@mellanox.com>
The transmitter disable bytes are standardized by the MSA and managed by the upper layer using the dev_writeb() routines when
appropriate based on module type.
Writing the transmitter enable bytes are not appropriate for CR cables and will generate write errors so attempting to
emulate this behavior without knowing the type of module is also troublesome.
The 'links' section specifies symbolic links which should be added to the package in key : value format.
The key is the source of the link. It must be exist in the filesystem already (as part of the 'files' section)
and be relative to the root of the filesystem.
The value is the name of the link, and can be relative or absolute to the final filesystem.
For example, given that a package produces the real binary "/usr/bin/foobar" and you want /usr/bin/foobar-link -> /usr/bin/foobar
it will be specified as follows:
links:
/usr/bin/foobar : /usr/bin/foobar-link
