Hello everyone, We are in the final week of GSoC'18 program and yesterday our code has successfully merged. It got crashed in the first build because we thought we would add the code but disable the build currently but we didn’t test the case when device manager will try to find the driver in a certain directory which we hardcoded at the time of loading the module. So we just changed it to an OR condition where it won’t be able to find the driver binary but still be able to boot the OS in any case.
Hello everyone, this week we have tried to get the response from the command but unfortunately, it didn’t work out. In the meantime, I have submitted the code for review and PulkoMandy had already reviewed once. I have been going through Linux patches1 2 which are related to the issue we are currently facing.
I have done following improvements in the code
Disabled adding drivers to the kernel, removed statements from
Hello everyone, here we are with another update on the project. Last week we have started with installing interrupt handler, so basically we will pass the address of a function while installing the interrupt handler, later when an interrupt occurs that function will be called.
We opted for pin-based interrupt handler, which is one of the levels of interrupt handling. I have explained them in previous blogs.
Instructions to install an interrupt handler: bus->irq = pciInfo->u.
So here we are in the final week of the second phase of this project. I would like to address what was planned for this phase and what we have achieved and will proceed to plan for the third phase.
Second Phase Highlights We were successful in register mapping through MMUIO. We have created a bus manager but not linked with controller ATM. Interrupts have not been implemented but also not required in this phase.
Hey guys! Last week we have improved the code and made it more readable. We have completed the reset and clock sequence and proceed with power sequence. In the 4th step of the sequence, it asks to get the Operation Conditions Register(OCR) value of SD card. In the SD host controller spec, in command register there is command index bits which mention about setting up command number specified in bits 45-40 of the command-format in SD Memory Card Physical Layer Specification.
Finally, we got the register mapping work and they are responsive, we have tested by enabling software reset bit and it has all the default values of registers which are set by Qemu except the present state register and capabilities register. These both should be left unaffected as mentioned in the spec. We are following SD Host specification version 1.00 for now, which also doesn’t support UHS but Qemu seems to be supporting it well.
Hello everyone! Here’s the update of week #6, in the last update we were not able to access the registers. When we tried mapping it, there were all zeros. so we knew there’s something wrong in the way we were accessing the register and in between this we got to know that qemu emulation for sdhc hardware only supports spec version 2 and 3 and the spec which we intended to implement was 4.
Hey, folks! So we are at the end of first phase of the project and I had expected that I would be able to implement PIO but it seems that I have lagged a bit. Till now we have got our controller driver setting up the mmc bus and mmc disk driver to publish a slot. To implement PIO before DMA, also requires register mapping which we are currently working on.
Hey, here I am with another update! Last time I mentioned about splitting up the module but due to time constraint we agreed to skip that currently and move forward. After setting up the bus, I thought it would be bus manager which needs to be setted up for data transfer and other read and write operations but it turns out to few things which need to be done before that and it’s actually not the bus manager who do these operations, it will just create an instance of the interrupts and the operations to be done, and call back after it’s done.
Hey everyone! here I am with another update. Last time I had concluded-“PCI class is not discoverable to device manager”, it was actally a bit wrong. So korli explained that device manager won’t load a driver which system doesn’t know so in order for device manager to consider sdhci bus device, it has to be added under a condition of the devices of same type. So we added it under “disk”.
