boru has quit [Killed (NickServ (GHOST command used by boru`))]
boru` is now known as boru
thinkfat has joined #openocd
thinkfat_ has quit [Ping timeout: 258 seconds]
tarekb has quit [Read error: Connection reset by peer]
nerozero has joined #openocd
sbach has quit [Read error: Connection reset by peer]
sbach has joined #openocd
Haohmaru has joined #openocd
tchebb_ is now known as tchebb
dreamcat4 has joined #openocd
Hawk777 has quit [Quit: Leaving.]
tarekb has joined #openocd
<tarekb>
Hey Everyone,
<tarekb>
is Tomas Vanek chatting in this channel ?
<PaulFertser>
tarekb: hey :) very rarely
<PaulFertser>
Only on special occassions I guess.
<tarekb>
unlucky me :/
<tarekb>
I wanted to check with him how to proceed on my L5 series, I have got stuck with ~15 change for stm32l4x flash driver
<PaulFertser>
tarekb: he's usually responsive over e-mail.
<PaulFertser>
He can come for a chat if you ask I guess.
<tarekb>
I will try to reach him via mail, it's kinda unfortunate, that he is the only one reviewing my STM32 patches
<PaulFertser>
Indeed. Do you think we can do something to make it better?
<tarekb>
PaulFertser: we are all volunteers here, and we cannot force people to do the review
<tarekb>
and honestly Tom is a very good reviewer, I will check with him as he started reviewing the serie a while ago
<PaulFertser>
tarekb: can we probably hire someone trustworthy for a specific task?
<olerem>
specialisation make sense, it is reducing learning overhead for the volunteers. For example i feel my self more specialized on the mips topics, so i mostly never review anything arm related
<olerem>
tarekb: in case you need to speedup reviewing/mainlining process and your company have budget for this tasks, then contracting some one would make sense
<tarekb>
PaulFertser: honestly, I dunno.
<tarekb>
there is a lot of people paid by some companie to do a specific task and unfortunately does not help on other topics
<PaulFertser>
tarekb: yep :( and they often have surprisingly little clue too.
<tarekb>
ST is paying for me
<tarekb>
SIFive for Tim
<tarekb>
....
<tarekb>
and everyone is working in his corner
<tarekb>
time to time I try to fix/add things not related to STM32 like the autocompletion and other stuff
<ildar[m]>
<zapb_> "ildar, I don't what you mean...." <- sorry, I found the problem in my code. The RTT down channel works fine.
<olerem>
well, we can decide to go best effort strategy and do not reveiw patches too deep
<olerem>
similar strategy which is done on netdev kernel
<tarekb>
orelem: this may work, but not for changes like the ADIv6 support as is touches all arm cores
<olerem>
ack
<tarekb>
orelem: so this is up to the reviewer to decide if this worth notpicking or not
<PaulFertser>
ildar[m]: anything worth improving in the docs probably?
<tarekb>
Antonio, is proposing for a 0.12.0 end of this year
<olerem>
tarekb: sure, it is always about reviewer. The question is, are we ready to accept regressions? how match testutomation do we have?
<tarekb>
so we need to encourage people to push their changes, but we still need to review the existing and upcomming code
<tarekb>
orelem: none, zero public automation
<ildar[m]>
PaulFertser: I donr
<olerem>
i know, how about non public?
<tarekb>
in ST we have a farm that tests a huge set of STM32 devices mainly cortex-m and the MP1
<ildar[m]>
I don't think so. Completely my fault.
<olerem>
tarekb: openocd tests?
<tarekb>
yes
<PaulFertser>
ildar[m]: thanks for letting us know
<tarekb>
maily functional test with gdb attached
<tarekb>
orelem: it's better than nothing ;)
<olerem>
ack
<olerem>
i'm just thinking on how to continue
<tarekb>
orelem: last year I had a trainee and his work was to automate some deep tests for cortex-m, the work have not finished due to covid situation
<tarekb>
I will try to finish it, but this will require some time
<tarekb>
PaulFertser: do you have some idea on how to automate the testing ?
<olerem>
kind of like kernel-ci :D
<PaulFertser>
tarekb: not really. I think regressions are not too bad if we care to fix what's reported. OpenOCD is targetting developers so it shouldn't be problematic for people to try older/different versions and report bugs.
<tarekb>
orelem: PaulFertser: maybe we can go fast reviewing/merging in a defined period, then go to code freeze, and concentrate only on fixes
<tarekb>
preparing the 0.12.0
<olerem>
i do not really care about releases, it is different problem :)
<olerem>
or not even a problem, at least for me
<olerem>
the challange is the path: developer -> reviewe -> mainline
<PaulFertser>
tarekb: btw, I have to plan migration of gerrit+jenkins in the coming weeks. We only have time till 7th Sep and then Gerrit GitHub OAuth will stop working.
<olerem>
we can decide, changes related to user interface: new commands, etc.. need better review. Since we will need to keep it some how.
<olerem>
changes hidden under hood, should be compilable and not crazy from first look. sure it can have bugs.. it happens all the time :)
tomtastic has quit [Ping timeout: 268 seconds]
<tarekb>
orelem: ack
<tarekb>
I agree, and we need other people participating
<tarekb>
I will try to participate more in reviews
<olerem>
it would be wellcome to have kernel like MAINTAINERS file and scripts/get_maintainer.pl script
<tarekb>
orelem: is this a list of developpers or reviewers ... ?
<olerem>
tarekb: this is of peaple who more or less often deals with this HW and able to say, ACK, this code looks ok for me and for my HW
<olerem>
if you send a patch, you address this patch to list of peaple who have anough competence to review it
<tarekb>
Oleksij, I was mistyping your nick the full day (olerem)
<tarekb>
olerem: nice !!! I see your name in 4 locations here
<olerem>
ack
<tarekb>
I have never gone this deep, maybe one day I will work on linux stuff
<tarekb>
curently my open source contribution is all about OpenOCD
<tarekb>
and it's already time consuming :'(
<olerem>
tarekb: sure, can you imagine how mach time it consume on the reviewers side it is at the end there is no time to develop things, only reviewing it :D
w00tSpeaks has quit [Quit: Konversation terminated!]
w00tSpeaks has joined #openocd
<tarekb>
olerem: I do fully feel the struggle
<tarekb>
sorry I need to go offline, talk to you soon
tarekb has quit [Quit: Leaving.]
tomtastic has joined #openocd
tarekb has joined #openocd
<zapb_>
ildar[m], nice!
<tarekb>
hey PaulFertser:
<tarekb>
I'm wondering if it's possible to get the concerned flash bank from -gdb-flash_write-start event
<PaulFertser>
tarekb: you mean in Tcl?
<tarekb>
yes
<tarekb>
I'm using a device with multiple flash banks, and I want to identify which bank is concerned by this event
<borneoa_>
tarekb: I don't think the bank is passed to the handler. There is a trick to change current target before entering in an event, but no other info...
<PaulFertser>
tarekb: I also suggest to do "set debug remote 1" in GDB to see what GDB sends
<tarekb>
PaulFertser: gdb sends the address, and the buffer to write, and we can't get the address in the event handler as well
<tarekb>
borneoa_: I can't foresee a solution currently, I will check if I can propose a patche to expose some variable in event handlers
<PaulFertser>
tarekb: I guess it's not too hard to extend the handler to get that info. But why do you want it in the first place?
<tarekb>
PaulFertser: I'm working on STM32L5 with 3 defined banks, and I want get the flash bank that gdb is writing to, in order to do a specific initialisation to that bank
<tarekb>
PaulFertser: I have a workaround (with some TCL scripting and assumptions), but I wanted to check, maybe I'm missing an existing features to simplify my configuration file
<PaulFertser>
tarekb: but why do you need to do initialisation in Tcl?
<tarekb>
PaulFertser: when Trustzone is enabled and RDP level is 0.5, I want to disable the flashloader using a new command I have introduced in #6273
<braunr>
olerem: my main task as a team "expert" is reviewing other's code :(
<tarekb>
as Tomas is suggesting to let the user decide to disable the loader or not, as he can provide the correct non-secure RAM as workarea
<tarekb>
but within the IDE, I want to have a default always working behavior
<PaulFertser>
tarekb: if you count on that event handler how is normal "program" (without GDB) going to work?
<PaulFertser>
The one you call when you run openocd -c "program /path/to.elf verify reset exit"
<PaulFertser>
I think the experience should be consistent between these two ways of flashing.