Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > uk.comp.os.linux > #20247 > unrolled thread

Endless problems trying to compile for/on embedded devices - Ch 2

Back to article view | Back to uk.comp.os.linux

Contents

  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

Page 1 of 2  [1] 2  Next page →

#20247 — Endless problems trying to compile for/on embedded devices - Ch 2

About a year ago, uk.comp.os.linux correspondents tried to help me with 
compiling GCC 4.9.3 on a Zyxel NSA221 NAS.  The characteristics of this 
device are:

   ~ # uname -a
   Linux NASY 2.6.24.4 #1 Mon Aug 5 15:20:10 CST 2013 armv5tejl GNU/Linux

   ~ # cat /proc/cpuinfo
   Processor       : ARM926EJ-S rev 5 (v5l)
   BogoMIPS        : 183.09
   Features        : swp half thumb fastmult edsp java
   CPU implementer : 0x41
   CPU architecture: 5TEJ
   CPU variant     : 0x0
   CPU part        : 0x926
   CPU revision    : 5
   Cache type      : write-back
   Cache clean     : cp15 c7 ops
   Cache lockdown  : format C
   Cache format    : Harvard
   I size          : 32768
   I assoc         : 4
   I line length   : 32
   I sets          : 256
   D size          : 32768
   D assoc         : 4
   D line length   : 32
   D sets          : 256
   Hardware        : Oxsemi NAS
   Revision        : 0000
   Serial          : 00000cb31aadab80

   GLibC	   : 2.8*
   libc-dev        : 2.5-5*

   ~ # /lib/libc.so.6
   GNU C Library stable release version 2.8, by Roland McGrath et al.
   Copyright (C) 2008 Free Software Foundation, Inc.
   This is free software; see the source for copying conditions.
   There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
   PARTICULAR PURPOSE.
   Compiled by GNU CC version 4.3.2.
   Compiled on a Linux >>2.6.32-28-generic-pae<< system on 2011-01-22.
   Available extensions:
        crypt add-on version 2.1 by Michael Glad and others
        Native POSIX Threads Library by Ulrich Drepper et al
        Support for some architectures added on, not maintained in
   glibc core.
        BIND-8.2.3-T5B

   Current GCC     : 4.2.3

* Note the disparity, as this an OEM embedded device, the device's own 
headers aren't present, and the 2.5-5 dev package is the only one 
available via the intsy package manager ipkg.  Also, /usr is under the 
control of the firmware, so user stuff has to go elsewhere, and, as ipkg 
uses /opt, I've been installing stuff there as well.


1)	  At the time, it was suggested that I try to build the correct 
headers and, coming back to the problem now, I'm now investigating this 
sort of approach.  I've been trying to follow this, but with GCC 4.9.3:

	https://how-to-build-for-arm.wikispaces.com/gcc-4_8_2

In the Kernel Headers section, given the above CPU info, and that there is 
no obviously applicable default configuration, can anyone suggest what to 
use as the third command:
	make ARCH=arm <what should I put here?>


2)	Although at the time I was never able to make progress beyond a 
certain point compiling GCC 4.9.3 on the NAS itself, I have now managed to 
do this apparently successfully.  The config command line given was 
(without the line breaks inserted here for clarity):

~/build/gcc-4-9-3-build # ./gcc-4-9-3/configure
	--enable-languages=c,c++,lto,objc
	--prefix=/opt
	--with-native-system-header-dir=/opt/include
	--with-local-prefix=/opt/share
	--with-gmp=/opt --with-isl=/opt --with-mpc=/opt --with-mpfr=/opt
	--disable-threads --disable-tls
	--without-fortran --without-java
	> Config.log 2>&1

However, now I'm having trouble building the tools to test it, notably 
autogen which depends on guile.  I've built and installed apparently 
successfully all the dependencies for guile ...

	gc-7.2
	libffi-3.2.1
	libiconv-1.14
	libtool-2.4.6
	libunistring-0.9.6

... and the following configure command for guile apparently runs 
successfully ...

export BDW_GC_CFLAGS='-I/opt/include';
	export BDW_GC_LIBS='-L/opt/lib';
	export LIBFFI_CFLAGS='-I/opt/include';
	export LIBFFI_LIBS='-L/opt/lib';
	./configure --prefix=/opt > Config.log 2>&1

... but make fails with ...

  CC       libguile_2.0_la-finalizers.lo
