Dear Andrew Lunn, On Sun, 23 Nov 2014 04:36:03 +0100, Andrew Lunn wrote: > > No, it is not the BootROM that does this. It is the binary header, > > which is something different. > > O.K, so this definitely needs documenting somewhere, since it is not > obvious. I'm not sure if it is sufficient to make this part of the > commit log, or if it should be documented in Documentation/power. I can send a follow-up patch that adds a more detailed comment in arch/arm/mach-mvebu/pm.c maybe? > > The "binary header" is currently the piece of code that we extract > > using the kwbimage tool from existing U-Boot images to build working > > Barebox images, since we haven't yet written the equivalent code in > > Barebox land. > > Is it a binary blob in the uboot source tree? Originally, parts of it were available in the form of source code, and only the code doing the DDR3 training to calculate the optimal timings was provided as a binary blob. However, in order to allow the U-Boot folks to add complete support for Armada XP, Marvell opened this part as well. See http://git.denx.de/?p=u-boot/u-boot-testing.git;a=shortlog;h=refs/heads/marvell-armada-xp-2014-09-29-spl. > > So, the specification of where the "resume informations" is located and > > how this information is organized is purely defined by software that > > can potentially be changed, not by the BootROM. Though that if we > > decided to use a different protocol, we would basically have a > > suspend/resume in the kernel that would not work with any Marvell > > platform that uses the default bootloader. > > It also makes mainline suspend/resume dependent on Marvell not > changing the bootloader. Yes, absolutely. Just like the suspend/resume mechanism also depends on which firmware was installed in the PIC micro-controller that controls the power rails. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
