subject:"Re\: \[uClinux\-dev\] qemu\/m68k"

Re: [uClinux-dev] qemu/m68k

2014-08-29 Thread Waldemar Brodkorb

Hi,

Thanks for the help. After adding the FEC Kernel patch, the error
didn't occur anymore. I now have a shell (sash) with simpleinit and
can execute my uClibc tests. 

best regards
 Waldemar
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] qemu/m68k

2014-08-25 Thread Waldemar Brodkorb

Hi Greg,
Greg Ungerer wrote,

 Hi Waldemar,
 
 On 22/08/14 06:25, Waldemar Brodkorb wrote:
 Do you have a suggestion why I get a segfault after first executed
 command? Similar behaviour Thomas Petazzoni have seen, while he was
 trying to run buildroot in Qemu/m68k. See here:
 http://lists.busybox.net/pipermail/buildroot/2012-April/052585.html
 
 No, I haven't seen that behavior. Is it a hush problem?
 Maybe try a simpler shell to see if you get the same result.
 
 Okay, it seems a problem with my uClibc version or configuration.
 Still investigating. But using the sash from uClinux works fine
 with my own kernel.
 
 Ok, at least that gives you a working base to go from.

Okay, after further investigation and deeper digging in the uClinux
buildsystem I found partially a solution to my problem.
uCLinux uses a gcc wrapper and is linking executables with
-nostdlib and manually adding the needed C libraries and startup
files. 
I have just used -static, but this pulled in crtbegin.o and crtend.o
from gcc. I now use a gcc wrapper with a modified spec file, so that
crtbegin.o/crtend.o is not added to my binary.
Furthermore I added following patch to my gcc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584

Both changes required to create a working BFLT executable.
Otherwise elf2flt seems to pick up the data section of crtbegin.o,
which ends up with a BFLT file with a wrong data start.

I can provide more details and output of readelf of the sh.gdb files,
if required. I am not sure if this can be fixed in the linker script
used by elf2flt. 

But I still don't get an interactive shell working. I use simpleinit
and sash. The output of Qemu is:
Starting Linux (built with OpenADK).
Freeing unused kernel memory: 432K (401a - 4020c000)
Shell invoked to run file: /etc/rc
Command: echo Starting OpenADK
Starting OpenADK
Command: hostname openadk
Command: mount -t proc proc /proc
Command: mount -t sysfs sys /sys
Command: mkdir -m 755 /dev/pts
Command: mount -t devpts devpts /dev/pts
Command: mount -t tmpfs -o size=8M tmpfs /tmp
Command: chmod 1777 /tmp
Command: mkdir -p /var/log
Command: mkdir -p /var/run
Command: mkdir -p /var/tmp
Command: mdev -s
Command: mount
rootfs on / type rootfs (rw)
devtmpfs on /dev type devtmpfs (rw,relatime,mode=0755)
proc on /proc type proc (rw,relatime)
sys on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
tmpfs on /tmp type tmpfs (rw,relatime,size=8M)
Command: ifconfig lo 127.0.0.1 up
Execution Finished, Exiting

openadk login: Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b

My inittab is:
s0:linux:/sbin/getty -L -n 38400 ttyS0
1:linux:/sbin/getty -L -n 38400 ttyS1

I have taken a look into the coldfire example from qemu.org. They
are using simpleinit and busybox msh. I tried busybox hush, instead
of sash, but without success. msh seems no longer available in
busybox. Does uClinux provide a interactive shell? 

(need to try the uClinx system with the gdb method. I am just using kernel with 
initramfs
piggyback) 
 
 qemu: hardware error: mcf_fec_read: Bad address 0x1c4
 
 Hmmm, yeah, it does stop there. Not sure why. I will need to look
 more closely at that.
 
 Did you found anything?
 
 Yep. The problem is that the FEC driver is writing to registers
 that don't exist in the FEC hardware module on the ColdFire
 family. Support for some of the extended registers used on
 the FEC are used on ARM implementations, and they had added
 support for those in more recent years.
 
 I never picked those up on real hardware. Accesses to those
 on addresses cause no (visible) problems.
 
 Anyway, attached is a patch I propose to fix it. I will be
 sending this to the linux net-dev list soon.
 
Great! I will test it really soon. Or may be your upcoming patch.
 
thanks
 Waldemar
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] qemu/m68k

2014-08-22 Thread Geert Uytterhoeven

