Current Server Time: 00:27 (Central Europe)

#apertus IRC Channel Logs

2020/03/20

Timezone: UTC


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