[U-Boot] SAMA5D2 xplained SD/eMMC boot

[Yang, Wenyou <Wenyou.Yang@atmel.com>]

Hi Marek,

> -----Original Message-----
> From: Marek Vasut [mailto:marex at denx.de]
> Sent: 2016?4?22? 20:18
> To: Yang, Wenyou <Wenyou.Yang@atmel.com>
> Cc: u-boot at lists.denx.de
> Subject: Re: SAMA5D2 xplained SD/eMMC boot
> 
> On 04/22/2016 02:54 AM, Yang, Wenyou wrote:
> > Hi Marek,
> 
> Hi!
> 
> >> -----Original Message-----
> >> From: Marek Vasut [mailto:marex at denx.de]
> >> Sent: 2016?4?21? 10:59
> >> To: Yang, Wenyou <Wenyou.Yang@atmel.com>
> >> Cc: u-boot at lists.denx.de
> >> Subject: Re: SAMA5D2 xplained SD/eMMC boot
> >>
> >> On 04/21/2016 04:46 AM, Yang, Wenyou wrote:
> >>> Hi,
> >>
> >> Hi!
> >>
> >> [...]
> >> pile of unnecessary email headers redacted.
> >> [...]
> >>
> >>>>>>>>>> Hi!
> >>>>>>>>>>
> >>>>>>>>>> I've been playing around with latest mainline u-boot on
> >>>>>>>>>> sama5d2 xplained ultra. I noticed that if I want to boot the
> >>>>>>>>>> board from SD card (SDHCI1), the board will indeed load the
> >>>>>>>>>> SPL from it, but SPL will try to load u-boot.img from eMMC
> >>>>>>>>>> (SDHCI0) and fail, as my eMMC is blank.
> >>>>>>>>>
> >>>>>>>>> Yes, there is some issue to load u-boot.img. I found there is
> >>>>>>>>> something to do on
> >>>>>>>> sdhci.c.
> >>>>>>>>>
> >>>>>>>>> You can try this branch, it should works.
> >>>>>>>>>
> >>>>>>>>> https://github.com/linux4sam/u-boot-at91/commits/u-boot-2016.0
> >>>>>>>>> 3-
> >>>>>>>>> at
> >>>>>>>>> 91
> >>>>>>>>
> >>>>>>>> I am not interested in using non-mainline stuff. Do you have
> >>>>>>>> any particular patch/commit which I can refer to ? I do not
> >>>>>>>> think this has anything to do with sdhci.c driver at all, it
> >>>>>>>> has to do with detecting the boot device from which SPL was
> >>>>>>>> started and loading u-boot.img from the same boot device
> >>>>>>>> instead of always using
> >> SDHCI0.
> >>>>>>>
> >>>>>>> I will test the mainline code. I will let you know when I get something.
> >>>>>>
> >>>>>> OK.
> >>>>>>
> >>>>>> Does the SoC have any sort of register which lists the current boot
> device ?
> >>>>>
> >>>>> In this SoC, there is not register to list the current boot device.
> >>>>
> >>>> And thus, it is not possible to detect at runtime from which device
> >>>> the SoC booted and thus load u-boot.img from the same device. Correct ?
> >>>
> >>> Yes,
> >>
> >> Ha, thanks for confirming.
> >
> > Sorry, can I correct what I said yesterday?
> 
> What if I said "no" ? :-)
> 
> > There is a register to list the boot information exported by ROMCode.
> >
> > The boot information is stored in R4 register when the ROMCode jumps to the
> bootstrap.
> 
> Ha, so the U-Boot SPL can save the r4 register early in the boot and extract the
> boot device from it. That's neat. Thanks!
> 
> > Here is the contents definitions R4 on the SAMA5D2 (improved compared to old
> MPUs to take care of IOSet features).
> 
> Is this stuff somewhere in the SAMA5Dx datasheet ? It'd be nice to know/have this
> information for other SAMA5Dx too (d3 and d4).

It seems it is not included in the in the SAMA5Dx datasheet.

This feature is available since AT91SAM9G45, inclusive d3 and d4.

> 
> > /* bootFrom ID Definitions */
> > #define BOOT_FROM_KEY             	(0xBAu << 24)
> >
> > #define BOOT_FROM_SPI               	(0x0u << 0)
> > #define BOOT_FROM_MCI               	(0x1u << 0)
> > #define BOOT_FROM_SMC               	(0x2u << 0)
> > #define BOOT_FROM_TWI               	(0x3u << 0)
> > #define BOOT_FROM_QSPI             	(0x4u << 0)
> >
> > /* ID number of the IP from the data sheet */
> > #define BOOT_FROM_ID0               (0x0u << 4)
> > #define BOOT_FROM_ID1               (0x1u << 4)
> > #define BOOT_FROM_ID2               (0x2u << 4)
> > #define BOOT_FROM_ID3               (0x3u << 4)
> > #define BOOT_FROM_ID4               (0x4u << 4)
> >
> > #define BOOT_FROM_ID_Pos            	4
> > #define BOOT_FROM_ID_Msk            	(0xfu << BOOT_FROM_ID_Pos)
> > #define BOOT_FROM_ID(value)         	((BOOT_FROM_ID_Msk &
> ((value) << BOOT_FROM_ID_Pos)))
> >
> > #define BOOT_FROM_TYPE_SD_OR_AT25   	(0x0u << 8)
> > #define BOOT_FROM_TYPE_MMC_OR_AT45  (0x1u << 8)
> > #define BOOT_FROM_TYPE_EMMC         	(0x2u << 8)
> >
> > /* QSPI serial flashes */
> > #define BOOT_FROM_TYPE_SPANSION     	(0x0u << 8)
> > #define BOOT_FROM_TYPE_MICRON       	(0x1u << 8)
> > #define BOOT_FROM_TYPE_MACRONIX     	(0x2u << 8)
> >
> > /* Chip Select or (MCI) Slot identifier used in code by the IP. */
> > #define BOOT_FROM_CS0               (0x0u << 12) // Slot A
> > #define BOOT_FROM_CS1               (0x1u << 12) // Slot B
> > #define BOOT_FROM_CS2               (0x2u << 12) // Slot C
> > #define BOOT_FROM_CS3               (0x3u << 12) // Slot D
> > #define BOOT_FROM_CS4               (0x4u << 12)
> >
> > #define BOOT_FROM_CS_Pos            12
> > #define BOOT_FROM_CS_Msk            (0xfu << BOOT_FROM_CS_Pos)
> > #define BOOT_FROM_CS(value)         ((BOOT_FROM_CS_Msk & ((value) <<
> BOOT_FROM_CS_Pos)))
> >
> > #define BOOT_FROM_IOSET_Pos         16
> > #define BOOT_FROM_IOSET_Msk         (0x3u << BOOT_FROM_IOSET_Pos)
> > #define BOOT_FROM_IOSET(value)       ((BOOT_FROM_IOSET_Msk &
> ((value) << BOOT_FROM_IOSET_Pos)))>>
> >
> >
> >> [...]
> >>
> >> --
> >> Best regards,
> >> Marek Vasut
> >
> > Sorry for incorrect information before.
> 
> No problem, thanks for the update!
> 
> > Best Regards,
> > Wenyou Yang
> >
> 
> 
> --
> Best regards,
> Marek Vasut


Best Regards,
Wenyou Yang