From: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
To: Jonas Gorski <jogo@openwrt.org>
Cc: linux-mips@linux-mips.org, hauke@hauke-m.de, openwrt@kresin.me,
antonynpavlov@gmail.com
Subject: Re: [PATCH v2] Re: Adding support for device tree and command line
Date: Sun, 29 May 2016 14:19:26 -0700 [thread overview]
Message-ID: <1464556766.5020.42.camel@chimera> (raw)
In-Reply-To: <c481d3b1-bee1-89c9-bbb8-ef17d91570bf@openwrt.org>
On Sun, 2016-05-29 at 12:53 +0200, Jonas Gorski wrote:
> Maybe a better solution here would be to create a new symbol
> fw_passed_dtb and let the code store a1 in there if a0 is -2, or
> __appended_dtb in case it is valid? Then we wouldn't need to special
> case APPENDED_DTB for any mach wanting to use it, and they can just
> check fw_passed_dtb.
>
> something like:
>
> arch/mips/kernel/head.S:
> ...
>
> #ifdef CONFIG_USE_OF
> li t1, -2
> beq a0, t1, dtb_found
> move t0, a0
>
> #ifdef CONFIG_MIPS_RAW_APPENDED_DTB
> PTR_LA t0, __appended_dtb
>
> #ifdef CONFIG_CPU_BIG_ENDIAN
> li t1, 0xd00dfeed
> #else
> li t1, 0xedfe0dd0
> #endif
> lw t2, (t0)
> bne t1, t2, no_dtb_found
> nop
>
> #endif
> no_dtb_found:
> li t0, 0
> dtb_found:
> LONG_S t0, fw_passed_dtb
> #endif
That prefers the wrong DTB in case both are present. I propose this
instead:
#ifdef CONFIG_USE_OF
#ifdef CONFIG_MIPS_RAW_APPENDED_DTB
PTR_LA t0, __appended_dtb
#ifdef CONFIG_CPU_BIG_ENDIAN
li t1, 0xd00dfeed
#else
li t1, 0xedfe0dd0
#endif
lw t2, (t0)
beq t1, t2, dtb_found
nop
#endif
li t1, -2
beq a0, t1, dtb_found
move t0, a1
no_dtb_found:
li t0, 0
dtb_found:
LONG_S t0, fw_passed_dtb
#endif
next prev parent reply other threads:[~2016-05-29 21:19 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-23 21:14 Adding support for device tree and command line Hauke Mehrtens
2016-05-23 21:34 ` Hauke Mehrtens
2016-05-23 22:12 ` Daniel Gimpelevich
2016-05-24 5:32 ` [RFC PATCH] " Daniel Gimpelevich
2016-05-24 11:27 ` Antony Pavlov
2016-05-24 15:15 ` Daniel Gimpelevich
2016-05-24 15:27 ` Daniel Gimpelevich
2016-05-24 16:48 ` Antony Pavlov
2016-05-24 17:00 ` Daniel Gimpelevich
2016-05-25 3:31 ` Antony Pavlov
2016-05-25 3:33 ` Daniel Gimpelevich
2016-05-27 21:06 ` [PATCH v2] " Daniel Gimpelevich
2016-05-28 10:31 ` Antony Pavlov
2016-05-28 19:05 ` Daniel Gimpelevich
2016-05-29 1:23 ` Daniel Gimpelevich
2016-05-30 17:24 ` Antony Pavlov
2016-05-29 10:53 ` Jonas Gorski
2016-05-29 18:38 ` Daniel Gimpelevich
2016-05-29 19:01 ` Jonas Gorski
2016-05-29 19:08 ` Daniel Gimpelevich
2016-05-29 19:22 ` Jonas Gorski
2016-05-29 19:26 ` Daniel Gimpelevich
2016-05-29 19:30 ` Jonas Gorski
2016-05-29 21:19 ` Daniel Gimpelevich [this message]
2016-05-26 16:25 ` [RFC PATCH] " Hauke Mehrtens
2016-05-26 17:24 ` Daniel Gimpelevich
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=1464556766.5020.42.camel@chimera \
--to=daniel@gimpelevich.san-francisco.ca.us \
--cc=antonynpavlov@gmail.com \
--cc=hauke@hauke-m.de \
--cc=jogo@openwrt.org \
--cc=linux-mips@linux-mips.org \
--cc=openwrt@kresin.me \
/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