From: Alexander Clouter <alex@digriz.org.uk>
To: Wu Zhangjin <wuzhangjin@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [PATCH v1] MIPS: fix vmlinuz build when only 32bit math shell is available
Date: Tue, 19 Jan 2010 09:55:57 +0000 [thread overview]
Message-ID: <20100119095556.GF32413@chipmunk> (raw)
In-Reply-To: <42fa29d2007a40a31a0bb8fbf1091e11eb9b5ac2.1263893871.git.wuzhangjin@gmail.com>
Hi,
* Wu Zhangjin <wuzhangjin@gmail.com> [2010-01-19 17:43:09+0800]:
>
> Does this revision work for you?
>
> Changes from v0:
>
> - Revert the '-n "$(VMLINUX_SIZE)"' to avoid the error of "make clean"
> - Consider more situations of the VMLINUX_LOAD_ADDRESS
>
> [snipped]
>
> So, we can split the original 64bit string to two parts, and only
> calculate the low 32bit part, which is big enough(about 4095 M) for a
> normal linux kernel image file, now, we calculate the
> VMLINUZ_LOAD_ADDRESS like this:
>
As a passing query, why do we have the high 32bit (0xffffffff....) spiel
if later we can just make VMLINU[XZ]_LOAD_ADDRESS the low half? I see
the output of 'nm' shows:
----
alex@berk:/usr/src/wag54g/linux$ nm vmlinux | head -n1
941019e4 t .ex0
alex@berk:/usr/src/wag54g/linux$ nm vmlinuz | head -n1
944abb50 B .heap
----
However I am guessing it's some 64bit CPU requirement as my x86_64
kernel seems to have 0xffffffff.... Which raises the question, why is
AR7 not just using VMLINUX_LOAD_ADDRESS=0x94100000?
> 1. Append "the high 32bit of VMLINUX_LOAD_ADDRESS" as the prefix if it
> exists.
>
> 2. Get the sum of "the low 32bit of VMLINUX_LOAD_ADDRESS + VMLINUX_SIZE"
> with printf "%08x" (08 herein is used to prefix the result with 0...)
>
> The corresponding shell script is:
>
> A=$VMLINUX_LOAD_ADDRESS;
> # Append "the high 32bit of VMLINUX_LOAD_ADDRESS" as the prefix if it exists.
> [ "${A:0:10}" != "${A}" ] && echo -n ${A:2:8};
> # Get the sum of "the low 32bit of VMLINUX_LOAD_ADDRESS + VMLINUX_SIZE"
> printf "%08x" $(($VMLINUX_SIZE + 0x${A:(-8)}))
>
Eugh, bash-ism's...
----
alex@berk:/usr/src/wag54g/linux$ bash -c 'A=1234567890; echo ${A:0:5}'
12345
alex@berk:/usr/src/wag54g/linux$ dash -c 'A=1234567890; echo ${A:0:5}'
dash: Bad substitution
----
Your 'punishment', use Plan9 for a period of no less than a week! :)
You have to use the pattern matching approach I used in my original
patch, that's portable. Look at 'man 1 dash' and search for 'substr'
for more details.
Cheers
--
Alexander Clouter
.sigmonster says: I'm not prejudiced, I hate everyone equally.
next prev parent reply other threads:[~2010-01-19 9:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-19 9:43 [PATCH v1] MIPS: fix vmlinuz build when only 32bit math shell is available Wu Zhangjin
2010-01-19 9:43 ` Wu Zhangjin
2010-01-19 9:55 ` Alexander Clouter [this message]
2010-01-19 10:27 ` Wu Zhangjin
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=20100119095556.GF32413@chipmunk \
--to=alex@digriz.org.uk \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=wuzhangjin@gmail.com \
/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.