• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 1134 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.

Need support for booting Linux on AM335x custom board.

Manuel Martinez Guillen1
Intellectual 270 points
Other Parts Discussed in Thread: TPS65217

Hi,

We just begin to evaluate our first AM335x custom board. After a scare because we crossed SDA and SCL on I2C0 (big mistake resolved crossing the damping resistors suggested in the last ERRATA doc) we finally saw the 'C' chars printed by the debug uart. By the way: specially thanks to BISER who gave us a lot of support in the hardware designing stage.

Well, this what we're done until now without getting a Linux booted from MMC0:

1. We tried to boot the Android image. It didn't work because uboot hasn't found the magic number in our EEPROM.

2. We tried to programme the magic number using the starterware diagnostics. It didn't worked. Not sure but I think it's because the "page write size" of our EEPROM is different: the script reads right but writes wrong.

3. We patched the eeprom_read() function to fill the ID structure. It didn't worked: uboot loads the kernel image in RAM but when the kernel starts the processor goes to reset or hang w/o printing anything.

4. We wrote the ID in our EEPROM "by hand" using uboot and run the starterware diagnostics. DDR3 diagnostics are right for different configurations: 256MB w/ termination res, 256MB w/o term. res. and 512MB w/ term. res. So, in principle, we discard a memory issue.

5. Finally we have tried to boot again the Android image with the ID already written. But uboot still not recognizing the "magic number". How is possible that the diagnostic image accepts the ID and not the Android image???.

Our hardware is a SOM based on the starter kit and on the carrier board is only installed the power supply and debug/jtag connectors. Is the starter kit kernel looking for some other hardware that makes the processor hang/reboot?

We know that we should to use the jtag as soon as possible but we'd like to read the first opinion/advise of someone from TI.

Regards,

Manuel.

  • 0
    Intellectual 270 points

    Hello again,

    We have compiled the kernel en debug mode and this is the output that we can see in console:

    -----------------------------------------------------------------

    U-Boot SPL 2012.10 (Apr 02 2013 - 16:13:54)
    OMAP SD/MMC: 0
    reading u-boot.img
    reading u-boot.img


    U-Boot 2012.10 (Apr 02 2013 - 16:13:54)

    I2C: ready
    DRAM: 256 MiB
    WARNING: Caches not enabled
    MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
    Using default environment

    Net: cpsw
    Hit any key to stop autoboot: 0
    SD/MMC found on device 0
    reading uEnv.txt

    184 bytes read
    Loaded environment from uEnv.txt
    Importing environment from mmc ...
    Running uenvcmd ...
    reading uImage

    2070608 bytes read
    reading board.dtb

    10121 bytes read
    ## Booting kernel from Legacy Image at 80200000 ...
    Image Name: Linux-3.8.4
    Image Type: ARM Linux Kernel Image (uncompressed)
    Data Size: 2070544 Bytes = 2 MiB
    Load Address: 80008000
    Entry Point: 80008000
    Verifying Checksum ... OK
    ## Flattened Device Tree blob at 80f80000
    Booting using the fdt blob at 0x80f80000
    Loading Kernel Image ... OK
    OK
    Loading Device Tree to 8fe65000, end 8fe6a788 ... OK

    Starting kernel ...

    data abort
    pc : [<80367104>] lr : [<80367143>]
    sp : 80561164 ip : 80560168 fp : 80560168
    r10: 80366320 r9 : 80366a9e r8 : 8fe65000
    r7 : 00000e05 r6 : 80560170 r5 : 8056017c r4 : 00000020
    r3 : 8056017c r2 : 49020000 r1 : 80560180 r0 : 00000055
    Flags: nzCv IRQs off FIQs on Mode SVC_32
    Resetting CPU ...

    resetting ...

    U-Boot SPL 2012.10 (Apr 02 2013 - 16:13:54)
    OMAP SD/MMC: 0
    reading u-boot.img
    reading u-boot.img

    ..............and so on....

    -----------------------------------------------------------------

    Unfortunately we don't get yet make our jtag (jlink pro) work right so it's is difficult to debug. We hope someone can give us a hint. By the way: is not a main hardware issue (soc, ddr, mmc or pmic) since I just boot  the Adaneo's WCE7 demo and I can see the touchscreen calibration app in a LCD.

    Regards, 

  • 0 in reply to Manuel Martinez Guillen1
    Expert 1925 points

    At least you're getting the bootloader going!  Are you trying to use an initrd (because the "device tree blob" is not used on my unit)?  I started with the stock EZSDK linux tree, then simply commented/adjusted the code slightly to select my board's basic features (TPS65217 with some adjustments for the C variant, removing EEPROM checks, selecting DDR3 support, selecting pin muxes simiar to my board, etc.).  Then build/boot that with minimal changes and see what happens.

    As a side-note, I still get kernel crashes if I remove all the unneeded board-code for some reason...haven't had a chance to figure it out yet.  But using the above method I was able to get an initial kernel working.  Then I proceeded to add functionality as I went.

    Also, I recommend creating a copy of the stock am335x-evm board file for your use and add a Makefile/Kconfig entry for it as a replacement for the stock file.  This way you will keep the stock file present for comparison (and for running on the EVK boards if needed).  However, if you have trouble, just start editing the stock file until you can boot.

    Finally, you are getting a data abort, so can you describe briefly what changes you made to your kernel?  Data aborts are usually alignment errors, or accesses to bad memory locations.  Did you ensure that you selected ARCH=arm when building the kernel?  And what toolchain did you use?

  • 0 in reply to David Paden
    Intellectual 270 points

    Hi,

    Thanks by the support David. As the original TI's image didn't work for us, now we're using a mainline kernel generated with buildroot. We have enabled the following kernel option:

    CONFIG_OMAP_RESET_CLOCKS=y

    Now the kernel is booting right. The trouble now is that the JTAG doesn't work.

    Best regards!