Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SiP: SoC dependent RAM init #142

Open
LeSpocky opened this issue Nov 29, 2021 · 8 comments
Open

SiP: SoC dependent RAM init #142

LeSpocky opened this issue Nov 29, 2021 · 8 comments

Comments

@LeSpocky
Copy link
Contributor

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
Copy link
Contributor

ehristev commented Dec 6, 2021

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 ?

@ehristev ehristev self-assigned this Dec 6, 2021
@LeSpocky
Copy link
Contributor Author

LeSpocky commented Dec 6, 2021

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
Copy link
Contributor

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
Copy link
Contributor Author

LeSpocky commented Jan 3, 2022

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
Copy link
Contributor Author

LeSpocky commented May 4, 2022

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? 🤔

@ehristev ehristev removed their assignment Jan 27, 2023
@LeSpocky
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants