ELDK and suse 9.0

ELDK and suse 9.0

[Kate Alhola]

I have user eldk a lot with Redhat 9 but after they discontinued it, i
decided to change to
suse 9 but looks a like that least standard eldk 2.1.0 install does not
work with suse9

May be i just need to build the rpm packages included in eldk with suse
from
sources but i have yet not have time to look out how they differ from
standard rpm
that comes with suse. Least symlinking eldk:s own rpm eith system rpm
does not work.
It gives just too many error messages about conflicts and dependensies.

I have tried tp get ELDK installed to suse 9.0 but it looks a like that
rpm program cpming with it
gives segmentetion fault when it uses build in rpm command. I have tried
it with two
diferent Suse 9.0 systems with exactly same results.


There is some debug traces:

install runs and does not give any error messages bus just ends. Running
it with strace
indicates that /opt/eldk/bin/rpm gives segmentation fault and running it by
strace indicates that that command fails with following log:


Kate

----- Debug traces comes here ------------
[root@katerinaii eldk-ppc-linux-x86]# cat debugout
trinity:/katerinaii/kate/denx/eldk-ppc-linux-x86 # ./install -v -d
/opt/eldk ppc_82xx


Do you really want to install into /opt/eldk directory[y/n]?: y

Installing cross RPMs

/opt/eldk/bin/rpm -ihv --nodeps  ./RPMS/rpm-4.0.3-1.03b_2.i386.rpm
Preparing...                ###########################################
[100%]
trinity:/katerinaii/kate/denx/eldk-ppc-linux-x86 # strace
/opt/eldk/bin/rpm -ihv --nodeps  ./RPMS/rpm-4.0.3-1.03b_2.i386.rpm

----- lots of lines deleted -----

open("/lib/libc.so.6", O_RDONLY)        = 7
read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0^\1\000"...,
1024) = 1024
fstat64(7, {st_mode=S_IFREG|0755, st_size=1470060, ...}) = 0
old_mmap(NULL, 1269380, PROT_READ|PROT_EXEC, MAP_PRIVATE, 7, 0) = 0x40244000
mprotect(0x40373000, 28292, PROT_NONE)  = 0
old_mmap(0x40373000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
7, 0x12e000) = 0x40373000
old_mmap(0x40378000, 7812, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40378000
close(7)                                = 0
open("/lib/ld-linux.so.2", O_RDONLY)    = 7
read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\n\0\000"...,
1024) = 1024
fstat64(7, {st_mode=S_IFREG|0755, st_size=101556, ...}) = 0
old_mmap(NULL, 88440, PROT_READ|PROT_EXEC, MAP_PRIVATE, 7, 0) = 0x4037a000
mprotect(0x4038f000, 2424, PROT_NONE)   = 0
old_mmap(0x4038f000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
7, 0x15000) = 0x4038f000
close(7)                                = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
[root@katerinaii eldk-ppc-linux-x86]#


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ELDK and suse 9.0

[Steven Scholz]

Kate,

 > I have user eldk a lot with Redhat 9 but after they discontinued it, i
 > decided to change to
 > suse 9 but looks a like that least standard eldk 2.1.0 install does not
 > work with suse9


Wolfgang Denk wrote on the U-Boot mailings list:

 > This is a known problem which will be fixed in ELDK-3.0 (due to be out soon).
 >
 > You have two options:
 >
 > 1) Install on an older SuSE or on a RedHat system and copy the files
 > 2) download the file ftp://ftp.denx.de/pub/tmp/ELDK-update-2.2.0.tar.bz2
 >    Then change into the source tree with the ELDK files and perform
 >    the following operations:
 >
 >         bash$ rm RPMS/rpm-4.0.3-1.03b_2.i386.rpm \
 >                 RPMS/rpm-build-4.0.3-1.03b_2.i386.rpm \
 >                 RPMS/rpm-devel-4.0.3-1.03b_2.i386.rpm \
 >                 tools/usr/lib/rpm/rpmpopt-4.0.3
 >         bash$ tar jxf /tmp/ELDK-update-2.2.0.tar.bz2
 >
 >    Then build the ISO image as documented, and try again.
 >
 >
 > Best regards,
 >
 > Wolfgang Denk

Both ways work. I am using ELDK-2.2 on SuSE 9.

Good luck,

Steven

--
Steven Scholz

imc Measurement & Control               imc Meßsysteme GmbH
Voltastr. 5                             Voltastr. 5
13355 Berlin                            13355 Berlin
Germany                                 Deutschland
fon: +49 30 467090-0                    Tel: 030 / 467090-0
fax: +49 30 4631576                     fax: 030 / 4631576


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

reboot by software

[John Zhou]

Hello!

I have a linux running on my mpc8260 board( power on reset at 0xfff00100, I use 32 bit flash, and directly maping 0xF0000000 ~ 0xFFFFFFF in kernel).

Now, I want to reboot system by software. But, when I jump to 0xfff00100 in kernel mode, it's going dead. Can anybody help me?

Thanks.

John

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ELDK and suse 9.0

[Wolfgang Denk]

In message <3FDEC481.2010708@iti.fi> you wrote:
>
> I have user eldk a lot with Redhat 9 but after they discontinued it, i
> decided to change to
> suse 9 but looks a like that least standard eldk 2.1.0 install does not
> work with suse9

This is a FAQ. Please see
http://www.denx.de/twiki/bin/view/DULG/ELDKInstallationAborts


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
The management question ... is not _whether_ to build a pilot  system
and  throw  it away. You _will_ do that. The only question is whether
to plan in advance to build a throwaway, or to promise to deliver the
throwaway to customers.       - Fred Brooks, "The Mythical Man Month"

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: reboot by software

[Wolfgang Denk]

Dear John,

in message <000101c3c3b8$68333110$b702a8c0@newrock2> you wrote:
>
> I have a linux running on my mpc8260 board( power on reset at
> 0xfff00100, I use 32 bit flash, and directly maping 0xF0000000 ~
> 0xFFFFFFF in kernel).
>
> Now, I want to reboot system by software. But, when I jump to
> 0xfff00100 in kernel mode, it's going dead. Can anybody help me?

Jumping to some address does not cause a reboot of the system.  After
a   reset,  the  CPU  state  (especially  the  state  of  the  memory
controller) is somewhat special. The safest  way  to  cause  a  clean
reboot of the whole system is to actually go through a reset.

Try something like this:

void
m8260_restart(char *cmd)
{
	__volatile__	unsigned char	dummy;
	__volatile__	unsigned int	msr;
	uint		bad_addr;

	/* Get base address mapped by BR0/OR0 */
	bad_addr = ((immap_t *)IMAP_ADDR)->im_memctl.memc_br0 & 0xFFFF8000;
	cli();

	/* Enable CheckStop Reset */
	((immap_t *)IMAP_ADDR)->im_clkrst.car_rmr |= 0x00000001;

	/* Invalidate BR0 mapping */
	((immap_t *)IMAP_ADDR)->im_memctl.memc_br0 = 0;

	/* Set MSR and cause reset */
	__asm__("mfmsr %0" : "=r" (msr) );
	msr &= ~0x1000;
	__asm__("mtmsr %0" : "=r" (msr) );
	dummy = * (unsigned char *) bad_addr;
	printk("Restart failed\n");
	while(1);
}

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Bankers do it with interest (penalty for early withdrawal).

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: reboot by software

[Gary Thomas]

On Tue, 2003-12-16 at 02:38, John Zhou wrote:
> Hello!
>
> I have a linux running on my mpc8260 board( power on reset at
> 0xfff00100, I use 32 bit flash, and directly maping
> 0xF0000000 ~ 0xFFFFFFF in kernel).
>
> Now, I want to reboot system by software. But, when I jump
> to 0xfff00100 in kernel mode, it's going dead. Can anybody help me?

