#apertus IRC Channel Logs

Good morning!

BAndiT1983: For the self programming of PIC32, is there anything specific to write?

either the bootloader, when a new version is release or mostly firmware of course

pic32 will start the bootloader, check if firmware is there and if yes, then jump to firmware

firmware reports back if screen requires an update, as the MCU has only one core, we don't have to bother with multi-threading or race conditions, just with fast code execution

Good morning! I have made many changes. It conforms to linux kernel code style (do mention if i missed something). This does not include ioctl yet. Please review: https://github.com/Swaraj1998/apertus-kernel-challenge/tree/master/task1

will check shortly

metal_dent[m]: not on it's own, another way is to plug in the programmer, which we want to avoid, as it's easier for the user to update it over usb or the camera could automatically do it, if there is newer firmware pack

bluez_[m]: okay, that looks a lot better than last time ... please elaborate on the design choices you made for this task

one thing i did was that device major can be set by user as module param or dynamically allocated otherwise

write is dynamic as you suggested (not in stack)

Bertl: I am not sure what exactly you mean by design choices here, this one is pretty much like a normal character device... is it not?

well, what cases are expected to work

okay... one could be that if the bytes requested by the user (during read) is less than the size of string "checksum: %d\n", the user wont get any output

and what is the expected checksum?

and what about the IOCTL?

but that is user's issue i guess...

well, let's run some tests with the module

give me a minute or two to build

ok i found one issue... but that is in the load script and not in the module itself... i hardcoded zero as minor number... will change that

well, that is fine, no?

yes yes... its just something i was worried about... but then i found the reason ':D

Bertl: presently I am working on the challenge and I find that it is not nessary to code for read functions for ioct and proc

Bertl: correction read not write

bluez_[m]: will take a few more minutes, had to update the kernel

ok ok... no problem

yeah, just make sure that it behaves well (this is part of testing)

well, that is one reason why I asked about your design decisions

its just a choice then right?

well, it is a choice if you made it _before_ you wrote the code :)

no no i did take that decision... but I just didn't think much then cuz I thought that was normal ':D

*it

yes, please 'fix' it like a bug

done ':D

Already up-to-date.

what about those: https://pastebin.com/raw/KPCsw6ic

in holds info about the file, various members... one use i found was that the private_data member could hold any allocated data needed for the driver

in that we can store any kind of structure we want

that can help manage the driver...like semaphores and stuff

well, let's do some test now (kernel is updated) to see what the driver does

<Bertl "well, let's do some test now (ke"> okay...

cat /proc/csumdev

that looks fine

dd if=/dev/zero bs=128 count=1 >/dev/csumdev

checksum: 0

oh okay

that's interesting as it never finishes ...

what does this command do?

check with 'man dd'

no no i mean the way it is written

what does that do?

does it run both concurrently?

the combined output is then sent to /dev/csumdev

(echo -n '01'; echo -n '23') | od -a

correct

that is a good question, got any answers for that?

searching ':D

works as expected, but ...

gives:

another 'design decision'? :)

<Bertl "error writing 'standard output':"> I think this might be because my driver does not allow successive writes unless seeked to 0th position before doing the next write.... dd does multiple writes when count is > 1

<bluez_[m] "I think this might be because my"> yes that is the issue... i confirmed it does copy the first block

just remove the code that returns if *ppos > 0 ...? I will try that....

need to make more changes...

bluez_[m]: take your time ...

<bluez_[m] "just remove the code that return"> sorry sorry removing this actually fixed it.... but due to another bug in my app.c I kept receiving weird results... sizeof(char*) is always 8.... it should be strlen or hardcoded length of data.... changed it

off for now .... coming back son

<bluez_[m] "sorry sorry removing this actual"> no it did not 😕... will fix it

BAndiT1983: Hi, is the LCD dimming task for changing the brightness of the LED?

okay

few tests, not much

okay!

metal_dent[m]: what do you mean with beta on the PICs?

what do you mean by hosted? AXIOM Beta is the camera

Bertl: I fixed both the issues! I had it fixed since before but I was checking the wrong way. Please have a look. And do comment if any other issues. I am going to bed now. Will do the rest tomorrow. Good night!

or host software, like software for camera as host

latter one is correct, wording is right, but sometimes i have also to think twice, as english is not my mother language

T729* i mean

thanks for spotting the misleading reference in T884

so I take it your code is ready for the next test round?

> so I take it your code is ready for the next test round?

at the moment, yes

> (T729 the only one)

So shall we test?

chgrp: invalid group: ‘wheel’

wheel group works for me ':D

maybe staff would work for you...

what's the reason for the 'wheel' group here?

did you test that?

I can't write to the device without it

unless we change it

can write to it as root

yup..seems like it

if i change the mode bits for the character device file then also it works

for unpriviledged user

yup yup... realized now ':D

good that you did...

thanks!

checksum += *(uint8_t*)&buf[i];

i tried this command: dd if=/dev/random bs=4 count=2 > /dev/csumdev

naturally :)

could have been a design decision ....

<Bertl_oO "but good that you tested it :)"> :)

m not sure... the formatting?

