8d3fcb5e | 11-Sep-2011 |
Valentin Longchamp <valentin.longchamp@keymile.com> |
POST: add new memory regions test
This test is similar to the actual POST memory test but quicker and far less complete. It checks the address and data lines and then only tests some regularly place
POST: add new memory regions test
This test is similar to the actual POST memory test but quicker and far less complete. It checks the address and data lines and then only tests some regularly placed sub regions of the RAM. This can be useful when we want to test the RAM but we do not have enough time to run the full memory test.
The POST memory test code was rearranged in order to avoid code duplication between the two tests but the memory test functionnality remains the same.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com> Signed-off-by: Holger Brunck <holger.brunck@keymile.com> Ackey-by: Mike Frysinger <vapier@gentoo.org>
show more ...
|
4204298d | 02-Jun-2011 |
Heiko Schocher <hs@denx.de> |
post, memorytest: add support for none powerpc archs
change bd->bi_memsize to gd->ram_size, as this is defined on all archs, so this post test can used on none powerpc archs too.
Signed-off-by: Hei
post, memorytest: add support for none powerpc archs
change bd->bi_memsize to gd->ram_size, as this is defined on all archs, so this post test can used on none powerpc archs too.
Signed-off-by: Heiko Schocher <hs@denx.de> cc: Wolfgang Denk <hs@denx.de> cc: Mike Frysinger <vapier@gentoo.org>
show more ...
|
f6f7395e | 10-May-2011 |
Mike Frysinger <vapier@gentoo.org> |
post: new nor flash test
This adds a simple flash test to automatically verify erasing, writing, and reading of sectors. The code is based on existing Blackfin tests but generalized for everyone to
post: new nor flash test
This adds a simple flash test to automatically verify erasing, writing, and reading of sectors. The code is based on existing Blackfin tests but generalized for everyone to use.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
show more ...
|
9d921f19 | 22-Oct-2010 |
Peter Tyser <ptyser@xes-inc.com> |
post/i2c: Add ability to ignore I2C devices
Add the ability to not report an I2C POST error for a set of given I2C addresses on bootup. This is useful for cases when a device may or may not be pres
post/i2c: Add ability to ignore I2C devices
Add the ability to not report an I2C POST error for a set of given I2C addresses on bootup. This is useful for cases when a device may or may not be present, and neither case is considered an error. For example:
- Some form factors such as XMC and Compact PCI Express have an I2C EEPROM whose address changes based on geographical address. Eg installed in one slot its EEPROM address is, 0x50, in another its 0x51, etc. This allows multiple devices to have their EEPROMs present on the same I2C bus. Thus the I2C devices present for an XMC or CPCIe card depend on if and where other cards are installed in the same system.
- Some cards have optional I2C devices. Eg one hardware build configuration has different I2C devices than another and software can't determine if the optional device should be present or not.
- Some cards have optional daughtercards with I2C devices on them.
- I2C EEPROMs address range depends on their size. Its possible to support differently size EEPROMs by only probing the EEPROM's base address and ignoring the other addresses that are impacted by its size.
A new CONFIG_SYS_POST_I2C_IGNORES define has been added which specifies a list of I2C addresses for the I2C POST to ignore.
Signed-off-by: Peter Tyser <ptyser@xes-inc.com> Acked-by: Heiko Schocher <hs@denx.de> Acked-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
show more ...
|
9f949c9a | 22-Oct-2010 |
Peter Tyser <ptyser@xes-inc.com> |
post/i2c: Don't probe address 0
According to the I2C specification device address 0 is the "general call address", ie a broadcast address. The I2C specification states that the format of a general
post/i2c: Don't probe address 0
According to the I2C specification device address 0 is the "general call address", ie a broadcast address. The I2C specification states that the format of a general call uses at least 2 bytes, which U-Boot's probing routine does not adhere to.
Not probing device address 0 will prevent possible issues with devices that accept general calls. Additionally, this change shouldn't reduce POST coverage since each I2C device should still be accessed via its own, unique address.
Signed-off-by: Peter Tyser <ptyser@xes-inc.com> Acked-by: Heiko Schocher <hs@denx.de> Acked-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
show more ...
|