wiki: Add Core chatlog for 2020-08-06

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

1 files changed, 147 insertions, 0 deletions

diff --git a/wiki/Chat_log/20200806-core-chatlog b/wiki/Chat_log/20200806-core-chatlog
new file mode 100644
index 0000000..28e4d93
--- /dev/null
+++ b/wiki/Chat_log/20200806-core-chatlog
@@ -0,0 +1,147 @@
+09:34 < marex> morimoto: shimoda: hi, I was curious, is there some extra documentation for the bootrom ? esp. the IPL A/B switching mechanism ? I recall the security LCS stuff in TFA implements some calls into bootrom, so maybe there is some list of bootrom functions you can call from your own system software ? is there some internal renesas documentation for that ?
+09:35 < marex> I mean, there must be some way to push the bootrom to boot the IPL Bcopy, right ?
+09:35 < geertu> marex: Sounds like Core?
+09:35 < wsa> then, let's switch over to core. Zebax adapters fit there, too, if we want to keep the topic ;)
+09:35 < wsa> geertu: have fun!
+09:36 < geertu> wsa: Na, Samtec is I/O ;-)
+09:36 < geertu> Welcome to today's Core Group Chat Meeting!
+09:36 < geertu>    
+09:36 < geertu> Agenda:
+09:36 < geertu> 1. Status Updates
+09:36 < geertu> 2. Discussion Topics 
+09:37 < geertu> Topic 1. Status updates
+09:37 < geertu> A) What have we done since last time:
+09:37 < geertu> Marek worked on U-Boot (late driver teardown and SH4 fixes).
+09:37 < geertu> Morimoto-san is considering a remote-access-system for COVID-19.
+09:37 < geertu> Ulricht figured out i2c/wdt ordering for system restart.
+09:37 < geertu> Geert attended ELC-NA, Reviewed RZ/G2 patches, investigated QEMU GPIO
+09:37 < geertu> virtualization review suggestions, sent pull requests for v5.9, and
+09:37 < geertu> enjoyed Summer Holidays.
+09:37 < geertu> B) What we plan to do till next time:
+09:37 < geertu> Marek plans to upstream CI test hooks for SH4 QEMU.
+09:37 < geertu> Shimoda-san plans to convert the usb2-clock doc to json-schema, and
+09:37 < geertu> start R-Car V3U initial support.
+09:37 < geertu> Ulrich plans to follow-up i2c-sh_mobile atomic transfer work, and
+09:37 < geertu> implement the same for i2c-rcar.
+09:37 < geertu> Geert plans to do more DT binding doc conversions, and continue QEMU
+09:37 < geertu> GPIO virtualization.
+09:37 < geertu> (oops, looks like I included some I/O work)
+09:38 < geertu> C) Problems we have currently:
+09:38 < geertu> Geert is struggling with describing multi-level sh-pfc subnodes in
+09:38 < geertu> json-schema, and discovered the QEMU GPIO virtualization review
+09:38 < geertu> suggestions turned out to be unfeasible.
+09:39 < geertu> ----EOT---
+09:39 < geertu> Anything I missed?
+09:39 < geertu> morimoto: I'm looking forward to anything easing remote control of boards.
+09:39 < morimoto> Yes, same here
+09:39 < morimoto> but it is under discussion
+09:39 < morimoto> now. no guarantee yet
+09:40 < morimoto> marex: I have no idea. shimoda: do you know that ?
+09:40 < geertu> You're aware Salvator-XS and Ebisu already provide all required signals for power/reset control on EXIO-D?
+09:40 < morimoto> geertu: thank you for your help about v5.x booting
+09:40 < geertu> Cfr. https://elinux.org/R-Car/Boards/Salvator-XS#Remote_Control
+09:41 < geertu> You still need something to control main power, and provide the signals, so perhaps that's what "GPIO power/reset control" will be about on future boards?
+09:41 < geertu> morimoto: You're welcome. The ability to boot boards is critical ;-)
+09:42 < geertu> Topic 2. Discussion Topics
+09:43 < geertu> A) IPL A/B switching
+09:43 < geertu> marex: ^ ;-)
+09:43 < marex> geertu: maybe if you could easily test your IPL before doing actual update, and with the ability to fall back to known working version by plain reboot ...
+09:43 < marex> geertu: ... then people would finally ditch their old IPL and old U-Boot :-)
+09:44 < geertu> marex: If only it supported H3 ES1.x...
+09:44 < marex> geertu: and that easy test might be for example by being able to easily boot a B-copy of IPL ...
+09:44 < shimoda> marex: As I wrote an email, IPL A/B feature is in secure boot
+09:44 < shimoda> so, I don't think we can use IPL A/B in normal boot
+09:44 < morimoto> geertu: we are considering for next new M4 board
+09:44 < geertu> morimoto: BTW, what's M4?
+09:44 < geertu> A, R-Car M4-something?
+09:45 < marex> shimoda: isn't there some function call you can do to the bootrom, which would tell it to load the initial SA0 certificate from different location for example ?
+09:45 < wsa> GeM4
+09:45 < wsa> ?
+09:45 < marex> shimoda: or , patch the existing SA0 certificate in OCRAM at 0xe6300400 with the B-copy flag and then make bootrom start loading from that, without reloading the certificate ?
+09:46 < morimoto> geertu: R-Car Gen4 M4-x board.
+09:46 < marex> shimoda: there is https://github.com/ARM-software/arm-trusted-firmware/blob/master/drivers/renesas/rcar/rom/rom_api.c
+09:46 < geertu> morimoto: Cool!
+09:46 < marex> shimoda: and that is some function call API to the bootrom itself
+09:47 < marex> shimoda: so there clearly are some functions exported from the bootrom, and I wonder if maybe, there is a function which allows me to do the above :-)
+09:47 < geertu> marex: Oh, that code does support H3 ES1.x
+09:47 < marex> shimoda: in fact, is there a documentation which describes those bootrom functions ?
+09:47 < wsa> morimoto: Cool, in deed! First time I hear about Gen4 becoming real
+09:47 < marex> geertu: upstream ATF doesnt support H3 ES1.x, nor does upstream U-Boot
+09:50 < morimoto> wsa: geertu: morimoto is the man who can fulfill your dreams
+09:50 < marex> morimoto: do you still plan to run ATF-UBoot-Linux on that ?
+09:51 < neg> marex: haha :-)
+09:51 < neg> s/marex/morimoto/ about the fulfillment of dreams
+09:52 < shimoda> marex: sorry, I don't understand what should i do about IPL A/B
+09:52 < morimoto> neg: :)
+09:52 < marex> shimoda: so, look at that rom_api.c code first
+09:52 < wsa> morimoto: but it means a lot of paperwork for you again... :/
+09:52 < marex> shimoda: it seems that this allows ATF to call bootrom functions
+09:52 < morimoto> marex: maybe, but not sure detail
+09:52 < marex> shimoda: hence, there is likely a list of all such callable bootrom functions somewhere in renesas
+09:53 < morimoto> wsa: yes :(
+09:53 < marex> shimoda: and I wonder, can you share that list / document ?
+09:53 < kbingham> marex, if ATF does support H3ES1.x (as listed in that table) does that mean I can update the firmwares/uboot on this gmsl board? or is uboot a hard blocker.
+09:54 < marex> shimoda: and if not, can you look into that document and tell me whether there might be a function which allows me to skip reloading the SA0 certificate from HF and continue using the one in DBSC4 SystemRAM 0xe6300400 address instead , after reboot ?
+09:54 < marex> kbingham: 07:47 < marex> geertu: upstream ATF doesnt support H3 ES1.x, nor does upstream U-Boot
+09:54 < kbingham> marex, <geertu> marex: Oh, that code does support H3 ES1.x
+09:55 < marex> kbingham: so if it was added and tested, you could
+09:55 < kbingham> my question is given ATF has tables for H3ES1, does that mean there is a chance uboot will work, or it will need development.
+09:55 < morimoto> \me I need to quit soon for next Renesas meeting
+09:56 < marex> kbingham: its untested, so backup your HF and test it if you want :)
+09:56  * morimoto n?
+09:56  * morimoto I need to quit soon for next Renesas meeting
+09:56 < wsa> then, next meeting?
+09:56 < marex> morimoto: good bye :(
+09:56 < wsa> Aug, 27th?
+09:57 < geertu> I was just going to aak: 3 or 4 weeks?
+09:57 < geertu> s/aak/ask/
+09:57 < kbingham> 27th is listed as Linux Plumbers (virtual) in my calendar
+09:57 < morimoto> marex: I will miss you...
+09:57 < marex> awwwww
+09:57 < kbingham> morimoto, you can't go ... I didn't get to tell you that GMSL is headed upstream yet though ;-)
+09:57 < kbingham> hehe
+09:57 < wsa> Is Sep, 3rd better? It is fine for me
+09:57 < geertu> both a re fine for me.
+09:57 < geertu> Plumbers is in the afternoon/evening, right?
+09:58 < kbingham> morimoto, Well, ok so I've told you now so you can go if you need ;D
+09:59 < wsa> morimoto, shimoda: any preference for the next meeting?
+09:59 < morimoto> kbingham: nice to know :)
+10:00 < geertu> wsa: let's decide by email, as pinchartl isn't here
+10:00 < morimoto> wsa: 27th Aug, 3rd Sep, both are OK for me
+10:00 < wsa> geertu: good idea
+10:00 < wsa> morimoto: so, enjoy your meetings!
+10:00 < wsa> ;)
+10:00 < geertu> Anything else to discuss?
+10:00 < morimoto> wsa: thanks, and bye
+10:00 < morimoto> exit
+10:00 < shimoda> marex: now I understood a bit :) Renesas BSP doesn't have rom_api.c, but Baylibre submitted it. So, Renesas has a document which can share to someone for secure boot. OK, I'll ask a person in Renesas later.
+10:00 < morimoto> oops
+10:01 -!- morimoto [~user@FL1-119-240-85-188.iba.mesh.ad.jp] has left #periperi ["ERC (IRC client for Emacs 26.3)"]
+10:02 < marex> shimoda: thank you, really appreciated :)
+10:02 < geertu> Thanks for joining, and have a nice continued day!
+10:02 < shimoda> perhaps, next meeting at 27th?
+10:02 < shimoda> or, 3rd, Sep?
+10:02 < marex> shimoda: see, the thing is, if I could do reboot-into-B-copy, I could also do easy-ish ATF CI testing without weird instrumentation around the boards
+10:02 < shimoda> by the way, I used 2 laptop PCs, I can join both this meeting and Renesas internal meeting :)
+10:03 < geertu> shimoda: smart ;-)
+10:03 < shimoda> geertu: :)
+10:03 < kbingham> geertu, Just digging for timezone of plumbers. Has it been announced? My registration just says "Timezone: TBD"
+10:03 < geertu> Who takes the mic for MM? kbingham?
+10:03 < shimoda> marex: I understood your expectation. thanks!
+10:04  * kbingham fumbles in the air ready to catch.
+10:04 < geertu> kbingham: It was originally planned to be held in US, right?
+10:04 < geertu> ELC-NA was in NA timezone
+10:04 < kbingham> geertu, I think there was a vote for preferred timezone of the virtual event, so they were going to make a decision on that.
+10:04 < marex> shimoda: besides, we are lagging behind even NXP in this department
+10:04 < kbingham> But I didn't see the decision results yet.
+10:05 < marex> shimoda: NXP iMX can do this A/B copy update since iMX5x, which is like 10 years old now, we should improve
+10:06 < shimoda> marex: thanks for sharing information about iMX
+10:06 < geertu> marex: We have old SoCs. Arnd was wondering about us upstreaming "new" SoCs like RZ/G2H containing 2015-era CA57 ;-)
+10:06 < marex> geertu: iMX51 is CA8
+10:07 < marex> shimoda: sure
+10:08 < kbingham> Ok, so are we ready to head through to the mm room ?
+10:08 < marex> shimoda: its also not any secret or secure feature, its all there in the datasheet, which btw is publicly available
+10:08 < marex> kbingham: yep, I stop here
+10:08  * kbingham waits to grab mic from geertu
+10:09 < kbingham> or maybe I'll just shout without the mic ;-)
+10:09 < geertu> kbingham: mic