• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 1066 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM3352: Crashing U-Boot debug output

Richard McAleer
Expert 1485 points
Part Number: AM3352

Tool/software: Linux

Hi
I have taken over a project that is using a board based closely on the beaglebone black.

I am in the process of trying to bring this project up to date with the most recent TI-SDK
(which uses linux-4.4.19+gitAUTOINC+db0b54cdad-gdb0b54cdad/ and u-boot-2016.05+gitAUTOINC+2f757e5b2c-g2f757e5b2c/ )

At present it has an old U-boot that succeeds sufficiently to enable me to load a kernel and DTB via NFS. The output of the old U-Boot looks as though it has a few issues; but manages to get through to a command line. From here I am trying to load a new U-boot via TFTP
This looks to launch then almost immediately crash:

U-Boot# setenv autoload no; dhcp; setenv serverip 10.255.0.148; tftp 0x80800000 u-boot.bin; go 0x80800000
link up on port 0, speed 100, full duplex
BOOTP broadcast 1
DHCP client bound to address 10.255.3.255
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 10.255.0.148; our IP address is 10.255.3.255
Filename 'u-boot.bin'.
Load address: 0x80800000
Loading: ############################
         1.7 MiB/s
done
Bytes transferred = 397594 (6111a hex)
## Starting application at 0x80800000 ...

U-Boot 2016.05-00119-gb5d9570-dirty (Feb 27 2017 - 16:08:43 +1100)

       Watchdog enabled
I2C:   ready
DRAM:  512 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - MMC init failed, using default environment

Could not get board ID.
<ethaddr> not set. Validating first E-fuse MAC
Net:   data abort
pc : [<9ff851c8>]          lr : [<9ff526eb>]
reloc pc : [<808331c8>]    lr : [<808006eb>]
sp : 9ef29428  ip : 00000061     fp : 00000017
r10: 8084eae8  r9 : 9ef31ed8     r8 : 9ffeca58
r7 : 9ff9efc0  r6 : 9ef31fb0     r5 : 44e10600  r4 : 9ff9d050
r3 : 4030b847  r2 : 9ff8dbb6     r1 : 9ff8dbb0  r0 : ffffffff
Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32
Resetting CPU ...

resetting ...

This smells to me like there is either something defined in my DTS that should not be (or conversely that there is something fundamental missing).
Is anyone able to shed any light on how I might use the debug that has been output to track down where the culprit is hiding?

Thanks for any help.
Best regards,
Richard


for interet the output from the older U-Boot looks like:

U-Boot SPLLL 2014.07-00107-gd28f2b9-dirty (Nov 22 2016 - 11:44:08)
Could not probe the EEPROM; something fundamentally wrong on the I2C bus.
Could not get board ID.
ddr params.
Could not probe the EEPROM; something fundamentally wrong on the I2C bus.
Could not get board ID.
Setting pinmux
bbb lt fake
mux done
Could not probe the EEPROM; something fundamentally wrong on the I2C bus.
Could not get board ID.
SDRAM init
ddr init fake start
ddr init fake end
board init
malloc
timer
Could not probe the EEPROM; something fundamentally wrong on the I2C bus.
Could not get board ID.
board init 600
board not bone
PIMC success
tps 0
tps 1
tps 2
tps 3
tps 4
tps 5
osc success
board init end
boot device
boot debug device
U-boot load start
U-boot load end %d


U-Boot 2014.07-00107-gd28f2b9-dirty (Nov 22 2016 - 12:36:41)

I2C:   readyEZ
DRAM:  DRAM config
512 MiB
init trace
start serial
MMCEZ:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Could not probe the EEPROM; something fundamentally wrong on the I2C bus.
Could not get board ID.
late init.
Net:   <ethaddr> not set. Validating first E-fuse MAC
Could not probe the EEPROM; something fundamentally wrong on the I2C bus.
Could not get board ID.
late init.
Enable rmii
Existing Phy not found
phy id 508209 0 -1 cpsw
New Phy 0 found
usb eth init.
usb eth init end.
cpsw, usb_ether
Hit any key to stop autoboot:  0 
U-Boot# <INTERRUPT>
U-Boot#

  • 0
    TI__Guru**** 393215 points
    Hi,

    The software team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    TI__Guru 55345 points

    Hello Richard,

    Please, pass the kernel to U-Boot. Is it your purpose to pass a U-Boot to U-Boot?
    U-Boot# setenv autoload no; dhcp; setenv serverip 10.255.0.148; tftp 0x80800000 zImage.bin; go 0x80800000

    Best regards,
    Kemal

  • 0 in reply to Kemal R. Shakir
    Expert 1485 points
    Hi Kemal

    Yes at present I am trying to debug a new U-boot by launching it from a working (but older) U-boot. (Unfortunately I have not got JTAG access to this board).

    I have been able to successfully boot a kernel image via TFTP in the manner you suggest.

    I was hoping someone might have suggestions as to how to use the debug from the U-Boot crash to narrow down the options for what is causing the problem. I suspect if I have a look for an elf with symbols I might be able to work out where the program counter had been left.

    For now I have been able to scatter printfs thoughout the initial code and it looks like I have an issue with code attempting to read from EEPROM during the Ethernet initialisation. It would useful to have been able to direct myself towards this from the dump that was shown. I will investigate further tomorrow (both the root problem and how I might have tracked it down more efficiently)

    Thanks again for the suggestion.

    All the best,
    Richard
  • 0 in reply to Richard McAleer
    TI__Guru 55345 points

    You can hard code the EEPROM ID memory layout as in this post and add a #define DEBUG line to include/configs/ti_armv7_common.h in order to get additional debug messages.

  • 0 in reply to Kemal R. Shakir
    Expert 1485 points

    Thanks for the suggestion Kemal

    I'll certainly enable as much debug as I can for the time being.

    I've tracked down the issue to hardware: the EEPROM read was failing silently (the debug is only output on a an error code < 0)

    It looks as though some of the subsequent code would handle this (the EEPROM info not being populated) but eventually there was the presumption of data in board_is_icev2 through its call to  board_ti_get_rev() which was returning null as the EEPROM read had failed. 

    All the best,

    Richard