Hi Greg,

On Fri, Aug 22, 2014 at 2:40 AM, Greg Ungerer g...@uclinux.org wrote:
 qemu: hardware error: mcf_fec_read: Bad address 0x1c4


 Hmmm, yeah, it does stop there. Not sure why. I will need to look
 more closely at that.


 Did you found anything?

 Yep. The problem is that the FEC driver is writing to registers
 that don't exist in the FEC hardware module on the ColdFire
 family. Support for some of the extended registers used on
 the FEC are used on ARM implementations, and they had added
 support for those in more recent years.

 I never picked those up on real hardware. Accesses to those
 on addresses cause no (visible) problems.

 Anyway, attached is a patch I propose to fix it. I will be
 sending this to the linux net-dev list soon.

Instead of sprinkling the driver with (more) #ifdefs, wouldn't it be
better to use FEC_QUIRK_* flags in fec_devtype / platform data?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] qemu/m68k

2014-08-21 Thread Waldemar Brodkorb

Hi Greg,

 Do you have a suggestion why I get a segfault after first executed
 command? Similar behaviour Thomas Petazzoni have seen, while he was
 trying to run buildroot in Qemu/m68k. See here:
 http://lists.busybox.net/pipermail/buildroot/2012-April/052585.html
 
 No, I haven't seen that behavior. Is it a hush problem?
 Maybe try a simpler shell to see if you get the same result.
 
Okay, it seems a problem with my uClibc version or configuration.
Still investigating. But using the sash from uClinux works fine
with my own kernel.
 
 qemu: hardware error: mcf_fec_read: Bad address 0x1c4
 
 Hmmm, yeah, it does stop there. Not sure why. I will need to look
 more closely at that.

Did you found anything?
 
BTW: Are Cisco devices not official supported by uClinux?
I recently had the luck to find an old Cisco 1000 Series router
with a M68360 Motorola CPU. I like to use it probably for some
runtime testing, if I can boot Linux on it.

best regards
 Waldemar
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] qemu/m68k

2014-08-21 Thread Greg Ungerer


Hi Waldemar,

On 22/08/14 06:25, Waldemar Brodkorb wrote:

Do you have a suggestion why I get a segfault after first executed
command? Similar behaviour Thomas Petazzoni have seen, while he was
trying to run buildroot in Qemu/m68k. See here:
http://lists.busybox.net/pipermail/buildroot/2012-April/052585.html


No, I haven't seen that behavior. Is it a hush problem?
Maybe try a simpler shell to see if you get the same result.


Okay, it seems a problem with my uClibc version or configuration.
Still investigating. But using the sash from uClinux works fine
with my own kernel.


Ok, at least that gives you a working base to go from.



qemu: hardware error: mcf_fec_read: Bad address 0x1c4


Hmmm, yeah, it does stop there. Not sure why. I will need to look
more closely at that.


Did you found anything?


Yep. The problem is that the FEC driver is writing to registers
that don't exist in the FEC hardware module on the ColdFire
family. Support for some of the extended registers used on
the FEC are used on ARM implementations, and they had added
support for those in more recent years.

I never picked those up on real hardware. Accesses to those
on addresses cause no (visible) problems.

Anyway, attached is a patch I propose to fix it. I will be
sending this to the linux net-dev list soon.



BTW: Are Cisco devices not official supported by uClinux?
I recently had the luck to find an old Cisco 1000 Series router
with a M68360 Motorola CPU. I like to use it probably for some
runtime testing, if I can boot Linux on it.


I don't think anything is official in uClinux really :-)

There is some old and probably very crufty support for the 68360
in mainline. Not sure what platforms it was used on.

Regards
Greg



From 66b3d160150bee108c40e032214a2d93d782aff1 Mon Sep 17 00:00:00 2001
From: Greg Ungerer g...@uclinux.org
Date: Mon, 18 Aug 2014 16:47:43 +1000
Subject: [PATCH] net: fec: do not read/write undefined registers on ColdFire
 FEC

The Freescale FEC hardware module is used on many different SoC parts,
across at least 3 different CPU architectures. The FEC implementation on
the ColdFire family parts does not define the following registers:

  FEC_R_FIFO_RSFL
  FEC_R_FIFO_RSEM
  FEC_R_FIFO_RAEM
  FEC_R_FIFO_RAFL
  FEC_RACC
  FEC_MIIGSK_CFGR
  FEC_MIIGSK_ENR

