upload zImage to Ben NanoNote

[Xiangfu Liu]

Hi

thanks for the info. will keep post when have progress on "upload zImage"

Bas Wijnen wrote:
> Hi,
> 
> For clarity, I suppose you are referring to table 3-30 in the 4720
> datasheet.
> 
> It seems that indeed there is some setup done by the boot rom when
> booting from nand flash.  Appearantly this setup is not undone when
> booting from usb, so this is likely to be the issue you're seeing.  I
> don't see it with Iris, because I don't use the flash at all yet (all
> programs and data are read from usb).
> 
> Setting up those pins to "alternate function" should help.  All the pins
> that are mentioned in the table are set by __gpio_as_nand() from
> include/asm-mips/jz4740/ops.h .  Except the port A pins, but they are
> set to "alternate function" already by __gpio_as_sdram_16bit() (I think
> Linux uses _32bit, which makes no difference because all the other pins
> are unavailable in the 4720).
> 
> So in short, adding __gpio_as_nand() to the startup code (near all the
> other __gpio_as_* calls) should fix your problem.
> 
> Thanks,
> Bas
> 
> On Sun, Dec 27, 2009 at 10:53:31PM +0800, Xiangfu Liu wrote:
>> Hi  Bas Wijnen
>>
>>  I found there is some GPIO status difference in different boot mode.
>>  [Table 3-30] -- Pins are used and are set to function pins during BOOT
>> maybe we need set those GPIO when usbboot mode. 
>>
>>
>> Bas Wijnen wrote:
>>> On Sun, Dec 06, 2009 at 01:02:45AM +0800, Xiangfu Liu wrote:
>>>> I have try to send the Linux(zImage) or u-boot to device like Iris.
>>>> I use the "xbboot" in xburst-tools.git 
>>> I took most of my own "stage 1" driver from xburst-tools as well, so I'm
>>> familiar with the code.
>>>
>>>> direct boot to usbboot mode:
>>>>   1. upload the stage1 to device. (for init PLL, SDRAM, Serial Console)
>>>>   2. upload the zImage to 0x80600000
>>>>   3. run the zImage at 0x80600000
>>>>   then nothing happen in serial console.
>>>>
>>>> BUT if I boot the device to rootfs first, then reset the device to usbboot mode:
>>>>   1. upload the stage1 to device. (for init PLL, SDRAM, Serial Console)
>>>>   2. upload the zImage to 0x80600000
>>>>   3. run the zImage at 0x80600000
>>>> everything ok. kernel booting. 
>>>>
>>>> ----here is the u-boot:
>>>> direct boot to usbboot mode:
>>>>   1. upload the stage1 to device. (for init PLL, SDRAM, Serial Console)
>>>>   2. upload the u-boot.bin to 0x80100000
>>>>   3. run the u-boot.bin at 0x80100000
>>>> u-boot work fine. but stop at "Starting kernel ..." after read the kernel form nand. Uncompress kernel etc.
>>>>
>>>> BUT if I boot the device to rootfs first, then reset the device to usbboot mode:
>>>>   1. upload the stage1 to device. (for init PLL, SDRAM, Serial Console)
>>>>   2. upload the u-boot.bin to 0x80100000
>>>>   3. run the u-boot.bin at 0x80100000
>>>> everything ok. kernel boot to rootfs success.
>>>>
>>>> do you have any clues on this issue?
>>> It seems that some setting up remains in effect after the reset.  I know
>>> that the usbboot stage1 doesn't set up the nand flash, so that may be a
>>> problem.  Perhaps the chip does that by itself when it is booting from
>>> it, but not when booting over usb.
>>>
>>> Also, it is possible that the settings that stage1 tries to use to set
>>> up the sdram are wrong.  Usbboot needs to get some configuration values
>>> from the host.  However, that doesn't really fit with the description,
>>> because then it shouldn't work after a booting rootfs either.
>>>
>>> In case of problems like this one, I excessively use printf (in this
>>> case to the serial port).  For example, I'm printing line numbers of a
>>> file which seems to be a problem.  It usually helps to find the source
>>> of the problem. :-)  If you do this, make sure that the serial port's
>>> buffer is flushed (that is, you wait until it's empty) before
>>> continuing.  It makes everything much slower, but it means that the last
>>> message received is indeed the last thing that was sent.
>>>
>>> Thanks,
>>> Bas
>>>
>>
>> -- 
>> Xiangfu Liu
>> Email: xiangfu at qi-hardware dot com
>> Web: http://www.qi-hardware.com
>>
>> _______________________________________________
>> Qi Developer Mailing List
>> Mail to list (members only): developer at lists.qi-hardware.com
>> Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Qi Developer Mailing List
>> Mail to list (members only): developer at lists.qi-hardware.com
>> Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer


-- 
Xiangfu Liu
Email: xiangfu at qi-hardware dot com
Web: http://www.qi-hardware.com