[U-Boot] Galileo instructions

[Bin Meng]

Hi Simon,

On Tue, Sep 22, 2015 at 3:41 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi Bin,
>
> On 14 September 2015 at 20:30, Bin Meng <bmeng.cn at gmail.com> wrote:
>>
>> Hi Simon,
>>
>> On Tue, Sep 15, 2015 at 10:15 AM, Simon Glass <sjg at chromium.org> wrote:
>> > Hi Bin,
>> >
>> > On 14 September 2015 at 20:06, Bin Meng <bmeng.cn at gmail.com> wrote:
>> >>
>> >> Hi Simon,
>> >>
>> >> On Tue, Sep 15, 2015 at 9:52 AM, Simon Glass <sjg at chromium.org> wrote:
>> >> > 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.
>> >>
>> >> Looks it is the Windows version. So you are using Linux version which
>> >> does not have such feature? It's quite odd if that's the case.
>> >>
>> >> >
>> >> >>
>> >> >>> 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.
>> >> >
>> >>
>> >> It is not a partial *image*. It is a complete image which can boot on
>> >> the board. It is not working because we programmed (ie: using Dediprog
>> >> sf100) or downloaded (ie: using Dediprog em100) to a wrong place. We
>> >> probably could say it is a partial *rom*, if we specify *rom*
>> >> corresponds to the whole SPI flash.
>> >>
>> >> > 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
>> >>
>> >> No, I don't think so. The SPI flash is only the flash media to store
>> >> bootloader, but the bootloader file size does not have to match the
>> >> SPI flash size. The SPI flash can have some places to store kernel
>> >> image, root file system, etc. We cannot create a u-boot.rom which
>> >> occupies all these spaces.
>> >>
>> >> > 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?
>> >>
>> >> Again, it is not a partial *image*. It is a complete *image*. The
>> >> flash tool (I am using Dediprog sf100) supports writing a file to
>> >> whatever flash offset. And I believe, such feature is probably
>> >> supported by all flash tools in the market as it is a very basic and
>> >> common use case. Why are you forcing users to always erase the whole
>> >> SPI flash and program a file which corresponds to the whole SPI flash?
>> >> It is not only SPI flash, but also the case for NOR flash, NAND flash
>> >> programmers that I have ever used. All of these support writing a file
>> >> to a particular flash offset.
>> >
>> > Well since this seems to be what you want, then at least the docs
>> > should be updated to explain this.
>>
>> I think this is a common sense, isn't it? As I said, perhaps there is
>> a preconceived idea on the ROM location. Since preciously all x86
>> board you've worked on happen to require a u-boot.rom corresponding to
>> whole SPI flash in order to boot (this is required by the chipset
>> implementation, as there is a flash descriptor plus Intel ME firmware
>> needs to be there). But SPI flash is not solely used to store
>> bootloader, just like the case on ARM and PowerPC targets.
>
> Sure, but yes I do think it is confusing.
>
>>
>> >
>> > Perhaps it is more confusing because the image goes at the end of the
>> > ROM, not the start.
>> >
>>
>> Well, it seems to me you've been working too much in the ARM world
>> where ARM bootloaders (to be exactly, 1st stage bootloaders) normally
>> starts from flash offset 0 because the reset vector is there. :-) This
>> is always the case for x86 (at the flash end due to x86 reset vector
>> is there), and for PowerPC BookE processors (like IBM/AMCC 4xx,
>> Freescale MPC85xx, QorIQ P/T series). Other PowerPC processors like
>> 603, 83xx have an option to decide where the bootloader should be (ie:
>> they can reside at the start of the flash, just like ARM). I would say
>> this is not a confusion, as this is something defined by the
>> architecture and/or the SoC implementation that we (as U-Boot users)
>> must be aware of.
>
> Working *not enough* in the ARM world :-)
>
> I do think it would be useful to update the docs here. The 'ROM size'
> parameter seems pretty confusing to me. I suggest a README.x86 update.
>

OK, sounds good to me.

Regards,
Bin