diff options
| -rw-r--r-- | wiki/Chat_log/20200806-core-chatlog | 147 |
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 |