* [U-Boot] Galileo instructions
@ 2015-09-12 21:06 Simon Glass
2015-09-13 9:28 ` Bin Meng
0 siblings, 1 reply; 13+ messages in thread
From: Simon Glass @ 2015-09-12 21:06 UTC (permalink / raw)
To: u-boot
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.
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 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.
Regards,
Simon
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Galileo instructions
2015-09-12 21:06 [U-Boot] Galileo instructions Simon Glass
@ 2015-09-13 9:28 ` Bin Meng
2015-09-14 12:45 ` Simon Glass
0 siblings, 1 reply; 13+ messages in thread
From: Bin Meng @ 2015-09-13 9:28 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Sun, Sep 13, 2015 at 5:06 AM, Simon Glass <sjg@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.
> 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.
Regards,
Bin
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Galileo instructions
2015-09-13 9:28 ` Bin Meng
@ 2015-09-14 12:45 ` Simon Glass
2015-09-14 12:49 ` Bin Meng
0 siblings, 1 reply; 13+ messages in thread
From: Simon Glass @ 2015-09-14 12:45 UTC (permalink / raw)
To: u-boot
Hi Bin,
On 13 September 2015 at 03:28, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Sun, Sep 13, 2015 at 5:06 AM, Simon Glass <sjg@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. Why don't we just change the ROM
size? This point is not mentioned in README.x86.
Regards,
Simon
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Galileo instructions
2015-09-14 12:45 ` Simon Glass
@ 2015-09-14 12:49 ` Bin Meng
2015-09-14 12:51 ` Simon Glass
0 siblings, 1 reply; 13+ messages in thread
From: Bin Meng @ 2015-09-14 12:49 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Mon, Sep 14, 2015 at 8:45 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 13 September 2015 at 03:28, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Simon,
>>
>> On Sun, Sep 13, 2015 at 5:06 AM, Simon Glass <sjg@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.
Regards,
Bin
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Galileo instructions
2015-09-14 12:49 ` Bin Meng
@ 2015-09-14 12:51 ` Simon Glass
2015-09-14 13:59 ` Bin Meng
0 siblings, 1 reply; 13+ messages in thread
From: Simon Glass @ 2015-09-14 12:51 UTC (permalink / raw)
To: u-boot
Hi Bin,
On 14 September 2015 at 06:49, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Simon,
>
> On Mon, Sep 14, 2015 at 8:45 PM, Simon Glass <sjg@chromium.org> wrote:
> > Hi Bin,
> >
> > On 13 September 2015 at 03:28, Bin Meng <bmeng.cn@gmail.com> wrote:
> >> Hi Simon,
> >>
> >> On Sun, Sep 13, 2015 at 5:06 AM, Simon Glass <sjg@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).
Regards,
Simon
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Galileo instructions
2015-09-14 12:51 ` Simon Glass
@ 2015-09-14 13:59 ` Bin Meng
2015-09-14 14:32 ` Bin Meng
0 siblings, 1 reply; 13+ messages in thread
From: Bin Meng @ 2015-09-14 13:59 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Mon, Sep 14, 2015 at 8:51 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 14 September 2015 at 06:49, Bin Meng <bmeng.cn@gmail.com> wrote:
>>
>> Hi Simon,
>>
>> On Mon, Sep 14, 2015 at 8:45 PM, Simon Glass <sjg@chromium.org> wrote:
>> > Hi Bin,
>> >
>> > On 13 September 2015 at 03:28, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >> Hi Simon,
>> >>
>> >> On Sun, Sep 13, 2015 at 5:06 AM, Simon Glass <sjg@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
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.
Regards,
Bin
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Galileo instructions
2015-09-14 13:59 ` Bin Meng
@ 2015-09-14 14:32 ` Bin Meng
2015-09-15 1:52 ` Simon Glass
0 siblings, 1 reply; 13+ messages in thread
From: Bin Meng @ 2015-09-14 14:32 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Mon, Sep 14, 2015 at 9:59 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Mon, Sep 14, 2015 at 8:51 PM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Bin,
>>
>> On 14 September 2015 at 06:49, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>
>>> Hi Simon,
>>>
>>> On Mon, Sep 14, 2015 at 8:45 PM, Simon Glass <sjg@chromium.org> wrote:
>>> > Hi Bin,
>>> >
>>> > On 13 September 2015 at 03:28, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> >> Hi Simon,
>>> >>
>>> >> On Sun, Sep 13, 2015 at 5:06 AM, Simon Glass <sjg@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).
> 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.
[1] http://www.dediprog.com/save/79.pdf/to/DP_EM100Pro_user%20manual_V1.3.pdf
Regards,
Bin
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Galileo instructions
2015-09-14 14:32 ` Bin Meng
@ 2015-09-15 1:52 ` Simon Glass
2015-09-15 2:06 ` Bin Meng
0 siblings, 1 reply; 13+ messages in thread
From: Simon Glass @ 2015-09-15 1:52 UTC (permalink / raw)
To: u-boot
Hi Bin,
On 14 September 2015 at 08:32, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Mon, Sep 14, 2015 at 9:59 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Simon,
>>
>> On Mon, Sep 14, 2015 at 8:51 PM, Simon Glass <sjg@chromium.org> wrote:
>>> Hi Bin,
>>>
>>> On 14 September 2015 at 06:49, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>
>>>> Hi Simon,
>>>>
>>>> On Mon, Sep 14, 2015 at 8:45 PM, Simon Glass <sjg@chromium.org> wrote:
>>>> > Hi Bin,
>>>> >
>>>> > On 13 September 2015 at 03:28, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> >> Hi Simon,
>>>> >>
>>>> >> On Sun, Sep 13, 2015 at 5:06 AM, Simon Glass <sjg@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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Galileo instructions
2015-09-15 1:52 ` Simon Glass
@ 2015-09-15 2:06 ` Bin Meng
2015-09-15 2:15 ` Simon Glass
0 siblings, 1 reply; 13+ messages in thread
From: Bin Meng @ 2015-09-15 2:06 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Tue, Sep 15, 2015 at 9:52 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 14 September 2015 at 08:32, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Simon,
>>
>> On Mon, Sep 14, 2015 at 9:59 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Mon, Sep 14, 2015 at 8:51 PM, Simon Glass <sjg@chromium.org> wrote:
>>>> Hi Bin,
>>>>
>>>> On 14 September 2015 at 06:49, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>
>>>>> Hi Simon,
>>>>>
>>>>> On Mon, Sep 14, 2015 at 8:45 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>> > Hi Bin,
>>>>> >
>>>>> > On 13 September 2015 at 03:28, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> >> Hi Simon,
>>>>> >>
>>>>> >> On Sun, Sep 13, 2015 at 5:06 AM, Simon Glass <sjg@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.
>
>>
>> [1] http://www.dediprog.com/save/79.pdf/to/DP_EM100Pro_user%20manual_V1.3.pdf
>
Regards,
Bin
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Galileo instructions
2015-09-15 2:06 ` Bin Meng
@ 2015-09-15 2:15 ` Simon Glass
2015-09-15 2:30 ` Bin Meng
0 siblings, 1 reply; 13+ messages in thread
From: Simon Glass @ 2015-09-15 2:15 UTC (permalink / raw)
To: u-boot
Hi Bin,
On 14 September 2015 at 20:06, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Simon,
>
> On Tue, Sep 15, 2015 at 9:52 AM, Simon Glass <sjg@chromium.org> wrote:
> > Hi Bin,
> >
> > On 14 September 2015 at 08:32, Bin Meng <bmeng.cn@gmail.com> wrote:
> >> Hi Simon,
> >>
> >> On Mon, Sep 14, 2015 at 9:59 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> >>> Hi Simon,
> >>>
> >>> On Mon, Sep 14, 2015 at 8:51 PM, Simon Glass <sjg@chromium.org> wrote:
> >>>> Hi Bin,
> >>>>
> >>>> On 14 September 2015 at 06:49, Bin Meng <bmeng.cn@gmail.com> wrote:
> >>>>>
> >>>>> Hi Simon,
> >>>>>
> >>>>> On Mon, Sep 14, 2015 at 8:45 PM, Simon Glass <sjg@chromium.org> wrote:
> >>>>> > Hi Bin,
> >>>>> >
> >>>>> > On 13 September 2015 at 03:28, Bin Meng <bmeng.cn@gmail.com> wrote:
> >>>>> >> Hi Simon,
> >>>>> >>
> >>>>> >> On Sun, Sep 13, 2015 at 5:06 AM, Simon Glass <sjg@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.
Perhaps it is more confusing because the image goes at the end of the
ROM, not the start.
>
> >
> >>
> >> [1] http://www.dediprog.com/save/79.pdf/to/DP_EM100Pro_user%20manual_V1.3.pdf
> >
Regards,
Simon
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Galileo instructions
2015-09-15 2:15 ` Simon Glass
@ 2015-09-15 2:30 ` Bin Meng
2015-09-21 19:41 ` Simon Glass
0 siblings, 1 reply; 13+ messages in thread
From: Bin Meng @ 2015-09-15 2:30 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Tue, Sep 15, 2015 at 10:15 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 14 September 2015 at 20:06, Bin Meng <bmeng.cn@gmail.com> wrote:
>>
>> Hi Simon,
>>
>> On Tue, Sep 15, 2015 at 9:52 AM, Simon Glass <sjg@chromium.org> wrote:
>> > Hi Bin,
>> >
>> > On 14 September 2015 at 08:32, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >> Hi Simon,
>> >>
>> >> On Mon, Sep 14, 2015 at 9:59 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >>> Hi Simon,
>> >>>
>> >>> On Mon, Sep 14, 2015 at 8:51 PM, Simon Glass <sjg@chromium.org> wrote:
>> >>>> Hi Bin,
>> >>>>
>> >>>> On 14 September 2015 at 06:49, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >>>>>
>> >>>>> Hi Simon,
>> >>>>>
>> >>>>> On Mon, Sep 14, 2015 at 8:45 PM, Simon Glass <sjg@chromium.org> wrote:
>> >>>>> > Hi Bin,
>> >>>>> >
>> >>>>> > On 13 September 2015 at 03:28, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >>>>> >> Hi Simon,
>> >>>>> >>
>> >>>>> >> On Sun, Sep 13, 2015 at 5:06 AM, Simon Glass <sjg@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.
>
> 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.
>>
>> >
>> >>
>> >> [1] http://www.dediprog.com/save/79.pdf/to/DP_EM100Pro_user%20manual_V1.3.pdf
>> >
Regards,
Bin
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Galileo instructions
2015-09-15 2:30 ` Bin Meng
@ 2015-09-21 19:41 ` Simon Glass
2015-09-22 2:06 ` Bin Meng
0 siblings, 1 reply; 13+ messages in thread
From: Simon Glass @ 2015-09-21 19:41 UTC (permalink / raw)
To: u-boot
Hi Bin,
On 14 September 2015 at 20:30, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Simon,
>
> On Tue, Sep 15, 2015 at 10:15 AM, Simon Glass <sjg@chromium.org> wrote:
> > Hi Bin,
> >
> > On 14 September 2015 at 20:06, Bin Meng <bmeng.cn@gmail.com> wrote:
> >>
> >> Hi Simon,
> >>
> >> On Tue, Sep 15, 2015 at 9:52 AM, Simon Glass <sjg@chromium.org> wrote:
> >> > Hi Bin,
> >> >
> >> > On 14 September 2015 at 08:32, Bin Meng <bmeng.cn@gmail.com> wrote:
> >> >> Hi Simon,
> >> >>
> >> >> On Mon, Sep 14, 2015 at 9:59 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> >> >>> Hi Simon,
> >> >>>
> >> >>> On Mon, Sep 14, 2015 at 8:51 PM, Simon Glass <sjg@chromium.org> wrote:
> >> >>>> Hi Bin,
> >> >>>>
> >> >>>> On 14 September 2015 at 06:49, Bin Meng <bmeng.cn@gmail.com> wrote:
> >> >>>>>
> >> >>>>> Hi Simon,
> >> >>>>>
> >> >>>>> On Mon, Sep 14, 2015 at 8:45 PM, Simon Glass <sjg@chromium.org> wrote:
> >> >>>>> > Hi Bin,
> >> >>>>> >
> >> >>>>> > On 13 September 2015 at 03:28, Bin Meng <bmeng.cn@gmail.com> wrote:
> >> >>>>> >> Hi Simon,
> >> >>>>> >>
> >> >>>>> >> On Sun, Sep 13, 2015 at 5:06 AM, Simon Glass <sjg@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.
Regards,
Simon
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Galileo instructions
2015-09-21 19:41 ` Simon Glass
@ 2015-09-22 2:06 ` Bin Meng
0 siblings, 0 replies; 13+ messages in thread
From: Bin Meng @ 2015-09-22 2:06 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Tue, Sep 22, 2015 at 3:41 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 14 September 2015 at 20:30, Bin Meng <bmeng.cn@gmail.com> wrote:
>>
>> Hi Simon,
>>
>> On Tue, Sep 15, 2015 at 10:15 AM, Simon Glass <sjg@chromium.org> wrote:
>> > Hi Bin,
>> >
>> > On 14 September 2015 at 20:06, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >>
>> >> Hi Simon,
>> >>
>> >> On Tue, Sep 15, 2015 at 9:52 AM, Simon Glass <sjg@chromium.org> wrote:
>> >> > Hi Bin,
>> >> >
>> >> > On 14 September 2015 at 08:32, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >> >> Hi Simon,
>> >> >>
>> >> >> On Mon, Sep 14, 2015 at 9:59 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >> >>> Hi Simon,
>> >> >>>
>> >> >>> On Mon, Sep 14, 2015 at 8:51 PM, Simon Glass <sjg@chromium.org> wrote:
>> >> >>>> Hi Bin,
>> >> >>>>
>> >> >>>> On 14 September 2015 at 06:49, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >> >>>>>
>> >> >>>>> Hi Simon,
>> >> >>>>>
>> >> >>>>> On Mon, Sep 14, 2015 at 8:45 PM, Simon Glass <sjg@chromium.org> wrote:
>> >> >>>>> > Hi Bin,
>> >> >>>>> >
>> >> >>>>> > On 13 September 2015 at 03:28, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >> >>>>> >> Hi Simon,
>> >> >>>>> >>
>> >> >>>>> >> On Sun, Sep 13, 2015 at 5:06 AM, Simon Glass <sjg@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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2015-09-22 2:06 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-12 21:06 [U-Boot] Galileo instructions Simon Glass
2015-09-13 9:28 ` Bin Meng
2015-09-14 12:45 ` Simon Glass
2015-09-14 12:49 ` Bin Meng
2015-09-14 12:51 ` Simon Glass
2015-09-14 13:59 ` Bin Meng
2015-09-14 14:32 ` Bin Meng
2015-09-15 1:52 ` Simon Glass
2015-09-15 2:06 ` Bin Meng
2015-09-15 2:15 ` Simon Glass
2015-09-15 2:30 ` Bin Meng
2015-09-21 19:41 ` Simon Glass
2015-09-22 2:06 ` Bin Meng
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.