HI,
On 21-03-16 11:25, Chen-Yu Tsai wrote:
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've figured out the cause of why CONFIG_MACPWR all of a sudden
makes the Hummingbird A31 not boot. My recent changes make any board
which has CONFIG_MACPWR set not boot.
Your hunch about using dm-gpio code from the SPL was close, but
the problem is actually not in the SPL but in the main u-boot,
in SPL we use non dm gpio code, but in main u-boot we do use
dm for gpio, and the place where I added the gpio calls for
CONFIG_MACPWR get called before dm is setup, that is why that
broke things.
I'll send a v2 of the patch causing these problems, with this fixed.
Regards,
Hans
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
