All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jagan Teki <jagannadh.teki@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] rk3288: broken boot
Date: Wed, 14 Feb 2018 16:17:24 +0530	[thread overview]
Message-ID: <CAD6G_RREdWC40hxqA5uD00eWrnZm4Zrkp6vEHYFCVN2jdSuv-w@mail.gmail.com> (raw)
In-Reply-To: <6F29BF54-F25E-4CF4-8EB2-36AAE096FA4B@theobroma-systems.com>

On Wed, Feb 14, 2018 at 5:38 AM, Dr. Philipp Tomsich
<philipp.tomsich@theobroma-systems.com> wrote:
> Jagan,
>
>> On 13 Feb 2018, at 13:20, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>
>> On Tue, Feb 13, 2018 at 5:29 PM, Dr. Philipp Tomsich
>> <philipp.tomsich@theobroma-systems.com> wrote:
>>> I verified the build for evb-rk3288_defconfig and everything looks fine:
>>>
>>> spl/u-boot-spl.bin:     file format binary
>>>
>>>
>>> Disassembly of section .data:
>>>
>>> 00000000 <.data>:
>>>       0:       eaffffff        b       0x4     <— this is the extra branch inserted (to be overwritten by mkimage)
>>>       4:       ea000016        b       0x64
>>
>> I saw this on SPL, but I'm using TPL where I'm using mkimage to tp binary
>>
>>>        ...
>>>      20:       ea00000f        b       0x64
>>>      24:       e59ff014        ldr     pc, [pc, #20]   ; 0x40
>>>      28:       e59ff014        ldr     pc, [pc, #20]   ; 0x44
>>>      2c:       e59ff014        ldr     pc, [pc, #20]   ; 0x48
>>>      30:       e59ff014        ldr     pc, [pc, #20]   ; 0x4c
>>>      34:       e59ff014        ldr     pc, [pc, #20]   ; 0x50
>>>      38:       e59ff014        ldr     pc, [pc, #20]   ; 0x54
>>>      3c:       e59ff014        ldr     pc, [pc, #20]   ; 0x58
>>
>> I can see the difference of size by 8 bytes with spl/u-boot-spl-dtb.bin
>>
>> with tparams->header_size = RK_SPL_HDR_START + 4; (working scenario)
>> $ ls -l spl/u-boot-spl-dtb.bin
>> -rw-r--r-- 1 root root 37571
>>
>> normal build have
>> $ ls -l spl/u-boot-spl-dtb.bin
>> -rw-r--r-- 1 root root 37563
>
> In order to find the issue, I’d recommend to look at both the ELF file
> and the binary for your TPL stage. Disassembling the binary will show
> whether the extra branch is indeed added as the first instruction and
> if the second instruction is a branch to the reset entry-point.

This is what I found with mkimage tpl, the extra 0xeaffffff branch
inserted start with 0x820 in case of working, but branch insertion did
4 bytes prior to 0x820 [1]

https://paste.ubuntu.com/p/BbZrvJhqJD/

  reply	other threads:[~2018-02-14 10:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-15  7:08 [U-Boot] rk3288: broken boot Jagan Teki
2017-12-15  9:00 ` Dr. Philipp Tomsich
2017-12-15  9:15 ` Kever Yang
2018-02-13 10:46   ` Jagan Teki
2018-02-13 11:15     ` Dr. Philipp Tomsich
2018-02-13 11:59       ` Dr. Philipp Tomsich
2018-02-13 12:20         ` Jagan Teki
2018-02-14  0:08           ` Dr. Philipp Tomsich
2018-02-14 10:47             ` Jagan Teki [this message]
2018-02-14 11:02               ` Dr. Philipp Tomsich

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=CAD6G_RREdWC40hxqA5uD00eWrnZm4Zrkp6vEHYFCVN2jdSuv-w@mail.gmail.com \
    --to=jagannadh.teki@gmail.com \
    --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.