How to debug HW startup?

Stefan Roese sr at denx.de
Mon Jan 13 12:39:47 CET 2020


Hi Mauro,

On 13.01.20 11:24, Mauro Condarelli wrote:
> On 1/13/20 7:53 AM, Stefan Roese wrote:
>> Hi Mauro,
>>
>> On 11.01.20 20:00, Mauro Condarelli wrote:
>>> I managed to find ONE of the reasons why my ROM build didn't run:
>>> I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`.
>>
>> I see. This explains of course, why your board does not boot without
>> any "preloader".
>>
>>> I wanted, nonetheless, be prepared for further mishaps, but
>>> I have some other problems (see below).
>>
>> Are these issues now fixed? I scanned the discussion about the DEBUG
>> UART on the list. Is this working for you now or do you have any other
>> issues still? Did you successfully boot your new U-Boot from SPI NOR?
> Yes and no :(
> 
> I fixed my RAM-based problems, but booting from SPI NOR still refuses to
> utter a single byte.
> I do attach  my defconfigs and my board.c for your reading pleasure (in
> case you have troubles getting asleep they should provide a good cure).

Before looking into this in more depth (I actually do have problems sleeping
though, so I might take a look at it later ;)), why don't you re-start with
your defconfig by using the linkit defconfig file. If you are lucky, the
LinkIt binary might even work for the VoCore2. Or what are the differences
except the SoC type and WLAN? Its the same DDR2 config and the same UART.
So it might get you pretty far - also with ROM based booting.
  
> I also added a couple of printouts in drivers/pinctrl/pinctrl-uclass.c
> and it
> turns out system tries to setup pins for uart2, but fails (maybe because
> pinctrl at 60 is not yet setup correctly?).
> This is the output I get from RAM-based u-boot:
> 
> <debug_uart> board_debug_uart_init():
> board_early_init_f():
> pinctrl_select_state_full('palmbus at 10000000', 'default'):
> pinctrl_select_state_full('uart2 at e00', 'default'):
> pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
> pinctrl_select_state_full('clkctrl at 0x2c', 'default'):
> 
> U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 01:03:59 +0100)
> 
> CPU:   MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
> Model: VoCore2
> DRAM:  128 MiB
> pinctrl_select_state_full('palmbus at 10000000', 'default'):
> pinctrl_select_state_full('pinctrl at 60', 'default'):
> pinctrl_select_state_full('pin_state', 'default'):
> pinctrl_select_state_full('uart2 at e00', 'default'):
> pinctrl_select_state_full('uart2_pins', 'default'):
> pinctrl_select_state_full('clkctrl at 0x2c', 'default'):
> pinctrl_select_state_full('watchdog at 100', 'default'):
> WDT:   Started with servicing (60s timeout)
> board_early_init_r():
> arch_early_init_r():
> MMC:   pinctrl_select_state_full('mmc at 10130000', 'default'):
> pinctrl_select_state_full('sd_iot_mode', 'default'):
> pinctrl_select_state_full('clk48m at 0', 'default'):
> pinctrl_select_state_full('mmc at 10130000', 'default'):
> mmc at 10130000: 0
> Loading Environment from FAT... *** Warning - bad CRC, using default
> environment
> 
> In:    uart2 at e00
> Out:   uart2 at e00
> Err:   uart2 at e00
> Model: VoCore2
> arch_misc_init():
> =>

I don't have all these pinctrl issues on LinkIt. I suspect a config
issue and / or dts issue. Please compare.

> 
> ROM-based u-boot, as said, does not print *anything*, not even garbage.
> I'm beginning to suspect I have some mishap with start address or similar.
> I have absolutely no idea how to debug this without a JTAG probe (which
> I don't have and would be non-trivial to get working; soldering required).

Yes. JTAG requires soldering IIRC.
  
> The only idea I currently have is to modify my "old" u-boot to do
> initialization
> and then jump to beginning of "new" u-boot.
> If I can make it work in an automatic way I can try removing
> initialization steps
> till I find the "culprit".
> Any better idea would be welcome, of course!
> 
> If I have to resort to that clumsy method, would be enough to put  "new"
> in  SPI NOR (of course at an higher address, e.g.: 30000 as "old" is only
> 183272 bytes long) and jump to the first location?
> I assume I will have to relocate CONFIG_SYS_TEXT_BASE=0xbc030000

This is the TEXT_BASE for ROM based booting:

CONFIG_SYS_TEXT_BASE=0x9c000000

Please see configs/linkit-smart-7688_defconfig.

> Did I forget something?

Not sure. I still think using the linkit port as a base for SPI NOR
based booting would be a very good test at least. Do you see any
problems with this approach (board / SoC differences)?

Thanks,
Stefan


More information about the U-Boot mailing list