Just jumping into the reset vector of the ROM/FLASH isn't going
to work since Linux is running with the MMU on, etc.  What you
really need is some way to tell the hardware to reenter the
RESET condition.

Probably the best way on that platform is to cause a machine
check (checkstop) and set it up to reset on checkstop.  Look
at the description of HID0 on the 8260 to see how to do it.

Here's how I did it on an 8250 (same core):
    unsigned long hid0;
    // Need interrupts off to force checkstop
    cli();
    ((immap_t *)IMAP_ADDR)->im_clkrst.car_rmr |= 0x01;  // Checkstop reset enable
    // Force a checkstop by turning on parity which is not implemented
    hid0 = mfspr(HID0);
    hid0 |= 0x30000000;
    mtspr(HID0, hid0);

--
Gary Thomas <gary@mlbassoc.com>
MLB Associates


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: reboot by software

[VanBaren, Gerald (AGRE)]

The problem with jumping to 0xFFF00100 is that the hardware (processor internal as well as external bits) is not reset and it messes up the start up sequence.  The easiest solution is to force a checkstop reset (via a machine check), which performs a hardware reset and gets the 8260 (and your external hardware if your hardware supports the reset properly) back into the reset state.

The easiest way to do this is to unmap the memory that is being used to execute code (including the vector area) and then force a machine check

For an example, see U-Boot reset: it may need to be adapted to your purposes, but is a very nice example.  U-Boot can be found on sourceforge.net.  It is maintained and supported by Wolfgang Denk and his merry band (the snippet below is from .../cpu/mpc8260/cpu.c and is copyright Wolfgang Denk with a GPL license).  For more information, see sourceforge and www.denx.de

gvb


int
do_reset(cmd_tbl_t *cmdtp, bd_t *bd, int flag, int argc, char *argv[])
{
	ulong msr, addr;

	volatile immap_t *immap = (immap_t *)CFG_IMMR;

	immap->im_clkrst.car_rmr = RMR_CSRE; /* Checkstop Reset enable */

	/* Interrupts and MMU off */
	__asm__ __volatile__ ("mfmsr    %0" : "=r"(msr) : );
	msr &= ~(MSR_ME|MSR_EE|MSR_IR|MSR_DR);
	__asm__ __volatile__ ("mtmsr    %0" : : "r"(msr) );

	/*
	 * Trying to execute the next instruction at a non-existing address
	 * should cause a machine check, resulting in reset
	 */
#ifdef CFG_RESET_ADDRESS
	addr = CFG_RESET_ADDRESS;
#else
	/*
	 * note: when CFG_MONITOR_BASE points to a RAM address, CFG_MONITOR_BASE
	 * - sizeof (ulong) is usually a valid address. Better pick an address
	 * known to be invalid on your system and assign it to CFG_RESET_ADDRESS.
	 */
	addr = CFG_MONITOR_BASE - sizeof (ulong);
#endif
	((void (*)(void ))addr)();
	return 1;

}


> -----Original Message-----
> From: owner-linuxppc-embedded@lists.linuxppc.org
> [mailto:owner-linuxppc-embedded@lists.linuxppc.org]On Behalf Of John
> Zhou
> Sent: Tuesday, December 16, 2003 4:39 AM
> To: linuxppc-embedded@lists.linuxppc.org
> Subject: reboot by software
>
>
>
> Hello!
>
> I have a linux running on my mpc8260 board( power on reset at
> 0xfff00100, I use 32 bit flash, and directly maping
> 0xF0000000 ~ 0xFFFFFFF in kernel).
>
> Now, I want to reboot system by software. But, when I jump to
> 0xfff00100 in kernel mode, it's going dead. Can anybody help me?
>
> Thanks.
>
> John
>
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: reboot by software

[Wells, Charles]

> Now, I want to reboot system by software. But, when I jump to 0xfff00100
in kernel mode, it's going > dead. Can anybody help me?

If you have the Software Watchdog Timer enabled, just do a lock-interrupts
followed by a branch-self.

Charlie


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/