finalizers.c:167: error: static declaration of 'GC_set_finalizer_notifier' 
follows non-static declaration
/opt/include/gc/gc.h:177: error: previous declaration of 
'GC_set_finalizer_notifier' was here
make[3]: *** [libguile_2.0_la-finalizers.lo] Error 1
make[3]: Leaving directory `/root/build/guile-2.0.9/libguile'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/root/build/guile-2.0.9/libguile'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/build/guile-2.0.9'
make: *** [all] Error 2

While I understand the sort of thing that is causing the message, I don't 
really know how to approach fixing the problem.  Can anyone help?

TIA

-- 
Please reply to newsgroup

[toc] | [next] | [standalone]

#20302

In article <nsiptj$snd$1@gioia.aioe.org>,
Java Jive  <java@evij.com.invalid> wrote:
>   Linux NASY 2.6.24.4 #1 Mon Aug 5 15:20:10 CST 2013 armv5tejl GNU/Linux
>   GLibC          : 2.8*
>   libc-dev        : 2.5-5*
>   GNU C Library stable release version 2.8, by Roland McGrath et al.
>   Compiled by GNU CC version 4.3.2.
>   Compiled on a Linux >>2.6.32-28-generic-pae<< system on 2011-01-22.
>   Current GCC     : 4.2.3

Sorry for the long pause, been trying to think of something positive to say.
I missed the earlier thread, are you compiling on the target ?  It clearly
isn't running any coherently assembled bunch of software so you may have
an uphill struggle.  At this point I think I'd look if there's an open
NAS distro that supports the device.

Failing that, using a toolchain like Buildroot might let you configure
and cross-build packages which are compatible with your device's
idiosyncracies of filesystem and versioning.

Good luck though if you carry on :-)

Nick

-- 
"The Internet, a sort of ersatz counterfeit of real life"
	-- Janet Street-Porter, BBC2, 19th March 1996

[toc] | [prev] | [next] | [standalone]

#20912 — UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3"

On Thu, 29 Sep 2016 10:20:36 +0000 (UTC), Java Jive
<java@evij.com.invalid> wrote:

About a year ago, uk.comp.os.linux correspondents tried to help me
with compiling GCC 4.9.x on a Zyxel NSA221 NAS.  More recently, I
posted that I've acquired some build files under GPL Licence from
Zyxel.

Using these, I have succeeded in doing all the customisations that are
worthwhile in terms of time and effort, incorporating these into a
build, and have loaded this build successfully onto both my servers.
This has dealt with problems such as:
	:-(	Both querying DHCP with the same machine name
	:-(	Unwanted processes and cron jobs such as Dropbox running.
	... etc.

However, much of what was supplied under GPL Licence is monolithic  -
a collection of pre-built files comprising an initrd and file system,
pre-built Zyxel bespoke software to provide the web GUI, etc  -  and
although I could do more by hacking all this about, I don't consider
the improvements to be gained would be worth the effort involved.

So starting from scratch, apparently successfully I've built a
cross-compiler based on GCC 4.94, GLibC 2.20, and Linux 2.6.36, and
have vmLinux, zImage, and uImage images of the kernel , and the
rudiments of a file system built.  Now, somehow I have to combine
these with the monolithic file-system previously provided, replacing
older files as appropriate.

As an exploratory effort, I'm loading the new kernel uImage by TFTP,
just to see what happens when it encountered Zyxel's legacy
filesystem, but it appears I'm doing something wrong.  Console output
is appended, the offending bytes at 0x4800800C+ are 00 20 99 44.  Can
anyone explain:
	1	How a kernel boots from such an image?
	2	How to configure kernel build to produce correct file layout?

Note:  I used a Zyxel-supplied mkimage binary to convert zImage to
uImage.

1.00 U-Boot 1.1.2 (Apr 11 2010 - 20:23:49)

U-Boot code: 48D00000 -> 48D172F4  BSS: -> 48D1AFA4
RAM Configuration:
        Bank #0: 48000000 256 MB
SRAM Configuration:
        128KB at 0x58000000
Flash:  4 MB
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
$ setenv serverip 192.168.1.20
$ printenv
bootcmd=cp 0x411e0000 0x4a000000 0x25c000; bootm 0x41020000
bootdelay=2
baudrate=115200
autoload=n
netmask=255.255.255.0
bootfile="uImage"
MODEL_ID=DC01
PRODUCT_NAME=NSA-221
FEATURE_BIT=00
CONTRY_TYPE=FF
VENDOR_NAME=ZyXEL Communications Corp.
ethaddr=50:67:F0:93:49:90
ipaddr=192.168.1.233
stdin=serial
stdout=serial
stderr=serial
bootargs=console=ttyS0,115200n8 root=/dev/ram0 rw init=/sbin/init
initrd=0x4a000000,4M elevator=cfq
mtdparts=physmap-flash.0:128k(uboot),1792k(kernel),1664k(initrd),448k(etc),48k(empty),8k(env1),8k(env2)
mem=256M poweroutage=yes
serverip=192.168.1.20

Environment size: 582/8187 bytes
$ tftpboot 0x48008000 uImage
Wait GMAC to reset
Wait for PHY reset
PHY is Realtek RTL8211BGR
Wait for link to come up.............Link up
Wait for auto-negotiation to completeLink is 10M/100M
TFTP from server 192.168.1.20; our IP address is 192.168.1.233
Filename 'uImage'.
Load address: 0x48008000
Loading:
 #################################################################
 #################################################################
 #################################################################
 #################################################################
 #################################################################
 #################################################################
         ############################
done
Bytes transferred = 2136452 (209984 hex)
$ bootm 0x48008000
## Booting image at 48008000 ...
   Image Name:   Linux-2.6.39
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2136388 Bytes =  2 MB
   Load Address: 48008000
   Entry Point:  48008000
   Verifying Checksum ... OK
   XIP Kernel Image ... OK

Starting kernel ...

undefined instruction
pc : [<4800800c>]    lr : [<48d12998>]
sp : 48cdd184  ip : 00000001  fp : 48ce0258
r10: 00000000  r9 : 48008040  r8 : 48cddfdc
r7 : 00000000  r6 : 48d1afa0  r5 : 48cde136  r4 : 00000000
r3 : 48008000  r2 : 48000100  r1 : 00000480  r0 : e1a00000
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...
-- 
========================================================
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

[toc] | [prev] | [next] | [standalone]

#20914 — Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3"

In uk.comp.os.linux Java Jive <java@evij.com.invalid> wrote:
> As an exploratory effort, I'm loading the new kernel uImage by TFTP,
> just to see what happens when it encountered Zyxel's legacy
> filesystem, but it appears I'm doing something wrong.  Console output
> is appended, the offending bytes at 0x4800800C+ are 00 20 99 44.  Can
> anyone explain:
>         1       How a kernel boots from such an image?
>         2       How to configure kernel build to produce correct file layout?
> 

Where did you get the idea about 0x48008000 from?
So you know that the code there (your uImage) is ARM code?
The fault at 0x4800800C implies it gets 1 or 3 instructions in before
exploding, which suggests it isn't valid instructions it's executing.

The 0x8000 bit probably comes from:
http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html
which is rather old now, but then so is your kernel.

The 'instruction' at 0x4800800C is 0x00209944 = 2136388 decimal, which is
the size of your image in the uImage header[1] that uboot correctly prints.

I'm not a uboot expert but I think that means the entry point address is
wrong, and you're jumping into the image header not the instructions.  To
take a wild guess, I think you want to load the uImage at 0x48000000 and set
the entry point to 0x48008000.  ie pass '-a 0x48000000 -e 0x48008000' to
mkimage.

Theo

[1] http://www.isysop.com/unpacking-and-repacking-u-boot-uimage-files/

[toc] | [prev] | [next] | [standalone]

#20915 — Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3"

Thanks Theo ...

On 07 Sep 2017 20:43:01 +0100 (BST), Theo
<theom+news@chiark.greenend.org.uk> wrote:
>
> In uk.comp.os.linux Java Jive <java@evij.com.invalid> wrote:
> > As an exploratory effort, I'm loading the new kernel uImage by TFTP,
> > just to see what happens when it encountered Zyxel's legacy
> > filesystem, but it appears I'm doing something wrong.  Console output
> > is appended, the offending bytes at 0x4800800C+ are 00 20 99 44.  Can
> > anyone explain:
> >         1       How a kernel boots from such an image?
> >         2       How to configure kernel build to produce correct file layout?
> 
> Where did you get the idea about 0x48008000 from?

From the existing Zyxel images  -  they all load at 0x48008000 and run
from there.

> So you know that the code there (your uImage) is ARM code?

Sure hope so, because otherwise it would mean that my first apparently
successful attempt to build a cross compiler, after years of trying
and failing, has failed yet again.

> The fault at 0x4800800C implies it gets 1 or 3 instructions in before
> exploding, which suggests it isn't valid instructions it's executing.
> 
> The 0x8000 bit probably comes from:
> http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html
> which is rather old now, but then so is your kernel.
> 
> The 'instruction' at 0x4800800C is 0x00209944 = 2136388 decimal, which is
> the size of your image in the uImage header[1] that uboot correctly prints.

Ah!  Well spotted!
 
> I'm not a uboot expert but I think that means the entry point address is
> wrong, and you're jumping into the image header not the instructions.

Yes, there appears to be some sort of header of 0x40 bytes in length,
but that exists also in the original Zyxel image.  The most confusing
thing is that the original Zyxel image seems to load at 0x48008000,
and have a run address the same,  but actually is run via 0x41020000,
which isn't even part of the same block of memory ...

## Booting image at 41020000 ...
   Image Name:   Linux-2.6.24.4
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1774888 Bytes =  1.7 MB
   Load Address: 48008000
   Entry Point:  48008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux...
<etc>

If I load something to the same address, but then boot from
0x41020000,  I get the original 2.6.24 kernel from MTD, not what I've
just loaded via TFTP, so, if the kernel is really being loaded and run
at 0x48008000 as the boot message implies, then I presume the code at
0x41020000 is copying it from MTD to there and then jumping into it,
but I don't know what address it jumps to.  Unfortunately it's not
given in any of the environment settings.

# Copy initrd to expected location, then boot from 0x41020000 
bootcmd=cp 0x411e0000 0x4a000000 0x25c000; bootm 0x41020000

# The default boot arguments
bootargs=console=ttyS0,115200n8 root=/dev/ram0 rw init=/sbin/init
initrd=0x4a000000,4M elevator=cfq
mtdparts=physmap-flash.0:128k(uboot),1792k(kernel),1664k(initrd),448k(etc),48k(empty),8k(env1),8k(env2)
mem=256M poweroutage=yes

$ bdinfo
arch_number = 0x00000480
env_t       = 0x00000000
boot_params = 0x48000100
DRAM bank   = 0x00000000
-> start    = 0x48000000
-> size     = 0x10000000

> To
> take a wild guess, I think you want to load the uImage at 0x48000000 and set
> the entry point to 0x48008000.  ie pass '-a 0x48000000 -e 0x48008000' to
> mkimage.
> 
> Theo

I can certainly try that, but, as explained above, that doesn't seem
to be what the Zyxel originals do  -  they have both load and start
addresses set to 0x48008000, the same that I have used.
-- 
========================================================
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

[toc] | [prev] | [next] | [standalone]

#20916 — Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3"

On Thu, 07 Sep 2017 21:48:32 +0100, Java Jive <java@evij.com.invalid>
wrote:
>
> On 07 Sep 2017 20:43:01 +0100 (BST), Theo
> <theom+news@chiark.greenend.org.uk> wrote:
> >
> > To
> > take a wild guess, I think you want to load the uImage at 0x48000000 and set
> > the entry point to 0x48008000.  ie pass '-a 0x48000000 -e 0x48008000' to
> > mkimage.
> > 
> > Theo
> 
> I can certainly try that, but, as explained above, that doesn't seem
> to be what the Zyxel originals do  -  they have both load and start
> addresses set to 0x48008000, the same that I have used.

$ tftpboot 0x48000000 uImage
Wait GMAC to reset
Wait for PHY reset
PHY is Realtek RTL8211BGR
Wait for link to come up...........Link up
Wait for auto-negotiation to completeLink is 10M/100M
TFTP from server 192.168.1.20; our IP address is 192.168.1.233
Filename 'uImage'.
Load address: 0x48000000
Loading:
 #################################################################
 #################################################################
 #################################################################
 #################################################################
 #################################################################
 #################################################################
         ############################
done
Bytes transferred = 2136452 (209984 hex)
$ bootm 0x48008000
## Booting image at 48008000 ...
Bad Magic Number

Also tried:

$ tftpboot 0x48008000 uImage
Wait GMAC to reset
Wait for PHY reset
PHY is Realtek RTL8211BGR
Wait for link to come up..........Link up
Wait for auto-negotiation to completeLink is 10M/100M
TFTP from server 192.168.1.20; our IP address is 192.168.1.233
Filename 'uImage'.
Load address: 0x48008000
Loading:
 #################################################################
 #################################################################
 #################################################################
 #################################################################
 #################################################################
 #################################################################
         ############################
done
Bytes transferred = 2136452 (209984 hex)
$ bootm 0x48008040
## Booting image at 48008040 ...
Bad Magic Number
-- 
========================================================
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

[toc] | [prev] | [next] | [standalone]

#20917 — Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3"

In uk.comp.os.linux Java Jive <java@evij.com.invalid> wrote:
> On Thu, 07 Sep 2017 21:48:32 +0100, Java Jive <java@evij.com.invalid>
> wrote:
> >
> > On 07 Sep 2017 20:43:01 +0100 (BST), Theo
> > <theom+news@chiark.greenend.org.uk> wrote:
> > >
> > > To
> > > take a wild guess, I think you want to load the uImage at 0x48000000 and set
> > > the entry point to 0x48008000.  ie pass '-a 0x48000000 -e 0x48008000' to
> > > mkimage.
> > 
> > I can certainly try that, but, as explained above, that doesn't seem
> > to be what the Zyxel originals do  -  they have both load and start
> > addresses set to 0x48008000, the same that I have used.
> 
> $ tftpboot 0x48000000 uImage
> $ bootm 0x48008000
> ## Booting image at 48008000 ...

That's not quite what I said.  You mkimage -a 0x48000000 -e 0x48008000
but then tftpboot and bootm 0x48000000.

> Yes, there appears to be some sort of header of 0x40 bytes in length, 
> but that exists also in the original Zyxel image.  The most confusing 
> thing is that the original Zyxel image seems to load at 0x48008000, 
> and have a run address the same,  but actually is run via 0x41020000, 
> which isn't even part of the same block of memory ... 
>
> ## Booting image at 41020000 ... 
>   Image Name:   Linux-2.6.24.4 
>   Image Type:   ARM Linux Kernel Image (uncompressed) 
>   Data Size:    1774888 Bytes =  1.7 MB 
>   Load Address: 48008000 
>   Entry Point:  48008000 
>   Verifying Checksum ... OK 
> OK 

As above, the length, load address and entry point are already in the
header.  So it can copy the image up and then jump into it.
Presumably if the load address and the bootm address are the same, it'll
skip the copy step.

I'm guessing that 0x41020000 is somewhere in the NOR flash, so it will copy
it from flash to RAM while doing so.  The initrd won't be copied as part of
the kernel image, hence the need to also copy it from flash to RAM using:

cp 0x411e0000 0x4a000000 0x25c000

I think the reason it doesn't work to both bootm and then entry at
0x48008000 is that the copy isn't just a copy, it'll strip off the uImage
header before jumping to the entry point.

I'm not sure why that isn't happening in that case, but maybe bootm
where the load address equals the image base address causes it to assume
it's booting from ROM where it can't clear the table.  If you set the entry
point to the base +0x8000 it should jump into the beginning of the kernel,
past the header.

All speculation though.

Theo

[toc] | [prev] | [next] | [standalone]

#20981 — Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3"

Over recent days, I've had to return my second NAS back to normal
duties acting as a backup for the first, but today have been exploring
this further ...

On 07 Sep 2017 23:04:43 +0100 (BST), Theo
<theom+news@chiark.greenend.org.uk> wrote:

> In uk.comp.os.linux Java Jive <java@evij.com.invalid> wrote:
> > On Thu, 07 Sep 2017 21:48:32 +0100, Java Jive <java@evij.com.invalid>
> > wrote:
> > >
> > > I can certainly try that, but, as explained above, that doesn't seem
> > > to be what the Zyxel originals do  -  they have both load and start
> > > addresses set to 0x48008000, the same that I have used.
> > 
> > $ tftpboot 0x48000000 uImage
> > $ bootm 0x48008000
> > ## Booting image at 48008000 ...
> 
> That's not quite what I said.  You mkimage -a 0x48000000 -e 0x48008000
> but then tftpboot and bootm 0x48000000.

No, that's not going to work.  I've got one step further now ...

What has to be done is to load via tftp *elsewhere* in memory, not
overlapping with the final memory destination determined by the start
and run addresses.  Thus, where <image file> is the filename of the
kernel section, with load and run addresses of 0x48008000, of an
existing image that is known to work ...

cp 0x411e0000 0x4a000000 0x25c000	# Copy initrd into place
tftpboot 0x048008000 <image file>		# Load kernel over tftp
bootm 0x048008000						# Try to boot it

...  fails, but ...

cp 0x411e0000 0x4a000000 0x25c000	# Copy initrd into place
tftpboot 0x57000000 <image file>		# Load kernel over tftp
bootm 0x57000000						# Try to boot it

... works.  U-boot copies the kernel, without the header, into place
at 0x48008000 and runs it.

However, when I try that with the new 2.6.36 kernel, it dies  -
there's no useful message after u-boot's checksum verification, it
just dies.  I've tried varying both the initial load and the final run
addresses, but, though it sometimes dies differently, it always dies.
I think at least part of the problem, maybe all of it, is that the new
kernel is just too big, 0x209984 as opposed to 0x1C0000 of the
original, but given the next known thing up in memory appears to be
u-boot itself at 0x4d000000, I would have expected that there is
enough room for it at least to have got further than ...

$ cp 0x411e0000 0x4a000000 0x25c000
$ tftpboot 0x56000000 uImage

Wait GMAC to reset
Wait for PHY reset
PHY is Realtek RTL8211BGR
Wait for link to come up..............Link up
Wait for auto-negotiation to completeLink is 10M/100M
TFTP from server 192.168.1.20; our IP address is 192.168.1.233
Filename 'uImage'.
Load address: 0x56000000
Loading:
*#################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 ############################
done
Bytes transferred = 2136452 (209984 hex)

$ bootm 0x56000000

## Booting image at 56000000 ...
   Image Name:   Linux-2.6.39
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2136388 Bytes =  2 MB
   Load Address: 48008000
   Entry Point:  48008000
   Verifying Checksum ... OK
OK

Starting kernel ...

(nothing after this) :-(
-- 
========================================================
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

[toc] | [prev] | [next] | [standalone]

#20991 — Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3"

In uk.comp.os.linux Java Jive <java@evij.com.invalid> wrote:
> On 07 Sep 2017 23:04:43 +0100 (BST), Theo
> <theom+news@chiark.greenend.org.uk> wrote:
> > That's not quite what I said.  You mkimage -a 0x48000000 -e 0x48008000
> > but then tftpboot and bootm 0x48000000.
> 
> No, that's not going to work.

What did it say when you tried it?

> cp 0x411e0000 0x4a000000 0x25c000       # Copy initrd into place
> tftpboot 0x57000000 <image file>                # Load kernel over tftp
> bootm 0x57000000                                                # Try to boot it
> 
> ... works.  U-boot copies the kernel, without the header, into place
> at 0x48008000 and runs it.
> 
> However, when I try that with the new 2.6.36 kernel, it dies  -
> there's no useful message after u-boot's checksum verification, it
> just dies.

Do you know that the kernel is being linked to load at physical address
0x48008000?  If you're loading it to an address other than the place it's
linked for, it will start executing instructions but fall over as soon as
there's an absolute branch (to the wrong address).  Kernels are not linked
position-independent.  The base address should be somewhere in the kernel
config (somewhere in 'make menuconfig' or equivalent - the settings are
stored in .config in the top level of the kernel sources)

One other thing: there may not be enough memory to decompress in RAM, so you
might have to load the uncompressed kernel.  There is some puzzlement
because the kernel in flash says:

## Booting image at 41020000 ... 
   Image Name:   Linux-2.6.24.4 
   Image Type:   ARM Linux Kernel Image (uncompressed) 
   Data Size:    1774888 Bytes =  1.7 MB 
   Load Address: 48008000 
   Entry Point:  48008000 
   Verifying Checksum ... OK 
OK 

Starting kernel ... 

Uncompressing Linux... 

- so I think the '(uncompressed)' is a red herring here (it probably means
that uboot hasn't compressed it, while 'uncompressing Linux' is a message
from the running kernel code itself.  Is your kernel compressed or
uncompressed?

>  I've tried varying both the initial load and the final run
> addresses, but, though it sometimes dies differently, it always dies.
> I think at least part of the problem, maybe all of it, is that the new
> kernel is just too big, 0x209984 as opposed to 0x1C0000 of the
> original, but given the next known thing up in memory appears to be
> u-boot itself at 0x4d000000, I would have expected that there is
> enough room for it at least to have got further than ...

That's just over 2MB.  The NAS seems to have 256MB - so it seems unlikely
space is a problem.

Where did you get your kernel .config from?  Did they supply it?

Theo

[toc] | [prev] | [next] | [standalone]

#20993 — Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3"

On 16 Sep 2017 16:14:25 +0100 (BST), Theo
<theom+news@chiark.greenend.org.uk> wrote:

> In uk.comp.os.linux Java Jive <java@evij.com.invalid> wrote:
> > On 07 Sep 2017 23:04:43 +0100 (BST), Theo
> > <theom+news@chiark.greenend.org.uk> wrote:
> > > That's not quite what I said.  You mkimage -a 0x48000000 -e 0x48008000
> > > but then tftpboot and bootm 0x48000000.
> > 
> > No, that's not going to work.
> 
> What did it say when you tried it?

"Bad Magic Number"

> > cp 0x411e0000 0x4a000000 0x25c000       # Copy initrd into place
> > tftpboot 0x57000000 <image file>                # Load kernel over tftp
> > bootm 0x57000000                                                # Try to boot it
> > 
> > ... works.  U-boot copies the kernel, without the header, into place
> > at 0x48008000 and runs it.
> > 
> > However, when I try that with the new 2.6.36 kernel, it dies  -
> > there's no useful message after u-boot's checksum verification, it
> > just dies.
> 
> Do you know that the kernel is being linked to load at physical address
> 0x48008000?  If you're loading it to an address other than the place it's
> linked for, it will start executing instructions but fall over as soon as
> there's an absolute branch (to the wrong address).  Kernels are not linked
> position-independent.  The base address should be somewhere in the kernel
> config (somewhere in 'make menuconfig' or equivalent - the settings are
> stored in .config in the top level of the kernel sources)

Good point, for which thanks!  I set the correct load and run
addresses in uImage, but of course that's not the same thing, and as I
haven't got the source for the mkimage binary, that converts vmLinuz
or similar into uImage, I don't know whether it would go through
making any necessay adjustments, so it would probably be necessary to
assume that it doesn't.  I'll check this, hopefully later today.

> One other thing: there may not be enough memory to decompress in RAM, so you
> might have to load the uncompressed kernel.  There is some puzzlement
> because the kernel in flash says:
> 
> ## Booting image at 41020000 ... 
>    Image Name:   Linux-2.6.24.4 
>    Image Type:   ARM Linux Kernel Image (uncompressed) 
>    Data Size:    1774888 Bytes =  1.7 MB 
>    Load Address: 48008000 
>    Entry Point:  48008000 
>    Verifying Checksum ... OK 
> OK 
> 
> Starting kernel ... 
> 
> Uncompressing Linux... 
> 
> - so I think the '(uncompressed)' is a red herring here (it probably means
> that uboot hasn't compressed it, while 'uncompressing Linux' is a message
> from the running kernel code itself.  Is your kernel compressed or
> uncompressed?

I too had noticed the apparent discrepancy in messages.  I think it's
compressed, because there's an apparently uncompressed pre-cursor file
of about double the size.
 
> >  I've tried varying both the initial load and the final run
> > addresses, but, though it sometimes dies differently, it always dies.
> > I think at least part of the problem, maybe all of it, is that the new
> > kernel is just too big, 0x209984 as opposed to 0x1C0000 of the
> > original, but given the next known thing up in memory appears to be
> > u-boot itself at 0x4d000000, I would have expected that there is
> > enough room for it at least to have got further than ...
> 
> That's just over 2MB.  The NAS seems to have 256MB - so it seems unlikely
> space is a problem.
> 
> Where did you get your kernel .config from?  Did they supply it?

I took the .config used by Zyxel for the 2.6.24 kernel and ran it
through 'make oldconfig' for the new 2.6.36 kernel.

> Theo

Your responses are so often very helpful Theo, that I'd like to take a
moment to say how much I appreciate them and you.  Thank you yet
again!
-- 
========================================================
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

[toc] | [prev] | [next] | [standalone]

#20996 — Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3"

On Sat, 16 Sep 2017 16:39:32 +0100, Java Jive <java@evij.com.invalid>
wrote:

> On 16 Sep 2017 16:14:25 +0100 (BST), Theo
> <theom+news@chiark.greenend.org.uk> wrote:
> > 
> > Do you know that the kernel is being linked to load at physical address
> > 0x48008000?  If you're loading it to an address other than the place it's
> > linked for, it will start executing instructions but fall over as soon as
> > there's an absolute branch (to the wrong address).  Kernels are not linked
> > position-independent.  The base address should be somewhere in the kernel
> > config (somewhere in 'make menuconfig' or equivalent - the settings are
> > stored in .config in the top level of the kernel sources)
> 
> Good point, for which thanks!  I set the correct load and run
> addresses in uImage, but of course that's not the same thing, and as I
> haven't got the source for the mkimage binary, that converts vmLinuz
> or similar into uImage, I don't know whether it would go through
> making any necessay adjustments, so it would probably be necessary to
> assume that it doesn't.  I'll check this, hopefully later today.
>
> [...]
>
> I took the .config used by Zyxel for the 2.6.24 kernel and ran it
> through 'make oldconfig' for the new 2.6.36 kernel.

Checking through .config, I couldn't find anything that was obviously
a load or run address, but there was ...
	CONFIG_ZBOOT_ROM_TEXT=0x0
	CONFIG_ZBOOT_ROM_BSS=0x0

Running 'make oldconfig' again, I've reached a setting ...
	Compressed ROM boot loader base address (ZBOOT_ROM_TEXT) [0]
... corresponding to the first above.  Presumably this is where I
should enter the load address?  The following pages seem to suggest
so, but contain the statement ...
	If ZBOOT_ROM is not enabled, this has no effect.
... but there is no ZBOOT_ROM setting in the .config file.
https://cateee.net/lkddb/web-lkddb/ZBOOT_ROM_TEXT.html
https://cateee.net/lkddb/web-lkddb/ZBOOT_ROM_BSS.html

Addendum:  Changing the above from the default value of zero brings up
the extra ZBOOT_ROM setting.  Rebuilding now ...
-- 
========================================================
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

[toc] | [prev] | [next] | [standalone]

#21000 — Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3"

In uk.comp.os.linux Java Jive <java@evij.com.invalid> wrote:
> On 16 Sep 2017 16:14:25 +0100 (BST), Theo
> <theom+news@chiark.greenend.org.uk> wrote:
>
> Good point, for which thanks!  I set the correct load and run
> addresses in uImage, but of course that's not the same thing, and as I
> haven't got the source for the mkimage binary, that converts vmLinuz
> or similar into uImage, I don't know whether it would go through
> making any necessay adjustments, so it would probably be necessary to
> assume that it doesn't.  I'll check this, hopefully later today.

I was slightly wrong - kernels can be relocatable, and indeed have to be for
KASLR to work.  But I'm not sure what the status on ARM was for your very
old kernel.

> > - so I think the '(uncompressed)' is a red herring here (it probably means
> > that uboot hasn't compressed it, while 'uncompressing Linux' is a message
> > from the running kernel code itself.  Is your kernel compressed or
> > uncompressed?
> 
> I too had noticed the apparent discrepancy in messages.  I think it's
> compressed, because there's an apparently uncompressed pre-cursor file
> of about double the size.

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.

> I took the .config used by Zyxel for the 2.6.24 kernel and ran it
> through 'make oldconfig' for the new 2.6.36 kernel.

That sounds sensible then.  I was a bit worried you had no .config at all.

> Your responses are so often very helpful Theo, that I'd like to take a
> moment to say how much I appreciate them and you.  Thank you yet
> again!

Kernel debugging by proxy is an interesting challenge... :)

Theo

[toc] | [prev] | [next] | [standalone]

#21005 — Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3"

On 17 Sep 2017 02:15:01 +0100 (BST), Theo
<theom+news@chiark.greenend.org.uk> wrote:

> In uk.comp.os.linux Java Jive <java@evij.com.invalid> wrote:
> > On 16 Sep 2017 16:14:25 +0100 (BST), Theo
> > <theom+news@chiark.greenend.org.uk> wrote:
> >
> > Good point, for which thanks!  I set the correct load and run
> > addresses in uImage, but of course that's not the same thing, and as I
> > haven't got the source for the mkimage binary, that converts vmLinuz
> > or similar into uImage, I don't know whether it would go through
> > making any necessay adjustments, so it would probably be necessary to
> > assume that it doesn't.  I'll check this, hopefully later today.
> 
> I was slightly wrong - kernels can be relocatable, and indeed have to be for
> KASLR to work.  But I'm not sure what the status on ARM was for your very
> old kernel.

It seems that setting CONFIG_ZBOOT_ROM_TEXT is the way to go.  If I
change the settings as follows ...
	CONFIG_ZBOOT_ROM_TEXT=0x48008000	# Original load & run
	CONFIG_ZBOOT_ROM_BSS=0x48d1afa4		# Original BSS
	CONFIG_ZBOOT_ROM=y
... I no longer have to hack arch/arm/boot/Makefile to get the correct
addresses in uImage !-)  Unfortunately, however, it made no difference
to the end result, the new kernel so built died exactly as the one
before :-(

> > > - so I think the '(uncompressed)' is a red herring here (it probably means
> > > that uboot hasn't compressed it, while 'uncompressing Linux' is a message
> > > from the running kernel code itself.  Is your kernel compressed or
> > > uncompressed?
> > 
> > I too had noticed the apparent discrepancy in messages.  I think it's
> > compressed, because there's an apparently uncompressed pre-cursor file
> > of about double the size.

Yes, after yesterday evening's build, I have in the output directory:
	Image	4025KB
	zImage	2087KB
	uImage	2087KB

So I think your analysis above is entirely correct.  zImage is
obviously the compressed, self-extracting version of Image, and uImage
is zImage with a u-boot header.  Because u-boot doesn't have to
decompress uImage, it gives a message describing it as being
uncompressed, but when a working kernel is booted, the first thing it
does is self-decompress, hence its own message apparently
contradicting u-boot's earlier one.

And, as per your remarks below, it seems that the new kernel is indeed
falling at the first hurdle, and is not even beginning to extract
itself ...

> 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.

Yes, I entirely agree.

This being so, I thought it was time to go back to basics, and run
some sort of check as to whether my cross-build system was indeed
producing arm code, not i386.  I admit that really I should have done
that before, but I guess I got so carried away by at last managing to
complete the cross-build that it went to my head!  Anyway, I compiled
a simple test.c ...

	#include <stdio.h>

	int main()
		{
		printf( "Hello arm world!\n" );
		return 0;
		}

... with the command ...

	armv5tejl-unknown-linux-gnueabi-gcc test.c

... copied the resulting a.out up to the NAS, and was vastly relieved
to see ...

	~ # ./a.out
	Hello arm world!

Phew!  <wipes sweat off brow>  So, whatever the problem is, I think
and hope that at least the cross build system is working!

> 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.

Certainly I have a working kernel, extracted from one of the OEM Zyxel
image files, and in binary dump the beginning of it seems very similar
to the one built by my cross-build system, but, unless the binutils,
etc, that I've built contains one, I don't have a dissassembler.

I may have some time to come back to this this evening, but for now
domestic duties are calling.

Thanks again for all your help.
-- 
========================================================
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

[toc] | [prev] | [next] | [standalone]

#21006 — Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3"

On Sun, 17 Sep 2017 17:02:18 +0100, Java Jive <java@evij.com.invalid>
wrote:
> 
> Certainly I have a working kernel, extracted from one of the OEM Zyxel
> image files, and in binary dump the beginning of it seems very similar
> to the one built by my cross-build system, but, unless the binutils,
> etc, that I've built contains one, I don't have a dissassembler.
> 
> I may have some time to come back to this this evening, but for now
> domestic duties are calling.

I've found the disassembler, but there's a problem ...

# armv5tejl-unknown-linux-gnueabi-objdump -D
build/linux/arch/arm/boot/Image | more
armv5tejl-unknown-linux-gnueabi-objdump:
build/linux/arch/arm/boot/Image: File format not recognized
-- 
========================================================
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

[toc] | [prev] | [next] | [standalone]

#21007 — Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3"

On Sun, 17 Sep 2017 20:45:36 +0100, Java Jive <java@evij.com.invalid>
wrote:
> 
> I've found the disassembler, but there's a problem ...
> 
> # armv5tejl-unknown-linux-gnueabi-objdump -D
> build/linux/arch/arm/boot/Image | more
> armv5tejl-unknown-linux-gnueabi-objdump:
> build/linux/arch/arm/boot/Image: File format not recognized

More haste less speed, as the above stands it's ambiguous and
potentially misleading.  I should've added that the same thing happens
with a working kernel file as well.
-- 
========================================================
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

[toc] | [prev] | [next] | [standalone]

#21008 — Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3"

In uk.comp.os.linux Java Jive <java@evij.com.invalid> wrote:
> I've found the disassembler, but there's a problem ...
> 
> # armv5tejl-unknown-linux-gnueabi-objdump -D
> build/linux/arch/arm/boot/Image | more
> armv5tejl-unknown-linux-gnueabi-objdump:
> build/linux/arch/arm/boot/Image: File format not recognized

It's not ELF, so you probably need
-b binary

You probably need
-marm
as well.

Theo

[toc] | [prev] | [next] | [standalone]

#21009 — Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3"

On 17 Sep 2017 21:10:32 +0100 (BST), Theo
<theom+news@chiark.greenend.org.uk> wrote:

> In uk.comp.os.linux Java Jive <java@evij.com.invalid> wrote:
> > I've found the disassembler, but there's a problem ...
> > 
> > # armv5tejl-unknown-linux-gnueabi-objdump -D
> > build/linux/arch/arm/boot/Image | more
> > armv5tejl-unknown-linux-gnueabi-objdump:
> > build/linux/arch/arm/boot/Image: File format not recognized
> 
> It's not ELF, so you probably need
> -b binary
> 
> You probably need
> -marm
> as well.

I'm afraid neither switch is recognised:

Usage: armv5tejl-unknown-linux-gnueabi-objdump <option(s)> <file(s)>
 Display information from object <file(s)>.
 At least one of the following switches must be given:
  -a, --archive-headers    Display archive header information
  -f, --file-headers       Display the contents of the overall file
header
  -p, --private-headers    Display object format specific file header
contents
  -P, --private=OPT,OPT... Display object format specific contents
  -h, --[section-]headers  Display the contents of the section headers
  -x, --all-headers        Display the contents of all headers
  -d, --disassemble        Display assembler contents of executable
sections
  -D, --disassemble-all    Display assembler contents of all sections
  -S, --source             Intermix source code with disassembly
  -s, --full-contents      Display the full contents of all sections
requested
  -g, --debugging          Display debug information in object file
  -e, --debugging-tags     Display debug information using ctags style
  -G, --stabs              Display (in raw form) any STABS info in the
file
  -W[lLiaprmfFsoRt] or

--dwarf[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,
          =frames-interp,=str,=loc,=Ranges,=pubtypes,
          =gdb_index,=trace_info,=trace_abbrev,=trace_aranges,
          =addr,=cu_index]
                           Display DWARF info in the file
  -t, --syms               Display the contents of the symbol table(s)
  -T, --dynamic-syms       Display the contents of the dynamic symbol
table
  -r, --reloc              Display the relocation entries in the file
  -R, --dynamic-reloc      Display the dynamic relocation entries in
the file
  @<file>                  Read options from <file>
  -v, --version            Display this program's version number
  -i, --info               List object formats and architectures
supported
  -H, --help               Display this information
-- 
========================================================
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

[toc] | [prev] | [next] | [standalone]

#20992 — Re: UBoot, Or "Endless problems trying to compile for/on embedded devices - Ch 3"

On Fri, 15 Sep 2017 18:06:13 +0100, Java Jive <java@evij.com.invalid>
wrote:
>
> I think at least part of the problem, maybe all of it, is that the new
> kernel is just too big, 0x209984 as opposed to 0x1C0000 of the
> original, but given the next known thing up in memory appears to be
> u-boot itself at 0x4d000000, 

This was erroneous and ought to be corrected.  The next known thing
going up in memory is in fact initrd at 0x4a000000, because it was
copied there by the previous command ...
	cp 0x411e0000 0x4a000000 0x25c000

However, the reasoning still stands ...
	0x048008000 + 0x209984 = 0x48217984
... which is comfortably less than 0x4a000000.
-- 
========================================================
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

[toc] | [prev] | [next] | [standalone]

#21022 — Re: UBoot - Ch 4

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

[toc] | [prev] | [next] | [standalone]

#21023 — Re: UBoot - Ch 4

Java Jive wrote:

> For anyone who's interested here's the difference command given and
> the resulting output:

Unified diffs (with -u option) are easier to read, or at least more 
familiar to the eye these days, as people are used to them from git.

You can use the patch utility to "send" changes from one source code 
tree to another.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | uk.comp.os.linux

csiph-web