Current Server Time: 13:28 (Central Europe)

#apertus IRC Channel Logs

2020/03/20

Timezone: UTC


00:13
max_bxl
off to bed too, bye
00:13
max_bxl
left the channel
02:45
Bertl_oO
off to bed now ... have a good one everyone!
02:45
Bertl_oO
changed nick to: Bertl_zZ
03:23
davidak
left the channel
07:14
RexOrMatrix[m]
left the channel
07:14
preetimenghwani[
left the channel
07:14
metal_dent[m]
left the channel
07:15
markvandenborre[
left the channel
07:27
preetimenghwani[
joined the channel
07:27
metal_dent[m]
joined the channel
07:27
RexOrMatrix[m]
joined the channel
07:30
markvandenborre[
joined the channel
08:36
Bertl_zZ
changed nick to: Bertl
08:36
Bertl
morning folks!
08:36
apurvanandan[m]
Good morning!
10:44
futarisIRCcloud
left the channel
11:23
BAndiT1983|away
changed nick to: BAndiT1983
11:30
omar31
joined the channel
11:44
metal_dent[m]
BAndiT1983: For the self programming of PIC32, is there anything specific to write?
11:45
BAndiT1983
hi metal_dent[m], what do you mean?
11:46
omar31
left the channel
11:47
metal_dent[m]
i mean what program exactly we want to write?
11:49
BAndiT1983
either the bootloader, when a new version is release or mostly firmware of course
11:49
BAndiT1983
the flash memory is split in multiple areas, just check the .ld file in bootlaoder or firmware, where you can place certain data
11:50
BAndiT1983
pic32 will start the bootloader, check if firmware is there and if yes, then jump to firmware
11:51
BAndiT1983
then the communication between the two starts, firmware sleeps and is woken up by bootloader, e.g. when USB has new messages or buttons pressed
11:51
BAndiT1983
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
11:53
metal_dent[m]
okay, so we are doing PIC32 self-programming to trigger all these steps on its own?
11:55
bluez_[m]
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
12:00
bluez_[m]
Bertl: please comment... if this looks good I will proceed for ioctl
12:01
Bertl
will check shortly
12:01
bluez_[m]
Okay! Thanks!
12:02
BAndiT1983
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
12:03
metal_dent[m]
okay
12:12
comradekingu
left the channel
12:13
comradekingu
joined the channel
12:23
Bertl
bluez_[m]: okay, that looks a lot better than last time ... please elaborate on the design choices you made for this task
12:23
bluez_[m]
design choices as in?
12:26
bluez_[m]
one thing i did was that device major can be set by user as module param or dynamically allocated otherwise
12:26
bluez_[m]
read write to the device work both through the device file and the procfs entry
12:27
bluez_[m]
write is dynamic as you suggested (not in stack)
12:30
bluez_[m]
is this the answer you expected?
12:32
bluez_[m]
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?
12:35
bluez_[m]
can you please clarify? ':D
12:36
Bertl
well, what cases are expected to work
12:36
Bertl
what will not work as the user might expect :)
12:38
bluez_[m]
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
12:40
bluez_[m]
other than that I guess any length of data can be written as long as it isn't so big so that kmalloc fails...
12:41
Bertl
and what is the expected checksum?
12:42
bluez_[m]
it is simply the sum of the bytes written
12:43
Bertl
and what about the IOCTL?
12:43
bluez_[m]
okay, maybe if user provides an integer directly, he will get a sum of 4 bytes of that integer... which isint expected i guess
12:45
bluez_[m]
but that is user's issue i guess...
12:45
bluez_[m]
<Bertl "and what about the IOCTL?"> i though i will implement it once i get a green signal from you about the current code
12:47
Bertl
well, let's run some tests with the module
12:48
bluez_[m]
okay!
12:48
Bertl
give me a minute or two to build
12:49
bluez_[m]
sure
12:51
bluez_[m]
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
12:55
bluez_[m]
also i found that if we directly echo some string into the device I get the checksum + 10 as output... this is because a newline character is added by echo command, which has an ascii value of 10
12:55
Bertl
well, that is fine, no?
12:55
Bertl
you can avoid the newline with -n btw
12:56
bluez_[m]
yes yes... its just something i was worried about... but then i found the reason ':D
12:56
bluez_[m]
<Bertl "you can avoid the newline with -"> ohh, thats nice
12:58
pratyush[m]
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
12:59
pratyush[m]
it would be okay?
13:04
pratyush[m]
Bertl: correction read not write
13:05
Bertl
as long as there are not unexpected problems for the user, it's fine
13:06
Bertl
bluez_[m]: will take a few more minutes, had to update the kernel
13:06
Bertl
(on my test system)
13:07
bluez_[m]
ok ok... no problem
13:07
pratyush[m]
Bertl : because the input operations are performed by the character driver and output via proc and ioctl
13:08
Bertl
yeah, just make sure that it behaves well (this is part of testing)
13:09
pratyush[m]
Bertl :sure
13:14
futarisIRCcloud
joined the channel
13:21
bluez_[m]
Bertl: I found something else... I stop adding bytes when i see null character... just assuming its a string it would be better... is that okay or should i remove that?
13:22
Bertl
well, that is one reason why I asked about your design decisions
13:23
bluez_[m]
oh I see...
13:24
bluez_[m]
its just a choice then right?
13:24
bluez_[m]
sorry i forgot to mention it then ':D
13:25
Bertl
well, it is a choice if you made it _before_ you wrote the code :)
13:25
Bertl
if you didn't plan for that, and it looks like you didn't :), then it's a bug :)
13:26
bluez_[m]
no no i did take that decision... but I just didn't think much then cuz I thought that was normal ':D
13:26
Bertl
do not push it ... fit ix :)
13:27
Bertl
*it
13:29
bluez_[m]
okay okay i agree... it is a bug cuz I realized its consequences later ':D But should I change it or is it okay this way?
13:29
Bertl
yes, please 'fix' it like a bug
13:30
bluez_[m]
ok ok will do
13:32
bluez_[m]
done ':D
13:32
Bertl
git says (no change)
13:32
Bertl
Already up-to-date.
13:33
bluez_[m]
pushed just now
13:36
Bertl
what about those: https://pastebin.com/raw/KPCsw6ic
13:40
bluez_[m]
Sorry sorry i did not notice them before, fixed them... but about the file pointer, i did find its uses but none are needed for this driver I feel... is that okay?
13:45
Umori
joined the channel
13:47
Bertl
so what is this argument for?
13:49
bluez_[m]
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
13:50
bluez_[m]
but it is supposed to be once allocated in open() and deallocated in release()
13:50
bluez_[m]
in that we can store any kind of structure we want
13:50
Bertl
and your driver doesn't need that why exactly?
13:51
bluez_[m]
that can help manage the driver...like semaphores and stuff
13:52
bluez_[m]
but for this simple driver i did not think that would be necessary... I am just learning so i do lack complete knowledge... but this is what i hv found yet... can you please suggest how I should use it?
13:54
Bertl
well, let's do some test now (kernel is updated) to see what the driver does
13:54
bluez_[m]
first i thought to store the written string in the private_data member.. but then as it is once allocated in open and then deallocated at close, that is not the behaviour we want
13:55
bluez_[m]
<Bertl "well, let's do some test now (ke"> okay...
13:56
Bertl
echo -n '0123' >/dev/csumdev
13:56
Bertl
cat /proc/csumdev
13:56
Bertl
checksum: 198
13:57
Bertl
that looks fine
13:57
bluez_[m]
they add the ascii values... is that not right?
13:58
Bertl
dd if=/dev/zero bs=128 count=1 >/dev/csumdev
13:58
Bertl
cat /proc/csumdev
13:58
Bertl
checksum: 0
13:58
Bertl
looks fine as well
13:59
bluez_[m]
oh okay
13:59
Bertl
(dd if=/dev/zero bs=4096 count=1; echo -n '0123') >/dev/csumdev
13:59
Bertl
that's interesting as it never finishes ...
14:00
Bertl
instead it fills the kernel message buffer with:
14:00
bluez_[m]
what does this command do?
14:00
Bertl
[ 560.165819] CSUM: write handler called
14:00
Bertl
check with 'man dd'
14:00
Bertl
it basically copies data from source to destination
14:00
bluez_[m]
no no i mean the way it is written
14:01
bluez_[m]
in brackets seperated by colon
14:01
bluez_[m]
what does that do?
14:01
Bertl
ah, see 'man bash' for that
14:01
bluez_[m]
does it run both concurrently?
14:01
Bertl
it is basically a subprocess which executes both in sequence
14:02
Bertl
the combined output is then sent to /dev/csumdev
14:02
bluez_[m]
oh ok ok i see
14:02
Bertl
(echo -n '01'; echo -n '23') | od -a
14:03
bluez_[m]
so the input to driver shold be 4096 null's followed by '0123'? That should have worked....
14:04
Bertl
correct
14:06
bluez_[m]
<Bertl "(echo -n '01'; echo -n '23') | o"> this one works if sent directly... why does it not work when sent this way?
14:07
Bertl
that is a good question, got any answers for that?
14:08
Bertl
here is another interesting case:
14:08
bluez_[m]
searching ':D
14:08
Bertl
dd if=/dev/zero bs=4 count=1 >/dev/csumdev
14:08
Bertl
works as expected, but ...
14:08
Bertl
dd if=/dev/zero bs=4 count=2 >/dev/csumdev
14:08
Bertl
gives:
14:09
Bertl
error writing 'standard output': No space left on device
14:09
Bertl
another 'design decision'? :)
14:16
bluez_[m]
ok i get it there are many issues ':D
14:17
bluez_[m]
<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
14:18
bluez_[m]
<Bertl "that is a good question, got any"> is this issue related to pipes?
14:22
bluez_[m]
<bluez_[m] "I think this might be because my"> yes that is the issue... i confirmed it does copy the first block
14:23
Bertl
okay, so how to fix this bug then?
14:24
bluez_[m]
just remove the code that returns if *ppos > 0 ...? I will try that....
14:27
bluez_[m]
no no that wont work ':D
14:27
bluez_[m]
need to make more changes...
14:32
davidak
joined the channel
14:52
Bertl
bluez_[m]: take your time ...
14:52
Bertl
off for now ... bbl
14:52
Bertl
changed nick to: Bertl_oO
15:14
supragya62
joined the channel
15:15
supragya62
left the channel
15:15
supragyaraj
joined the channel
15:23
bluez_[m]
<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
15:25
bluez_[m]
<Bertl "off for now ... bbl"> okkk.... i'll look into that combined output issue until then
15:27
pragya
joined the channel
15:28
pratyush[m]
changed nick to: theVirus[m]
15:29
theVirus[m]
off for now .... coming back son
15:31
BAndiT1983
theVirus[m]: go away, too many infected everywhere
15:35
bluez_[m]
<bluez_[m] "sorry sorry removing this actual"> no it did not 😕... will fix it
15:51
theVirus[m]
changed nick to: pratyush[m]
16:32
supragyaraj
left the channel
16:33
pragya
left the channel
17:15
metal_dent[m]
BAndiT1983: Hi, is the LCD dimming task for changing the brightness of the LED?
17:21
BAndiT1983
yes, by using PWM, it's already implemented, but not polished, also linearization of LED was done, which needs verification
17:23
metal_dent[m]
okay
17:30
metal_dent[m]
BAndiT1983: what is the current state of the communication b/w BL anf firmware?
17:33
BAndiT1983
few tests, not much
17:33
BAndiT1983
changed nick to: BAndiT1983|away
17:35
metal_dent[m]
okay!
17:43
metal_dent[m]
BAndiT1983: is beta already present on the PICs? or the hosting is still left?
17:53
omar31
joined the channel
18:53
BAndiT1983|away
changed nick to: BAndiT1983
18:54
BAndiT1983
metal_dent[m]: what do you mean with beta on the PICs?
18:55
metal_dent[m]
I mean is AXIOM Beta already hosted on the PICs?
18:58
BAndiT1983
what do you mean by hosted? AXIOM Beta is the camera
18:59
metal_dent[m]
what is the meaning of "Host (PC/Axiom Beta) software to flash PIC16 and PIC32 firmware via USB." ?
19:01
bluez_[m]
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!
19:02
BAndiT1983
to host -> place in this meaning, like place the software for flashing pic32/pic16 on the camera, but implementation is also required ;)
19:02
BAndiT1983
or host software, like software for camera as host
19:02
metal_dent[m]
ohoo 😅 , sorry I misunderstood
19:02
BAndiT1983
latter one is correct, wording is right, but sometimes i have also to think twice, as english is not my mother language
19:56
BAndiT1983
changed nick to: BAndiT1983|away
20:22
omar31
left the channel
20:49
bluez_[m]
Hey! Can anyone confirm if the task T730 is in gsoc 2020? It does not have a gsoc 2020 label but it is mentioned in the kernel challenge... or is T29 is the only task related to the kernel challenge? Thanks!
20:50
bluez_[m]
T729* i mean
20:53
Bertl_oO
no, T730 is obsolete as we are in the process of removing mentioned JTAG interface
20:54
Bertl_oO
thanks for spotting the misleading reference in T884
20:55
bluez_[m]
Okay... it was indeed misleading ':D
20:56
Bertl_oO
so I take it your code is ready for the next test round?
20:56
bluez_[m]
So T729 is the only related project to kernel challenge?
20:57
bluez_[m]
> so I take it your code is ready for the next test round?
20:57
bluez_[m]
Sure!....if you are free...
20:57
Bertl_oO
at the moment, yes
20:57
Bertl_oO
(T729 the only one)
20:57
bluez_[m]
> (T729 the only one)
20:57
bluez_[m]
Okay...thanks!
20:58
bluez_[m]
So shall we test?
20:59
Bertl_oO
sure
20:59
Bertl_oO
chgrp: invalid group: ‘wheel’
21:01
Bertl_oO
(is what I get on load.sh on raspian :)
21:02
bluez_[m]
wheel group works for me ':D
21:02
Bertl_oO
what do we learn from that?
21:03
bluez_[m]
maybe staff would work for you...
21:03
bluez_[m]
need to make it generic ':D
21:03
Bertl_oO
what's the reason for the 'wheel' group here?
21:05
bluez_[m]
I am not really sure... the book mentions that we need to change the group... for su permissions i guess
21:06
Bertl_oO
did you test that?
21:06
Bertl_oO
i.e. did it fail without the wheel group?
21:07
BAndiT1983|away
changed nick to: BAndiT1983
21:07
bluez_[m]
let me try
21:08
bluez_[m]
I can't write to the device without it
21:09
bluez_[m]
that is what the book mentions... only root can write by default
21:09
bluez_[m]
unless we change it
21:09
Bertl_oO
so that's the only option to write to this character device?
21:10
bluez_[m]
can write to it as root
21:11
Bertl_oO
okay, so wheel is optional if you can sudo
21:11
bluez_[m]
yup..seems like it
21:11
Bertl_oO
any other options to make it accessible for an unpriviledged user?
21:12
bluez_[m]
if i change the mode bits for the character device file then also it works
21:12
bluez_[m]
like to 777
21:12
bluez_[m]
for unpriviledged user
21:12
Bertl_oO
indeed, so lots of options here without the chgrp
21:13
bluez_[m]
yup yup... realized now ':D
21:13
Bertl_oO
but it's fine, no problem there, just wanted to point that out
21:13
bluez_[m]
good that you did...
21:13
bluez_[m]
i want to absorb as much as i can
21:14
bluez_[m]
thanks!
21:15
bluez_[m]
next?
21:15
Bertl_oO
checksum += *(uint8_t*)&buf[i];
21:15
Bertl_oO
first, what's wrong with this line?
21:16
bluez_[m]
i tried this command: dd if=/dev/random bs=4 count=2 > /dev/csumdev
21:16
bluez_[m]
for some cases i got negative values
21:17
Bertl_oO
naturally :)
21:17
Bertl_oO
but good that you tested it :)
21:17
Bertl_oO
could have been a design decision ....
21:18
bluez_[m]
so i thought maybe something wrong with signed chars, cuz ascii is only 7 bits...what if greater than that bytes are given... so I casted it into unsigned and it went away ':D
21:18
bluez_[m]
<Bertl_oO "but good that you tested it :)"> :)
21:18
Bertl_oO
okay, but that's obviously working now, so: what's wrong with the line?
21:21
bluez_[m]
m not sure... the formatting?
21:21
bluez_[m]
or maybe a different way i could hv written it...
21:22
bluez_[m]
((uint8_t)buf + i), this looks weird though...
21:23
Bertl_oO
well, the formatting is definitely wrong
21:23
Bertl_oO
regarding other ways to write it: yes, there are a bunch and some might be simpler
21:24
bluez_[m]
i did not find anything related on that code style page... let me check again
21:25
BAndiT1983
whoa, just seen the *(uint8_t*) stuff, there are definitely better ways, looks like you are trying to summon a demon
21:25
BAndiT1983
necronomicon, someone?
21:26
bluez_[m]
<BAndiT1983 "whoa, just seen the *(uint8_t*) "> haha... sry just suggesting a way ':D
21:27
bluez_[m]
((uint8_t*)buf)[i], how about this?
21:28
BAndiT1983
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
21:28
BAndiT1983
first you have think about what the result should be
21:28
bluez_[m]
ok ok
21:29
BAndiT1983
and then remember, that buf[] is pointing to a value, which you seem too convert to adress, then cast to adress and dereference again
21:29
bluez_[m]
something else....
21:29
BAndiT1983
so mumble-jumble there with castind, referencing and dereferencing
21:29
BAndiT1983
*casting
21:29
bluez_[m]
<BAndiT1983 "and then remember, that buf[] is"> yeah... should not do that probably...
21:30
Bertl_oO
so, let's take a step back and analyze the 'problem'
21:30
Bertl_oO
why did you get the unwanted behaviour in the first place?
21:30
aombk
left the channel
21:31
bluez_[m]
because negative values are added....?
21:32
bluez_[m]
if first bit is set that is
21:32
Bertl_oO
and why are there negative values?
21:32
bluez_[m]
because of signed char
21:32
bluez_[m]
-127 to 128
21:32
Bertl_oO
excellent
21:32
bluez_[m]
need to make it 0 to 255...
21:32
Bertl_oO
are there any similar types which are not signed?
21:33
bluez_[m]
okaay!
21:33
bluez_[m]
umm...good old unsigned char...
21:34
Bertl_oO
would that be a feasible replacement here?
21:34
bluez_[m]
yes
21:34
Bertl_oO
will it require any extra casting (somewhere else)?
21:34
aombk
joined the channel
21:34
bluez_[m]
i guess uint8_t is same as unsigned char....iirc
21:35
Bertl_oO
is uint8_t required to clarify the size of signed or unsigned char?
21:35
bluez_[m]
<Bertl_oO "will it require any extra castin"> oh god i can make the buf variable unsigned by declaration
21:36
bluez_[m]
<Bertl_oO "is uint8_t required to clarify t"> i dont think so... they are not arch dependent or anything
21:37
Bertl_oO
actually C doesn't require a char to be 8 bits in size
21:37
bluez_[m]
it doesn't???
21:38
Bertl_oO
so characters could as well have 9 bits or more, just the values are guaranteed to at least contain 0-255 (or -127 to +127)
21:38
bluez_[m]
omg...how??
21:38
Bertl_oO
now would that matter for your case?
21:39
bluez_[m]
<Bertl_oO "so characters could as well have"> ohhh...i see
21:39
bluez_[m]
<Bertl_oO "now would that matter for your c"> i dont think so...we have bytes fed in...we can just add bytes irrespective of characters or whatever
21:40
bluez_[m]
should it not work if i change the char* buf to unsigned char* buf??
21:41
Bertl_oO
so using unsiged char is fine in any case and for all practical purposes a char will be 8 bits anyway
21:41
bluez_[m]
i the declaration itself i mean...
21:41
Bertl_oO
did you give it a try?
21:41
bluez_[m]
<Bertl_oO "so using unsiged char is fine in"> yup yup
21:42
bluez_[m]
it does compile without warnings..
21:43
bluez_[m]
yes it works
21:44
bluez_[m]
sorry for that dark sorcery i did there ><
21:44
Bertl_oO
now for the formatting, when you cast to a pointer type (or declare one)
21:45
Bertl_oO
you want to leave a space between the type and the '*'
21:46
bluez_[m]
ohhh.... declaring i knew... casting one i didn't
21:46
Bertl_oO
now about the copy_from_user()
21:46
bluez_[m]
so it should hv been: *(uint8_t *)&buf[i] ??
21:47
Bertl_oO
yes, but as BAndiT1983 mentioned, this isn't really what you want/meant
21:47
Bertl_oO
let's say you want to read uint16_t instead
21:47
bluez_[m]
yes yes i just mean in case i did that
21:48
Bertl_oO
what does *(uint16_t *)&buf[i] give you?
21:48
Bertl_oO
e.g. for 0,1,2,3,4,5 (bytes in buf)
21:49
bluez_[m]
it will overlap.... i see....
21:49
Bertl_oO
correct, you will get 0x0001, 0x0102, 0x0203 or 0x0100, 0x0201, 0x0302 or on some archs just a misaligned kernel access :)
21:49
bluez_[m]
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
21:50
Bertl_oO
correct
21:50
Bertl_oO
so back to copy_from_user()
21:50
bluez_[m]
<Bertl_oO "correct, you will get 0x0001, 0x"> indeed indeed
21:50
bluez_[m]
okay okay
21:50
Bertl_oO
we need to allocate a buffer, then copy the data from the user, then process it ... why not just access the user data directly?
21:51
Bertl_oO
(because 'the book' said so? :)
21:52
bluez_[m]
no no
21:52
Bertl_oO
btw, when you mention 'the book' I presume it is Linux Device Drivers :)
21:52
bluez_[m]
kernel has a different address space...
21:52
bluez_[m]
<Bertl_oO "btw, when you mention 'the book'"> yes yes
21:53
Bertl_oO
so the kernel can't access userspace data?
21:53
bluez_[m]
user space has page tables setup... so we cant access those directly from kernel i suppose
21:54
Bertl_oO
so how does copy_from_user() do it then?
21:55
bluez_[m]
i am guessing it goes through all those page tables and finds the references... i am not sure...
21:56
Bertl_oO
so we can get access from kernel space after all
21:56
Bertl_oO
but there is a good reason to use copy_from_user() instead of doing the same manually
21:56
Bertl_oO
any idea what that would be?
21:58
bluez_[m]
I am not sure but that is interesting
21:58
Bertl_oO
good, something you can research then ...
22:01
bluez_[m]
arch dependence?
22:01
Bertl_oO
maybe?
22:01
Bertl_oO
rest of the code looks reasonably fine, please add the IOCTL and you should be done
22:01
bluez_[m]
different arch have different support for page tables..
22:01
bluez_[m]
<Bertl_oO "rest of the code looks reasonabl"> okay! thank you! will do it
22:02
bluez_[m]
also, i needed to know more about the T729 project
22:02
Bertl_oO
sure, ask away!
22:04
bluez_[m]
Some things are alien to me... i have a superficial idea about those but i needed more clarity... anything you suggest reading? I need to know more about how the whole setup of axiom beta works...
22:05
Bertl_oO
are you comfortable with reading schematics?
22:05
bluez_[m]
like i know what fpga's are but i have never worked with one... very interested to learn though
22:06
bluez_[m]
<Bertl_oO "are you comfortable with reading"> schematics? as in hardware description languages?
22:06
Bertl_oO
actually more like in circuit designs for discrete hardware
22:07
bluez_[m]
ohhh... yeah upto some extent...
22:08
bluez_[m]
never tried reading a large scale one though... but i am pretty sure i can get an idea
22:08
Bertl_oO
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/axiom_beta_main_board_v0.36_r1.2.sch.pdf
22:09
Bertl_oO
it is certain quite complicated, but the details are not _that_ interesting for this task
22:10
Bertl_oO
on page 5 and 6 you can see the interesting parts
22:10
Bertl_oO
the large squares are the Lattice MachXO2 FPGAs
22:11
Bertl_oO
(btw. just checked, the task description lists Lattice FPGA Know-How as Prerequisite :)
22:11
Bertl_oO
and the medium sized rectangles on the right side are the PIC MCUs
22:12
bluez_[m]
but I am interested to know... i can take a challenge
22:12
bluez_[m]
<Bertl_oO "(btw. just checked, the task des"> yes... thats why the question i asked earlier today... i thought of applying for t730...
22:13
Bertl_oO
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
22:13
bluez_[m]
<Bertl_oO "and the medium sized rectangles "> i see
22:14
bluez_[m]
and what exactly do these PIC's do?
22:14
Bertl_oO
the relevant part is the Programming and Configuration guide for the Lattice MachXO2 and I doubt many folks who have Lattice FPGA know-how do know the details there
22:15
Bertl_oO
the PICs are there to program and control the MachXO2s
22:15
bluez_[m]
<Bertl_oO "I don't think that the missing F"> thats a relief... the thing is i can dig a lot but for writing the proposal in time I need to know enough now..
22:16
Bertl_oO
the reason we went this route is mainly because we have a limited number of IOs from the main FPGA (the Zynq)
22:16
bluez_[m]
<Bertl_oO "the PICs are there to program an"> okay... and what do the fpga's do here?
22:16
Bertl_oO
so we reserve most of the Zynq IOs for high speed/sensor interface/data output stuff
22:17
Bertl_oO
but we also wanted to have some low speed interfaces - our shields - and some GPIOs for the plugins, center area, etc
22:17
bluez_[m]
okay that was clear
22:18
bluez_[m]
plugins like?
22:18
Bertl_oO
so we decided to add a bunch of low power FPGAs (those are basically programmable routing fabrics)
22:18
Bertl_oO
to handle all the low and medium speed interfaces
22:18
Bertl_oO
plugins like our HDMI plugin or USB plugin
22:19
Bertl_oO
but the FPGAs in turn need some programming to work, a bitstream we call 'gateware' to make them function as intended
22:20
Bertl_oO
and because the system (the axiom beta camera) is modular and extensible, we want to be able to change this gateware easily
22:20
Bertl_oO
now there are several interfaces to program the MachXO2 FPGAs
22:20
Bertl_oO
one is JTAG, another is I2C yet another is SPI
22:21
Bertl_oO
(with JTAG being the most general and versatile)
22:22
Bertl_oO
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
22:22
Bertl_oO
and for this purpose, the PICs were added
22:22
bluez_[m]
i saw JTAG is for debugging hardware... how does that come in here?
22:23
Bertl_oO
debugging and also programming (i.e. uploading gateware)
22:23
bluez_[m]
ohhh okay
22:23
Bertl_oO
and yes, we are interested in both
22:24
Bertl_oO
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
22:24
bluez_[m]
isn't I2C a bus?? so its just for data transfer? From where do we send this data?
22:25
Bertl_oO
the PICs I2C bus is connected to the ZYNQ and that's where the kernel is running
22:26
Bertl_oO
so any JTAG operation on the routing fabrics (MachXO2s) basically starts as an I2C command to the PIC16
22:26
Bertl_oO
which is then converted into some kind of JTAG action on the MachXO2
22:27
bluez_[m]
the kernel runs on an fpga?
22:27
Bertl_oO
and the result again is transferred via I2C back to the Zynq
22:28
Bertl_oO
the Zynq is a SoC so it is not just an FPGA, it also has two hardened ARM cores
22:28
Bertl_oO
(SoC = Sytem on Chip)
22:29
bluez_[m]
wow...amazing things we have... and i have no idea
22:29
Bertl_oO
note that it would also be quite simple to run Linux on an FPGA
22:30
Bertl_oO
but it would use up resources we can utilize better for image processing and data shuffling
22:30
bluez_[m]
It could? But would be have to mimic an existing arch for that?
22:30
Bertl_oO
yes, there are a number of soft CPUs for FPGAs
22:31
Bertl_oO
including the RISC-V architecture
22:31
bluez_[m]
like programming the fpga to behave like arm core for example...?
22:31
Bertl_oO
yes, precisely
22:32
bluez_[m]
i see i see
22:32
Bertl_oO
http://linuxgizmos.com/lattice-fpga-sbcs-can-run-linux-on-risc-v-softcore/
22:33
bluez_[m]
and programming these fpgas.....requires lot of configurations? or data transfers? how much time does it usually take?
22:33
Bertl_oO
the current implementation is a python script and it takes about 25 seconds to program one of the FPGAs
22:34
Bertl_oO
maybe a minute with verification
22:34
bluez_[m]
ohhh...
22:36
bluez_[m]
what libraries we use in these python script? i.e. what device we first communicate with?
22:36
bluez_[m]
<Bertl_oO "http://linuxgizmos.com/lattice-f"> thanks for this!
22:37
Bertl_oO
the python script uses smbus for the I2C access, but that's about it
22:38
Bertl_oO
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/ICSP/
22:38
Bertl_oO
ah, and the bitarray module
22:39
Bertl_oO
pic_jtag_load.py is for example a direc memory (SRAM) upload into the MachXO2 FPGA
22:40
Bertl_oO
note that the scripts are somewhat outdated, will update them soon, so just take them as examples
22:41
bluez_[m]
<Bertl_oO "pic_jtag_load.py is for example "> from pic to macxo2?
22:42
bluez_[m]
what exactly does a direct memory upload mean?
22:42
bluez_[m]
i am sorry if i am bothering with so many questions ':D
22:43
Bertl_oO
the FPGA is basically a huge electronic board with lots of gates and wires with transistors to 'connect' those wires
22:43
Bertl_oO
and those connections are controlled by a memory (SRAM)
22:44
Bertl_oO
which can be loaded with bits and those bits control which transistors/connections are on or off
22:44
bluez_[m]
okay... so the sram in pic contains all the programming or configurations needed
22:44
Bertl_oO
the SRAM is part of the MachXO2 (FPGA)
22:45
Bertl_oO
and the PIC transfers the data into this SRAM
22:45
bluez_[m]
<Bertl_oO "which can be loaded with bits an"> ouuu... so like a bitmap of sort?
22:45
Bertl_oO
yes, a very complicated one :)
22:45
bluez_[m]
<Bertl_oO "and the PIC transfers the data i"> okay I am getting the picture now
22:46
bluez_[m]
<Bertl_oO "yes, a very complicated one :)"> ofc its complicated... it has every right to be ':D
22:46
Bertl_oO
read up on the Lattice guide about programming the MachXO2
22:46
Bertl_oO
it will probably answer most of your questions in this regard
22:47
Bertl_oO
besides the SRAM, the MachXO2 also features a flash memory which is 'copied' into the SRAM at 'power on'
22:48
bluez_[m]
<Bertl_oO "besides the SRAM, the MachXO2 al"> oh yes.. we would need to flash the data in first...
22:48
bluez_[m]
so its a complete board in itself
22:49
bluez_[m]
<Bertl_oO "read up on the Lattice guide abo"> which guide exactly? did you send me a link?
22:49
Bertl_oO
it's linked under 'Useful Links' in the task
22:49
bluez_[m]
oh ok ok i see it
22:51
bluez_[m]
i should hv probably gone through the links first... but anyway... your explanation was way more approachable... i can dig in now
22:51
bluez_[m]
thanks a lot!
23:04
Bertl_oO
you're welcome!
23:22
aombk2
joined the channel
23:23
intracube
left the channel
23:23
apoorva_arora_
joined the channel
23:23
apoorva_arora
left the channel
23:23
apoorva_arora_
changed nick to: apoorva_arora
23:25
aombk
left the channel
23:26
futarisIRCcloud
left the channel
23:27
futarisIRCcloud
joined the channel
23:28
intracube
joined the channel
23:31
bluez_[m]
okay I should go to bed now... I'll continue tomorrow... good night!
23:32
Bertl_oO
nn
23:37
alexML_
left the channel
23:37
alexML
joined the channel