Hi Simon, On Wed, 5 Dec 2018 at 06:38, Simon Goldschmidt <simon.k.r.goldschm...@gmail.com> wrote: > > On Wed, Dec 5, 2018 at 2:21 PM Simon Glass <s...@chromium.org> wrote: > > > > Hi Simon, > > > > On Sun, 25 Nov 2018 at 23:05, Simon Goldschmidt > > <simon.k.r.goldschm...@gmail.com> wrote: > > > > > > [I've cut down the CC list a bit due to some gmail warnings] > > > On Mon, Nov 26, 2018 at 4:00 AM Simon Glass <s...@chromium.org> wrote: > > > > > > > > Hi Simon, > > > > > > > > On Sun, 25 Nov 2018 at 14:09, Simon Goldschmidt > > > > <simon.k.r.goldschm...@gmail.com> wrote: > > > > > > > > > > On Thu, Nov 22, 2018 at 9:50 PM Simon Glass <s...@chromium.org> wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > On Thu, 22 Nov 2018 at 10:02, Tom Rini <tr...@konsulko.com> wrote: > > > > > > > > > > > > > > On Thu, Nov 22, 2018 at 03:44:28PM +0100, Simon Goldschmidt wrote: > > > > > > > > Am Do., 22. Nov. 2018, 14:44 hat Tom Rini <tr...@konsulko.com> > > > > > > > > geschrieben: > > > > > > > > > > > > > > > > > On Thu, Nov 22, 2018 at 02:24:49PM +0100, Marek Vasut wrote: > > > > > > > > > > On 11/22/2018 01:52 PM, Tom Rini wrote: > > > > > > > > > > > On Thu, Nov 22, 2018 at 10:25:14AM +0100, Christian > > > > > > > > > > > Gmeiner wrote: > > > > > > > > > > > > > > > > > > > > > >> Am Mo., 19. Nov. 2018 um 16:56 Uhr schrieb Simon Glass < > > > > > > > > > s...@chromium.org>: > > > > > > > > > > >>> > > > > > > > > > > >>> This board has not been converted to CONFIG_DM_BLK by > > > > > > > > > > >>> the deadline. > > > > > > > > > > >>> Remove it. > > > > > > > > > > >>> > > > > > > > > > > >> > > > > > > > > > > >> As the board is still mainted I will NAK it for the > > > > > > > > > > >> moment. Are there > > > > > > > > > > >> any hints want needs to be done > > > > > > > > > > >> to port thie board over to new DM stuff? > > > > > > > > > > > > > > > > > > > > > > Yes, as a start you need to switch over to using > > > > > > > > > > > CONFIG_OF_CONTROL and > > > > > > > > > > > selecting/providing a dtb file. I see ot1200 is using > > > > > > > > > > > DWC_AHSATA which > > > > > > > > > > > needs more work, but this is the board-level work that > > > > > > > > > > > needs doing. > > > > > > > > > > > > > > > > > > > > Wasn't there a possibility to use platform data in board > > > > > > > > > > file instead of > > > > > > > > > > DT ? Or is DT mandatory now , including the libfdt overhead > > > > > > > > > > ? > > > > > > > > > > > > > > > > > > In short, DT for U-Boot and platform data for SPL is what's > > > > > > > > > recommended, > > > > > > > > > yes. > > > > > > > > > > > > > > > > > > > > > > > > > This is a little confusing for me. Socfpga gen5 SPL doesn't do > > > > > > > > that. And it > > > > > > > > seems a little strange or outdated overall. > > > > > > > > > > > > > > > > Would there be some kind of reference architecture or mach to > > > > > > > > look at > > > > > > > > what's the suggested/up-to-date way to implement SPL? Also > > > > > > > > regarding code > > > > > > > > flow? > > > > > > > > > > > > > > So, SPL is where things get, ahem, fuzzy. While I don't want to > > > > > > > encourage boundless growth in U-Boot proper, we aren't exactly > > > > > > > size > > > > > > > constrained (but rather, functional/logical constrained). But in > > > > > > > SPL, > > > > > > > yes, we have many platforms with 32/64/128 kilobyte hard limits > > > > > > > (and > > > > > > > some smaller) and we can't always shove in a "TPL" before SPL > > > > > > > either. > > > > > > > So in SPL we do make use of platform data instead. While not the > > > > > > > smallest size constraint, am335x_hs_evm is a reasonable thing to > > > > > > > look at > > > > > > > in this case. > > > > > > > > > > > > Also 'rock' uses CONFIG_OF_PLATDATA which provides a halfway house - > > > > > > still uses DT, but it gets converted into C structs so saves code > > > > > > space. > > > > > > > > > > > > firefly-rk3288 is a pretty good DM/DT example, including SPL. > > > > > > > > > > I've currently got an issue on socfpga gen5 that could be solved best > > > > > by enabling CONFIG_OF_EMBED (mixing const and non-const sections is a > > > > > problem for CRC calculation). However, it could probably also solve by > > > > > using platform data (but that doesn't work out of the box, yet). The > > > > > problem with CONFIG_OF_EMBED is that I think it's OK to enable this > > > > > for SPL but I don't like enabling it for U-Boot, so: > > > > > > > > > > Would it make sense to duplicate the whole "Provider of DTB for OF > > > > > control" choice so that it can be OF_EMBED for SPL but different for > > > > > U-Boot? Or does it make more sense to convert socfpga gen5 to use > > > > > OF_PLATDATA? > > > > > > > > We should not be using OF_EMBED in in-tree boards or production code. > > > > > > What's the reason for this? I can understand this for U-Boot, and I > > > can understand that it's at least theoretically a bit cleaner for SPL, > > > too. But there are some drawbacks when doing this in SPL where code is > > > not relocated: > > > - you lose the ability to check total size in linker file (which is > > > bad for size-constrained platforms: sometimes you notice failure only > > > when booting) > > > > You can add an SPL size check in Makefile.spl if you like. > > That might be required, yes. > > > > - you get an inconsistent memory layout regarding read/write: the > > > linker places bss at the end but then, DTB follows as const data > > > > This should be handled by the $(SPL-BIN)-pad.bin file (or by binman if > > you are using that). > > I don't understand that. How does the padding help? I have these > sections (roughly): > - text: readonly > - bss: writable > - DTB: readonly, added as post build step after linking > > How does $(SPL-BIN)-pad.bin help?
It covers over the BSS section so that the image ends where the DTB starts, thus fixing the addressing issue you mentioned. It allows you to do this: cat u-boot-spl-nodtb.bin u-boot-spl.dtn >-u-boot-spl.bin > > > > - binary size "on disk" grows due to this inconsistent memory layout > > > (since the flat binary includes the DTB, it needs to include the > > > zeroed-out bss, too) > > > > Right, but this is a few bytes. Why does it matter? > > > > > - "spl/u-boot-spl.hex" created by the default Makefiles does not seem > > > to include the DTB > > > > That might just be a bug. > > It might, yes. The hex file is currently built from the elf file, so > there's no DTB in there. OK. Could be worth a patch. > > > > > > > > Can you please explain the issue a bit more? > > > > > > Of course: socfpga gen5 has a feature where the boot rom can jump to > > > SPL in SRAM on warm boot. To ensure SPL is still valid after a reboot, > > > the boot rom can check its consistency by calculating a CRC over one > > > specified range in SRAM. On first boot, SPL stores its start, length > > > and CRC value to special registers for the boot rom. Since the > > > contents of bss changes while SPL is running, bss cannot be included > > > in this CRC range. (Same goes for the '.data' region, but it's > > > possible to build SPL without actually using it.) > > > > How about calculating that checksum at build time instead? You could > > use binman to do that. > > > > > > > > So to ensure the DTB is untouched, I have to make sure it has a lower > > > address than the bss section. Using OF_EMBED does this for me. And I > > > expect using platform data would work too. Do you have another idea > > > how to achieve my goal of combining all write-only sections in SPL > > > into one block? > > > > Yes, do it at build time. Or calculate your CRC before you write any > > BSS variables. > > Creating the correct checksum is not the point. I can do that before using > bss. > > The problem is that on the next boot, this checksum is not valid any > more because bss might have changed. Right, but just skip the BSS section when checksumming - i.e. checksum the code and then the DT but omit the BSS. > > > > > > > Oh, and I currently count 109 defconfig files containing "OF_EMBED", > > > so I wasn't aware that this should not be used. Maybe these platforms > > > have similar reasons like I have and would enable OF_EMBED only for > > > SPL if they could. At least for socfpga_stratix10 that should work. > > > > That is very bad news. I'll see about adding a Makefile warning. > > OK. Looking forward to the discussion that starts then :-) Yes... Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
