summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20200806-core-chatlog
blob: 28e4d932e79f59b676a13c0fc2b2e353d3b5a63a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
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