problem locating RSDP

[algawi86]

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.

[robbiedobbie]

Are you sure that you haven't written to the memory space containing the RSDP before searching for it?

[algawi86]

I'm positive.

[Schol-R-LEA]

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?

[algawi86]

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)

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
}

[hannah]

Sounds like bad ram to me. Some bits are flipped when they shouldn't.

Code: Select all

R        _
01010010 01011111 

[SpyderTL]

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?

[algawi86]

so i wont compare the NULL terminator.

sizeof(char[]) = strlen(char[])+1

regarding memory issues or ACPI disable, i'll check it.

thanks

[SpyderTL]

Hmm.. You might also want to try hard coding the length to 8, just to eliminate that as a possible issue. (Temporarily)

[Brendan]

Hi,

Are you sure that you haven't written to the memory space containing the RSDP before searching for it?

I'm positive.

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.


Cheers,

Brendan

[BrightLight]

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.

[algawi86]

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 ?

[algawi86]

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.

[Octocontrabass]

Have you tried looking for the table without booting an OS?

[Brendan]

Hi,

i also tried booting into recovery root shell with single user mode and still i couldn't find anything, couldn't find the RSDP

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).

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 ?

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.


Cheers,

Brendan