Configuring Intel HDA

[DavidCooper]

First, am I correct when assuming the following memory addresses for various HDA registers (I won't list them all)?
FEBF0000 - GCAP
FEBF0002 - VMIN
FEBF0003 - VMAJ

Yes.

Second, the tables for these offsets look different than a table I'm used to in my PDF reader (I wish there was an HTML version of this spec).

I can see the problem you have with reading the tables if all the right-hand columns are detached from the rest. Yes, the descriptions line up with the bits. Here's a rearrangement of what you posted:-

3.3.2 Offset 00h: GCAP – Global Capabilities
Length: 2 bytes

Table 3. Global Capabilities
Bit, Type, Description


15:12 RO

Number of Output Streams Supported (OSS): A value of 0000b indicates that there
are no Output Streams supported. A value of maximum 15 output streams are
supported.
0000b: No output streams supported
0001b: 1 output stream supported
…
1111b: 15 output streams supported


11:8 RO

Number of Input Streams Supported (ISS): A value of 0000b indicates that there are
no Input Streams supported. A maximum of 15 input streams are supported.
0000b: No input streams supported
0001b: 1 input stream supported
…
1111b: 15 input streams supported



7:3 RO

Number of Bidirectional Streams Supported (BSS): A value of 00000b indicates that
there are no Bidirectional Streams supported. A maximum of 30 bidirectional streams
are supported.
00000b: No bidirectional streams supported
00001b: 1 bidirectional stream supported
…
11110b: 30 bidirectional streams supported



2:1 RO

Number of Serial Data Out Signals (NSDO): A 0 indicates that one SDO line is
supported; a 1 indicates that two SDO lines are supported. Software can enable the use
of striping by setting the appropriate bit in the Stream Buffer Descriptor.
00: 1 SDO
01: 2 SDOs
10: 4 SDOs
11: Reserved



0 RO

64 Bit Address Supported (64OK): A 1 indicates that 64 bit addressing is supported by
the controller for BDL addresses, data buffer addresses, and command buffer addresses.
A 0 indicates that only 32-bit addressing is available.


Then underneath the table, it says:-

There are a maximum of 30 Streams that can be supported, of which 15 may be configured as
output and 15 may be configured as input streams at any one point in time.

All the tables would ideally be rewritten for you in the same way, but we could miss a few out. This is the first useful one:-

3.3.7 Offset 08h: GCTL – Global Control

Length: 4 bytes

Table 8. Global Control Register

Bit, Type, Reset, Description

31:9 RsvdP 0's

Reserved

8 RW 0

Accept Unsolicited Response Enable (UNSOL): If UNSOL is a 1, Unsolicited Responses from the codecs are accepted by the controller and placed into the Response Input Ring Buffer. If UNSOL is a 0, unsolicited responses are not accepted and dropped on the floor.

7:2 RsvdP 0's

Reserved

1 RW 0

Flush Control (FCNTRL): Writing a 1 to this bit initiates a flush. The flush is complete when Flush Status is set. Before a flush cycle is initiated, the DMA Position Buffer must be programmed with a valid memory address by software, but the DMA Position Buffer bit 0 need not be set to enable the position reporting mechanism. Also, all streams must be stopped (the associated RUN bit must be 0).
When the flush is initiated, the controller will flush pipelines to memory to ensure that the hardware is ready to transition to a D3 state. Setting this bit is not a critical step in the power state transition if the content of the FIFOs is not critical.

0 RWS HwInit

Controller Reset (CRST): Writing a 0 to this bit causes the High Definition Audio controller to transition to the Reset state. With the exception of certain registers such as those required for Wake support, all state machines, FIFO's, and memory mapped configuration registers (not PCI Configuration Registers) in the controller will be reset. The link RESET# signal will be asserted and all other link signals will be driven to their "reset" values. After the hardware has completed sequencing into the reset state, it will report a 0 in this bit. Software must read a 0 from this bit to verify that the controller is in reset.
Writing a 1 to this bit causes the controller to exit its Reset state and de-assert the link RESET# signal. Software is responsible for setting/clearing this bit such that the minimum link RESET# signal assertion pulse width specification is met (see Section 5.5).
When the controller hardware is ready to begin operation, it will report a 1 in this bit. Software must read a 1 from this bit before accessing any controller registers. The CRST# bit defaults to a 0 after hardware reset, therefore software needs to write a 1 to this bit to begin operation.
Note that the CORB/RIRB RUN bits and all Stream RUN bits must be verified cleared to 0 before CRST# is written to 0 (asserted) in order to assure a clean restart.
When CRST is 0 indicating that the controller is in reset, most registers will return their default values on reads, and writes will have no effect. The exceptions are the WAKEEN and STATESTS registers, which are only cleared on power-on reset, and the CRST bit itself, which will cause the controller to leave the reset state when a 1 is written to it.

If that's helpful, I can do the rest of them the same way, probably spread out over a few days.

[SpyderTL]

Well, I don't feel so bad about not booting with -machine q35.

I tried with ArchLinux and got:

This kernel requires an x86-64 CPU, but only detected an i686 CPU.
Unable to boot - please use a kernel appropriate for your CPU.

[Ethin]

Now that I know that, it should make things much, much easier. I'll see about making functions that are capable of reading from these registers and report back to you the values they get so that we can verify that all of this works nicely. While I'm at it I'll probably look at KolibriOS' code to see how they did some of it, since I know that'll be a challenge.
@SpyderTL: That's odd; are you sure your using qemu-system-x86_64? That's what I'm using and with -machine q35 my OS booted perfectly (but that might be because the bootloader I'm using, which is not grub, gets the machine into long mode before executing the kernel).

[SpyderTL]

You are right. I was using qemu-system-i386.

But after switching to qemu-system-x86_64, my OS still does not boot, and ArchLinux gets further, but still fails to boot with a kernel panic.

I'll add it to my list of stuff to get working when I get around to it.

[Ethin]

That's odd. I would think that -machine q35, being supposedly faster than the default machine, would be more compatible. What was the kernel panic you got?

[SpyderTL]

Command Line:

"c:\program files\qemu\qemu-system-x86_64.exe" -cdrom "archlinux-2019.02.01-x86_64.iso" -soundhw all -machine q35

Result:

Initramfs unpacking failed: write error

Maybe I'll try bumping up the default memory size.

[Ethin]

Qemu sets it to (I think) something like 128 MB by default.

[eekee]

A faster emulation is actually less likely to be compatible for a whole bunch of reasons.

[Klakap]

I am quite confused with values on 0xFEBF0000 because a lot of useful registers are missing! Please what is it?

(16 bits)
0xFEBF0000 = 0x4401
0xFEBF0004 = 0x0000
0xFEBF0008 = 0x003C
0xFEBF000C = 0x001D

And other is zeroes, sometimes little value(as 1)!

Please what is it?

[DavidCooper]

I am quite confused with values on 0xFEBF0000 because a lot of useful registers are missing! Please what is it?

(16 bits)
0xFEBF0000 = 0x4401
0xFEBF0004 = 0x0000
0xFEBF0008 = 0x003C
0xFEBF000C = 0x001D

And other is zeroes, sometimes little value(as 1)!

Please what is it?

The specification should tell you what they are. That said though, those values look out of place. I'd expect to see something like [0] 01 (64-bit address supported), [1] 44 (4 input streams and 4 output streams available), [2] 00 (minor version), [3] 01 (major version), [4] 003C (output payload capability), [6] 001D (input payload capability) as the first eight bytes rather than them being spread across the first sixteen bytes. If you're getting the 3C and 1D in the wrong places, either your code isn't accessing the right addresses or QEMU's messed it up.