|
| From: | Kevin Wells |
| Subject: | RE: [Ltib] Ltib - Unable to open an initial console |
| Date: | Fri, 30 Apr 2010 23:53:38 +0200 |
|
Hi Henry, There is a patch (update7) up there now that handles both
machines IDs. You might need to update your CVS tree to get the kernel spec update that downloads it. It
will add both the LPC3XXX and the PHY3250 machines IDs to the board files. thanks, Kevin From:
address@hidden [mailto:address@hidden On Behalf Of Li
Yuan-Lung Dear Kevin, Yes, I used the LPC32xx board. As your suggestion, I reviewed the deployment.txt and
enable CONFIG_DEBUG_LL option. Then I got these messages: Starting kernel ... Uncompressing
Linux.............................................................................
done, booting the kernel. Error: unrecognized/unsupported machine ID (r1 =
0x000009cf). Available machine support: ID (hex) NAME 000002e0 Phytec 3250 board
with the LPC3250 Microcontroller Please check your kernel config and/or bootloader. I decided to upgrade the machine ID to be PHY3250 After checking the source code, I found 2 steps to work
around. (1) /arch/arm/mach-lpc32xx/board-phy3250.c Change MACHINE_START
(LPC3XXX, "Phytec 3250 board with the LPC3250 Microcontroller") To MACHINE_START (PHY3250,
"Phytec 3250 board with the LPC3250 Microcontroller") (2)/include/asm-arm/mach-types.h Add #define MACH_TYPE_PHY3250
2511 Change #ifdef
CONFIG_MACH_LPC3XXX # ifdef
machine_arch_type # undef
machine_arch_type # define
machine_arch_type __machine_arch_type # else # define
machine_arch_type MACH_TYPE_LPC3XXX # endif # define
machine_is_lpc3xxx() (machine_arch_type == MACH_TYPE_LPC3XXX) #else # define
machine_is_lpc3xxx() (0) #endif To #ifdef CONFIG_MACH_LPC3XXX # ifdef
machine_arch_type # undef
machine_arch_type # define
machine_arch_type __machine_arch_type # else # define
machine_arch_type MACH_TYPE_PHY3250 # endif # define machine_is_lpc3xxx()
(machine_arch_type == MACH_TYPE_PHY3250) #else # define
machine_is_lpc3xxx() (0) #endif Am I correct? Thank you for your advising! Henry 2010/4/29 Kevin Wells <address@hidden> Hi Henry, Is this with the 31xx or 32xx board? Or
is it the a404 board? Also, is the kernel running when you
lose the console? If it's the LPC32xx…then please keep
reading. If the kernel is uncompressing and seems
to start, but there is no console output, it's possible the machine IDs used in u-boot and the kernel are
different. You can enable the CONFIG_DEBUG_LL option in the kernel and then try booting the kernel.
If the machine IDs are the issue, you'll see a message stating the difference and the kernel will stop
running. The 32x0 kernels recently changed the
machine ID from the generic 'LPC3XXX' used for all boards to PHY3250, EA3250, and FDI3250 depending
on which board you use. u-boot was also updated with this change, so depending on which board's
version of u-boot you use, you will get a corresponding 'non-LPC3XXX' machine ID passed via the
ATAG list. To allow for some backward
compatability, the LPC3XXX is also supported in the kernel here along with the new machine IDs, so older builds of
u-boot with the LPC3XXX machine ID should work fine with the new kernel builds (as long as the kernel is
built via LTIB, the 2.6.34 patches do not have this support!). Note 2.6.34 support is not in LTIB yet. Older build kernels with just the
LPC3XXX machine ID support will no longer work with the new version of u-boot. Just to clear things up, 'older' and
'newer' builds simply refer to u-boot and kernel builds before the machine ID patch and after the machine ID patch,
respectively. The patch that changes these IDs was posted about a month ago. It’s a bit messy, but it needed to be
done, I couldn't release all board variants to mainline with the same machine IDs. There should be some
information about this in the deployment.txt file, but I can understand that existing users probably wouldn't
look at this. Here are the build machine IDs:
old u-boot.bin -> LPC3XXX for Phytec, Embedded Artist, and FDI boards
new u-boot.bin -> Either PHY3250, EA3250, or FDI3250 based on the LTIB
platform selected
old uImage -> LPC3XXX for Phytec, Embedded Artist, and FDI boards
new uImage (2.6.27.8) -> LPC3XXX + one of PHY3250, EA3250, or FDI3250 based
on the LTIB platform selected
new uImage (2.6.34) -> Only one of PHY3250, EA3250, or FDI3250 Here are the working combinations
new u-boot.bin (PHY3250, EA3250, or FDI3250 machine IDs) -> Will not boot
older kernel with LPC3XXX machines IDs
new u-boot.bin (PHY3250 machine ID) -> Only boots newer kernel builds with
PHY3250 machine ID
new u-boot.bin (EA3250 machine ID) -> Only boots newer kernel builds with
EA3250 machine ID
new u-boot.bin (FDI3250 machine ID) -> Only boots newer kernel builds with
FDI3250 machine ID
old u-boot.bin (LPC3XXX machine ID, all boards) -> boots older and newer
kernel builds This will probably sting a few people in
the short term, but it needed to be done. thanks, Kevin From: henry.li@wonselor.com [mailto:address@hidden] On
Behalf Of Li Yuan-Lung
Dear
Kevin, I
have similar problem. Below is the situation: 1.
I have ltib image build in early March.(old-uImage, old-rootfs, old-uboot.bin) 2.
This week I built a new image from ltib(new-uImage, new-rootfs, new-uboot.bin) The
boot parameter is the same as below: "console=ttyS0,115200n81
root=/dev/mtdblock3 rw rootfstype=jffs2 init=/sbin/init" The
symptom is, after uboot uncompress the linux kernel, I lose my console forever.
So I take some combination test as below: (1)new-uboot.bin
(133KB)
new-uImage-->new-rootfs (X, not work)
old-uImage-->old-rootfs (X, not work)
new-uImage-->oldrootfs (X, not work)
old-uImage-->oldrootfs (X, not work) (2)old-uboot.bin
(144KB)
new-uImage-->new-rootfs (O, work!)
old-uImage-->old-rootfs (O, work!) The
"not work" condition is the same as the symptom. My
conclusion is that maybe there is some modification in u-boot source to affect
the boot parameter pass to kernel. But I haven't check that yet. Do you have
any comment? Henry 2010/4/29
Kevin Wells <address@hidden> Hi
Peter,
|
| [Prev in Thread] | Current Thread | [Next in Thread] |