But the driver reads and writes to those undefined locations. Those reads
and writes don't seem to have any side effects on real hardware. At least
none that have been observed so far. But they will trip qemu to trigger a
trap for an undefined access.

Modify the conditionals that currently exist in the driver to be used when
compiling for any ColdFire architecture (not just the M5272).

Signed-off-by: Greg Ungerer g...@uclinux.org
---
 drivers/net/ethernet/freescale/fec_main.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 4f87dff..b9045bb 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -832,7 +832,9 @@ fec_restart(struct net_device *ndev)
 	const struct platform_device_id *id_entry =
 platform_get_device_id(fep-pdev);
 	int i;
+#if !defined(CONFIG_COLDFIRE)
 	u32 val;
+#endif
 	u32 temp_mac[2];
 	u32 rcntl = OPT_FRAME_SIZE | 0x04;
 	u32 ecntl = 0x2; /* ETHEREN */
@@ -889,7 +891,7 @@ fec_restart(struct net_device *ndev)
 	/* Set MII speed */
 	writel(fep-phy_speed, fep-hwp + FEC_MII_SPEED);
 
-#if !defined(CONFIG_M5272)
+#if !defined(CONFIG_COLDFIRE)
 	/* set RX checksum */
 	val = readl(fep-hwp + FEC_RACC);
 	if (fep-csum_flags  FLAG_RX_CSUM_ENABLED)
@@ -950,7 +952,7 @@ fec_restart(struct net_device *ndev)
 #endif
 	}
 
-#if !defined(CONFIG_M5272)
+#if !defined(CONFIG_COLDFIRE)
 	/* enable pause frame*/
 	if ((fep-pause_flag  FEC_PAUSE_FLAG_ENABLE) ||
 	((fep-pause_flag  FEC_PAUSE_FLAG_AUTONEG) 
@@ -968,7 +970,7 @@ fec_restart(struct net_device *ndev)
 	} else {
 		rcntl = ~FEC_ENET_FCE;
 	}
-#endif /* !defined(CONFIG_M5272) */
+#endif /* !defined(CONFIG_COLDFIRE) */
 
 	writel(rcntl, fep-hwp + FEC_R_CNTRL);
 
@@ -1689,7 +1691,7 @@ static int fec_enet_mii_probe(struct net_device *ndev)
 	if (id_entry-driver_data  FEC_QUIRK_HAS_GBIT) {
 		phy_dev-supported = PHY_GBIT_FEATURES;
 		phy_dev-supported = ~SUPPORTED_1000baseT_Half;
-#if !defined(CONFIG_M5272)
+#if !defined(CONFIG_COLDFIRE)
 		phy_dev-supported |= SUPPORTED_Pause;
 #endif
 	}
@@ -1884,7 +1886,7 @@ static int fec_enet_get_ts_info(struct net_device *ndev,
 	}
 }
 
-#if !defined(CONFIG_M5272)
+#if !defined(CONFIG_COLDFIRE)
 
 static void fec_enet_get_pauseparam(struct net_device *ndev,
 struct ethtool_pauseparam *pause)
@@ -2039,7 +2041,7 @@ static int fec_enet_get_sset_count(struct net_device *dev, int sset)
 		return -EOPNOTSUPP;
 	}
 }
