From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Mon, 14 Sep 2015 19:52:19 -0600 Subject: [U-Boot] Galileo instructions In-Reply-To: References: Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Bin, On 14 September 2015 at 08:32, Bin Meng wrote: > Hi Simon, > > On Mon, Sep 14, 2015 at 9:59 PM, Bin Meng wrote: >> Hi Simon, >> >> On Mon, Sep 14, 2015 at 8:51 PM, Simon Glass wrote: >>> Hi Bin, >>> >>> On 14 September 2015 at 06:49, Bin Meng wrote: >>>> >>>> Hi Simon, >>>> >>>> On Mon, Sep 14, 2015 at 8:45 PM, Simon Glass wrote: >>>> > Hi Bin, >>>> > >>>> > On 13 September 2015 at 03:28, Bin Meng wrote: >>>> >> Hi Simon, >>>> >> >>>> >> On Sun, Sep 13, 2015 at 5:06 AM, Simon Glass 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