Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > uk.comp.os.linux > #21022
| From | Java Jive <java@evij.com.invalid> |
|---|---|
| Newsgroups | uk.comp.os.linux, alt.os.linux |
| Subject | Re: UBoot - Ch 4 |
| Date | 2017-09-27 18:02 +0100 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <5amnsc5ht1mealpgck2siujo5v8dsotim0@4ax.com> (permalink) |
| References | <nsiptj$snd$1@gioia.aioe.org> <ltu2rc9mfihivlir6p72vengac9nqefvq4@4ax.com> |
Cross-posted to 2 groups.
On 17 Sep 2017 02:15:01 +0100 (BST), Theo
<theom+news@chiark.greenend.org.uk> wrote:
> This is interesting. It suggests we're not managing to run the
> decompression code. If the kernel was correctly compressed, but broken in
> another way, we'd get 'Uncompressing Linux...' and then no further.
> That we don't suggests we aren't correctly executing even the decompressor.
>
> Do you have a working kernel image as a file? Are you able to disassemble
> and compare with the one you built?
>
> There's some useful pointers here (for OMAP processors)
> http://processors.wiki.ti.com/index.php/Kernel_-_Common_Problems_Booting_Linux
>
> - the one about having the incorrect low level UART is relevant.
> Unlike a PC, there's no BIOS to use as a terminal so the first thing the
> kernel has to do is bring up the low level UART.
Having been distracted for a few days by the need to rebuild the PC,
I've now restarted investigating this. By an empirical process of
reverting back closer and closer to the Zyxel-supplied method of
building the kernel until it worked, and then trying to move forwards
again from there, I've now come to the conclusion that yet again you
are right, Theo.
Basically, when I try building from the Zyxel-supplied 2.6.24.4 kernel
source files, it works, regardless of whether I use their binaries as
supplied, or mine as built by my cross-build process, but if I use a
'vanilla' kernel source downloaded from the web, even one of the same
generation, it falls at the first hurdle as previously described.
Accordingly I ran WinDiff - a graphical difference finder programme
- from a Windows machine on the two Linux source trees in the build
share, and immediately noticed that in the Zyxel-supplied source there
is an OxNAS section which is completely absent from the 'vanilla'
downloaded source. (Zyxel NASs are built around an Oxford
Semiconductor, as was, NAS SoC board.)
I think, as suggested by you above Theo, this exactly explains the
symptoms seen, kernels built from 'vanilla' sources immediately fail
because they can't find the OxNAS board's UART to output boot log
messages to.
So, back on the Linux build PC now, I searched for all files in the
Zyxel source containing the string oxnas and ran a diff command for
every file found against its counterpart in the 'vanilla' source. A
sample of the output is appended below.
My question now is, how do I apply these known differences to patch
the 'vanilla' kernel?
For anyone who's interested here's the difference command given and
the resulting output:
#> for F in $(grep -irls oxnas TestBuild/trunk/linux-2.6.24.4/); do if
[ "${F%\~}" == "${F}" ]; then echo diff -rBbEZ ${F}
cross/src/linux-2.6.24/${F#TestBuild/trunk/linux-2.6.24.4/} >>
oxnas.diff 2>&1; diff -rBbEZ ${F}
cross/src/linux-2.6.24/${F#TestBuild/trunk/linux-2.6.24.4/} >>
oxnas.diff 2>&1; fi; done
diff -rBbEZ TestBuild/trunk/linux-2.6.24.4/kernel.config_NSA221
cross/src/linux-2.6.24/kernel.config_NSA221
diff: cross/src/linux-2.6.24/kernel.config_NSA221: No such file or
directory
diff -rBbEZ TestBuild/trunk/linux-2.6.24.4/include/asm-arm/assembler.h
cross/src/linux-2.6.24/include/asm-arm/assembler.h
51,52d50
< * OXNAS altered to >= 6 from >= 5 as 926 supports pld, but
implements it as
< * nop, so wastes instruction cycles to include pld support
54c52
< #if __LINUX_ARM_ARCH__ >= 6
---
> #if __LINUX_ARM_ARCH__ >= 5
diff -rBbEZ TestBuild/trunk/linux-2.6.24.4/include/asm-arm/uaccess.h
cross/src/linux-2.6.24/include/asm-arm/uaccess.h
386,408d385
< #ifdef CONFIG_OXNAS_INSTRUMENT_COPIES
< extern unsigned long __must_check __copy_from_user_alt(void *to,
const void __user *from, unsigned long n);
< static inline unsigned long __must_check __copy_from_user(void *to,
const void __user *from, unsigned long n)
< {
< // ymtseng.20090213: Remove noisy messages.
< // if (n >= CONFIG_OXNAS_INSTRUMENT_COPIES_THRESHOLD)
printk("__copy_from_user() %lu bytes\n", n);
< return __copy_from_user_alt(to, from , n);
< }
< extern unsigned long __must_check __copy_to_user_alt(void __user
*to, const void *from, unsigned long n);
< static inline unsigned long __must_check __copy_to_user(void __user
*to, const void *from, unsigned long n)
< {
< // ymtseng.20090213: Remove noisy messages.
< // if (n >= CONFIG_OXNAS_INSTRUMENT_COPIES_THRESHOLD)
printk("__copy_to_user() %lu bytes\n", n);
< return __copy_to_user_alt(to, from , n);
< }
< extern unsigned long __must_check __clear_user_alt(void __user
*addr, unsigned long n);
< static inline unsigned long __must_check __clear_user(void __user
*addr, unsigned long n)
< {
< // ymtseng.20090213: Remove noisy messages.
< // if (n >= CONFIG_OXNAS_INSTRUMENT_COPIES_THRESHOLD)
printk("__clear_user() %lu bytes\n", n);
< return __clear_user_alt(addr, n);
< }
< #else // CONFIG_OXNAS_INSTRUMENT_COPIES
412d388
< #endif // CONFIG_OXNAS_INSTRUMENT_COPIES
424,427d399
< #ifdef CONFIG_OXNAS_INSTRUMENT_COPIES
< // ymtseng.20090213: Remove noisy messages.
< // if (n >= CONFIG_OXNAS_INSTRUMENT_COPIES_THRESHOLD)
printk("copy_from_user() %lu bytes\n", n);
< #endif // CONFIG_OXNAS_INSTRUMENT_COPIES
429,431d400
< #ifdef CONFIG_OXNAS_INSTRUMENT_COPIES
< n = __copy_from_user_alt(to, from, n);
< #else // CONFIG_OXNAS_INSTRUMENT_COPIES
433d401
< #endif // CONFIG_OXNAS_INSTRUMENT_COPIES
441,444d408
< #ifdef CONFIG_OXNAS_INSTRUMENT_COPIES
< // ymtseng.20090213: Remove noisy messages.
< // if (n >= CONFIG_OXNAS_INSTRUMENT_COPIES_THRESHOLD)
printk("copy_to_user() %lu bytes\n", n);
< #endif // CONFIG_OXNAS_INSTRUMENT_COPIES
446,448d409
< #ifdef CONFIG_OXNAS_INSTRUMENT_COPIES
< n = __copy_to_user_alt(to, from, n);
< #else // CONFIG_OXNAS_INSTRUMENT_COPIES
450d410
< #endif // CONFIG_OXNAS_INSTRUMENT_COPIES
459,462d418
< #ifdef CONFIG_OXNAS_INSTRUMENT_COPIES
< // ymtseng.20090213: Remove noisy messages.
< // if (n >= CONFIG_OXNAS_INSTRUMENT_COPIES_THRESHOLD)
printk("clear_user() %lu bytes\n", n);
< #endif // CONFIG_OXNAS_INSTRUMENT_COPIES
464,466d419
< #ifdef CONFIG_OXNAS_INSTRUMENT_COPIES
< n = __clear_user_alt(to, n);
< #else // CONFIG_OXNAS_INSTRUMENT_COPIES
468d420
< #endif // CONFIG_OXNAS_INSTRUMENT_COPIES
[etc]
--
========================================================
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html
Back to uk.comp.os.linux | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Endless problems trying to compile for/on embedded devices - Ch 2 Java Jive <java@evij.com.invalid> - 2016-09-29 10:20 +0000
Re: Endless problems trying to compile for/on embedded devices - Ch 2 Nick Leverton <nick@leverton.org> - 2016-10-19 12:23 +0000
UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3" Java Jive <java@evij.com.invalid> - 2017-09-07 18:29 +0100
Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3" Theo <theom+news@chiark.greenend.org.uk> - 2017-09-07 20:43 +0100
Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3" Java Jive <java@evij.com.invalid> - 2017-09-07 21:48 +0100
Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3" Java Jive <java@evij.com.invalid> - 2017-09-07 22:11 +0100
Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3" Theo <theom+news@chiark.greenend.org.uk> - 2017-09-07 23:04 +0100
Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3" Java Jive <java@evij.com.invalid> - 2017-09-15 18:06 +0100
Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3" Theo <theom+news@chiark.greenend.org.uk> - 2017-09-16 16:14 +0100
Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3" Java Jive <java@evij.com.invalid> - 2017-09-16 16:39 +0100
Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3" Java Jive <java@evij.com.invalid> - 2017-09-16 18:09 +0100
Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3" Theo <theom+news@chiark.greenend.org.uk> - 2017-09-17 02:15 +0100
Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3" Java Jive <java@evij.com.invalid> - 2017-09-17 17:02 +0100
Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3" Java Jive <java@evij.com.invalid> - 2017-09-17 20:45 +0100
Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3" Java Jive <java@evij.com.invalid> - 2017-09-17 20:53 +0100
Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3" Theo <theom+news@chiark.greenend.org.uk> - 2017-09-17 21:10 +0100
Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3" Java Jive <java@evij.com.invalid> - 2017-09-17 22:28 +0100
Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3" Java Jive <java@evij.com.invalid> - 2017-09-16 16:23 +0100
Re: UBoot - Ch 4 Java Jive <java@evij.com.invalid> - 2017-09-27 18:02 +0100
Re: UBoot - Ch 4 Andy Burns <usenet@andyburns.uk> - 2017-09-27 19:16 +0100
Re: UBoot - Ch 4 Java Jive <java@evij.com.invalid> - 2017-09-28 22:17 +0100
Re: UBoot - Ch 4 Theo <theom+news@chiark.greenend.org.uk> - 2017-09-29 00:42 +0100
Re: UBoot - Ch 4 Java Jive <java@evij.com.invalid> - 2017-09-30 19:53 +0100
csiph-web