((uint8_t)buf + i), this looks weird though...

regarding other ways to write it: yes, there are a bunch and some might be simpler

whoa, just seen the *(uint8_t*) stuff, there are definitely better ways, looks like you are trying to summon a demon

<BAndiT1983 "whoa, just seen the *(uint8_t*) "> haha... sry just suggesting a way ':D

nah, the brackets are not good, as it's implicating different stuff, even if compiler is able to read it, a developer could be confused

ok ok

something else....

*casting

so, let's take a step back and analyze the 'problem'

if first bit is set that is

because of signed char

excellent

are there any similar types which are not signed?

umm...good old unsigned char...

yes

is uint8_t required to clarify the size of signed or unsigned char?

<Bertl_oO "is uint8_t required to clarify t"> i dont think so... they are not arch dependent or anything

it doesn't???

omg...how??

<Bertl_oO "so characters could as well have"> ohhh...i see

should it not work if i change the char* buf to unsigned char* buf??

i the declaration itself i mean...

<Bertl_oO "so using unsiged char is fine in"> yup yup

yes it works

now for the formatting, when you cast to a pointer type (or declare one)

ohhh.... declaring i knew... casting one i didn't

so it should hv been: *(uint8_t *)&buf[i] ??

let's say you want to read uint16_t instead

what does *(uint16_t *)&buf[i] give you?

it will overlap.... i see....

like for index 1...we get that pointer and cast it to uint16_t... but actually 0 and 1 are part for the first 16bit

so back to copy_from_user()

okay okay

(because 'the book' said so? :)

btw, when you mention 'the book' I presume it is Linux Device Drivers :)

<Bertl_oO "btw, when you mention 'the book'"> yes yes

user space has page tables setup... so we cant access those directly from kernel i suppose

i am guessing it goes through all those page tables and finds the references... i am not sure...

but there is a good reason to use copy_from_user() instead of doing the same manually

I am not sure but that is interesting

arch dependence?

rest of the code looks reasonably fine, please add the IOCTL and you should be done

<Bertl_oO "rest of the code looks reasonabl"> okay! thank you! will do it

sure, ask away!

are you comfortable with reading schematics?

<Bertl_oO "are you comfortable with reading"> schematics? as in hardware description languages?

ohhh... yeah upto some extent...

http://vserver.13thfloor.at/Stuff/AXIOM/BETA/axiom_beta_main_board_v0.36_r1.2.sch.pdf

on page 5 and 6 you can see the interesting parts

(btw. just checked, the task description lists Lattice FPGA Know-How as Prerequisite :)

but I am interested to know... i can take a challenge

I don't think that the missing FPGA know how is a big deal in this specific case, just be prepared to dig into that really soon

and what exactly do these PIC's do?

the PICs are there to program and control the MachXO2s

the reason we went this route is mainly because we have a limited number of IOs from the main FPGA (the Zynq)

so we reserve most of the Zynq IOs for high speed/sensor interface/data output stuff

okay that was clear

so we decided to add a bunch of low power FPGAs (those are basically programmable routing fabrics)

plugins like our HDMI plugin or USB plugin

and because the system (the axiom beta camera) is modular and extensible, we want to be able to change this gateware easily

one is JTAG, another is I2C yet another is SPI

unfortunately those interfaces requires a bunch of IOs, which we do not have to spare, so we needed another simpler 'IO expander' to handle those

i saw JTAG is for debugging hardware... how does that come in here?

ohhh okay

the nice part about the PICs is that they only need a single I2C interface (i.e. 2 wires) to program them and the same two wires can be used to talk to them

the PICs I2C bus is connected to the ZYNQ and that's where the kernel is running

which is then converted into some kind of JTAG action on the MachXO2

and the result again is transferred via I2C back to the Zynq

(SoC = Sytem on Chip)

note that it would also be quite simple to run Linux on an FPGA

It could? But would be have to mimic an existing arch for that?

including the RISC-V architecture

yes, precisely

http://linuxgizmos.com/lattice-fpga-sbcs-can-run-linux-on-risc-v-softcore/

the current implementation is a python script and it takes about 25 seconds to program one of the FPGAs

ohhh...

<Bertl_oO "http://linuxgizmos.com/lattice-f"> thanks for this!

http://vserver.13thfloor.at/Stuff/AXIOM/BETA/ICSP/

pic_jtag_load.py is for example a direc memory (SRAM) upload into the MachXO2 FPGA

<Bertl_oO "pic_jtag_load.py is for example "> from pic to macxo2?

i am sorry if i am bothering with so many questions ':D

and those connections are controlled by a memory (SRAM)

okay... so the sram in pic contains all the programming or configurations needed

and the PIC transfers the data into this SRAM

yes, a very complicated one :)

<Bertl_oO "yes, a very complicated one :)"> ofc its complicated... it has every right to be ':D

it will probably answer most of your questions in this regard

<Bertl_oO "besides the SRAM, the MachXO2 al"> oh yes.. we would need to flash the data in first...

<Bertl_oO "read up on the Lattice guide abo"> which guide exactly? did you send me a link?

oh ok ok i see it

thanks a lot!

nn