All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Roese <sr@denx.de>
To: u-boot@lists.denx.de
Subject: How to debug HW startup?
Date: Mon, 13 Jan 2020 12:39:47 +0100	[thread overview]
Message-ID: <7b3ca5c2-f84d-a4b1-ce60-591939e3cd01@denx.de> (raw)
In-Reply-To: <d04fd790-0135-fc18-7489-1a0157c193cc@mclink.it>

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

  reply	other threads:[~2020-01-13 11:39 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-09 17:28 How to debug HW startup? Mauro Condarelli
2020-01-10  6:31 ` Stefan Roese
2020-01-10  9:06   ` Mauro Condarelli
2020-01-10 13:33     ` Stefan Roese
2020-01-11 19:00       ` Mauro Condarelli
2020-01-11 20:42         ` Sean Anderson
2020-01-11 21:38           ` Mauro Condarelli
2020-01-11 23:58             ` Sean Anderson
2020-01-12  0:22               ` Mauro Condarelli
2020-01-13  6:53         ` Stefan Roese
2020-01-13 10:24           ` Mauro Condarelli
2020-01-13 11:39             ` Stefan Roese [this message]
2020-01-13 12:24               ` Mauro Condarelli
2020-01-13 12:45                 ` Stefan Roese
2020-01-13 14:14                   ` Mauro Condarelli
2020-01-13 23:08                     ` Mauro Condarelli
2020-01-14 11:03                       ` Mauro Condarelli
2020-01-14 23:55                       ` Debugging VoCore2 ROM Startup (was: How to debug HW startup?) Mauro Condarelli
2020-01-15  7:25                         ` Debugging VoCore2 ROM Startup Stefan Roese
2020-01-15  9:04                           ` Mauro Condarelli
2020-01-15  9:31                             ` Stefan Roese
2020-01-15  9:51                               ` Stefan Roese
2020-01-15 10:23                               ` Mauro Condarelli
2020-01-15 10:48                                 ` Stefan Roese
2020-01-15 12:50                                   ` Mauro Condarelli
2020-01-15 15:04                                     ` Stefan Roese
2020-01-15 15:55                                       ` Mauro Condarelli
2020-01-15 16:20                                         ` Stefan Roese
2020-01-15 17:25                                           ` Mauro Condarelli
2020-01-16  6:33                                             ` Stefan Roese

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7b3ca5c2-f84d-a4b1-ce60-591939e3cd01@denx.de \
    --to=sr@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.