On 02.05.16 04:29, Derald D. Woods wrote:
> On 05/01/2016 09:17 PM, Derald D. Woods wrote:
>> On 05/01/2016 08:57 PM, Tom Rini wrote:
>>> On Sun, May 01, 2016 at 08:32:48PM -0500, Derald D. Woods wrote:
>>>> On 05/01/2016 03:37 AM, Masahiro Yamada wrote:
>>>>> Hi Adam,
>>>>>
>>>>>
>>>>> 2016-04-30 3:06 GMT+09:00 Adam Ford <aford...@gmail.com>:
>>>>>> On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini <tr...@konsulko.com>
>>>>>> wrote:
>>>>>>> On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote:
>>>>>>>
>>>>>>>> Does anyone with an OMAP3 board have any issues with this patch? I
>>>>>>>> will admit I haven't stayed on top of stuff due to moving, and
>>>>>>>> other
>>>>>>>> issues at home, but I pulled down the master to reviews some on
>>>>>>>> related stuff, and found that master doesn't boot. I used git
>>>>>>>> bisect
>>>>>>>> this morning and it narrowed down a problem with booting to this
>>>>>>>> patch.
>>>>>>>>
>>>>>>>> With the patch, I get:
>>>>>>>>
>>>>>>>> U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27)
>>>>>>>> Trying to boot from MMC
>>>>>>> OK. Do you have u-boot.bin or u-boot.img (which?) written to the
>>>>>>> raw
>>>>>>> offset in MMC or from filesystem? Based on the log it looks like
>>>>>>> filesystem.
>>>>>> I have u-boot.img copied to the fatfs on the card, but I didn't
>>>>>> put it
>>>>>> in a specific location.
>>>>>>
>>>>>> I never used to have to do that. Is this a new behavior and is it
>>>>>> documented somewhere?
>>>>>>
>>>>>> adam
>>>>> You are expecting to boot it from FAT,
>>>>> but I think spl_boot_mode() on your board returns MMCSD_MODE_RAW.
>>>>>
>>>>> Can you fix the function to return MMCSD_MODE_FS?
>>>>>
>>>>>
>>>>>
>>>>> This commit changed to allow to load raw U-Boot image,
>>>>> so MMCSD_MODE_RAW never fails.
>>>>>
>>>>> So, you can no longer rely on the former behavior
>>>>> "try MMCSD_MODE_RAW first, and fallback to MMCSD_MODE_FS".
>>>>>
>>>> So everyone loading MLO from the FAT filesystem is now wrong? I am
>>>> trying to understand how this came into being the default.
>>> ... yes, we can't break the case of SPL+U-Boot being on FS on MMC1. I
>>> wonder if:
>>> commit 22d90d560a2b01c47f180e196e6c6485eb8e65db
>>> Author: Alexander Graf <ag...@suse.de>
>>> Date: Tue Mar 1 09:56:34 2016 +0100
>>>
>>> omap3: Use raw SPL by default for mmc1
>>>
>>> Isn't part of what's going wrong now.
>>>
>> Reverting that commit worked for me!
>>
>> ---8<----------------------------------------------
>>
>> U-Boot SPL 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05)
>> Trying to boot from MMC1
>> reading args
>> spl_load_image_fat_os: error reading image args, err - -1
>> reading u-boot.img
>> reading u-boot.img
>>
>>
>> U-Boot 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05 -0500)
>>
>> OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz
>> Logic DM37x/OMAP35x reference board + LPDDR/NAND
>>
>> ---8<----------------------------------------------
>>
>> Derald
>>
>>
>
> I should also mention that I have Tom's patch from this mailing list
> thread:
>
> "[U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size"
>
> So with the reversion and patch I can boot master on 'omap3_logic' again.
Ok, so I've tried to see why things don't work and dug out my beagle xm
from the shelf. Unfortunately, I don't even get it to boot at all with
current master. Bisecting points me to the commit below which makes
sense - we simply change the raw offset on SD for all OMAP systems.
Is that a good idea? It probably breaks pretty much every user that uses
raw boot right now.
Alex
ef5ebe951bec72631cdbc7cef9079e6c684e5d0b is the first bad commit
commit ef5ebe951bec72631cdbc7cef9079e6c684e5d0b
Author: Semen Protsenko <semen.protse...@linaro.org>
Date: Wed Apr 20 12:05:59 2016 +0300
ti_armv7_common.h: Fix U-Boot location on eMMC
According to common eMMC partition table for Android boot (see
PARTS_DEFAULT definition in include/configs/dra7xx_evm.h), "bootloader"
partition (where u-boot.img is stored) starts at 256 KiB. Which is equal
to 512 sectors (as 1 MMC sector size is 512 bytes).
This patch fixes CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR constant so
that
it points to correct address of "bootloader" partition and SPL is
able to
read, parse and run u-boot.img correctly.
This change was originally done as part of patch [1] in omapzoom u-boot.
Without this patch, SPL fails to parse U-Boot header with next error:
mkimage signature not found - ih_magic = 4814325a
While at it, also fix U-Boot partition size, which is 384 KiB (as
stated in
include/configs/dra7xx_evm.h).
[1]
http://omapzoom.org/?p=repo/u-boot.git;a=commit;h=742b82d0c0aa0ed8096c2225a00e9f350212efa9
Signed-off-by: Sam Protsenko <semen.protse...@linaro.org>
Reviewed-by: Tom Rini <tr...@konsulko.com>
:040000 040000 654bed461e899940d8c2acab63de79cbb39551fb
713db2df931848d19ce3f41602b79f7197dd9646 M include
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
