linux-tegra.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH] ARM: uncompress: Enable debug in head.S
Date: Wed, 4 Nov 2020 23:40:05 +0300	[thread overview]
Message-ID: <6877bfc9-3099-226a-7f9c-9f1c488e0872@gmail.com> (raw)
In-Reply-To: <CACRpkdZnZ0fxU=7_RLMEivvFProa5r9VPpPiHHR_45zzk3_kCA@mail.gmail.com>

29.09.2020 16:48, Linus Walleij пишет:
> On Wed, Sep 23, 2020 at 12:13 AM Dmitry Osipenko <digetx@gmail.com> wrote:
> 
>> I have CONFIG_DEBUG_UNCOMPRESS=y and was trying today's linux-next which
>> unfortunately doesn't work well on NVIDIA Tegra30 because it's
>> frequently failing to boot, hanging early during boot, about 1 of 5
>> boots are failing. Then I also noticed that Tegra20 has a similar
>> problem, but worse, only 1 of 10 boots succeed.
> 
> Hm let's try to fix that.
> 
> So you got the "Uncompressing Linux..." message before and all
> worked fine? So we know the physical UART base is correct.
> 
>> I loaded Tegra2 QEMU and got it also hanging on boot. I retried multiple
>> times and most of the times it's was a silent CPU hang, but one time I
>> got an endlessly reoccurring debug message from QEMU telling that CPU
>> tries to write to a wrong/non-existent IO address. Then I attached to
>> QEMU's GDB session and found that CPU hangs at the busyuart.
> 
> Could you try to implement
> waituarttxrdy in arch/arm/include/debug/tegra.S?
> A copy of the contents in busyuart should work.
> 
> I suspect this could be FIFO overflow making the hardware
> hang.
> 
> If this is trouble to you I can try to make a patch
> that you can test, just tell me.
> 
>> Reverting
>> this patch resolves the trouble for both QEMU and real HW.
>>
>> I also tried to revert only the "ARM: 9006/1: uncompress: Wait for ready
>> and busy in debug prints" patch and got this in QEMU:
>>
>> Starting kernel ...
>>
>> DTB:0x016F6A20 (0x00005DA6)
>> C:0x010000C0-0x016FC820->0x0125AF00-0x01957660
>> Uncompressing Linux...
> (...)
>> LZMA data is corrupt
>>
>>  -- System halted
> 
> Hmmmm is the physical and virtual address to the UART
> really correct?
> 
> Else it might write in some random memory.

Hello Linus,

Just want to let you know that the problem isn't fixed yet and I haven't
got around to work on yet too. Hopefully next week!

  reply	other threads:[~2020-11-04 20:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200901124736.155281-1-linus.walleij@linaro.org>
2020-09-22 22:13 ` [PATCH] ARM: uncompress: Enable debug in head.S Dmitry Osipenko
2020-09-29 13:48   ` Linus Walleij
2020-11-04 20:40     ` Dmitry Osipenko [this message]
2020-11-10 13:28       ` Linus Walleij

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=6877bfc9-3099-226a-7f9c-9f1c488e0872@gmail.com \
    --to=digetx@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).