How to debug HW startup?

Mon Jan 13 13:45:18 CET 2020

On 13.01.20 13:24, Mauro Condarelli wrote:
> 
> 
> 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.

See below.

>>> 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.

You might be correct here. So this explicit pin-muxing for UART2 is
only needed when DEBUG UART is used. This makes the code a bit clearer
and smaller. Lets keep it on our list to remove this, once all this
is resolved.

>>>
>>> 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".

I see. Please give the LinkIt version a try first. This sounds easier
(if it works) and more promising for my taste.

>> 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.

Yes. This test is just for basic very low level bootup checking. If
this works, then you can use it as a basis to fine-tune your VoCore2
version from it by changing MMC etc support.

> 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?

Please find attached the current mainline versions for LinkIt, one
for RAM booting and one for ROM booting (in SPI NOR). I checked both
version and they work fine on my LinkIt 7688 board:

U-Boot 2020.01-00473-g88366b96ee (Jan 13 2020 - 13:37:15 +0100)

CPU:   MT7628 Rev 1.2 - Boot from XTAL (4-Byte SPI Addr)
Model: LinkIt-Smart-7688
DRAM:  128 MiB
Loading Environment from SPI Flash... SF: Detected mx25l25635e with page size 256 Bytes, erase size 64 KiB, total 32 MiB
OK
Net:   eth0: eth at 10110000
Hit any key to stop autoboot:  0
=>

Thanks,
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: u-boot.bin-rom
Type: application/octet-stream
Size: 455708 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200113/afa44818/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: u-boot.bin-ram
Type: application/octet-stream
Size: 453724 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200113/afa44818/attachment-0003.obj>