SiP: SoC dependent RAM init

[LeSpocky]

The SAMA5D2 SiP variants ATSAMA5D27C-D5M and ATSAMA5D27C-D1G have the same pin/ball layout and are mostly the same, but differ only in RAM attached, so it is possible to use one or the other on a PCB (we did that already by accident).

Those chips can be distinguished by reading chip id from CIDR register, the values are SAMA5D27C_D1G_EXID and SAMA5D27C_D5M_EXID for this example. The bootstrap could do matrix and memory init (or is there more?) based on the actual variant found. However currently the menu only allows to select one specific memory size, there's no flexibility.

Would it be possible to extend the bootstrap in a way it could detect drop-in compatible SoC variants and act depending on what was detected?

[ehristev]

Yes, I think what you are saying is possible. However it's not implemented and not in the current roadmap. We will be happy to try out a patch if you decide to implement this. I will keep it in mind for future development if you decide not to work on it. So one question though: when you select in bootstrap the MPU, the config, etc, you can choose the right memory amount and type? or are there any issues ?

[LeSpocky]

Thanks for your feedback so far.

So one question though: when you select in bootstrap the MPU, the config, etc, you can choose the right memory amount and type? or are there any issues ?

I can select those, no issues. So there's no urgent demand here.

After reading the code again today, I noticed some things, more or less related to the problem field:

• In the 3.x branch there is sama5d2_lpddr2sip_vb which somehow has the same goal (work with different variants of the same SiP MPU), but distinguishes at compile time. For our current task, we follow the same approach, build at91bootstrap twice with different configurations, and in SAM-BA read the EXID register to decide which binary to flash.
• In the 4.x or master branch, I saw the DRAM configuration was moved to a common place instead of duplicating it in board code over and over again. I think this a good way and it would make selecting at runtime easier. 👍🏼
• I'm not sure if the settings for W9751G6KB can be used for the SAMA5D27C-D5M unmodified. There are two different configurations for W971GG6SB depending if it's part of SAMA5D27C-D1G or another chip, so I think our usecase is not yet covered by master anyways, probably because there's no board in at91bootstrap using the SAMA5D27C-D5M, yet. I just sticked to what I found some months ago based on datasheet reading and the settings from the SAM-BA presets and applets.

[ehristev]

Thanks for your feedback so far.

So one question though: when you select in bootstrap the MPU, the config, etc, you can choose the right memory amount and type? or are there any issues ?

I can select those, no issues. So there's no urgent demand here.

After reading the code again today, I noticed some things, more or less related to the problem field:

* In the 3.x branch there is _sama5d2_lpddr2sip_vb_ which somehow has the same goal (work with different variants of the same SiP MPU), but distinguishes at compile time. For our current task, we follow the same approach, build at91bootstrap twice with different configurations, and in SAM-BA read the EXID register to decide which binary to flash.

There was something called a 'virtual board' because we had to support the lpddr2 sip but we had no board to actually add to at91bootstrap. So this was more like an 'example' that could be used by people wanting to use the sip.

* In the 4.x or master branch, I saw the DRAM configuration was moved to a common place instead of duplicating it in board code over and over again. I think this a good way and it would make selecting at runtime easier. 👍🏼

That was one of the main goals of at91bootstrap4 . I am glad it's appreciated

* I'm not sure if the settings for W9751G6KB can be used for the SAMA5D27C-D5M unmodified. There are two different configurations for W971GG6SB depending if it's part of SAMA5D27C-D1G or another chip, so I think our usecase is not yet covered by master anyways, probably because there's no board in at91bootstrap using the SAMA5D27C-D5M, yet. I just sticked to what I found some months ago based on datasheet reading and the settings from the SAM-BA presets and applets.

That's right. We do not have things in bootstrap that are not covered by our evaluation kits, with a few notable exceptions. One of the reasons is that we try to validate all the code that we publish on a real board. If you can add a new DDR profile , like W9751G6KB , you can create a custom defconfig that picks this DDR profile and we can merge it into master.

[LeSpocky]

If you can add a new DDR profile , like W9751G6KB , you can create a custom defconfig that picks this DDR profile and we can merge it into master.

Not sure if I find time for this. 😞

Background: I had to find a way to move forward quickly. I already had code to support the ATSAMA5D27C-D5M in a custom v3.9.x branch since summer 2020. For the new board (where either D5M or D1G is soldered depending what can be bought at the time) I let ptxdist build at91bootstrap twice with different configurations for each SoC variant, the at91bootstrap code uses the RAM size defines resulting from kconfig and ifdefs to build either one ore the other variant. When flashing the NAND flash on the boards with a SAM-BA qml script, I let the script read the CPU register with the EXID and flash the correct image depending on that. This is working, it is in production and I won't get time to test newer versions of the bootstrap soon. 🤷🏼‍♂️

[LeSpocky]

FTR: due to ongoing chip delivery shortages, we have to do the same move (populating one or the other variant on the PCB) for another product, which can also boot from SD card. It would be great if we could avoid making different SD cards, and have the second stage bootloader (aka at91bootstrap) decide at runtime. If it's not easily possible to let at91bootstrap do it, maybe U-Boot SPL is a possibility? 🤔

[LeSpocky]

FTR: due to ongoing chip delivery shortages, we have to do the same move (populating one or the other variant on the PCB) for another product, which can also boot from SD card. It would be great if we could avoid making different SD cards, and have the second stage bootloader (aka at91bootstrap) decide at runtime.

I got some time assigned to implement this "decide at runtime" feature for booting from SD card now. Just looking at the current state of master aka v4.0.6-rc1 to see if there's a way to implement this.

Meanwhile board specific code has gone completely. Also configurations for non-microchip boards gone (folder contrib deleted without any reasoning in the git commit messages).

I can select different RAM presets from Kconfig like CONFIG_DDR_W971GG6SB_D2 or CONFIG_DDR_W9751G6KB but only one at the time.

Would appreciate any sort of guidance how some sort of automatic runtime selection (maybe based on one configured base SiP type) could and should be implemented here. Will look into it now to see if I can come up with something in a few hours. If not I will probably hack something on top of our old v3.9.x modifications.

[LeSpocky]

Would appreciate any sort of guidance how some sort of automatic runtime selection (maybe based on one configured base SiP type) could and should be implemented here. Will look into it now to see if I can come up with something in a few hours. If not I will probably hack something on top of our old v3.9.x modifications.

It was a lot easier to hack this on top of v3.9.x for just the one board I need this for.

Leaving this open, because I still think it's a useful feature. But I won't come with a patch for v4.x anytime soon, still open for ideas anyways.

[LeSpocky]

Anyone else having an idea for an elegant solution for this problem in the v4.x branch?