<Xogium>
uh… can someone help me with this board ? I'm trying to connect openocd to the st-link chip on stm32mp157f-dk2 dev board from st and the hardware keeps resetting itself so it makes openocd polling fail
<Xogium>
I'm trying to attach openocd to diagnose a boot issue because even earlyprintk has been useless in linux
<Xogium>
I uh
<PaulFertser>
Xogium: hm, stlink is probably good only for cortex-m, not cortex-a
<PaulFertser>
I'm almost sure
<Xogium>
think ATF might be the one pulling the carpet inder my feet
<Xogium>
*under
rkta has quit [Quit: nyaa~]
<Xogium>
well if it is really only useful for the cortex-m inside, this is going to be quite annoying
<Xogium>
jtag was my last resort
<PaulFertser>
Xogium: stlink is not proper jtag and is not even proper swd :(
<PaulFertser>
Xogium: I'd like to see full serial log of a boot attempt.
<Xogium>
I'm not seeing what could be missing there…
<Xogium>
well, in mine rather
<Xogium>
for all I know it's something extremely stupid
<PaulFertser>
Xogium: I see in the good log they use initramfs and some essential drivers (such as interrupt controller and pinctrl) load only after some modules are loaded apparently.
<Xogium>
hmmm
<Xogium>
in the logs from stackoverflow you mean ?
<PaulFertser>
Probably related to "remoteproc remoteproc0: releasing m4" ? I have no idea what role m4 plays in the boot.
<PaulFertser>
Yes, I hope borneoa_ can help you here, he's plenty of experience with that target.
<Xogium>
I don't think it plays any role, its just idling away in case you might need it
<borneoa_>
Cortexm4 is not involved in the boot
<PaulFertser>
I'd say it's odd only after initramfs does something the pinctrl driver probes, that seems sick, but that's what works.
<Xogium>
well for all we know they built that as module so it waits because it is in the initramfs ? I dunno
<Xogium>
I can't seem to modify this thing because I apparently deselected a platform it requires, what the hell
<Xogium>
yocto config has 1024, mine has 512
<Xogium>
why would that config option depend on very specific arm platforms ?
<borneoa_>
Xogium: I don't know, it's the first stuff I found on gpio comparing the two configs
<borneoa_>
Still comparing... Big difference
<Xogium>
yeah… might not be related but… even so this is kinda weirdly specific
<Xogium>
yeah, very big differences. Kinda why I didn't feel like applying the fragments then wading through to figure out what I actually don't need
<Xogium>
even the fragments themselves are big
<borneoa_>
This I think is important, missing COMNFIG_COMMON_CLK_SCMI. latest tf-a uses scmi.
<Xogium>
hmmm
<Xogium>
yep sounds sensible
<Xogium>
let me toggle that
<borneoa_>
Just to verify your build process, try recompile your kernel source with the .config from ST installation. I see you are also on a newer GCC, but that should be ok
<borneoa_>
Check also other scmi related flags
<Xogium>
shall do
<borneoa_>
That's the onli scmi related stuff missing
<Xogium>
ok time to build this
Bertl is now known as Bertl_oO
<borneoa_>
Just to be sure, I've just checked. The initrd provided by ST does not include any kernel module. This is probably done to let user change kernel with no needs to make a new initrd. But this means that the kernel should have embedded all it needs. No modules can be loaded till the rootfs get mounted
<Xogium>
right
<Xogium>
I have very little modules in my own initramfs, certainly none that are vital
<Xogium>
the most critical stuff I built-in
<PaulFertser>
borneoa_: what would be the explanation for "Pinctrl STM32 initialized" to appear long after "Freeing initrd memory: 3548K"?
<Xogium>
ok time to flash this kernel. I've got 2 builds, one with the st config and the other with mine but with that scmi stuff enabled
<borneoa_>
I don't know, need to investigate. The initrd is compressed. Maybe it just show the freeing of the compressed ram space after it is decompressed. Can be confirmed checking the size of the compressed initrd.
<borneoa_>
Xogium: in the folder /boot/ you can put two set of uImage initrd and dtb. Then at boot, U-Boot gives you the possibility to select among them. It's quite useful to test a new kernel. The only issues are : size of /boot partition and modules in /lib/
<Xogium>
borneoa_: how do you tell it which one to pick ?
<Xogium>
I'm not familiar with u-boot I must say… this bootloader kind of hurts my brain far more than barebox ever did
<Xogium>
but I cannot use barebox with st ATF and kernel yet, because scmi
<borneoa_>
In /boot there are few text config files
<borneoa_>
I'm not at my PC. I will send you more details later
<Xogium>
thanks :)
<Xogium>
out of curiosity, how did you get so familiar with the mp1 ?
<borneoa_>
Xogium: I work for ST on mp1
<Xogium>
oh wow
<Xogium>
this is awesome :)
<Xogium>
borneoa_: sweet jesus it works. Sort of :D. I now can't boot properly but this is more due to kernel or systemd misconfiguration there, but I have console
<Xogium>
borneoa_: I'm in your debt. XD
<borneoa_>
Cool!
<Xogium>
yeepi
<borneoa_>
Stay on IRC, I will send you the instructions for dual boot in 30 minutes
<Xogium>
borneoa_: if you don't mind me asking, on what section of the mp1 do you work on ? Hardware ?
<Xogium>
borneoa_: I shall
<borneoa_>
Xogium: currently on sw customer support, but not directly on the front line; other colleagues filter most of the issues and I get the crappiest issues that need more time or interaction with developers. I will move to dev shortly. And I also take care of openocd for mp1.
<Xogium>
heh this is still very cool
<Xogium>
;) never thought I'd meet someone working on the mp1
<borneoa_>
So, this is what I usually do when test new kernel or DT. In /boot I make a copy of ST's uImage and <board>.dtb. "cp uImage{,.ok}", "cp <board>.dtb{,.ok}" and same for st-image-resize-initrd. Then edit /boot/mmc0_extlinux/<board>_extlinux.conf and I duplicate the section "LABEL OpenSTLinux" as "LABEL recovery", and make the latter point to the files .ok .you need to add the line for the dtb, otherwise uses the default one.
<borneoa_>
At this point you are free to change the uImage, dtb and initrd with you built one. Rebooting the recovery gives you an ssh through USB and you can easily SCP the new files
<borneoa_>
The selection of what to boot is done by U-Boot. A menu is printed, you have to enter the number of the boot option
<Xogium>
borneoa_: nice
<Xogium>
thanks :)
<Xogium>
I will try this way
<karlp>
gak. c++ is too good at protecting me. I tried to pull up a function to a class, and it's all "discarding qualifier! nooooo" and I hate the dancing of figuring out hwo to try and make what const and what not.
<karlp>
horror
<Haohmaru>
aww
<Haohmaru>
were you sprinkling const?
<karlp>
yeah, but that made other existing things get upset
<karlp>
doh, wrong channel anyway
<PaulFertser>
borneoa_: I wonder if Xogium's problem means some Kconfig dependency should be added.
<PaulFertser>
borneoa_: btw, what do you think about Tim's message regarding riscv review to the mailing list?
<borneoa_>
PaulFertser: if the problem is scmi, the dependency is with tf-a so outside the kernel. I mean, tf-a need scmi, no other link inside kernel kconfig
<Xogium>
well then how did I miss the clk_common_scmi stuff ?
<borneoa_>
PaulFertser: I'm quite busy recently, I had no time to run reviews on gerrit
<Xogium>
looks like scmi handles a TON of stuff, from power management to uart clock to watchdog
<borneoa_>
Xogium: kernel for tf-a need scmi stuff. The same kernel with scmi can run without tf-a but needs a different DT.
<Xogium>
hmm so that's why it isn't explicitly selected ?
<borneoa_>
Not part of default armv7 build
<Xogium>
right… that's what got me
<key2>
PaulFertser: ping?
<Haohmaru>
random question: esp8266 support?
<Haohmaru>
(asking for a friend)
<PaulFertser>
key2: pong
<key2>
I thought about implementing a jtag controller in a FPGA, connected to a ARM cpu over PCIe for example. What should the JTAG controller core do in order to make it the most efficient ?
<GyrosGeier>
we built one that was very efficient
<key2>
GyrosGeier: controller in a FPGA ?
<GyrosGeier>
it had conditionals like "send this pattern to a 33 bit DR, read back at the same time and if the last bit is clear, repeat"
<GyrosGeier>
yes
<key2>
ah ok
<key2>
that's what I wanted to do
<key2>
yours is open source ?
<bencoh>
by jtag controller, you mean jtag adapter~?
<GyrosGeier>
basically, a construct like that allows us to wait for a memory transaction on ARM to finish
<GyrosGeier>
ours isn't open source, no
<key2>
ok
<GyrosGeier>
also, I think it's no longer sold
<key2>
oki
<GyrosGeier>
but we managed 4 MB/s download to an ARM7, and 3 MB/s to an ARM9
<key2>
and if the taps were chained ?
<key2>
how would it handle that ?
<PaulFertser>
There're some drivers for JTAG over PCIe sent to the mailing list, and one of them is upstream.
<PaulFertser>
src/jtag/drivers/xlnx-pcie-xvc.c
<key2>
PaulFertser: interesting.
<GyrosGeier>
for chained taps, we had commands to add N '1' bits as pre-/postamble
<PaulFertser>
key2: I do not know anything more than was written there in source code and Gerrit discussion
<key2>
PaulFertser: that's already a good start
<GyrosGeier>
N being the sum of the IR lengths or the number of ICs on the chain (for DR)
<GyrosGeier>
the bypass chain is always 1 bit, so
<GyrosGeier>
and the bypass IR is always all-ones
<key2>
ok
<key2>
GyrosGeier: it was using openocd ?
<GyrosGeier>
no, proprietary stack
<GyrosGeier>
since we integrated into Windows CE Platform Builder
<key2>
PaulFertser: that's interesting, looks like it was a xilinx fpga on the PCIe bus, without any driver :) they access it directly by the bus
<GyrosGeier>
which has an actual demand for high transfer speeds, because they pull 500kB of data when they hit a breakpoint
<key2>
and it would interrupt by itself when DR would have a value and you are reading for example?
<GyrosGeier>
I still wonder about the JTAG signals on the PCIe connector, what are these used for and by whom?
<GyrosGeier>
yes
<GyrosGeier>
a loop running in the fpga that polls the ICEbreaker status
<GyrosGeier>
and makes sure to pass through RUN-TEST/IDLE
nerozero has quit [Ping timeout: 256 seconds]
Platin21 has joined #openocd
<Platin21>
Anyone online here?
<Platin21>
I'm on the search for help with the usb location i dunno why openocd has no command to show all of them in there format but it seems like it's not easily set able to anything one would want. As i have a usb device on ftdi_sio 1-6:1.1 and that is not reconginzed
<Haohmaru>
you want to list usb devices? what OS?
<Platin21>
I'm on linux, it's lsusb -t there the docs say
<Haohmaru>
yeah-ish
<Platin21>
But that is not my problem the problem is getting openocd accepting the bus
<Platin21>
But that is not my problem the problem is getting openocd accepting the bus
<Platin21>
|__ Port 2: Dev 50, If 2, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
<Platin21>
|__ Port 2: Dev 50, If 0, Class=Vendor Specific Class, Driver=usbfs, 480M
<Platin21>
|__ Port 2: Dev 50, If 3, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
<Platin21>
|__ Port 2: Dev 50, If 1, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
<Platin21>
|__ Port 3: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 12M
<Platin21>
|__ Port 4: Dev 7, If 0, Class=Vendor Specific Class, Driver=usbfs, 480M
<Platin21>
|__ Port 6: Dev 72, If 2, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
<Platin21>
|__ Port 6: Dev 72, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
<Platin21>
|__ Port 6: Dev 72, If 3, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
<Platin21>
|__ Port 6: Dev 72, If 1, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
<Platin21>
Now port 6 houses a ftdi and port 2
<Platin21>
Referred by lsusb as => /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M (children are above)
<Platin21>
So i would have expected it taking 1-1.6 but it doesn't do that says no device on the bus
<PaulFertser>
Platin21: did you check the official user manual regarding that, is it really lacking the instructions?
<Platin21>
Config Command: adapter usb location [<bus>-<port>[.<port>]...]
<Platin21>
Displays or specifies the physical USB port of the adapter to use. The path roots at bus and walks down the physical ports, with each port option specifying a deeper level in the bus topology, the last port denoting where the target adapter is actually plugged. The USB bus topology can be queried with the command lsusb -t or dmesg.
<Platin21>
This command is only available if your libusb1 is at least version 1.0.16.
<PaulFertser>
Platin21: btw in the future please do not paste more than two lines it the channel, use some pastebin instead.
<PaulFertser>
Platin21: please show full lsusb -t output via pastebin
<Platin21>
Not possible sadly as i need to have both devices connected with openocd. ESP32 has some weird way to get the debug info via jtag
<Platin21>
If you have a idea how i can match it else for two identical boards i'm open to the answer PaulFertser
<PaulFertser>
Platin21: I do not say you need just one device connected.
<PaulFertser>
Platin21: I say that if you match by usb location you do not need match by serial.
<PaulFertser>
Platin21: two boards shouldn't have same serial
<Platin21>
You mean not matching the vendor id etc. yeah
<PaulFertser>
Platin21: I mean either matching serial '6009C3E1E2A4' or matching usb location.
<PaulFertser>
Platin21: it looks like it should be 1-6, not 1-1.6
<Platin21>
Ahh yeah i see my fault:) Thanks
<PaulFertser>
Port 1 there is for the hub itself
<PaulFertser>
Platin21: but why do you really need both serial and location?
<Platin21>
It's a weird test where these ports can change
<Platin21>
Many thanks anyways took me quite some time to figure that out ..
Platin21 has quit [Quit: Client closed]
<PaulFertser>
borneoa_: do you think I could do anything so that OpenOCD stays healthy?
<borneoa_>
PaulFertser: don't know. What do you have in mind? I think we mainly need people reviewing patches in gerrit. Then need some spare time to confirm the review and merge.
<PaulFertser>
borneoa_: I'm not sure, probably OpenOCD can e.g. fund all your Fridays and you'll have an official day off at ST or something like that?
<borneoa_>
PaulFertser: in last weeks I was remaking the ADIv6 series during some limited spare time. I hope to return on gerrit soon
<borneoa_>
PaulFertser: that's what you mean... I think it would be difficult with my current french contract to have 2 official activity.
<PaulFertser>
borneoa_: that's one of the possibilities I guess. Probably someone comes with other ideas one day. You're doing amazing work all around the codebase, I think your involvement gave the project a huge boost.
<Xogium>
well… I also just found out why my neat dracut script designed to facilitate the use of a writable overlayfs with a read-only rootfs wasn't working
<Xogium>
I learned that 'function' isn't a standard shell word
<Xogium>
it's at the very least a bashism
<Xogium>
you learn something new every day :p
xytx has joined #openocd
<borneoa_>
PaulFertser: I have started some discussion with my manager to make my involvement in openocd more "formal", having some kind of work time allocated to openocd. I don't know if and where that talk will land. I will keep you updated. Anyway if you think you can identify some sponsorship, there could also be someone else interested in your proposal.
<borneoa_>
PaulFertser: recently there is quite some noise in the news about opensource projects with not enough resources to guarantee maintainers job. And openocd shares this same common problem...
<borneoa_>
key2: the openocd driver xlnx-pcie-xvc is not for a real jtag interface. In xilinx FPGA is possible to map some arm core, and the debug bus (arm adi) can be accessible through the PCIe interface of the FPGA. So plugging the FPGA board ina a PC you can debug the core in the FPGA without using a jtag interface. Not really what you want to do...
<key2>
you are right
<key2>
I will make a jtag controller core that is a bit smart
Haohmaru has quit []
klys has quit [Ping timeout: 250 seconds]
Slide-O-Mix has quit [Ping timeout: 240 seconds]
klys has joined #openocd
xytx has quit [Quit: Leaving]
Slide-O-Mix has joined #openocd
ericonr has quit [Quit: WeeChat 3.3]
ericonr has joined #openocd
Krazubu has joined #openocd
Steffanx- has joined #openocd
Krazubu has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
Krazubu has joined #openocd
Krazubu has quit [Client Quit]
indy has joined #openocd
<douardda>
hi, I'm still trying to figure if I can make something from a cc2630 based eink label
<PaulFertser>
Hi
<douardda>
I've been able to dump the flash and RAM, and to load a simple hello world program (using contiki)
<PaulFertser>
Sounds like helluva progress
<douardda>
(ti dev environment for these chips is a nighmare)
<douardda>
(anyway)
<douardda>
my problem is the jtag connexion is pretty unstable
<douardda>
I often have to try several times to get the tap enabled
<douardda>
and while palying with gdb, I very often end up with openocb screaming a lot of 'openocd Invalid ACK (7) in DAP response JTAG-DP STICKY ERROR'
<douardda>
errors
<douardda>
where should I look to make it more stable?
<PaulFertser>
Do you have an oscilloscope to check signal integrity?
<douardda>
(I am using a cheap FT232H)
<PaulFertser>
Do you have resistors in series on all data lines to supress ringing?
<douardda>
PaulFertser: I do have a scope yes (2 actually)
<douardda>
PaulFertser: I have no termination resistors (nor serie ones)
<douardda>
but I am currently using a slow rate (100khz) and it does the same thing (started at 1mhz)
<PaulFertser>
douardda: you might try adding them. All JTAG adapters usually have something like 47 Ohm there, source termination style.
<douardda>
ok will try that
<douardda>
thank a lot
<PaulFertser>
douardda: ringing happens on every edge
<douardda>
I imagine yes
<PaulFertser>
douardda: so unfortunately it sometimes doesn't matter how slow you go.
<PaulFertser>
douardda: also sometimes just adding more ground lines between adapter and the target helps.
<douardda>
indeed, it's the raising times that matter
<douardda>
not the frea
<douardda>
freq
<PaulFertser>
With standard jtag flat cable gnd is every second line.
<douardda>
ok I'll dig this hole
<douardda>
(but tomorrow, it's getting a bit late here)
<douardda>
thanks a lot
<PaulFertser>
douardda: I suggest you check the signals with an oscilloscope first.