1 files changed, 189 insertions, 0 deletions
diff --git a/wiki/Chat_log/20180509-core-chatlog b/wiki/Chat_log/20180509-core-chatlog
new file mode 100644
index 0000000..dc9a99a
--- /dev/null
+++ b/wiki/Chat_log/20180509-core-chatlog
@@ -0,0 +1,189 @@
+Core-chat-meeting-2018-05-09
+
+09:37 < geertu> Welcome to today's Core Group Chat!
+09:37 < geertu> Agenda:
+09:37 < geertu> 1. Status Updates
+09:37 < geertu> 2. Discussion Topics
+09:37 < geertu>   a. New U-Boot on R-Car Gen2 changes the FLASH layout.
+09:37 < geertu>   b. [PATCH/RFC] ARM: shmobile: defconfig: Enable LPAE
+09:37 < geertu>      (https://www.spinics.net/lists/arm-kernel/msg648585.html)
+09:37 < geertu> Topic 1. Status updates
+09:37 < geertu> Marek worked on U-Boot (R8A7792 DT clock driver, cleanups, pre-release
+09:37 < geertu> testing).
+09:37 < geertu> Morimoto-san enjoyed GW, worked on DMAC error handling for
+09:37 < geertu> virtualization, and is working on a new tool "periject".
+09:37 < geertu> Niklas replaced hardcoded SYSC numbers for M3-N, and helped to fix
+09:37 < geertu> hickups on dual-CPU systems.
+09:37 < geertu> Shimoda-san resubmitted clk and dts[i] support for R-Car E3, enabled
+09:37 < geertu> usb2.0 ch3 dts on H3 ES2.0, and updated IPMMU material.
+09:37 < geertu> Simon posted some misc enablement and cleanup patches.
+09:37 < geertu> Geert reposted BD9571 DDR Backup Mode, made rcar-gpio interrupts work on
+09:37 < geertu> qemu+kvm, enabled the PMU on R-Car Gen2, RZ/A1, and RZ/G1, and updated
+09:37 < geertu> periupport for v4.17-rc4.
+09:38 < geertu> B) What we plan to do till next time: 
+09:38 < geertu> Kaneko-san will upport M3-N WDT support.
+09:38 < geertu> Marek will continue working on U-Boot (new DM/DT capable I2C driver, and
+09:38 < geertu> E3 Ebisu support).
+09:38 < geertu> Morimoto-san will design the new "periject" tool.
+09:38 < geertu> Shimoda-san will update rcar-sysc for R-Car E3, and pave the way forward
+09:38 < geertu> for IPMMU.
+09:38 < geertu> Geert will send clk and pfc pull requests for v4.18, do periupport
+09:38 < geertu> analysis and upporting, and handle CPG/MSSR and SYSC errata.
+09:39 < geertu> C) Problems we have currently:
+09:39 < geertu> Morimoto-san wants to know each member's opinion about periject.
+09:39 < geertu> ---
+09:39 < geertu> Anything I missed?
+09:40 < geertu> Topic 2. Discussion Topics
+09:40 < geertu> a. New U-Boot on R-Car Gen2 changes the FLASH layout.
+09:41 < geertu> Unfortunately Marek is at the dentist.
+09:41 < Marex> not yet
+09:41 < Marex> but almost
+09:41 < geertu> OK ;-)
+09:41 < Marex> so yeah, thoughts ?
+09:41 < geertu> But the issue is that the new and improved U-Boot for R-Car Gen2 needs more space in FLASH ROM than allowed by the current partitioning in DT
+09:42 < geertu> Hence the partitioning should be changed to accomodate that.
+09:43 < Marex> yes
+09:44 < geertu> Marex: I assume this is for the "loader" partition?
+09:44 < dammsan> as long as it is documented on a public wiki i am alright with that
+09:44 < geertu> It seems most boards use 256 KiB for loader
+09:45 < geertu> But Koelsch and Stout use 512 KiB
+09:45 < geertu> Ah, Stout calls the partitions loader/uboot/uboot-env/flash
+09:45 < Marex> sec
+09:45 < geertu> All others use loader/user/flash
+09:46 < Marex> https://elinux.org/R-Car/Boards/U-Boot-Gen2
+09:46 < Marex> see at the end
+09:46 < Marex> "Flashing U-Boot"
+09:48 < Marex> I would say we reserve the first 0x200000 bytes for U-Boot and go with that, if we decide to change flash layout
+09:48 < dammsan> thanks - looking good
+09:48 < neg> Marex: I like the ip address 'tftp 0x50000000 192.168.1.300:u-boot-spl.bin' :-)
+09:48 < Marex> the original layout had 0x40000 bytes for U-Boot , which 0x40000 for the SPI loader (of which 16 kiB were used, but due to SPI NOR erase size of 64 kiB, that's what it is) and then used 8 bytes from another 64 kiB sector
+09:49 < Marex> what I would like to have is even an improvement of what's in the wiki
+09:49 < geertu> neg: Copied from a movie?
+09:49 < Marex> first 64 KiB for U-Boot SPL, then four sectors for env , spare sector for env , redundant env , spare sector for redundant env and then three sectors for U-Boot
+09:49 < geertu> neg: Does it crash U-Boot?
+09:50 < Marex> that should be future-proof enough
+09:50 < geertu> What's "redundant env"?
+09:50 < wsa_> gotta run, cya guys!
+09:50 -!- wsa_ [~wsa@p54B334D6.dip0.t-ipconnect.de] has quit [Quit: ...]
+09:50 < Marex> geertu: another copy of env, in case the first copy gets corrupted
+09:50 < geertu> Changing the partitioning in upstream DTS means that we do break anyone who has stored real data in his FLASH
+09:51 < geertu> sector=64KiB?
+09:51 < Marex> geertu: yes, if they update bootloader now, they should also update the layout
+09:51 < Marex> yes
+09:51 < dammsan> hm..
+09:51 < Marex> and we can pass that layout through the kernel command like via mtdparts=
+09:51 < dammsan> wouldn't it make sense if U-Boot could pass the layout to the kernel?
+09:51 < geertu> Marex: If they don't update U-Boot, but fetch tomorrow's upstream, their data is inaccessible, too
+09:51 < Marex> yes, and remove it from DT
+09:52 < dammsan> seems inline with the memory detection topic
+09:52 < geertu> Having to remember to pass mtdparts= all the time is cumbersome.
+09:52 < Marex> geertu: er, sector = 256 kiB on that flash, not 64 kiB
+09:53 < geertu> And will lead to someone overwriting his/her boot loader when doing a FLASH test on Linux
+09:53 < dammsan> oh, so no runtime patching like with memory nodes?
+09:53 < Marex> flash partitioning isn't a HW property, so why would it be in DT ?
+09:53 < dammsan> manually passing it seems cumbersome
+09:53 < Marex> geertu: you can set bootargs to contain mtdparts
+09:53 < geertu> dammsan: How to detect partitioning without a partition table on the medium?
+09:54 < geertu> Marex: "four sectors for env" = 4 x 256 KiB = 1 MiB?
+09:54 < dammsan> u-boot needs to be aware of it, so it can share this information?
+09:54 < Marex> geertu: yes
+09:54 < Marex> geertu: you cannot get below that with redundant env and spare sectors
+09:55 < dammsan> obviously if we had a partition table that might be helpful with all the different boot stack components
+09:55 < geertu> Marex: OK, I don't have anything large and valuable stored in that FLASH
+09:55 < Marex> dammsan: U-Boot can be made aware of it and it can pass that information, sure
+09:56 < dammsan> geertu: what do you think?
+09:56 < geertu> dammsan: I think partition info in DTS is fragile
+09:56 < dammsan> for sure
+09:56 < dammsan> so where to put it?
+09:57 < geertu> While even you don't really use the FLASH, you do want to have the partition info, so you can run a FLASH test on Linux (read-only everywhere, write to all but the boot loader partition)
+09:57 < Marex> mtdparts on kernel command line ?
+09:57 < geertu> s/even/even if/
+09:57 < Marex> with the first 1 MiB marked ro ?
+09:58 < geertu> Marex: That's not sufficiently safe, IMHO
+09:58 < dammsan> makes sense
+09:58 < geertu> First MiB marked ro sounds good to me
+09:58 < geertu> Marex: I mean that I regularly boot kernels with 
+09:58 < geertu> CONFIG_CMDLINE="ignore_loglevel root=/dev/ram"
+09:59 < geertu> CONFIG_CMDLINE_FORCE=y
+09:59 < geertu> (for using initrd on remote boards)
+09:59 < dammsan> i suppose there is no way we can store a partition table somewhere?
+09:59 < dammsan> one physical sector minimum per copy, 2 copies
+09:59 < geertu> So the partition info must be stored in the board-spcific part
+09:59 < geertu> dammsan: yes we can.
+10:00 < dammsan> since it is a runtime configuration item it makes sense to separate that from DTS
+10:00 < geertu> dammsan: We do have the SPI loader in the first 16KiB, but some partitioning schemes can have the part table elsewhere (not at the start of the device_
+10:00 < dammsan> aligning to the end of the flash?
+10:01 < geertu> E.g. Amiga RDB can be anywhere in the first 2 cylinders (yeah, legacy naming)
+10:01 < dammsan> must be possible to probe for the size somehow
+10:02 < geertu> Size is known from FLASH type (even SPI NOR autoprobing)
+10:02 < dammsan> ok
+10:02 < dammsan> so either at the end or using some offset
+10:03 < dammsan> if we are inconveniently disturbing the users with a partition chance
+10:03 < dammsan> change i mean
+10:03 < dammsan> then we may as well go all the way?
+10:03 < geertu> Yep
+10:03 < dammsan> or am i being overly difficulat as usual =)
+10:03 < dammsan> probably =)
+10:04 < geertu> No, if you do it wrong, the board needs JTAG rescue
+10:04 < geertu> Better safe than sorry
+10:04 < geertu> Next topic?
+10:04 < dammsan> yeah so doing a generation jump with several features at once is probably good
+10:04 < geertu>  b. [PATCH/RFC] ARM: shmobile: defconfig: Enable LPAE
+10:04 < geertu> (https://www.spinics.net/lists/arm-kernel/msg648585.html)
+10:05 < dammsan> i think for 32-bit arm we need two configs
+10:05 < dammsan> if we should bother about lpae
+10:05 < horms> This is not the first time this has come up
+10:05 < geertu> The RZ/G1 crew wants to have LPAE enabled, but that's incompatible with older SoCss
+10:05 < geertu> Indeed, multi_v7_defconfig also doesn't have LPAE because of that
+10:05 < Marex> geertu: so what is the decision ?
+10:05 < horms> The last time, iirc, the answer was it'll all be awesome with fragments
+10:05 < horms> but I guess fragments never got committed to mainline
+10:05 < Marex> geertu: U-Boot generally uses mtdparts and I dont think it supports any of this partitioning stuff in flash ...
+10:06 < geertu> Marex: On-FLASH partition table?
+10:06 < Marex> geertu: I see, I don't think U-Boot supports it, so I'd have to check how that can be added
+10:06 < dammsan> Marek: please
+10:07 < geertu> horms: kernel/configs/ has some fragments
+10:07 < horms> ok, can we add an lpae fragment?
+10:07 < Marex> geertu: also, noone really uses that sort of thing, the systems I am aware of all use mtdparts passing on the kernel command line
+10:07 < horms> would that solve the problem?
+10:07 < horms> would it be more than one line long?
+10:07 < geertu> I guess so, and Arnd will be happy, too, if it can be used with e.g. multi_v7_defconfig, too
+10:07 < Marex> geertu: I guess we can have our special solution though
+10:07 < Marex> dammsan: yes ?
+10:08 < geertu> Marex: From one side, if everybody else uses mtdparts, I thinkl we should use it, too.
+10:08 < dammsan> Marex: seems both geertu and i like the idea of on-flash partition table
+10:08 < horms> geertu: ok, then I suggest we try that. I could make a patch and the RZ/G guys could test it.
+10:08 < geertu> But there are too many use cases for kernels that cannot receive bootargs from U-Boot (uImage/zImage with appeneded DTB, CONFIG_CMDLINE_FORCE, ...)
+10:09 < Marex> dammsan: then again, everyone else uses mtdparts and I have yet to see a recent system with on-flash partition table
+10:09 < dammsan> sure
+10:10 < dammsan> just feels like a sane thing to move towards
+10:10 < dammsan> but the offset for the partition table needs to be described somewhere
+10:10 < geertu> Given the SPI loader is 16 KiB, but the block size is 64 KiB, you have 48 KiB for partitioning?
+10:10 < dammsan> both for U-Boot and Linux
+10:11 < dammsan> geertu: we probably want dedicated physical sectors?
+10:11 < dammsan> to be more fail safe
+10:11 < geertu> dammsan: That's safer, yes
+10:11 < Marex> dammsan: it wastes another sector of the SPI NOR too
+10:11 < Marex> dammsan: while if it's in mtdparts, it could be stored alongside the other U-Boot environment
+10:12 < dammsan> true
+10:12 < dammsan> not having it in DTS must be good at least
+10:12 < dammsan> we can agree on that
+10:12 < Marex> and you can adjust it in U-Boot with setenv mtdparts instead of having a custom solution in some sector with custom command to set it up
+10:12 < Marex> yes, it doesn't describe hardware, it shouldn't be in DT
+10:12 < dammsan> sure makes sense
+10:13 < dammsan> so how to move forward?
+10:14 < dammsan> 1. remove DTS partion info from upstream
+10:14 < Marex> I think U-Boot could be tweaked to pass mtdparts via bootargs automatically, which would solve geerts's problem with custom bootargs without mtdparts ?
+10:14 < geertu> Marex: Nope, U-Boot cannot pass bootargs with uImage/zImage with appeneded DTB, or CONFIG_CMDLINE_FORCE
+10:14 < dammsan> geertu: i understand your problem
+10:15 < Marex> geertu: assume mainline U-Boot, which yes, can, if you don't use the uImage/zImage hack
+10:15 < dammsan> but would on-flash partition help in such case?
+10:15 < geertu> Marex: uImage/zImage with appeneded DTB is indeed mainly a workaround for old U-Boot
+10:15 < geertu> Marex: CONFIG_CMDLINE_FORCE is a workaround for people changing bootargs on shared boards in a farm
+10:16 < geertu> Although I could just add a "setenv bootargs" to my scripts
+10:16 < geertu> Anyway, we ran out of time (no pinchartl to kick us out ;-)
+10:17  * Marex gotta run too to make it for the train
+10:18 < geertu> Anything else to discuss?
+10:18 < dammsan> not from my side at this point
+10:18 < neg> Not from me but the flash layout discussion was educational :-)
+10:19 < geertu> Thanks for joining, and have a nice continued day!