Skip to content

Conversation

slp
Copy link
Collaborator

@slp slp commented Sep 29, 2025

u-boot uses a legacy CMOS device to obtain the ram size, so do a minimal implementation ourselves.

While there, also fix a bug in the recently introduced firmware support code.

Add ram size info to ArchMemoryInfo, since we're going to need for the
CMOS legacy device.

Signed-off-by: Sergio Lopez <[email protected]>
@slp slp force-pushed the add-cmos-device branch 3 times, most recently from 0ed164d to 866d449 Compare September 30, 2025 15:15
slp added 2 commits September 30, 2025 17:22
u-boot uses a legacy CMOS device to obtain the ram size, so do a minimal
implementation ourselves.

Signed-off-by: Sergio Lopez <[email protected]>
We need to inject the firmware region just before the last one.
Fix it to do it properly.

Signed-off-by: Sergio Lopez <[email protected]>
@MatiasVara
Copy link
Collaborator

IIUC this legacy device is always enabled in x86-64, am I right? may we have a way to decide to use it or not?

@slp
Copy link
Collaborator Author

slp commented Oct 1, 2025

IIUC this legacy device is always enabled in x86-64, am I right? may we have a way to decide to use it or not?

Yes, so far we've tried to always use the same set of legacy devices, only moving around the virtio ones. I think it's better to always have the cmos device (which is very small and innocuous) present.

@slp
Copy link
Collaborator Author

slp commented Oct 10, 2025

@MatiasVara do you need more changes to this PR?

@MatiasVara
Copy link
Collaborator

MatiasVara commented Oct 10, 2025

@MatiasVara do you need more changes to this PR?

I have nothing to add. It LGTM. I did not try it though.

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