MityDSP-L138F Boot issue, I2C0
Added by Jon Cox about 1 year ago
I'm an electrical engineer working on the design of a system using the MityDSP SoM - in particular, the L138-FI-325-RC.
We are noticing an issue with the device booting properly only on some of our carrier boards - we have high confidence that the SoM module itself is OK, as it will boot normally when placed in a different carrier board. We have also swapped the MicroSD Flash card used to store our kernel to verify the kernel image integrity as well. So, it seems very likely that something on our carrier board is causing the SoM module to fail boot.
We have probed the power rails supplying the SoM board, as well as the 3.3V and 1.2VCore rails on the SoM and these appear OK. The POWER GOOD LED (D4) is also lit on functional and non-functional setups.
However, we notice that in a working setup the DONE LED will switch on once the system has properly booted.
In our non-functional setup, the DONE LED (D1) will slowly float to ON over a period of 2-3 seconds...the voltage drop over this LED is 1.9V when ON. This seems like the SoM is attempting to boot and gives up / goes to a failed boot state.
Probing via the UART terminal, it seems that the terminal stops printing at the kernel load from MicroSD Flash - we don't see a terminal interrupt in U-Boot.
We did notice that removing the other I2C devices on the I2C0 line via depopulating the level translator fixed this issue, so it seems that something is interrupting the I2C0 access for the two I2C devices on the SoM (RAM and PMIC).
Question: is there a way to modify the boot process to not allow these external I2C devices to interfere with the SoM I2C devices? Apologies if this is a naive question...we are trying to avoid board modifications.
Thanks!
JC
Replies (1)
RE: MityDSP-L138F Boot issue, I2C0 - Added by Michael Williamson about 1 year ago
Hi JC,
The low level boot software (first stage, user boot loader, UBL) reads the EEPROM on the I2C0 bus to determine the model number, which includes information needed for initializing the DDR (e.g., the size of the DDR is needed, etc.). If the UBL is not able to determine the DDR configuration, it may not properly initialize the DDR, and so you're going to have a lot of problems running anything with the processor...
In addition, the PMIC is accessed by the kernel in order to support adjusting the core voltage level when clocking the ARM processor above 300 MHz. You can potentially work around that by limiting the max CPU frequency supported by the kernel.
If you can, I would recommend moving your I2C devices to a different bus (or even to spare FPGA pins and using a soft I2C core in the FPGA) if they are interfering with access to the I2C0 devices on the SOM.
If you don't have address conflicts (see the datasheet, the I2C0 reserved addresses should be outlined there), perhaps you need to adjust your pullup resistors on the level translator or choose a different translator device. We have had some headaches with level translators locking up the bus if not designed properly (is it a true buffer translator, or a FET based translator?).
With regards,
Mike
