problem locating RSDP
problem locating RSDP
Hey,
after going through the following wiki page
http://wiki.osdev.org/RSDP
I wrote a module which should be able to locate the RSDP, but unfortunately i never seem to find "RSD PTR ", I made sure the string was carfully compared and everything.
before giving up i dumped the entire memory region to file indeed there was no RSD PTR string inside, but i did find "_SD PTR" instead.
the machine is a g580 lenovo laptop with a second gen i5 processor.
any help will be more than welcome.
thanks.
after going through the following wiki page
http://wiki.osdev.org/RSDP
I wrote a module which should be able to locate the RSDP, but unfortunately i never seem to find "RSD PTR ", I made sure the string was carfully compared and everything.
before giving up i dumped the entire memory region to file indeed there was no RSD PTR string inside, but i did find "_SD PTR" instead.
the machine is a g580 lenovo laptop with a second gen i5 processor.
any help will be more than welcome.
thanks.
-
- Member
- Posts: 36
- Joined: Fri May 16, 2014 2:40 pm
- Libera.chat IRC: robbiedobbie
Re: problem locating RSDP
Are you sure that you haven't written to the memory space containing the RSDP before searching for it?
Re: problem locating RSDP
I'm positive.
- Schol-R-LEA
- Member
- Posts: 1925
- Joined: Fri Oct 27, 2006 9:42 am
- Location: Athens, GA, USA
Re: problem locating RSDP
The Ideapad g580 is from 2013 (and the CPU is 3rd gen, not 2nd), and has UEFI with a BIOS mode. Do you have particular need to use the BIOS mode, or can you use UEFI (which, as the wiki states, provides a direct interface to the RSDP)?
Assuming for the moment, that such a reason exists, could you please either post or give a repo link to the code in question, so we could put eyes on it for you?
Assuming for the moment, that such a reason exists, could you please either post or give a repo link to the code in question, so we could put eyes on it for you?
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.
Re: problem locating RSDP
the problem is that i need code which works both for windows and linux, and more important, the code needs to be as os independent as possible, this is why i use old bios mode.
unfortunately i cannot post full code, but the relevant snippets can be seen below. it works on every machine tested other than that old g580.
(updated to include ebda code)
unfortunately i cannot post full code, but the relevant snippets can be seen below. it works on every machine tested other than that old g580.
(updated to include ebda code)
Code: Select all
#define RSDP_BASE_1 0xE0000
#define RSDP_END_1 0xFFFFF
#define BIOS_EBDA_PA 0x40E
#define RSDP_SIG "RSD PTR "
#define RSDT_SIG "RSDT"
#define XSDT_SIG "XSDT"
#define APIC_SIG "APIC"
static PRSDP_DESC scan_for_rsdp (char* start, UINT32 length)
{
char* end = start + length;
for (; start < end; start += 16)
{
if (!TPmemcmp(start, RSDP_SIG, sizeof(RSDP_SIG) -1))
return (PRSDP_DESC)start;
}
return NULL;
}
void* map_physical_region_cached(UINT64 base, size_t size)
{
return ioremap_cache(base, size);
}
BOOLEAN get_acpi_table(const char* sig, PACPI_TBL* out_tbl, UINT32* out_tbl_size)
{
PRSDP_DESC p;
char *rsdp = NULL;
rsdp = (char*)map_physical_region_cached(RSDP_BASE_1, RSDP_END_1 - RSDP_BASE_1);
if (!rsdp)
goto ebda;
if ((p = scan_for_rsdp(rsdp, RSDP_END_1 - RSDP_BASE_1)) == NULL)
goto ebda;
goto found;
ebda:
{
UINT16 ebda_rm_segment = *(u16*)map_physical_region_cached(0x40E,2);
rsdp = (char*)map_physical_region(((UINT32)ebda_rm_segment)*16,1024);
if (!rsdp)
return FALSE;
if ((p = scan_for_rsdp(rsdp, 1024)) == NULL)
return FALSE;
}
found:
//rest of the code
}
Last edited by algawi86 on Wed Feb 01, 2017 2:17 pm, edited 1 time in total.
Re: problem locating RSDP
Sounds like bad ram to me. Some bits are flipped when they shouldn't.
Code: Select all
R _
01010010 01011111
Re: problem locating RSDP
You may also want to check the BIOS settings. There may be a setting that disables ACPI, and changing the first character of the pointer table may be the BIOS's way of "disabling" all ACPI support.
My gut feeling is that the problem is going to be something simple like this, because this functionality is pretty straight forward.
Maybe your TPmemcmp function is broken.
Why are you subtracting one from the RSDP_SIG size?
My gut feeling is that the problem is going to be something simple like this, because this functionality is pretty straight forward.
Maybe your TPmemcmp function is broken.
Why are you subtracting one from the RSDP_SIG size?
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Re: problem locating RSDP
so i wont compare the NULL terminator.
sizeof(char[]) = strlen(char[])+1
regarding memory issues or ACPI disable, i'll check it.
thanks
sizeof(char[]) = strlen(char[])+1
regarding memory issues or ACPI disable, i'll check it.
thanks
Re: problem locating RSDP
Hmm.. You might also want to try hard coding the length to 8, just to eliminate that as a possible issue. (Temporarily)
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Re: problem locating RSDP
Hi,
Cheers,
Brendan
I'd write an "absolute bare minimum boot test" to check that nothing (including code you didn't write if you're using something like (e.g.) GRUB) has modified it before your code searched. If you know the address where you expect to find it, it should be relatively easy to write a "cmp [es:address],..." boot sector.robbiedobbie wrote:Are you sure that you haven't written to the memory space containing the RSDP before searching for it?algawi86 wrote:I'm positive.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
- BrightLight
- Member
- Posts: 901
- Joined: Sat Dec 27, 2014 9:11 am
- Location: Maadi, Cairo, Egypt
- Contact:
Re: problem locating RSDP
The RSDP doesn't have a null terminator. The first field in it in the ASCII characters 'RSD PTR ' (notice the last space) but it doesn't have a null terminator. The size of this signature is 8 on all PCs and thus should be hard-coded; you don't need strlen() for ACPI detection. Right after it (at offset 9) is the checksum of the structure, no null terminators.
You know your OS is advanced when you stop using the Intel programming guide as a reference.
Re: problem locating RSDP
i've checked in the machine bios and couldn't find any thing that might change or disable ACPI,
neither in GRUB boot options (didn't find acpi=off)
i also tried booting into recovery root shell with single user mode and still i couldn't find anything, couldn't find the RSDP
the only thing i can think of at the moment is that the hard drive currently in this machine was swapped from another machine with the OS still in it, could that cause the problems ?
neither in GRUB boot options (didn't find acpi=off)
i also tried booting into recovery root shell with single user mode and still i couldn't find anything, couldn't find the RSDP
the only thing i can think of at the moment is that the hard drive currently in this machine was swapped from another machine with the OS still in it, could that cause the problems ?
Re: problem locating RSDP
algawi86 wrote:i've checked in the machine bios and couldn't find any thing that might change or disable ACPI,
neither in GRUB boot options (didn't find acpi=off)
i also tried booting into recovery root shell with single user mode and still i couldn't find anything, couldn't find the RSDP
the only thing i can think of at the moment is that the hard drive currently in this machine was swapped from another machine with the OS still in it, could that cause the problems ?
I've double checked the hdd thing, when booting from a live usb of mint, i still can't find that table.
-
- Member
- Posts: 5587
- Joined: Mon Mar 25, 2013 7:01 pm
Re: problem locating RSDP
Have you tried looking for the table without booting an OS?
Re: problem locating RSDP
Hi,
Cheers,
Brendan
Why did you try this? All OSs can and will modify and/or trash thousands of things before anything happens in user-space at all; and ACPI tables were deliberately designed to use memory that is freed/recycled/reused by the OS (a special "ACPI reclaimable" area type was added by to the firmware's memory map by the ACPI specification specifically for this reason).algawi86 wrote:i also tried booting into recovery root shell with single user mode and still i couldn't find anything, couldn't find the RSDP
If you are an OS developer (and therefore you wrote all the OS's code yourself) then you would know if it does/doesn't matter for your OS. If you're an application/utility developer (using a forum intended for OS developers and not intended for application developers); then all OSs can and will modify and/or trash thousands of things before anything happens in user-space at all.algawi86 wrote:the only thing i can think of at the moment is that the hard drive currently in this machine was swapped from another machine with the OS still in it, could that cause the problems ?
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.