How to debug HW startup?

[Mauro Condarelli]

On 1/13/20 12:39 PM, Stefan Roese wrote:
> 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 will try it.
Just to be on the safe side, could You attach a binary (or two: ROM and
RAM) to
the mail? If it works it would really give me a start base.
 
>> 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.
I will, but I was trying to say something different:
Apparently the stock software tries to initialize uart2 pinctrl and it
*seems* to succeed later in initialization.
This *seems* to indicate explicit pin setup in board_early_init_f() is
not strictly needed (we would lose only the first few lines even if
we don't fix the error).
I had a look to pinctrl-mt7628.c and it seems to do the right thing
upon call to ('uart2_pins', 'default'), so anything after that *should*
work even without low-level setup.

>>
>> 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
AFAIK 0x9c000000 and 0xbc000000 map to the same (unmapped) memory
region, the latter being uncached.
I proposed 0xbc030000 (but it could be 0x9c030000) as base to leave some
space for "old" (possibly crippled) u-boot doing initialization and then
"jumping"
to "new".

> 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)?
No. I see no troubles, for a basic startup.
MMC would probably need some changes, but that can come later.
As said: I would like to try a prebuilt binary as first thing, so I can
be sure I have no other problems (like gcc version or other local
variations); then I would try to reproduce locally the equivalent binary
with no changes and finally I would try to incorporate my specific
needs.
What do You think?

> Thanks,
> Stefan
Best regards and TiA!
Mauro