renesas/periject.git - Renesas periject clone

diff options

author	Geert Uytterhoeven <geert+renesas@glider.be>	2022-04-04 14:20:38 +0200
committer	Geert Uytterhoeven <geert+renesas@glider.be>	2022-04-04 14:20:38 +0200
commit	7e51d78f4effc186d5ae33867f0cc3302c1313ce (patch)
tree	ccf926fae069a344f905e7b502e1e54bc41e4817 /wiki/H3_Salvator-X/update_salvator_bootloader_v2160.tar.bz2
parent	4528e889920d1223142b0319db93e1ddb64520e7 (diff)

Auto-update sweep for v5.18-rc1

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

Diffstat (limited to 'wiki/H3_Salvator-X/update_salvator_bootloader_v2160.tar.bz2')

0 files changed, 0 insertions, 0 deletions

Core-chat-meeting-2017-06-20 10:06 < geertu> Welcome to today's Core Group Chat! 10:06 < dammsan> i've heard that issue before 10:06 < geertu> pinchartl: Does it happen on H3 ES2? 10:06 < dammsan> maybe m3-w don't recall 10:06 < pinchartl> geertu: haha, good joke :-) 10:06 < pinchartl> (I'll tell you when I'll have an H3 ES2.0 board...) 10:06 < geertu> pinchartl: Havenn't you played with H3 ES2 in Tokyo? 10:07 < pinchartl> geertu: not to the point where I could test this properly 10:07 < geertu> Agenda: 10:07 < geertu> 1. Status updates 10:07 < geertu> 2. Core additional tasks 10:07 < geertu> Topic 1. Status updates 10:07 < geertu> A) What have I done since last time 10:07 < geertu> B) What I plan to do till next time 10:07 < geertu> C) Problems I have currently 10:07 < pinchartl> dammsan: if anything comes back to your memory, please let me know 10:07 < dammsan> ok! 10:07 < pinchartl> (now I'll stop hijacking the meeting) 10:07 < dammsan> (same here) 10:07 < geertu> 'sort -R' tells me Niklas is first 10:08 < neg> A) Nothing 10:08 < neg> B) Nothing planed (Multimedia eats time...) 10:08 < neg> C) None 10:08 < neg> --eot-- 10:09 < geertu> Thank you, Niklas! 10:09 < geertu> Next is Magnus 10:09 < dammsan> A) IPMMU update posted 10:10 < dammsan> B) resend IPMMU if I get enough feedback, need to review patches from Laurent 10:10 < dammsan> C) None 10:10 < geertu> Thank you, Magnus! 10:11 < geertu> Next is Shimoda-san 10:11 < shimoda> yes 10:11 < shimoda> A) 10:12 < shimoda> - Nothing 10:12 < shimoda> B) 10:12 < shimoda> - Get feedback about R-Car D3's CPG for Geert-san's questions 10:12 < shimoda> C) 10:12 < shimoda> - Nothing 10:12 < shimoda> -- EOT -- 10:12 < geertu> Thank you, Shimoda-san! 10:12 < geertu> Next is Geert 10:13 < geertu> A) 10:13 < geertu> - RFC for CPG/MSSR module clock restore during resume 10:13 < geertu> - Initial Salvator XS support 10:13 < geertu> B) 10:13 < geertu> - More suspend/resume for CPG/MSSR and PFC 10:13 < geertu> - Mark periupport priority < H commits that are in linux-next 10:13 < geertu> C) 10:13 < geertu> - None 10:13 < geertu> -- EOT -- 10:13 < geertu> Next is Marek 10:14 < marex-cloud> Marek is broken 10:14 < marex-cloud> A) ULCB M3 U-Boot port is posted , but only tested by booting U-Boot from U-Boot 10:15 < marex-cloud> B) work on DT conversion of the U-Boot , so we can drop DT from Linux into U-Boot and create board ports that way instead 10:15 < marex-cloud> C) none 10:15 < marex-cloud> is U-Boot even part of the core group ? 10:16 < geertu> Good question! 10:16 < geertu> dammsan: It's not listed in my SoW ;-) 10:17 < geertu> But as it's part of basic infrastructure, it fits better in core than in any of the other groups 10:18 < geertu> Regarding B, that means we'll have to update U-Boot regularly, as we keep on adding more device support to the DTS? 10:18 < marex-cloud> that's a good question 10:19 < marex-cloud> usually you don't want to update your bootloader in a delivered product 10:19 < marex-cloud> on a devkit, that might be easier 10:19 < geertu> I guess if you TFTP a specific DTB, it will take precedence? 10:19 < marex-cloud> then again, while you're adding more devices to Linux, U-Boot will only support a subset of them (we don't need ie. any of the multimedia stuff in U-Boot, maybe video out, but that's about it) 10:20 < marex-cloud> geertu: for now, I'd like to keep bundling the DT with U-Boot just like we do on other boards 10:20 < geertu> Or is the DTB stored in a separate partition on FLASH, so it cane be updated easily? 10:20 < marex-cloud> geertu: we can unbundle that later, once things are a bit more fleshed out 10:20 < marex-cloud> geertu: also, we'd probably need to patch BL2/BL3 to load two files, U-Boot and DT 10:21 < pinchartl> marex-cloud: what "other boards" ? 10:21 < geertu> marex-cloud: IC, as U-Boot need the DT for its own initialization 10:22 < marex-cloud> pinchartl: other boards in U-Boot 10:22 < geertu> it cannot load it from FLASH later. 10:22 < geertu> s/need/needs/ 10:22 < pinchartl> marex-cloud: don't break my TFTP + NFS workflow 10:22 < marex-cloud> geertu: there are ways around that if your flash is memory mapped, which I'm not sure the RPC supports 10:22 < geertu> BL2/BL3 can pass a minimal DTB, and U-Boot can load a more advanced one later, which we can update when needed? 10:22 < pinchartl> I'm fine if U-Boot needs some DT that I don't need to update more often than updating the boot loader itself 10:22 < marex-cloud> pinchartl: eh ? how would that break it ? 10:23 < marex-cloud> pinchartl: OK 10:23 < pinchartl> but I want to be able to load kernel + DT over TFTP and boot them regardless of what DT is bundled with U-Boot 10:23 < marex-cloud> pinchartl: ah, that's fine then 10:23 < marex-cloud> pinchartl: you can use separate DTs for both (although it would be preferred if you didnt :) ) 10:24 < pinchartl> in particular, if U-Boot patches the DT (to set the DRAM size for instance), it has to patch the DT I load over TFTP 10:24 < marex-cloud> pinchartl: U-Boot does patch the DT passed to the kernel with RAM size and ethernet MAC 10:24 < marex-cloud> geertu: well, if that's the case already, we could use that to supply DT to U-Boot 10:25 < pinchartl> marex-cloud: if you want to use the same DT for U-Boot and Linux, then add TFTP support to BL3 :-) 10:25 < marex-cloud> geertu: but I'd rather like to start slow, get the DT support in at all first and then move on to fiddling with BL 10:26 < marex-cloud> geertu: I think these are two tasks which depend on one another, but getting the DT support into U-Boot with bundled DT is much easier then complicating it with passing DT from BL 10:27 < marex-cloud> pinchartl: just use U-Boot as your TFTP client ... 10:27 < geertu> marex-cloud: OK, bundling a (minimal) DT is fine. 10:28 < marex-cloud> geertu: I'd like to bundle the same DT as we use in linux, not a minimal one ... 10:29 < marex-cloud> geertu: the less we diverge with the DT, the better 10:29 < geertu> marex-cloud: OK, but we're still developing "the one in Linux"


context:
space:
mode: