AM5749: Custom Bootloader for U-Boot/Linux Kernel

Hi Alex,

Instead of writing a separate SBL and then jumping from SBL to SPL which in itself
is a complicated exercise why not implement the functionality in SPL?

If it i just a bunch of register writes to do the link training then something like:

do_board_detect can call your custom function in board/ti/am57xx/board.c
in the u-boot directory. This gets called pretty early so i believe that is what you want.

- Keerthy

That sounds absolutely ideal!!! (sorry for the exclamations, but I am just super happy if it turns out to be this easy :) )

It pretty much is just a series are register initialization writes, and during the training phase, you just sit there and spin polling a status register indicating when the training is done.  Assuming the do_board_detect() doesn't have some sort of governing timeout value, then this should work.

It'll be a couple of days until I am ready to explore this awesome solution of yours.  I'll report back then if I'm successful or if I need more help.  Thanks!

Hi Keerthy,

I am now at the point that I have my proprietary board up and going, and I have my u-boot project (from your Yocto-based SDK) compiling and whatnot where I can modify code and rebuild MLO, u-boot.img, u-boot-spl.bin, etc, but I have run into a bit of a snag which you can hopefully help me with.

This may be irrelevant, but this custom PCIe card of mine is originally based on your AM5728 EVM reference design (and maybe partly on the AM5749 IDK), and I think on those I would run into the same problem.

So, for reference, I am following your (TI's) steps for debugging the SPL and U-Boot as outlined on your Wiki:

http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_U-Boot.html?highlight=uboot#uboot-spl-debugging-tips

The problem I run into is two-fold (with a third problem looming).

1. If I put a spin loop in the do_board_detect() call in the SPL (as outlined in the Wiki's instructions), I guess like with your EVM, the power registers (or something) are not getting initialized in time, so the processor  automatically powers itself off.  How do I prevent that?  It seems to be a chicken-and-egg problem because the emulator does not have enough time to connect to the processor before the processor shuts down, so even if I could use a GEL script or something to configure the registers, I couldn't run it on connect because I can't connect.  So inside do_board_detect() seems to be a bad spot to hook into, so where could I hook into so that the processor is initialized enough to not automatically shut itself off?
2. Again, following the instructions outlined in your Wiki above, if I try to load the u-boot image's symbols (while sitting at the u-boot prompt), I get an error from CCS that it can't determine the target type.  What's up with that?
3. (looming issue) The wiki above mentions a watchdog timer that needs to be disabled or else the connection will disconnect, and just vaguely states, "See GEL files..."  Well, for SPL/U-Boot debugging, there are specifically no GEL files (as they would interfere with the initialization process), so specifically which GEL file (for an AM5749 target) should I go look at?

Thanks!

Alex

EDIT:  Issue (1) above is the "PMIC auto-off after seven seconds" issue as described in your AM572x GP EVM Hardware Setup guide.  The guide says to connect to the target immediately after power to connect in time before the auto-shutdown, but as I stated, that's still not enough time.  (Yes, I'm using an XDS560v2 emulator, not a slower XDS100 or XDS200.)

Alex,

Thanks for the detailed answers. I understood the problem. Now before i suggest the right place
to do PCIe related register writes i want to know by what time frame this is expected to be done?

Ex: within 1S of boot or 3S of boot?

Based on that i can try to figure out a good place to add your code.

Thanks,
Keerthy

The sooner the better I would think.  It needs to be up and waiting by the time BIOS (on the host computer) goes out and attempts to enumerate all the devices on the PCIe bus.

Edit:  As a starting point, I'd be happy just to know where the point is that all the baseline components (PMIC registers [obviously[, CPU speed, DDR, and even UART maybe [but not required]) have been initialized.

It's been a week (minus 12 hours).  Any update on this?

Alex,

Apologies for the long silence. I recommend adding the code just before jumping to u-boot from MLO.

[2020-06-11 09:41:04.102] U-Boot SPL 2019.01-g2bd8328999-dirty (Jun 11 2020 - 09:39:53 +0530)
[2020-06-11 09:41:04.118] DRA762-GP 1.0 ABZ package
[2020-06-11 09:41:04.118] no pinctrl state for default mode
[2020-06-11 09:41:04.502] Trying to boot from MMC1
[2020-06-11 09:41:04.502] no pinctrl state for default mode
[2020-06-11 09:41:04.502] Lding Environment from FAT... OK
[2020-06-11 09:41:04.566] Jumping to U-Boot
[2020-06-11 09:41:04.566] loaded - jumping to U-Boot...

This happens within < 1S of boot.

Function: board_init_r
File: common/spl/spl.c

Custom PCIe setup function to be called just before:
debug("loaded - jumping to U-Boot...\n");
 
I put an infinite while loop before that i did not observe any reset of PMIC.

Could you try to insert your custom function there just before jumping to u-boot.

Best Regards,
Keerthy