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

add a133 support #192

Closed
wants to merge 1 commit into from
Closed

add a133 support #192

wants to merge 1 commit into from

Conversation

baidxi
Copy link

@baidxi baidxi commented Mar 15, 2023

add a133 support

Signed-off-by: juno <[email protected]>
Copy link
Contributor

@apritzel apritzel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi,

thanks for sending this! I had something similar here locally, so happy to test and review.

*/
sram_swap_buffers a133_sram_swap_buffers[] = {
/* 0x21000-0x21400 (IRQ stack) */
{ .buf1 = 0x21000, .buf2 = 0x43200, .size = 0x0400 },
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You wouldn't need to backup this area if you don't use it below (since spl_addr is after that buffer here). But see below ...

/* 0x21000-0x21400 (IRQ stack) */
{ .buf1 = 0x21000, .buf2 = 0x43200, .size = 0x0400 },
/* 0x40a00-0x421FF (Stack) */
{ .buf1 = 0x40a00, .buf2 = 0x43600, .size = 0x1800 },
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we would need to back this up, we can just say that usable SRAM ends at 0x40a00. That's still plenty of SRAM to play with.

},{
.soc_id = 0x1855, /* Allwinner A133 */
.name = "A133",
.spl_addr = 0x24000,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spl_addr should point to the same address that the BROM would load any eGON binaries to, which should be SRAM A1 or 0x20000 in this case. Otherwise we cannot share the SPL between SD card/eMMC and FEL booting, because they are hard linked against a certain SRAM address.
Was there any particular reason you chose the beginning of SRAM C here? If not, please change it to 0x20000.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

start at 0x20000 only 4K is valid, at very early. so change to SRAM C location

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What makes you think so? I dumped all the first 16KB, twice, then wrote something to 0x22000 (or 0x23000), and read that back, with the rest untouched. So everything from 0x20000 to 0x23fff is perfect SRAM, available early. This is also mentioned in the manual: "16K(support Byte operation, clock source is AHB1)". So there is no mentioning of this being sparse, or restricted, or borrowed to another peripheral.
If you tried writing something to 0x21000 and it crashed: This is due to this area being used by the BROM FEL routine (for the IRQ stack), you must not touch the area between 0x21000 and 0x21400. You mention this yourself in the patch, by backing up this part.
So do you have any other insight into why there would be only 4K available?
As mentioned before, we cannot easily change this location to our liking, as this has to match where the BROM loads to.

.spl_addr = 0x24000,
.scratch_addr = 0x25000,
.thunk_addr = 0x43000, .thunk_size = 0x200,
.swap_buffers = a133_sram_swap_buffers,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the above changes, you might not need a separate swap_buffers array, instead I ended up re-using v831_sram_swap_buffers, which just stores away the IRQ FEL stack. We might want to use a higher address, though, to get more usable SRAM.

@baidxi baidxi closed this by deleting the head repository Mar 30, 2023
@parthitce parthitce mentioned this pull request Jul 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants