AHCI Driver Partition Setup in QEMU/Hardware

I have enabled dynamic settings, but one of the issues I encountered is the storage of information for use in the next system boot. To address this, after reviewing existing sample applications, I arrived at the following structure:

<start name="report_rom">
	<resource name="RAM" quantum="2M"/>
	<provides> <service name="Report"/> <service name="ROM"/> </provides>
	<config>
		<policy label="pci_decode -> system" report="acpi_drv -> acpi"/>
		<policy label="platform_drv -> devices" report="pci_decode -> devices"/>
	</config>
</start>

<start name="acpi_drv" caps="350">
	<resource name="RAM" quantum="4M"/>
	<route>
		<service name="Report"> <child name="report_rom"/> </service>
	</route>
</start>

<start name="pci_decode" caps="350">
	<resource name="RAM" quantum="2M"/>
	<route>
		<service name="Report">             <child name="report_rom"/> </service>
		<service name="ROM" label="system"> <child name="report_rom"/> </service>
	</route>
</start>

<start name="platform_drv" caps="100" managing_system="yes">
	<resource name="RAM" quantum="1M"/>
	<provides> <service name="Platform"/> </provides>
	<route>
		<service name="ROM" label="devices"> <child name="report_rom"/> </service>
		<service name="Report"> <child name="report_rom"/> </service>	</route>
	<config>
		<report devices="yes"/>
		<policy label="ahci_drv -> "> <pci class="AHCI"/> </policy>
	</config>
</start>

<start name="ahci_drv" caps="300">
	<resource name="RAM" quantum="12M" />
	<provides><service name="Block" /></provides>
	<config atapi="yes">
		<report ports="yes"/>
		<vfs>
			<ram/>
			<import>
				<rom name="ext2.raw"/>
			</import>
		</vfs>
		<default-policy root="/" file="ext2.raw" block_size="512" writeable="yes"/>
		<policy label="ahci_fs -> " device="1" writeable="yes"/>
	</config>
	<route>
		<service name="Report"> <child name="ahci_report_rom"/> </service>
		<any-service> <parent /> <any-child/> </any-service>
	</route>
</start>

<start name="ahci_report_rom">
	<binary name="report_rom"/>
	<resource name="RAM" quantum="1M"/>
	<provides> <service name="Report"/> <service name="ROM"/> </provides>
	<config verbose="yes"/>
</start>

This sample configuration is functional for testing with QEMU, adding an AHCI driver, and utilizing an ext2.raw partition. However, on actual hardware, there is a step missing: the partitioning needs to occur in such a way that I can reference it in the ahci_drv module. Without this, I encounter the following error:

[init -> ahci_fs] Error: Mounting 'ext2fs' file system failed (13)
[init -> ahci_fs] Error: failed to create <rump> VFS node
[init -> ahci_fs] Error: 	fs="ext2fs"
[init -> ahci_fs] Error: 	ram="48M"
[init -> ahci_fs] Error: 	writeable="yes"

What module should I add to this set of modules to create and correctly name the partition so that I can use the file system structure on the hard disk?

The part_block component parses DOS/GPT partition tables and provides dedicated block sessions for partitions as well as the whole disk.

Thank you, I had seen this component in the Sculpt OS code but was unsure about it. Your guidance led me to conduct a more thorough investigation, and it worked out.

I just have another question. My test system also has a mini SATA drive, which is connected via the same AHCI controller. However, the Genode driver can’t detect it. Have you encountered this issue?

Note: My device doesn’t have a serial output, and although I enabled the terminal log, it still doesn’t display the driver logs. Therefore, I don’t have a clear output to share the error with you.

Sorry for my late reply, but I do not have tips to enable this drive. May you send more information about this mini SATA drive? You could use a Live Linux and lshw, smartctl, journalctl etc. Also, the parts of /report/log in Sculpt OS concerning ahci may be of help.

Regarding terminal log and drivers, make sure to route the driver logs to that terminal, otherwise they get routed to the parent init, which itself will use serial output. I.e. insert something like this in the driver routes…

<route>
					<service name="LOG"> <child name="terminal....log..." /> </service>
					<any-service> <parent/> <any-child/> </any-service>
</route>

Thank you for the suggestions and apologies for the delay in gathering the details. I’ve taken the steps you mentioned to retrieve more information on the mini SATA drive using Live Linux and Sculpt OS logs. Below are the results:

The first picture contains the hardware information of the mini SATA device, extracted through Live Linux.

This next image shows that the partitioning was completed correctly.

Here is the Sculpt OS output displayed in the log section.

And finally, this is the final output from Sculpt OS.

Thanks for the details. What bothers me most is #0: off (ATA). As the device is named /dev/sda in Linux I’d expect #0 is the one most interesting to us. @ssumpf do you have further ideas about the off state?

Also, your screenshot misses some lines from the ahci driver startup. May you please look for those in your log and send them?

Could it be the same problem as in issue ahci_drv: devices not reported · Issue #5088 · genodelabs/genode · GitHub?

In that case, the following commit might help:

1 Like

@cproc: Sorry, I totally missed issue 5088. @hamed: Could you give cproc’s patch a try?

1 Like

Thank you, Christian. Disabling the reset() function resolved the issue effectively.

However, there’s still a problem I’ve encountered on a low-spec system. If I delay the driver execution by showing logs, the driver runs correctly. Otherwise, both the AHCI and Realtek drivers fail to initialize, and the system freezes at that point in execution.

Is that the system with the Celeron CPU? Which Celeron is it exactly?

Yes, it’s a Celeron. Intel Celeron J4105.

This CPU has a single-core performance that is comparable to the Lenovo X201 from 2010 according to Intel Celeron J4105 vs i5-520M [cpubenchmark.net] by PassMark Software. Please keep that in mind during evaluation assessment.