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!