Detecting hardware
- Revelation
- Member
- Posts: 47
- Joined: Sat Jun 21, 2008 8:15 am
Re: Detecting hardware
I only get FFFF as return value. Are you sure the procedure is correct?
Now is the winter of my disk content.
Re: Detecting hardware
I have also heard of compilers (M$?) that have int = 64, long = 32 for x64, but that was a while ago.AJ wrote:On my i586-32 GCC Cross Compiler, char=8, short = 16, int = 32, long = 32, long long = 64.
On my x86-64 GCC Cross Compiler, char=8, short = 16, int = 32, long = 64, long long = 64.
JAL
- Revelation
- Member
- Posts: 47
- Joined: Sat Jun 21, 2008 8:15 am
Re: Detecting hardware
My compiler uses these settings: char=8, short = 16, int = 32, long = 32, long long = 64. So that should not be the problem.
These are my inl and outl functions:
These are my inl and outl functions:
Code: Select all
inline int inl(unsigned short port)
{
unsigned long ret_val;
asm volatile("inl %1,%0" : "=a" (ret_val) : "dN" (port));
return ret_val;
}
inline void outl(unsigned short port, unsigned long value)
{
asm volatile ("outl %0,%w1": :"a" (value), "Nd" (port));
}
Now is the winter of my disk content.
- Brynet-Inc
- Member
- Posts: 2426
- Joined: Tue Oct 17, 2006 9:29 pm
- Libera.chat IRC: brynet
- Location: Canada
- Contact:
Re: Detecting hardware
You're wrong.Masterkiller wrote:The "long" type is strict 32-bit in size. You should use it instead of int.
http://en.wikipedia.org/wiki/64bit#64-bit_data_models
You should never assume that.. use Stdint types.
- Revelation
- Member
- Posts: 47
- Joined: Sat Jun 21, 2008 8:15 am
Re: Detecting hardware
I've changed my inl and outl to
But I still get FFFF as return value. I still haven't got a clue what could cause this. Should I initialize something before doing this scan procedure?
Code: Select all
inline unsigned long inl(unsigned short port)
{
unsigned long ret_val;
__asm__ __volatile__("inl %%dx, %%eax" : "=a" (ret_val) : "dN" (port));
return ret_val;
}
inline void outl(unsigned short port, unsigned long value)
{
__asm__ __volatile__("outl %%eax, %%dx" : : "d" (port), "a" (value));
}
Now is the winter of my disk content.
- raistlinthewiz
- Member
- Posts: 34
- Joined: Wed Jun 29, 2005 11:00 pm
- Contact:
Re: Detecting hardware
0xFFFF as return means there is not pci peripheral on that bus/dev location.
check this thread http://forum.osdev.org/viewtopic.php?f=1&t=17339
check this thread http://forum.osdev.org/viewtopic.php?f=1&t=17339
- Masterkiller
- Member
- Posts: 153
- Joined: Sat May 05, 2007 6:20 pm
Re: Detecting hardware
OK, I'm wrong, but it depends on the compiler. Every compiler include documentation of size of types. Once you compile an application there is no more long and int, there is 32-bit pointer (dword).Brynet-Inc wrote:You're wrong.Masterkiller wrote:The "long" type is strict 32-bit in size. You should use it instead of int.
http://en.wikipedia.org/wiki/64bit#64-bit_data_models
You should never assume that.. use Stdint types.
Another hardware device detection is done by BIOS just before loads the bootsector. If not clear the screen and hang the execution on the bootsector, you will see a table result of the PCI Scanning of the BIOS and other information. Last line contains the text "Verifying DMI Pool Data...". If you still get 0xFFFFFFFF value from reading BUS/DEVICE address listed in that table, you have an error in your program.Revelation wrote:But I still get FFFF as return value. I still haven't got a clue what could cause this. Should I initialize something before doing this scan procedure?
ALCA OS: Project temporarity suspended!
Current state: real-mode kernel-FS reader...
Current state: real-mode kernel-FS reader...
- Revelation
- Member
- Posts: 47
- Joined: Sat Jun 21, 2008 8:15 am
Re: Detecting hardware
Thanks for the help guys! I have found out that the problem lies with Bochs and not with my code, because when I did a real test, I got correct results. My guess at the moment is that I haven't compiled bochs with the enable-pci flag.
Now is the winter of my disk content.