Hi, On Mon, Mar 21, 2016 at 6:18 PM, Hans de Goede <hdego...@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 <hdego...@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 > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.