The picture in that link is not available:
Now it is, thanks for fixing it =)
Hi, Julian.
I was able to boot the RPI with the image you provided, and I connected the RPI to the IPMC development bed following the pin mapping suggested. However, I am getting the following error:
pi@raspberrypi:~ $ flashipmc
[Progress] 10%
{'details': {'file': '/home/pi/ipmc-tester/ipmc-tester/../ipmc-config/stapl/20200928_cern_ipmc.stp'},
'measurements': [{'data': {'s': 'Init', 'v': 244.45676803588867},
'name': 'timer',
'pass': 0}],
'name': 'jam_player_program',
'pass': -1,
'summary': {'duration': 244.79293823242188,
'exitcode': -1,
'finalState': -1,
'verbose': 'Init failed - device not found?'},
'test_type_name': 'PROGRAM_v.1.0'}
BTW, the development kit powered up as it should. I will try to debug the setup further, but I was wondering if you have any suggestions since we are in a rush.
One more question: I assume that it will flash the IPMC with some default firmware, right? So in case of troubles, the procedure is: remove the IPMC from the blade, install it in the development kit, flash this default firmware and then return it to the blade to reprogram it as usual. Does this sound correct?
Thanks,
Thiago
Hi, Julian.
I was able to get the recovery setup to work (informing here so you don’t need to spend time on this). I was able to recover a bricked IPMC from more than 2 years ago caused by a norollback that failed (no idea why).
Now that I have a way to recover the cards in case of problems, I will proceed with using the norollback option you suggested above for the current issue.
Thiago
Hi Thiago,
Did you manage to switch to v.1.3 ? Did it solve your issue ?
Cheers,
Julian
Dear Thiago,
I was just wondering where you are with updating the IPMC software from 1.2 to 1.3. Any news on the issue of using the IPMC for updating the MMC?
Cheers,
Ralf.
Hello,
I’m also from the NSW and I’m trying to look at the issue since we’re getting closer and closer to running and Thiago is quite busy with other work, too.
However, I’m quite new to IPMC. How should we update the IPMC software? If I ran this command I got
ipmitool -H 192.168.0.2 -P "" -m 0x20 -t 0x72 -T 0x82 -b 7 -B 0 mc info
Device ID : 1
Device Revision : 0
Firmware Revision : 1.07
IPMI Version : 1.5
Manufacturer ID : 28688
Manufacturer Name : Unknown (0x7010)
Product ID : 528 (0x0210)
Product Name : Unknown (0x210)
Device Available : yes
Provides Device SDRs : yes
Additional Device Support :
Sensor Device
FRU Inventory Device
IPMB Event Generator
Rongkun
Hi,
I’m tried compiling with v.1.3.1 tag of ep-ese-be-xtca / ipmc-project · GitLab. However I encounter some error message during utf-8 decoding in line strVar = strVar + chunk.decode("utf-8")
Traceback (most recent call last):
File "compile.py", line 302, in <module>
main(USERNAME, PASSWORD)
File "compile.py", line 270, in main
link = CERNSSORequestInstance.post_stream(URL, data = values, files = files)
File "compile.py", line 134, in post_stream
strVar = strVar + chunk.decode("utf-8")
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe2 in position 0: unexpected end of data
I wonder if the url request returns incorrect data? Are you able to reproduce this error?
Another question I have is should we use false or true in <nonVolatileParams forced="false" /> ?
Best,
Rongkun
Hi Rongkun,
Can you please update your compile.py file to read
strVar = strVar + chunk.decode("utf-8", "ignore")
in line 134?
This was mentioned in issue IPMC Compilation not working and was updated in the ep-ese-be-xtca/ipmc-project gitlab files.
Please let me know if it helps. Cheers,
Ralf
Hi @spiwoks ,
thanks for your comments, the compilation works with your advice. Will it be added to next tag?
Also, from @tcpaiva 's sensor file, I saw that there seems to be some difference in the template when switching from 1.2 to 1.3:
| From v1.2 | → | 1.3 template has changed |
|---|---|---|
| sensor_sfpga_initialize | → | initialize_sensor_sfpga |
| sensor_sfpga_update_reading | → | read_sensor_sfpga (?) |
| sensor_sfpga_fill_reading | → | sensor_sfpga_fill_rd |
I guess we need to switch from the old template to the new? It seems like read_sensor_sfpga and sensor_threshold_update_s together are replacing sensor_sfpga_update_reading to do the sensor value filling?
Another question I have is, concerning Julian’s comment Issue upgrading MMC - #12 by jumendez, how should we set the nonVolatileParams in our config.xml?
Rongkun
Hi @rowang,
I am glad to hear that it works for you now. The patch was already in the master. I made a new tag v1.3.2.
As for the XML file, yes, you’ll have to migrate to the new format as described in README.md · master · ep-ese-be-xtca / ipmc-project · GitLab
When migrating your IPMC card from 1.2 to 1.3, for the first boot, and the first one only, you have to use
ipmitool … activate norollback
Hope this helps. Cheers,
Ralf.
Hi @spiwoks,
thanks. I’m talking about the C files in ipmi-sensor. I guess they need to be changed, too?
the nonVolatileParams is a parameter in the xml though. I’m just curious if it is possibly related to our problem.
<nonVolatileParams forced="false" /> <!-- "false" keeps current non-volatile values
when "true" forces the value to compilation
ones -->
Rongkun
Hi, @spiwoks , @jumendez , @rowang . Sorry for my long radio silence, I had a wrong configuration in my email and missed these messages.
@rowang: first, thanks for bringing this to my attention. Your questions are main related to the MMCs we have in our system. They are not direct related to the IPMC infrastructure we are discussing here. Some functions were deprecated, but most of them still work with warnings (at least up to the version we are using, otherwise no sensor data would be seen). BTW, not sure which repository you are using, since our current repository has NDA files and it is somewhere else.
@spiwoks , @jumendez: Yes, I updated everything to v1.3 (I believe I am even using the v1.3.2, I would need to check). The communication improved and works partially, but we still see problems. Since we did not had the time to debug it further (we don’t know if the problem is in the IPMC side or in the MMC side), I did not get back here.
Thank you all
Hi,
so switching to v1.3 didn’t solve our issue of sdr fill and hpm upgrade for MMC…
Hi Rongkun, hi Thiago,
Thanks for your messages. Good to hear from Thiago after such a long time.
Julian is on holiday, and I am not at all familiar with the use of MMCs. But could you explain to me what it is you are trying to do, what commands you use, and why you conclude it doesn’t work?
We have an MMC emulation on the tester, and might be able to try to test something on that side, although I am not sure the emulation also handles HPM.1 commands …
I am also wondering if there is a way of tapping into the IPMC-L, and see what commands are actually being sent … or debug logging in the IPMC …
Cheers,
Ralf.
Hello Ralf,
A bit more update and good news. We tried single-bridge communication and both hpm upgrade and sdr fill has suceeded with the new version.
Previously we were either using old ipmc software or using dual-bridge communication SHM-IPMC-MMC and failed.
Rongkun
Hi Rongkun,
That is very good news!
For my interest, could you please send me the exact ipmitool commands you are using (you might remove the password though 
).
And could you also tell me what the error messages are when you try it using the double-bridge communication?
I should read the documentation again: I am not sure IPMC allows automatic routing; you probably have to wrap SendMessages in SendMessages providing some kind of static routing, i.e. for every hop you make a new SendMessage request to the address of the next hop …
So, far I have only ever used for a single hop.
Cheers,
Ralf.
Hi Ralf,
Sure the commands are:
# upgrade MMC firmware
ipmitool -H IPMC-MUO-NSW-TPC-01 -P <password hidden> -t 0x72 -b 7 hpm upgrade MMC_Mezanine_Rev1.8_b35.hpm
ipmitool -H IPMC-MUO-NSW-TPC-01 -P <password hidden> -t 0x72 -b 7 hpm activate
<reset cold>
# fill sensor sdr
ipmitool -H IPMC-MUO-NSW-TPC-01 -P <password hidden> -t 0x72 -b 7 sdr fill file mezz_thr_hyst_revc_6_v2.sdr
<reset cold>
The error looks like:
ipmitool -H 192.168.0.2 -P "" -m 0x20 -T 0x82 -b 7 -B 0 -t 0x72 sdr fill file VS_26MezzA.sdr
SDRR successfully erased
ipmitool: partial add failed
Cannot add SDR ID 0x0001 to repository...
ipmitool: partial add failed
...(similar) messages follow for every ID
Rongkun
Dear Rongkun,
Thanks a lot for your reply. That is very interesting! I learned something new: ipmitool actually provides double-bridge commands, i.e. a SendMessage encapsulated in another SendMessage 
Now, why the “sdr fill” command fails, I have no idea. Do you think it could be related to ipmitool - after all, it has to manage a lot of data, split over many different double-bridged messages … 
Does it work if you take a different path, or via a different IPMC implementation?
I have tried simple commands like “fru print” or “sel list”, which do work - but I do not have an MMC, I cheat by going from IPMC → ShMgr → IPMC, I can see it in the debug messages when using “-vvv”
Cheers,
Ralf.
Hi Ralf,
indeed, we tried dual-bridge with some other command like sdr, fru they worked, even faster. But it didn’t work for sdr fill.
I’m not sure if there’s a another path… maybe IPMC-IPMC-MMC in the same crate? I guess some action might fail as well. We didn’t try that. IPMC-ShMgr-IPMC is a cool idea to test, too, but it’s not talking to MMC as you pointed out.
Also the company tried only single-bridge with their own IPMC implementation.
Rongkun
Hi Rongkun,
I was wondering if you had ever seen the “ipmitool … sdr fill” work with a double bridge, e.g. with different hardware, a different IPMC or MMC … It might be that the problem is actually in ipmitool … since it works with a single bridge …
Cheers,
Ralf.