From: Stefano Babic <sbabic@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 11/11] ventana: switch to SPL
Date: Thu, 24 Apr 2014 10:18:20 +0200 [thread overview]
Message-ID: <5358C8CC.1070208@denx.de> (raw)
In-Reply-To: <CAJ+vNU2D8jN=qzdzz6MnFQ=ixJh3D9TYZo_2eVRNv-hcr5gSfg@mail.gmail.com>
Hi Tim,
On 24/04/2014 10:06, Tim Harvey wrote:
>>> +
>>> +/* configure mx6 mmdc io registers */
>>> +struct mx6_mmdc_ioregs mmdc_ioregs = {
>>> + /* DDR3 */
>>> + .mmdc_grp_ddr_type = 0x000c0000,
>>> + /* disable DDR pullups */
>>> + .mmdc_grp_ddrpke = 0x00000000,
>>> + /* SDCLK[0:1], CAS, RAS, Reset: Differential input, 40ohm */
>>> + .mmdc_dram_sdclk_0 = 0x00020030,
>>> + .mmdc_dram_sdclk_1 = 0x00020030,
>>> + .mmdc_dram_cas = 0x00020030,
>>> + .mmdc_dram_ras = 0x00020030,
>>> + .mmdc_dram_reset = 0x00020030,
>>> + /* ADDR[00:16], SDBA[0:1]: 40 ohm */
>>> + .mmdc_grp_addds = 0x00000030,
>>> + /* SDCKE[0:1]: 100k pull-up */
>>> + .mmdc_dram_sdcke0 = 0x00003000,
>>> + .mmdc_dram_sdcke1 = 0x00003000,
>>> + /* SDBA2: pull-up disabled */
>>> + .mmdc_dram_sdba2 = 0x00000000,
>>> + /* SDODT[0:1]: 100k pull-up, 40 ohm */
>>> + .mmdc_dram_sdodt0 = 0x00003030,
>>> + .mmdc_dram_sdodt1 = 0x00003030,
>>> + /* CS0/CS1/SDBA2/CKE0/CKE1/SDWE: 40 ohm */
>>> + .mmdc_grp_ctlds = 0x00000030,
>>> + /* SDQS[0:7]: Differential input, 40 ohm */
>>> + .mmdc_ddrmode_ctl = 0x00020000,
>>> + .mmdc_dram_sdqs0 = 0x00000030,
>>> + .mmdc_dram_sdqs1 = 0x00000030,
>>> + .mmdc_dram_sdqs2 = 0x00000030,
>>> + .mmdc_dram_sdqs3 = 0x00000030,
>>> + .mmdc_dram_sdqs4 = 0x00000030,
>>> + .mmdc_dram_sdqs5 = 0x00000030,
>>> + .mmdc_dram_sdqs6 = 0x00000030,
>>> + .mmdc_dram_sdqs7 = 0x00000030,
>>> +
>>> + /* DATA[00:63]: Differential input, 40 ohm */
>>> + .mmdc_grp_ddrmode = 0x00020000,
>>> + .mmdc_grp_b0ds = 0x00000030,
>>> + .mmdc_grp_b1ds = 0x00000030,
>>> + .mmdc_grp_b2ds = 0x00000030,
>>> + .mmdc_grp_b3ds = 0x00000030,
>>> + .mmdc_grp_b4ds = 0x00000030,
>>> + .mmdc_grp_b5ds = 0x00000030,
>>> + .mmdc_grp_b6ds = 0x00000030,
>>> + .mmdc_grp_b7ds = 0x00000030,
>>> +
>>> + /* DQM[0:7]: Differential input, 40 ohm */
>>> + .mmdc_dram_dqm0 = 0x00020030,
>>> + .mmdc_dram_dqm1 = 0x00020030,
>>> + .mmdc_dram_dqm2 = 0x00020030,
>>> + .mmdc_dram_dqm3 = 0x00020030,
>>> + .mmdc_dram_dqm4 = 0x00020030,
>>> + .mmdc_dram_dqm5 = 0x00020030,
>>> + .mmdc_dram_dqm6 = 0x00020030,
>>> + .mmdc_dram_dqm7 = 0x00020030,
>>> +};
>>
>> I will suggest you move these structure in a separate file. It is then
>> easier for a board developer to understand what is very board specific.
>
> hmmm... they are all very board specific but ok.
Well, I am noy saying to move it outside board/gateworks/gw_ventana. My
proposal is more as to signalize how to add SPL support for a new board.
Anyway, I agree it is a personal taste.
>
> not needed - I used it mainly for debugging and will remove it.
>
>>
>>> +
>>> + board_init_r(NULL, 0);
>>> +}
>>
>> Mmhhh...apart the access to the eeprom to get the ram size, this
>> function should be common.
>
> maybe, but I think we should wait to see what other boards come up
> with SPL support to see what actually ends up being common. An SPL
> that supports SPI or some of the other boot devices may need to do
> some additional things.
Agree, this makes sense. We can do it later.
>
> yes... considering we currently have 4 baseboards (a fifth on the
> way), supporting both IMX6DL or IMX6Q on each, and have 2 memory
> densities (a third on the way) SPL is a must for my sanity to
> eliminate what would be something like 5*2*3 various build-time
> configurations.
>
> The dynamic ddr configuration functionality I'm proposing helps out
> tremendously as well because the DDR3 calibration and testing I've
> done tells me that each board design (varied layout between SoC and
> DDR3) needs its own calibration values due to propagation delays and
> IMX6Q/D vs IMX6DL/SOLO need different calibration values on each board
> as well. This can all be handled with minimal tables and easily
> configured at runtime via baseboard detection, cpu detection, and
> memory density information.
Very nice.
>>> +#define CONFIG_SYS_NAND_U_BOOT_OFFS (14 * 1024 * 1024)
>>
>> This is ok - it is your decision where to put it.
>>
>> May I ask why do you need 14 MB at the beginning ? It seems you lose a
>> lot of place. NAND is cheap nowadays, but...
>
> it was perhaps a poor decision I made early on when I was following
> too much of the reference design without understanding all the
> details. They used a 16MB area in NAND for the bootstreams so that is
> what I used as well. I worked through the calculation once and the
> 16MB wasn't all that crazy considering at the time I was wanting
> enough room to support a 1MB u-boot. When you add the blocks and
> redundant blocks for FCB/DBBT (default is to have 2 copies of these),
> then double the bootloader size (because IMX BOOT ROM supports 2
> firmware images for redundancy), and factor in 20% headroom to allow
> for bad blocks, the 16MB wasn't all that crazy. Now that I'm talking
> about using 14MB for a <64KB SPL image, its overkill for sure.
>
> I don't want to impose a partition layout change on our existing users
> that I want to update to the SPL bootloader (with all the improved
> DDR3 calibration values) so I figure we'll put u-boot.img in the last
> 2MB of the 16MB partition for the 'bootloader' and leave the first
> 14MB for SPL to be flashed according to the IMX6 BOOT ROM.
ok, thanks for explanation
>
>>
>>> +
>>> +#include "imx6_spl.h" /* common IMX6 SPL configuration */
>>> #include "mx6_common.h"
>>> #define CONFIG_MX6
>>> #define CONFIG_DISPLAY_CPUINFO /* display cpu info */
>>> @@ -242,7 +253,7 @@
>>> "mtdparts=nor:512k(uboot),64k(env),2m(kernel),-(rootfs)"
>>> #else
>>> #define MTDIDS_DEFAULT "nand0=nand"
>>> -#define MTDPARTS_DEFAULT "mtdparts=nand:16m(uboot),1m(env),-(rootfs)"
>>> +#define MTDPARTS_DEFAULT "mtdparts=nand:14m(spl),2m(uboot),1m(env),-(rootfs)"
>
> and I'll be reverting that last change as well and leaving the
> original 16M partition for the 'bootloader' meaning the 14MB area
> flashed by kobs-ng according to the IMX6 BOOT ROM requirements for
> NAND boot as well as the 2MB area I'm reserving for u-boot.img.
>
> If I were to split the partitions like the above change, it will cause
> some grief for existing users that are using the 3.0.35 (non
> device-tree) vendor kernel that has the mtd partitions hard coded in
> the board support. Instead, I decided to patch the kobs-ng application
> used to flash the SPL so that it can be passed a max size to use
> within /dev/mtd0 and users that need to upgrade to the SPL bootloader
> will need to use that patched kobs-ng to flash the SPL to the first
> 14MB, then use std mtd utils to flash u-boot.img in the area between
> 14M and 16M.
>
> Don't forget, at some point soon I hope to add some functionality to
> u-boot to flash the SPL portion to nand (the way kobs-ng does) so that
> you don't need to boot to linux and use kobs-ng or use our JTAG tool.
This will be a great improvement ! Thanks for working on this issue.
Best regards,
Stefano
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
next prev parent reply other threads:[~2014-04-24 8:18 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-03 6:01 [U-Boot] [PATCH 00/11] MX6: SPL NAND support Tim Harvey
2014-04-03 6:01 ` [U-Boot] [PATCH 01/11] SPL: NAND: remove CONFIG_SYS_NAND_PAGE_SIZE Tim Harvey
2014-04-04 2:33 ` Masahiro Yamada
2014-04-09 14:55 ` Nikita Kiryanov
2014-04-14 11:38 ` Stefano Babic
2014-04-17 14:18 ` Tim Harvey
2014-04-18 22:23 ` Scott Wood
2014-04-03 6:01 ` [U-Boot] [PATCH 02/11] SPL: NAND: add support for mxs nand Tim Harvey
2014-04-14 11:38 ` Stefano Babic
2014-04-03 6:01 ` [U-Boot] [PATCH 03/11] MX6: provide linker script for SPL Tim Harvey
2014-04-09 14:55 ` Nikita Kiryanov
2014-04-14 12:02 ` Stefano Babic
2014-04-17 6:27 ` Tim Harvey
2014-04-18 21:10 ` Otavio Salvador
2014-04-03 6:01 ` [U-Boot] [PATCH 04/11] MX6: add common SPL configuration Tim Harvey
2014-04-09 14:55 ` Nikita Kiryanov
2014-04-09 15:32 ` Tim Harvey
2014-04-10 14:37 ` Nikita Kiryanov
2014-04-10 21:04 ` Scott Wood
2014-04-03 6:01 ` [U-Boot] [PATCH 05/11] MX6: add boot device support SPL Tim Harvey
2014-04-14 12:27 ` Stefano Babic
2014-04-17 6:16 ` Tim Harvey
2014-04-17 8:59 ` Stefano Babic
2014-04-03 6:01 ` [U-Boot] [PATCH 06/11] MX6: add struct for sharing data between SPL and uboot Tim Harvey
2014-04-09 14:55 ` Nikita Kiryanov
2014-04-14 12:35 ` Stefano Babic
2014-04-17 6:07 ` Tim Harvey
2014-04-17 9:30 ` Stefano Babic
2014-04-17 11:22 ` Igor Grinberg
2014-04-17 11:44 ` Stefano Babic
2014-04-18 6:35 ` Tim Harvey
2014-04-20 7:52 ` Igor Grinberg
2014-04-21 18:28 ` Tim Harvey
2014-04-22 7:44 ` Igor Grinberg
2014-04-03 6:01 ` [U-Boot] [PATCH 07/11] MX6: use macro building for MX6Q/MX6DL iomux regs Tim Harvey
2014-04-09 14:57 ` Nikita Kiryanov
2014-04-09 15:46 ` Tim Harvey
2014-04-10 14:08 ` Nikita Kiryanov
2014-04-10 14:51 ` Nikita Kiryanov
2014-04-11 5:23 ` Tim Harvey
2014-04-23 17:07 ` Stefano Babic
2014-04-23 19:00 ` Eric Nelson
2014-04-24 7:07 ` Igor Grinberg
2014-04-24 5:21 ` Tim Harvey
2014-04-23 15:30 ` Stefano Babic
2014-04-03 6:01 ` [U-Boot] [PATCH 08/11] MX6: add mmdc configuration for MX6Q/MX6DL Tim Harvey
2014-04-03 6:01 ` [U-Boot] [PATCH 09/11] IMX: add additional function for pinmux using an array Tim Harvey
2014-04-09 14:56 ` Nikita Kiryanov
2014-04-09 15:40 ` Tim Harvey
2014-04-10 14:41 ` Nikita Kiryanov
2014-04-23 5:03 ` Tim Harvey
2014-04-03 6:01 ` [U-Boot] [PATCH 10/11] ventana: auto-configure for IMX6Q vs IMX6DL Tim Harvey
2014-04-23 17:31 ` Stefano Babic
2014-04-24 5:04 ` Tim Harvey
2014-04-03 6:01 ` [U-Boot] [PATCH 11/11] ventana: switch to SPL Tim Harvey
2014-04-03 18:52 ` Tim Harvey
2014-04-23 18:03 ` Stefano Babic
2014-04-24 8:06 ` Tim Harvey
2014-04-24 8:18 ` Stefano Babic [this message]
2014-04-24 8:22 ` Stefan Roese
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5358C8CC.1070208@denx.de \
--to=sbabic@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.