üApp: picar-s: standalone CPS app uobject implementation

This task will convert the existing bang-bang CPS controller C implementation into a uobject. The following are the proposed sub-tasks:

  1. We will be working with forks and respective branches of the following repositories:

    • uberspark/uberxmhf.git on branch develop
    • uberspark/uberspark.git on branch develop
    • uberspark/uapp-SunFounder_PiCar-S.git on branch uobjcoll
    • uberspark/uobjcoll-SunFounder_Line_Follower.git on branch uobjcoll
    • uberspark/uobjcoll-raspberrypi-linux-i2c-bcm2835.git on branch uobjcoll-4.4.y

    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
  2. Build and install micro-hypervisor and I2C drivers i2c-bcm2708 from the above forks/branches and ensure baseline line-following functionality works

  3. Move the entire HMAC hypercall logic from: uobjcoll-SunFounder_Line_Follower/Line_Follower.c at uobjcoll · uberspark/uobjcoll-SunFounder_Line_Follower · GitHub into: uapp-SunFounder_PiCar-S/bangbang.c at uobjcoll · uberspark/uapp-SunFounder_PiCar-S · GitHub

  4. We may have to move the decrypted_buffer and encrypted_buffer definitions and copy over the array as defined in int * calculate_angle_speed(int *array,int arr_len,int fw_speed,int turn_angle,int st){ into the encrypted_buffer variable within: uapp-SunFounder_PiCar-S/bangbang.c at uobjcoll · uberspark/uapp-SunFounder_PiCar-S · GitHub

  5. Test the above refactoring with the line-following functionality

We can add more subtasks to fine-tune the final uobject once we have the aforementioned steps working.



I got the latest from git and have problems with building this code:

drivers/i2c/busses/i2c-bcm2708.c:184:1: warning: multi-line comment [-Wcomment]
 //#define u_readl_relaxed(c) ({ u32 __r = le32_to_cpu((__force __le32) \
drivers/i2c/busses/i2c-bcm2708.c: In function 'picar_i2c_address_readbuffer':
drivers/i2c/busses/i2c-bcm2708.c:232:27: error: 'UAPP_I2C_IOACCESS_READBUFFER' undeclared (first use in this function)
  val = khcall_fast_retu32(UAPP_I2C_IOACCESS_READBUFFER, bi_pos, bi_msg_len);
drivers/i2c/busses/i2c-bcm2708.c:232:27: note: each undeclared identifier is reported only once for each function it appears in
drivers/i2c/busses/i2c-bcm2708.c: In function 'picar_i2c_compute_hmac':
drivers/i2c/busses/i2c-bcm2708.c:252:17: error: 'UAPP_I2C_IOACCESS_HMAC' undeclared (first use in this function)
     khcall_fast(UAPP_I2C_IOACCESS_HMAC, (u32)buffer, msg_size);
drivers/i2c/busses/i2c-bcm2708.c: In function 'bcm2708_bsc_fifo_drain':
drivers/i2c/busses/i2c-bcm2708.c:266:65: warning: passing argument 3 of 'picar_i2c_address_readbuffer' makes integer from pointer without a cast
   bi->pos = picar_i2c_address_readbuffer(bi->pos, bi->msg->len, bi->base);
drivers/i2c/busses/i2c-bcm2708.c:222:19: note: expected 'u32' but argument is of type 'void *'
 static inline int picar_i2c_address_readbuffer (int bi_pos, u32 bi_msg_len, u32 bi_base){
drivers/i2c/busses/i2c-bcm2708.c: In function 'bcm2708_i2c_master_xfer':
drivers/i2c/busses/i2c-bcm2708.c:519:23: warning: unused variable 'ptr_i2c_driver' [-Wunused-variable]
   i2c_driver_param_t *ptr_i2c_driver = &i2c_drv_param;
drivers/i2c/busses/i2c-bcm2708.c:518:18: warning: unused variable 'digest_result' [-Wunused-variable]
   unsigned char *digest_result;
drivers/i2c/busses/i2c-bcm2708.c:517:16: warning: unused variable 'k_page2' [-Wunused-variable]
   struct page *k_page2;
drivers/i2c/busses/i2c-bcm2708.c: At top level:
drivers/i2c/busses/i2c-bcm2708.c:220:56: warning: 'static_buffer' defined but not used [-Wunused-variable]
 __attribute__((section(".data"))) static unsigned char static_buffer[1024];
make[3]: *** [scripts/Makefile.build:259: drivers/i2c/busses/i2c-bcm2708.o] Error 1

I am not sure what the goals of this task are.
It seems like we want to move the HMAC calculation and sensor reading into the bangbang library. Do we want all the functionality to be in bangbang.c and eliminate the need to use of libLineFollower.so located at uobjcoll-SunFounder_Line_Follower ?

No I was wanting to keep libLineFollower.so as is and just move the HMAC into bangbang. Does that make sense?

Hmmm… what is the error here? We have not made any changes to the driver code from our last PR merge, so am not sure why we are getting errors in this case…

Last time we had errors too. I thought this was fixed.
I am on uobjcoll-4.4.y branch and have done:

git fetch -a upstream
git pull upstream uobjcoll-4.4.y

Yes, we have UAPP_I2C_IOACCESS_HMAC defined within: uberxmhf/i2c-ioaccess.h at develop · uberspark/uberxmhf · GitHub and the header is included within: uobjcoll-raspberrypi-linux-i2c-bcm2835/i2c-bcm2708.c at uobjcoll-4.4.y · uberspark/uobjcoll-raspberrypi-linux-i2c-bcm2835 · GitHub

I also see that: uobjcoll-raspberrypi-linux-i2c-bcm2835/Makefile at uobjcoll-4.4.y · uberspark/uobjcoll-raspberrypi-linux-i2c-bcm2835 · GitHub has the proper definitions so that i2c-ioaccess.h is included in the compilation.

Can you check if : -I/home/anton/uberwork/uberxmhf/uxmhf-rpi3/uobjcoll/uobjs/main/include actually points to the up-to-date headers?

We hit this exact error in : üApp: picar-s: move low-level I2C driver HMAC appending into i2c-ioaccess uobject - #70 by amitvasudevan

The error at that time was you had /home/anton/uberwork/uberxmhf/uxmhf-rpi3/uobjcoll/uobjs/main/include point to a different folder and it was not pulling the correct headers in.

Have you done the same for your uberxmhf.git fork? You need to make sure /home/anton/uberwork/uberxmhf actually contains the latest upstream code.

I did update uberxmhf and then the kernel compiled.
Thought that uberxmhf was up-to-date from the last time but I guess this was not true.
Thank you!

My understanding is that we need to move the angle calculation in an Uber object and add HMAC in the Uber object and then calculate HMAC in the bangbang,c when we receive the data from the object.
Please confirm if this is the intent.

Yes the first step as indicated by the tasks in the OP is to move the HMAC calculation into bangbang.c along with the angle calculation code that is already present there. In other words, we want to first verify the HMAC of the incoming data into bangbang.c before calculating the angle/turn output.

ok, thank you for the clarification

I wanted to test everything before starting any modification and found out that the drivers can’t be loaded:

pi@raspberrypi:~ $ sudo insmod i2c-my-dev.ko
insmod: ERROR: could not insert module i2c-my-dev.ko: Invalid module format
pi@raspberrypi:~ $ sudo insmod i2c-my-bcm2708.ko
insmod: ERROR: could not insert module i2c-my-bcm2708.ko: Invalid module format
pi@raspberrypi:~ $

I am not sure why this would be the case. This worked when I tested it last time on my fork.
I think the issue is that these libraries that are part of the hypervisor do not get recompiled automatically and need to recompiled by hand:

I rebuilt the library in this folder manually, because it is not part of the automatic hypervisor rebuilding:
Rebuilt the kernel drivers and they linked with the library.
Now the drivers can be loaded and the basic functionality of the bangbang controller works as before.

Sounds good. Can you please add a couple of lines to the README to reflect the above requirements?

The following function returns an array with three values:
int * calculate_angle_speed()
How do we want the HMAC to be calculated and returned with regards to these three values:

result_array[0] = speed;
result_array[1] = step;
result_array[2] = turning_angle;
return result_array;

Let us calculate the HMAC only for the incoming sensor data that is used to compute the angle, speed and step. We dont need a HMAC on the result array for now.

There is no sensor data for the calculation of these three parameters.
The Python script passes these parameters to the libbangbang.so which calculates them.
It is just a function in C in bangbang.c
The data does not originate from any sensor, but from the Python script.