-#endif /* !defined(CONFIG_M5272) */
+#endif /* !defined(CONFIG_COLDFIRE) */
 
 static int fec_enet_nway_reset(struct net_device *dev)
 {
@@ -2058,7 +2060,7 @@

Re: [uClinux-dev] qemu/m68k

2014-08-16 Thread Greg Ungerer

Hi Waldemar,

On 16/08/14 04:12, Waldemar Brodkorb wrote:

Hi Greg,
Greg Ungerer wrote,

Hi Waldemar,

On 15/08/14 00:18, Waldemar Brodkorb wrote:

Hi uClinux hackers,

I am trying to build a Linux System for Qemu/m68k to do runtime
testing of a uClibc spin-off called uClibc-ng.
(http://www.uclibc-ng.org)

I am really a newbie regarding MMU-less Linux systems, so don't be
to critical ;)

I don't know what happened to the CVS there. Not sure if it will
be coming back.

May be yu could remove the dead links? Do you have access to the
webserver? Or you could setup a git repository for it?
I can help with it, if you need admin or technical information about
it.

Apparently the hard disk failed in the cvs.uclinux.org server. It will
be coming back, I don't have an ETA for that though.

There is some talk of putting up a git tree for it. Will keep this list
posted on progress towards that.

Anyway, I can give you a starting point that works for me. I have
used the tools I generated at:

http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20101118/m68k-uclinux-tools-20101118.sh

for a couple of years now. They generate working systems that
run on real hardware and also under qemu. The source for generating
those tools is there in that same directory:

http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20101118/

I only use it for building Coldfire targets.

That is building the uclinux-dist:

http://www.uclinux.org/pub/uClinux/dist/

That is a 3.10 kernel, but you can take any linus kernel and use
that with the same result. The uClibc in there may have some changes
over a stock 0.9.33.

A good place to start debugging these types of user space problems
is with the kernel trace option of flat files. So use the flthdr tool
to enable the kernel trace flag (-k) on the generated flat files,
then build you rootfs with those. Then at least you can see where
you app is in RAM.

Yeah, thanks a lot. Kernel trace helped. I got further booting up
the system. I am not really sure, what my problem was, but now I get
to the first shell (busybox hush). I think my elf2flt setup was
br0ken or -msep-data in CFLAGS fixed it.
My bootlog with a strace output of hush:
http://openadk.org/coldfire.txt

Do you have a suggestion why I get a segfault after first executed
command? Similar behaviour Thomas Petazzoni have seen, while he was
trying to run buildroot in Qemu/m68k. See here:
http://lists.busybox.net/pipermail/buildroot/2012-April/052585.html

No, I haven't seen that behavior. Is it a hush problem?
Maybe try a simpler shell to see if you get the same result.

BTW: I compiled uClinux, but the result does not start in Qemu.
I used CONFIG_DEFAULTS_FREESCALE_M5208EVB to configure it.
Is there a reason you use -m5307 for gcc, instead of -m5208?

Historical I would think. The original code was developed before
gcc had a -m5208 option. Probably never been updated.

Without the kernel patch from Thomas you get no output.
Without the Qemu patch from Thomas you get:
qemu-system-m68k -nographic -kernel image.elf
qemu: hardware error: mcf_intc_write: Bad write offset 28

With kernel and qemu patch I get:
Linux version 3.10.0-uc0 (wbx@kop-brodkorbw) (gcc version 4.5.1 (GCC) ) #3 Fri
Aug 15 19:52:04 CEST 2014
uClinux/COLDFIRE(m520x)
COLDFIRE port done by Greg Ungerer, g...@snapgear.com
...
qemu: hardware error: mcf_fec_read: Bad address 0x1c4

Hmmm, yeah, it does stop there. Not sure why. I will need to look
more closely at that.

Disabling FEC ethernet driver gets me too:
uclinux[mtd]: probe address=0x401e91b8 size=0x0
uclinux[mtd]: set ROMfs to be root filesystem
Creating 1 MTD partitions on ram:
0x-0x : ROMfs
mtd: partition ROMfs is out of reach -- disabled
TCP: cubic registered
NET: Registered protocol family 17
end_request: I/O error, dev mtdblock0, sector 2
EXT2-fs (mtdblock0): error: unable to read superblock
VFS: Cannot open root device (null) or unknown-block(31,0): error
-5
Please append a correct root= boot option; here are the available
partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,0)

Which version of Qemu are you using to bootup uClinux?

I am using a 1.2.50 modified with the patches I link to at:

http://marc.info/?l=uclinux-devm=134881405711207w=2

I sent those to the qemu devel list, I don't know if they ever got merged.

The next problem is due to the way images are put together by
default for ColdFire dev board targets. The romfs appended to the
kernel doesn't load by default on qemu.

The solution I use for this (to not have to modify the build) is to start
up qemu halted for the target:

qemu-system-m68k -s -S -nographic -machine mcf5208evb -kernel
images/image.elf

And then connect with a m68k-linux-gdb then do:

target remote localhost:1234
load images/image.elf
file linux-3.x/vmlinux

The resuming the target (c) starts up the image and it will have the
romfs in memory.

You can modify the kernel config and

Re: [uClinux-dev] qemu/m68k

2014-08-15 Thread Waldemar Brodkorb

Hi Greg,
Greg Ungerer wrote,

Hi Waldemar,

On 15/08/14 00:18, Waldemar Brodkorb wrote:
Hi uClinux hackers,