[U-Boot] [linux-sunxi] Re: Latest U-boot branch not booting on Hummingbird A31
Chen-Yu Tsai
wens at csie.org
Mon Mar 21 11:25:59 CET 2016
Hi,
On Mon, Mar 21, 2016 at 6:18 PM, Hans de Goede <hdegoede at redhat.com> wrote:
> 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.
Ethernet works with these 2 lines commented. The schematics show
an external pull-up on the PHY reset pin, so this GPIO is only
used to reset the PHY by driving it low. Driving it high shouldn't
cause any issues.
I'll send a patch removing CONFIG_MACPWR for this board.
Thanks
ChenYu
> 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
>
More information about the U-Boot
mailing list