[U-Boot] Galileo instructions

[Simon Glass]

Hi Bin,

On 14 September 2015 at 08:32, Bin Meng <bmeng.cn at gmail.com> wrote:
> Hi Simon,
>
> On Mon, Sep 14, 2015 at 9:59 PM, Bin Meng <bmeng.cn at gmail.com> wrote:
>> Hi Simon,
>>
>> On Mon, Sep 14, 2015 at 8:51 PM, Simon Glass <sjg at chromium.org> wrote:
>>> Hi Bin,
>>>
>>> On 14 September 2015 at 06:49, Bin Meng <bmeng.cn at gmail.com> wrote:
>>>>
>>>> Hi Simon,
>>>>
>>>> On Mon, Sep 14, 2015 at 8:45 PM, Simon Glass <sjg at chromium.org> wrote:
>>>> > Hi Bin,
>>>> >
>>>> > On 13 September 2015 at 03:28, Bin Meng <bmeng.cn at gmail.com> wrote:
>>>> >> Hi Simon,
>>>> >>
>>>> >> On Sun, Sep 13, 2015 at 5:06 AM, Simon Glass <sjg at chromium.org> wrote:
>>>> >>> Hi Bin,
>>>> >>>
>>>> >>> I have a Galileo Gen 2 and am trying to get U-Boot to start on it. The
>>>> >>> first problem I have is that the schematic says the chip is a W25Q64FV
>>>> >>> which I think is an 8MB part, but the image produced is only 1MB.
>>>> >>
>>>> >> Yes, the board has an 8MB SPI flash, but U-Boot (u-boot.rom) only
>>>> >> utilizes the last 1MB.
>>>> >>
>>>> >>>
>>>> >>> Also I know that there is a Gen 1 and a Gen 2. I recall you saying
>>>> >>> that U-Boot supports the Gen 2 but can easily support the Gen 1. But
>>>> >>> perhaps I have done something wrong.
>>>> >>>
>>>> >>
>>>> >> I've verified U-Boot can boot on both gen1 and gen2 boards.
>>>> >
>>>> > Thanks.
>>>> >>
>>>> >>> I downloaded the BSP from here:
>>>> >>>
>>>> >>> https://downloadcenter.intel.com/download/23197/Intel-Quark-BSP
>>>> >>>
>>>> >>> File name: Board_Support_Package_Sources_for_Intel_Quark_v1.1.0.7z
>>>> >>> Version: 1.1.0 (Latest)
>>>> >>>
>>>> >>> Date: 03/03/2015
>>>> >>> Size: 2.72 MB
>>>> >>>
>>>> >>> Any hints? I am using a dediprog em100 with a test clip over the flash chip.
>>>> >>>
>>>> >>
>>>> >> It's not clear to me what issue you got. It looks like there might be
>>>> >> some issue for dediporg em100 to handle the rom size mismatch? If this
>>>> >> is the case, you can just create an 8MB u-boot.rom with the 1MB
>>>> >> version with other 7MB filled up with 0xFFs.
>>>> >
>>>> > OK I did this and it works, thanks.
>>>>
>>>> So it's indeed the dediprog em100 cannot handle the rom mismatch?
>>>>
>>>> > Why don't we just change the ROM size? This point is not mentioned in README.x86.
>>>> >
>>>>
>>>> 1MB is enough for U-Boot. u-boot.rom does not necessarily have to
>>>> match the SPI flash size. And on Galileo since there is no Intel ME,
>>>> so we don't need to create a whole 8MB rom. This is the same as Intel
>>>> CrownBay, which has a 2MB SPI flash, but still 1MB u-boot.rom.
>>>
>>> What is the benefit of this mismatch? I only see the down-side at
>>> present (user confusion, unbootable .rom).
>>
>> I don't see this as a down-side. Why did you call this as unbootable
>> .rom? The Dediprog em100 does not work does not mean it is not
>> bootable. The assumption is to program this 1MB u-boot.rom to the last
>> 1MB of the SPI flash. Perhaps you need contact Dediprog to fix their
>> em100 tool to handle such rom mismatch correctly. Or maybe there is
>> some parameter to control such behavior that you are not aware of. I
>
> I don't have a dediprog em100 tool, but based on the user manual [1] I
> found on their website, the em100 tool does support such scenario. If
> you check page 22, the 'Configuration Setting' window allows you can
> specify the flash offset at which you download the rom file. The
> corresponding command line parameter is at page 33, which is '-a
> addr'. For example, on Galileo board, you need specify '-a 0x700000'
> (I believe).

Maybe that is the windows version? My version of the utility does not
have that option.

>
>> think this is quite a normal use case, as is exactly the same as other
>> architectures, that u-boot.bin does not have to match the flash media
>> size. Say on PowerPC BookE processors, the NOR flash media can be 8MB,
>> 16MB, but the generated bootable u-boot.bin is 512KB, 1MB, etc (Check
>> these Freescale QorIQ boards in U-Boot). Users need program u-boot.bin
>> to the last 512KB or 1MB in the NOR flash.
>>
>> And I don't see this is a confusion. Perhaps all x86 boards you've
>> played before require the Intel ME firmware, in which case your
>> u-boot.rom MUST match the SPI flash size, but we have to realize Intel
>> ME is an optional feature and not every x86 board requires that. I am
>> afraid this is a preconceived idea instead of confusion.
>>
>
> And one more use case from my experience FYI, on Intel Bayley Bay
> which is a BayTrail based board, and it requires Intel ME, as you see
> its u-boot.rom is 8MB which is the same as MinnowMax. But I did a
> trick in my debugging, that I changed the rom size to 1MB and remove
> the Intel ME Kconfig option from 'menuconfig'. This way I only need
> program a 1MB u-boot.rom starting from 0x700000. Only the very first
> time I touch this board, I chose to program the complete 8MB
> u-boot.rom to the SPI flash. Programming 1MB takes quite less time
> than 8MB, not to mention the first 5MB (flash descriptors plus Intel
> ME firmware) is always the same.

OK I see, but in that case you are building a partial image. This is
an optimisation which could be done another way, e.g. by cutting off
the top part of the image.

I think the .rom file should actually be writen to the ROM as is. To
me it seems clearer. Perhaps we should provide another file which is
optimised - e.g. a minimal file like u-boot.rom.min? Also even 1MB is
a lot more than you normally need to write - does the flashing tool
you use provide options to write a partial image?

>
> [1] http://www.dediprog.com/save/79.pdf/to/DP_EM100Pro_user%20manual_V1.3.pdf

Regards,
Simon