This task is the final piece of the I2C driver uobject construction and will move the HMAC appending logic from
i2c-bcm2708 low-level I2C driver into the
i2c-ioaccess uobject. The following are the proposed sub-tasks (we will expand on the bullets as we proceed):
We will be working with forks and respective branches of the following repositories:
Ensure the aforementioned forks/branches are upto date with the upstream repositories. The following gives an example of how to sync your fork of
uberspark/uberxmhf.git; the same can be applied to other repositories. Note these commands have to be applied on a local checkout of your fork.
git remote add upstream https://github.com/uberspark/uberxmhf.git git fetch -a upstream git checkout develop git pull upstream develop git push origin develop
Build and install micro-hypervisor and I2C drivers
i2c-bcm2708from the above forks/branches and ensure baseline line-following functionality works.
At a high level, we need to convert code fragments that read from and write to
bi->msg->bufto stand-alone constructs that read from and write to statically allocated shadow message buffers corresponding to
bi->msg->buf(there seem to be only 3 locations where this happens in the code). Then at the end of
bcm2708_i2c_master_xferbefore returning we compute the HMAC on the shadow message buffer (instead of
msgs->buf) and then copy the shadow message buffer to
The separation achieved in task 3 above will allow us to move the statically allocated shadow message buffers, the fragments operating on the statically allocated shadow message buffers, and the HMAC computation entirely into the
I think we can begin to make progress for task 3 by focusing on
i2c-bcm2708 and checking to see if we have
bi->nmsgs > 1 during our line-following. If so, this means multiple I2C transactions are present. In that case, let us see if all those transactions correspond to the same slave address (i.e,
bi->msg[i].addr == PICAR_I2C_ADDRESS for i=0 to bi->nmsgs) and if they are only reads and the maximum value for
bi->nmsgs during the line-following.
If for the entire line-following if the I2C messages we see are only for the PICAR_I2C_ADDRESS and just reads then I think we can just allocate a static shadow message buffer of size
bi->nmsgs (obtained in the experiment above) and then use that instead of bi->msg[i]->buf within the stand-alone constructs in (3).
Let me know your thoughts and let us discusss details as we dive into this. I propose we aim to get (3) working within i2c-bcm2708 before moving onto (4) to move things into the micro-hypervisor/uobject. This will allow us to use printk within i2c-bcm2708 for debugging while experimenting.