[U-Boot] [PATCH 1/6] km: modify Kconfig file organization for KM boards
Hi Stefan, Yes, it is just an updated version that matches the current mainline. Sorry, I am new to open source contribution, and will take more care next time. Cheers, Pascal Linder Von: Stefan Roese Gesendet: Dienstag, 18. Juni 2019 13:36 An: Linder Pascal; u-boot@lists.denx.de Cc: Holger Brunck Betreff: Re: [U-Boot] [PATCH 1/6] km: modify Kconfig file organization for KM boards Hi Pascal, On 18.06.19 13:27, Pascal Linder wrote: > As preparation for the upcoming transferring of configurations from header > files to Kconfig, a common Kconfig file for all KM boards was created. For > the moment, it only sources the other three, more specific, Kconfig files. > Therefore, the architecture Kconfig files now include the common Kconfig > file. Also, the configuration selection for KM boards was moved from the > architecture Kconfig files to the board specific Kconfig files. > > Signed-off-by: Pascal Linder > Signed-off-by: Holger Brunck > Cc: Mario Six > Cc: Prabhakar Kushwaha > --- > arch/arm/mach-kirkwood/Kconfig | 9 ++--- > arch/powerpc/cpu/mpc83xx/Kconfig | 44 ++- > arch/powerpc/cpu/mpc85xx/Kconfig | 8 ++--- > board/keymile/Kconfig| 16 + > board/keymile/km83xx/Kconfig | 62 > board/keymile/km_arm/Kconfig | 7 > board/keymile/kmp204x/Kconfig| 8 + > 7 files changed, 109 insertions(+), 45 deletions(-) > create mode 100644 board/keymile/Kconfig Are you only posting this patch in an updated version? That's fine, I just wanted to know. But: You need to provide a patch history. Please see here for more details: http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions No need to re-do this for this patch. But please next time. ;) Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] km/spi: port SPI flash of KM Kirkwood boards to driver model
Hi Stefan,
Many thanks for your feedback. I will promptly send another series of patches,
where I considered your comments. As the upcoming patches contain additional
changes in the Kconfig architecture of the KM boards, you can reject this patch
and only employ the new ones.
Sincerely,
Pascal Linder
Student Telekommunikation Netzwerke und Sicherheit
Klasse T-3b
Von: Stefan Roese
Gesendet: Donnerstag, 13. Juni 2019 08:46:23
An: Linder Pascal; u-boot@lists.denx.de
Cc: Holger Brunck
Betreff: Re: [PATCH] km/spi: port SPI flash of KM Kirkwood boards to driver
model
On 04.06.19 14:23, pascal.lin...@edu.hefr.ch wrote:
> From: Pascal Linder
>
> The required configurations were activated in the default configuration
> files of the board series and the SPI interface setting is added to
> the common device tree file.
>
> Some adaptions were necessary in the driver (kirkwood_spi.c) in order to
> support the driver model on the shared SPI bus. Weak functions were added
> to the claim and release operation (release was not yet implemented) and
> can be overwritten in the board specific file. For KM boards these
> functionality is needed to change the MPP configuration when claiming
> or releasing the bus as the pins are shared between the NAND and SPI NOR
> device.
>
> Finally, the deprecated code in the driver could be deleted as only KM
> boards were overwriting these weak functions. Every occurrence of the
> now unused preprocessor definition CONFIG_SYS_KW_SPI_MPP and its
> associated defines were removed as well.
>
> Signed-off-by: Pascal Linder
> Signed-off-by: Holger Brunck
> ---
> arch/arm/dts/kirkwood-km_kirkwood.dts | 22 +
> arch/arm/include/asm/arch-mvebu/spi.h | 11 -
> board/keymile/km_arm/km_arm.c | 23 -
> configs/km_kirkwood_128m16_defconfig | 4 ++
> configs/km_kirkwood_defconfig | 4 ++
> configs/km_kirkwood_pci_defconfig | 4 ++
> configs/kmcoge5un_defconfig | 4 ++
> configs/kmnusa_defconfig | 4 ++
> configs/kmsugp1_defconfig | 4 ++
> configs/kmsuv31_defconfig | 4 ++
> configs/mgcoge3un_defconfig | 4 ++
> configs/portl2_defconfig | 7 ++-
> drivers/spi/kirkwood_spi.c| 71 ++-
> include/configs/km/km_arm.h | 2 -
> scripts/config_whitelist.txt | 1 -
> 15 files changed, 97 insertions(+), 72 deletions(-)
It would be better (easier to review) to split this patch into multiple
separate patches. Perhaps something like this (just a rough idea):
patch 1/5: Add board specific MPP handling to kirkwood-spi (DM version)
patch 2/5: Add SPI nodes and properties to Keymile DT files
patch 3/5: Enable DM_SPI in defconfigs
patch 4/5: Add board specific DM SPI MPP stuff to Keymile boards
patch 5/5: Remove now unused MPP stuff (non-DM driver and header)
Please find some further comments below.
>
> diff --git a/arch/arm/dts/kirkwood-km_kirkwood.dts
> b/arch/arm/dts/kirkwood-km_kirkwood.dts
> index f035eff1c11..b2c0209f5db 100644
> --- a/arch/arm/dts/kirkwood-km_kirkwood.dts
> +++ b/arch/arm/dts/kirkwood-km_kirkwood.dts
> @@ -13,6 +13,10 @@
>device_type = "memory";
>reg = <0x 0x0800>;
>};
> +
> + aliases {
> + spi0 =
> + };
> };
>
>{
> @@ -29,3 +33,21 @@
>phy-handle = <>;
>};
> };
> +
> + {
> + status = "okay";
> +
> + flash@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "st,m25p80", "jedec,spi-nor", "spi-flash";
> + reg = <0>;
> + spi-max-frequency = <3300>;
> + mode = <3>;
> +
> + partition@uboot {
> + reg = <0x00 0x0c>;
> + label = "uboot";
> + };
> + };
> +};
> diff --git a/arch/arm/include/asm/arch-mvebu/spi.h
> b/arch/arm/include/asm/arch-mvebu/spi.h
> index d6f6d1ac574..58b6c32c4d8 100644
> --- a/arch/arm/include/asm/arch-mvebu/spi.h
> +++ b/arch/arm/include/asm/arch-mvebu/spi.h
> @@ -23,17 +23,6 @@ struct kwspi_registers {
>u32 dw_cfg; /* 0x10620 - Direct Write Configuration */
> };
>
> -/* They are used to define CONFIG_SYS_KW_SPI_MPP
> - * each of the below #defines selects which mpp is
> - * configured for each SPI signal in spi_claim_bus
> - * bit 0: selects pin for MOSI (MPP1 if 0, MPP6 if 1)
> - * bit 1: selects pin for SCK (MPP2 if 0, MPP10 if 1)
> - * bit 2: selects pin for MISO (MPP3 i
[U-Boot] Continuous Integration (CI)
Hi everyone, I recently saw the .travis.yml file in the repository and thought a bit more about CI in U-Boot. As I am using GitLab for my own repository, I would be interested in a .gitlab-ci.yml file. Does anybody already have implemented a GitLab CI for U-Boot or how do you guys approach this issue? Sincerely, Pascal Linder Student Telekommunikation Netzwerke und Sicherheit Klasse T-3b ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Default environment file
Hi everyone, I am currently moving the configurations of the KM boards from header files to Kconfig. But for the customly defined environment variables I did not found a decent solution until I have come across the default environment file, which seems very interesting to me. To this day, nevertheless, it appears that noone made use of the CONFIG_USE_DEFAULT_ENV_FILE configuration defined in env/Kconfig. Does anyone still have an example for this kind of environment definition or knows how to create it? In my opinion, this could be highly relevant for the transition away from the header files in include/configs. Sincerely, Pascal Linder Student Telekommunikation Netzwerke und Sicherheit Klasse T-3b ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Kconfig options for several boards
Hi everyone, I would like to turn on configurations for several Keymile boards, which are all using the Kirkwood architecture. Now, I do not want to change every defconfig file one after the other. Until now, we have used a common header file, but with the conversion to Kconfig another method has to be elaborated. While searching in the U-Boot source code, I found two different manners to fulfill our needs: * in arch/arm/mach-kirkwood/Kconfig: config TARGET_KM_KIRKWOOD bool "KM_KIRKWOOD Board" select BOARD_LATE_INIT select DM select DM_SPI select DM_SPI_FLASH imply CMD_CRAMFS imply CMD_DIAG imply FS_CRAMFS * in board/keymile/km_arm/Kconfig: config BOARD_SPECIFIC_OPTIONS # dummy def_bool y select DM select DM_SPI select DM_SPI_FLASH Which one do you guys prefer and for what reasons? Also, I would like to know what the dummy keyword is doing in the second proposition (found that in every usage of BOARD_SPECIFIC_OPTIONS). Many thanks in advance! Sincerely, Pascal Linder Student Telekommunikation Netzwerke und Sicherheit Klasse T-3b ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot Security
Hello everyone, I have created the FIT to be loaded by the SPL and the keys for the signature. Now, I am wondering how the signature is done by U-Boot? Is there an option in menuconfig that points to the key or is it me that has to do it manually? Also, I am wondering how to place the public key inside the U-Boot image? Sincerely, Pascal Linder Student Telekommunikation Netzwerke und Sicherheit Klasse T-3b Von: Simon Goldschmidt Gesendet: Samstag, 27. April 2019 21:12:03 An: Linder Pascal Betreff: Re: AW: [U-Boot] U-Boot Security Hello Pascal, I can't help you much there, I can only tell you SPL -> U-Boot should be the same as U-Boot -> FIT(Linux). I once tested this and it works, but it's too long ago to remember. And your first mail suggested the latter case (U-Boot -> FIT/Linux) already works for you... Besides, please keep the discussion public (on the mailing list). There are others who know this far better than me and might be able to help more. Regards, Simon On 27.04.19 17:50, Linder Pascal wrote: > Hello Simon, > > > Thanks for your response! Now, I am just wondering how the signature is done > by U-Boot. Or is it me that must sign the images manually with mkimage? > > > The key and certificate I have in a directory called keys inside U-Boot. Is > there an option in KConfig to create the relation to this key? > > > Summarized, I would like to know how to put the public key into my U-Boot > image? > > > Sincerely, > > > Pascal Linder > > Student Telekommunikation Netzwerke und Sicherheit > > Klasse T-3b > > ____ > Von: Simon Goldschmidt > Gesendet: Mittwoch, 24. April 2019 19:56:51 > An: Linder Pascal; u-boot@lists.denx.de > Betreff: Re: [U-Boot] U-Boot Security > > Am 24.04.2019 um 15:55 schrieb Linder Pascal: >> Hello everyone, >> >> >> I want to add some supplementary security to my embedded system. The >> Flattened Image Tree (FIT) to secure the operating system and the device >> tree, I have already found. Now, I am wondering if I could also secure >> U-Boot itself before starting it by the Secondary Program Loader (SPL). Does >> anyone knows a method to do that? > > Just as U-Boot can load Kernel + DTS as FIT, SPL can load U-Boot as FIT. > See CONFIG_SPL_LOAD_FIT. This FIT containing U-Boot + its DTS can then > be verified, too. > > Regards, > Simon > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] U-Boot Security
Hello everyone, I want to add some supplementary security to my embedded system. The Flattened Image Tree (FIT) to secure the operating system and the device tree, I have already found. Now, I am wondering if I could also secure U-Boot itself before starting it by the Secondary Program Loader (SPL). Does anyone knows a method to do that? For a helpful answer I would be really grateful. Sincerely, Pascal Linder Student Telekommunikation Netzwerke und Sicherheit Klasse T-3b ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] SPL
Hello everyone, With my NanoPi NEO Plus2 board, I try to make some modifications on the Flattened Image Tree (FIT). This includes compression and also some security features like signing/verifying. But I do not know if my modifications worked out. It is a FIT that is started by the SPL, i.e. it includes U-Boot, the ATF and the device tree blob for the bootloader. Therefore, I cannot see anything in the console that assures the proper function. Also, I wonder if it is even possible to sign the U-Boot image and verify it by the SPL. What functions does the sunxi SPL even support? For your answers I would be really grateful. Sincerely, Pascal Linder Student Telekommunikation Netzwerke und Sicherheit Klasse T-3b ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Migration to KConfig
Hello everyone, My task is to migrate a board from a U-Boot of version v2016.01 to the latest state of the mainline. So first of all, I am analyzing the configuration system KConfig that has changed in the meantime. I do not really understand what has changed with KConfig. Is it just the fact that we can now declare the configurations in the "defconfig" file? As I have seen, the KConfig file in the board specific folder only contains general information like the vendor and board name. I would really appreciate a helpful answer that brings me further in my school project. Sincerely, Pascal Linder Student Telekommunikation Netzwerke und Sicherheit Klasse T-3b ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Board specific files
Hello everyone, I am new to U-Boot and I am trying to understand what I need to code for using my own board with the bootloader. The device tree files I have already found under ./arch/arm/dts/. Can I just add my device tree under this directory? Also, what is the difference between the configuration files under ./configs/ and ./include/configs/? Do I need to add a file in both of the named directories? If someone knows a well documented guide to add a new board to the mainline, I would be very grateful. Sincerely, Pascal Linder Student Telekommunikation Netzwerke und Sicherheit Klasse T-3b ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
