From patchwork Wed Jun 3 17:03:26 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paul Kocialkowski X-Patchwork-Id: 480040 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from theia.denx.de (theia.denx.de [85.214.87.163]) by ozlabs.org (Postfix) with ESMTP id EF647140218 for ; Thu, 4 Jun 2015 03:03:51 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id C78844B635; Wed, 3 Jun 2015 19:03:49 +0200 (CEST) Received: from theia.denx.de ([127.0.0.1]) by localhost (theia.denx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKO_D9fYqXUG; Wed, 3 Jun 2015 19:03:49 +0200 (CEST) Received: from theia.denx.de (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 1B94D4B624; Wed, 3 Jun 2015 19:03:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 59F084B624 for ; Wed, 3 Jun 2015 19:03:47 +0200 (CEST) Received: from theia.denx.de ([127.0.0.1]) by localhost (theia.denx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zR6oCYEtgZAg for ; Wed, 3 Jun 2015 19:03:47 +0200 (CEST) X-policyd-weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 (only DNSBL check requested) Received: from gagarine.paulk.fr (gagarine.paulk.fr [109.190.93.129]) by theia.denx.de (Postfix) with ESMTPS id 148134B622 for ; Wed, 3 Jun 2015 19:03:43 +0200 (CEST) Received: by gagarine.paulk.fr (Postfix, from userid 65534) id C1CA11FE60; Wed, 3 Jun 2015 19:03:42 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on gagarine.paulk.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=unavailable autolearn_force=no version=3.4.0 Received: from localhost.localdomain (collins [192.168.1.129]) by gagarine.paulk.fr (Postfix) with ESMTP id CF8601FE41; Wed, 3 Jun 2015 19:03:36 +0200 (CEST) From: Paul Kocialkowski To: u-boot@lists.denx.de Date: Wed, 3 Jun 2015 19:03:26 +0200 Message-Id: <1433351007-1704-1-git-send-email-contact@paulk.fr> X-Mailer: git-send-email 1.9.1 Cc: Marek Vasut , Tom Rini Subject: [U-Boot] [RFC] [PATCH] omap-common: Common boot code OMAP3 support and cleanup X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.15 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" This patch introduces some changes to the omap common boot code, to allow the omap3 to benefit from it, but also to clean it up drastically. It was tested on an OMAP3 device booting from MMC. Since this also affects OMAP4, OMAP5 and AM33xx devices, I'm looking forward to having this tested on boards using those platforms. Since I do not own any such device, I cannot do the testing on them myself. While writing this patch, I came to learn about the boot device descriptor, as mentioned in the "Device Initialization by ROM Code" part of the OMAP36xx TRM. The booting parameter structure (for which the address is given in r0 by the bootrom when starting the U-Boot SPL) holds the address of that device descriptor, but I could not find any description of what its contents are. However, it was apparently being used on != OMAP3 devices, so I just adapted the same logic blindly and used the traditional switch/case for omap3. That said, the OMAP3 also has this descriptor, so I tried to read it when booting the U-Boot SPL from MMC. I got the following: boot device descriptor at 0x4020fbc0 boot device descriptor device data at 0x4020f524 boot mode ends up being 4 Now I would be interested in precise documentation about the fields of that descriptor (and that device data too) where the mmc boot mode is supposed to be stored. The value on omap3 is not usable as-is, so it's either a wrong offset or the mmc boot mode is not part of the structure on omap3. If there is no reason to use a static switch/case for omap3, I'd much rather do away with it. If not, I'd like to have certainty about that fact. In order to list the various values held there, here is a diff that I applied. I would be happy to get feedback from other omap platforms. It goes on top of this patch: diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c b/arch/arm/cpu/armv7/omap-common/boot-common.c index 3bd3f49..0ca3646 100644 --- a/arch/arm/cpu/armv7/omap-common/boot-common.c +++ b/arch/arm/cpu/armv7/omap-common/boot-common.c @@ -67,6 +67,7 @@ void save_omap_boot_params(void) if ((boot_device >= MMC_BOOT_DEVICES_START) && (boot_device <= MMC_BOOT_DEVICES_END)) { +/* #ifdef CONFIG_OMAP34XX switch (boot_device) { case BOOT_DEVICE_MMC1: @@ -77,18 +78,21 @@ void save_omap_boot_params(void) break; } #else +*/ boot_params = omap_boot_params->boot_device_descriptor; +printf("boot device descriptor at 0x%x\n", boot_params); if ((boot_params < NON_SECURE_SRAM_START) || (boot_params > NON_SECURE_SRAM_END)) return; boot_params = *((u32 *)(boot_params + DEVICE_DATA_OFFSET)); +printf("boot device descriptor device data at 0x%x\n", boot_params); if ((boot_params < NON_SECURE_SRAM_START) || (boot_params > NON_SECURE_SRAM_END)) return; boot_mode = *((u32 *)(boot_params + BOOT_MODE_OFFSET)); - +printf("boot mode ends up being %d\n", boot_mode); if (boot_mode != MMCSD_MODE_FS && boot_mode != MMCSD_MODE_RAW) #ifdef CONFIG_SUPPORT_EMMC_BOOT @@ -96,7 +100,7 @@ void save_omap_boot_params(void) #else boot_mode = MMCSD_MODE_UNDEFINED; #endif -#endif +//#endif } gd->arch.omap_boot_mode = boot_mode; @@ -124,11 +128,12 @@ void spl_board_init(void) * We cannot delay the saving further than this, * to prevent overwrites. */ - save_omap_boot_params(); /* Prepare console output */ preloader_console_init(); + save_omap_boot_params(); + #if defined(CONFIG_SPL_NAND_SUPPORT) || defined(CONFIG_SPL_ONENAND_SUPPORT) gpmc_init(); #endif