[U-Boot] [linux-sunxi] Re: Latest U-boot branch not booting on Hummingbird A31

[Hans de Goede]

Hi,

On 21-03-16 11:06, Chen-Yu Tsai wrote:
> Hi,
>
> On Mon, Mar 21, 2016 at 5:57 PM, Hans de Goede <hdegoede at redhat.com> wrote:
>> HI,
>>
>>
>> On 21-03-16 10:49, wens Tsai wrote:
>>>
>>> Hi Hans,
>>>
>>> I updated U-boot on my boards to your latest sunxi-wip branch:
>>>
>>>       f965340 ("sunxi: Enable support for the eMMC found on the orangepi
>>> plus")
>>>
>>> My Hummingbird A31 fails to boot after this. See log:
>>>
>>> HELLO! BOOT0 is starting!
>>> boot0 version : 3.0.0
>>> reg_addr 0x01f00100 =0x00000000
>>> reg_addr 0x01f00104 =0x00000000
>>> reg_addr 0x01f00108 =0x00000000
>>> reg_addr 0x01f0010c =0x00000000
>>> reg_addr 0x01f00110 =0x00000000
>>> reg_addr 0x01f00114 =0x00000000
>>> [DRAM]ver 1.03 clk = 312
>>> cpu 0 pmu 0
>>> dram size =1024
>>> sum=0x31776fa8
>>> src_sum=0x31776fa8
>>> Ready to disable icache.
>>> Jump to secend Boot.
>>> [      0.209]
>>>
>>> U-Boot 2011.09-rc1 (Jun 17 2014 - 17:30:56) Allwinner Technology
>>>
>>> [      0.217]version: 1.1.0
>>> [      0.220]pmbus:   ready
>>> [      0.222]PMU: AXP221
>>> [      0.225]PMU: AXP22x found
>>> [      0.227]PMU: bat ratio = 100
>>> [      0.231]PMU: dcdc3 1260
>>> [      0.233]PMU: pll1 1008 Mhz
>>> dcdc1_vol = 3000
>>> dcdc2_vol = 1200
>>> dcdc3_vol = 1260
>>> dcdc4_vol = 1200
>>> dcdc5_vol = 1500
>>> aldo1_vol = 3000
>>> aldo2_vol = 1800
>>> aldo3_vol = 3000
>>> eldo3_vol = 1800
>>> find power_sply to end
>>> fel key old mode
>>> run key detect
>>> no key found
>>> no key input
>>> dram_para_set start
>>> dram_para_set end
>>> [      0.277]DRAM:  1 GiB
>>> relocation Offset is: 15b25000
>>> donn't initialize ther user_gpio (main_key:boot_init_gpio)
>>> deu_mode1 not exist.
>>> lcdgamma4iep for lcd1 not exist.
>>> DRV_DISP_Init: opened
>>> [      0.542]fetch script data boot_disp.output_type fail
>>> [      0.547]fetch script data boot_disp.output_mode fail
>>> [      0.552]fetch script data boot_disp.auto_hpd fail
>>> [      0.557]lcd0_para.lcd_used=1
>>> workmode = 0
>>> [      0.603]NAND: NAND_UbootInit
>>> NB1 : enter NAND_LogicInit
>>> not burn nand partition table!
>>> NB1 : nftl num: 2
>>>    init nftl: 0
>>> NB1 : NAND_LogicInit ok, result = 0x0
>>> [      1.268]sunxi flash init ok
>>> probe mmc0 if exist
>>> SUNXI SD/MMC: 0
>>> Man 1d4144 Snr d3602657
>>> SD
>>> 0.2
>>> boot0 capacity: 0KB,boot1 capacity: 0KB
>>> boot0 magic = eGON.BT0蜡讕
>>> set next system status
>>> DRV_DISP_Exit: closed
>>> sunxi_board_close_source
>>> NAND_UbootExit
>>> NB1 : NAND_LogicExit
>>> reset cpu
>>> HELLO! BOOT0 is starting!
>>> boot0 version : 3.0.0
>>> reg_addr 0x01f00100 =0x00007347
>>> reg_addr 0x01f00104 =0x0000703b
>>> reg_addr 0x01f00108 =0x5aa5a55a
>>> reg_addr 0x01f0010c =0x000000ff
>>> reg_addr 0x01f00110 =0x000000ff
>>> reg_addr 0x01f00114 =0x000000ff
>>> eraly jump fel
>>>
>>> U-Boot SPL 2016.03-00320-geeea041 (Mar 21 2016 - 15:16:34)
>>> DRAM: 1024 MiB
>>> Trying to boot from MMC1
>>>
>>>
>>> and hangs...
>>>
>>> geeea041 is the SinA31s patch I have on top of your sunxi-wip branch.
>>>
>>> I bisected it down to 107fb76 ("sunxi: Fix gmac not working due to
>>> cpu_eth_init no longer being called"). Not sure why this commit fails
>>> though.
>>
>>
>> Hmm, can you try commenting out these 2 lines in
>> arch/arm/cpu/armv7/sunxi/board.c :
>>
>> #ifdef CONFIG_MACPWR
>>          gpio_request(CONFIG_MACPWR, "macpwr");
>>          gpio_direction_output(CONFIG_MACPWR, 1);
>> #endif
>>
>> Around line 103 ? That is the only bit which has changed in
>> the SPL path due to this patch.
>
> This fixes the problem. Thanks.
>
> I'm guessing it's a bad idea to call the generic GPIO
> functions, which are DM based, in SPL?

When building the SPL CONFIG_DM_GPIO is not set, and there
are non DM implementations for the SPL in drivers/gpio/sunxi_gpio.c

So the functions should work, and the fact that you get to

"Trying to boot from MMC1"

Shows that at least the SPL does not crash at this code, because
that is done way earlier (before the first message is printed
on the serial console, the same function also sets up the uart
muxing).

So I do not believe that the problem is actually calling the
gpio_request() (nop in non DM mode) nor gpio_direction_output()
in general.

Which would lead to the conclusion that the problem is the
changing of the gpio pin value before u-boot proper has loaded,
which is a bit weird.

Note that commenting out these lines will likely lead to a non
working ethernet on the board. If it does not then you do not
need CONFIG_MACPWR and it could be that you're driving some
$random pin high causing issues.

If the commenting out does lead to a non working ethernet
we could try to fix things by changing the #ifdef to:

#if !defined CONFIG_SPL_BUILD && defined CONFIG_MACPWR

Which would cause us to only turn on the gpio when initializing
gpio-s in u-boot proper and not in the SPL.

Regards,

Hans