Announcement

Collapse
No announcement yet.

dBug kcl parameter not used in -svn708

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • dBug kcl parameter not used in -svn708

    Hi,

    I have several XPort Pros, some are revision A11, some are revision B11. With the B11's, if I use the dBug command 'dn' to download a Linux image from a tftp server, then use the 'go' command to execute it, the kcl parameter is not used and defaults to rootfstype=romfs. The A11's work fine.

    Here is what is printed out from a B11 XPort Pro:

    External Reset

    ColdFire MCF5208 on the XPort Pro
    Firmware v4d.1a.1E-svn708 (Built on Apr 19 2010 14:21:37)
    Copyright 2006 Freescale Semiconductor, Inc.
    Lantronix Inc. 2007-2010
    Enter 'help' for help.

    Accepting FW upgrades
    Press any key to stop autoboot
    dBUG> show
    watchdog: off
    silentboot: off
    romfs_flash: off
    bootbank: Single
    safebank: 0
    netcon: on
    tftpsrv: on
    base: 16
    baud: 115200
    autoboot: Autoboot from flash
    server: 10.10.10.1
    client: 10.10.10.8
    gateway: 0.0.0.0
    netmask: 255.255.0.0
    filename: /tftpboot/linux.bin
    filetype: Image
    ethaddr: 00:20:4AE:46:6D
    dns: 0.0.0.0
    bootfc: 0
    maxbootfc: off
    kcl: root=/dev/nfs ip=dhcp nfsroot=10.10.10.1:/opt/lantronix/xport_sdk/shared
    dBUG> dn
    Downloading Image '/tftpboot/linux.bin' from 10.10.10.1
    Unable to locate 10.10.10.1
    TFTP transfer completed
    Read 1847424 bytes (3609 blocks)
    dBUG> go
    Shutting down IO
    [ 0.000000] Linux version 2.6.26-uc0-AR-496 ([email protected]) (gcc version 4.3.2 (Sourcery G++ Lite 4.3-45) ) #8 Wed Jul 27 18:01:38 EST 2011
    [ 0.000000] mcf_cp_init: Num CPs Configured = 3
    [ 0.000000] mcf_cp_int: CP1 BaseReg = 6 Mask = 0x00000004
    [ 0.000000] cpgpio:dir_input CP1 base=6 mask=0x04
    [ 0.000000] cpsetmode:CP1 base=6 mask=0x04 gpio=0x62 bit=0x2
    [ 0.000000] mcf_cp_int: CP2 BaseReg = 5 Mask = 0x00000002
    [ 0.000000] cpgpio:dir_input CP2 base=5 mask=0x02
    [ 0.000000] cpsetmode:CP2 base=5 mask=0x02 gpio=0x51 bit=0x1
    [ 0.000000] mcf_cp_int: CP3 BaseReg = 6 Mask = 0x00000008
    [ 0.000000] cpgpio:dir_input CP3 base=6 mask=0x08
    [ 0.000000] cpsetmode:CP3 base=6 mask=0x08 gpio=0x63 bit=0x3
    [ 0.000000]
    [ 0.000000]
    [ 0.000000] uClinux/COLDFIRE(m520x)
    [ 0.000000] COLDFIRE port done by Greg Ungerer, [email protected]
    [ 0.000000] Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
    [ 0.000000] XPort Pro and MatchPort AR support by Lantronix, Inc.
    [42949372.960000] Built 1 zonelists in Zone order, mobility grouping off. Total pages: 2032
    [42949372.960000] Kernel command line: rootfstype=romfs

    Note that in dBug, kcl is set to enable a rootfs over NFS. However, the last line of output shows that the wrong kernel command line is being passed to Linux.

    I believe this is a bug in this version of dBug, as a previous version with the '-svn408' suffix works fine.

    Is there source available for dBug or can I get the -svn408 version? How do I update dBug on the XPort Pro?

  • #2
    Hi I know it's been a couple of years since you posted this, but did you ever get this resolved?
    I'm seeing the exact same behavior and I don't know what's wrong.

    Thanks
    Matt S.

    Comment


    • #3
      Originally posted by mschuckmann View Post
      Hi I know it's been a couple of years since you posted this, but did you ever get this resolved?
      I'm seeing the exact same behavior and I don't know what's wrong.

      Thanks
      Matt S.
      FYI I figured this one out, it's a bug in how dBUG writes it's parameters and the way the the kernel command line (kcl) is read by config_BSP() in arch/m68knommu/platform/520x/config.c and m520x_get_dBugConfig() in linux-2.6.x/drivers/mtd/maps/m520x.c

      Basically it looks like there is a large block of flash starting at 0x60000 (I think it's called LTXdBUG1) that is devoted to storing a history of the dBUG parameters, m520x_get_dBugConfig() looks at mymtd->size to decide if this block is 64KB or 128KB (128KB seems to be for the XPortPro 16MB version based on the fact that it decides based on if mymtd->size == 0x1000000). Anyway it then searches this block for the latest set of parameters. The problem is config_BSP() gets called before mymtd is initialized by m520x_probe() so mymtd->size is junk when the device is trying to read kcl and the way the check for the size is done if mymtd->size is not 0x1000000 then it assumes it can only search the smaller 64KB block.

      Presumably dBUG (I don't know for sure because I don't have it's code) each time a parameter is changed writes a new config structure in the next location in this block all the way up to 128KB (hopefully it correctly erases this block when it has to wrap around?) Anyway the problem comes when dBug starts writing past that first 64KB, the kernel code will likely never see any config structure written beyond 64KB because at the point it reads the kcl it thinks the block is only 64KB and you'll see that any change made to kcl will have no effect on what the kernel sees.

      It is worth noting that subsequent calls to m520x_get_dBugConfig() after m520x_probe() has been called do work correctly but by then it's to late because kcl has already been read from the wrong place.

      I'm not sure what the correct fix to the kernel code is, I'll leave that up to Lantronix, but I have found a workaround, just follow the instructions to re-install dBUG using the DeviceInstaller and check the box to erase all the Flash so that you are sure to wipe out the LTXdBUG1 section and then dBUG will start writing config structures in the first 64KB block again and the kernel will see your changes to kcl (at least until it gets to that 64KB block which I think is around 100 writes). You maybe able to wipe out this block via an erase command from dBUG but I haven't tried that yet.

      I hope this helps somebody else out and they don't waste a couple of days like I did.

      Matt S.

      Comment


      • #4
        Hi,

        As per your above configuration, currently the device is having dBUG version R708 and linux SDK version 1.6.0.0 am I correct?

        can you try same in latest Linux SDK version > 2.0.0.0 while device running with dBUG version as R708.

        You can get latest SDK's under Linux SDK/New Releases
        http://forums.lantronix.com/forumdisplay.php?f=20

        Regards,
        Pradeep

        Comment


        • #5
          No I am running Linux SDK version 2.0.0.3 and dBUG version R708.
          I believe that the bug is very repeatable, you just need to change any of the dBUG parameters enough times.

          Matt S.

          Comment


          • #6
            Hi Matt,

            I tried to reproduce the issue by using dBUG R708 and linux sdk 2.0.0.3, I observer that once we change dBUG parameters enough times which means once it reaches 0x80000 location, it will erase entire mtd block and write from beginning. Below is my configuration and log message of kernel bootup.

            Software Reset

            ColdFire MCF5208 on the XPort Pro
            Firmware v4d.1a.1E-svn708 (Built on Apr 19 2010 14:21:37)
            Copyright 2006 Freescale Semiconductor, Inc.
            Lantronix Inc. 2007-2010
            Enter 'help' for help.

            Accepting FW upgrades
            dBUG> show
            watchdog: off
            silentboot: off
            romfs_flash: off
            bootbank: Single
            safebank: 0
            netcon: on
            tftpsrv: on
            base: 16
            baud: 115200
            autoboot: Stop at prompt
            server: 192.168.1.87
            client: 192.168.1.119
            gateway: 0.0.0.0
            netmask: 255.255.0.0
            filename: linux.bin
            filetype: Image
            ethaddr: 00:80:A3:91:6B6
            dns: 0.0.0.0
            bootfc: 1
            maxbootfc: 10
            kcl: root=/dev/nfs ip=dhcp nfsroot=10.10.10.1:/opt/lantronix/xport_sdk/shared
            dBUG> dn
            Downloading Image 'linux.bin' from 192.168.1.87
            TFTP transfer completed
            Read 1605760 bytes (3137 blocks)
            dBUG> go
            Shutting down IO
            Linux version 2.6.30.4-uc0-AR-804 ([email protected]) (gcc version 4.4.1 (Sourcery G++ Lite 4.4-53) ) #1 Tue Dec 20 01:00:38 PST 2011


            uClinux/COLDFIRE(m520x)
            COLDFIRE port done by Greg Ungerer, [email protected]
            Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
            XPort Pro and MatchPort AR support by Lantronix, Inc.
            Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064
            Kernel command line: root=/dev/nfs ip=dhcp nfsroot=10.10.10.1:/opt/lantronix/xport_sdk/shared
            NR_IRQS:256
            PID hash table entries: 64 (order: 6, 256 bytes)
            Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)


            If we observer my above log if we are running linux sdk 2.0.0.3 we will get message like "Linux version 2.6.30.4-uc0-AR-804" , but we I observe your log i am observing like "Linux version 2.6.26-uc0-AR-496" which means linux sdk 1.6.0.0.

            So, Can you please send latest log with linux sdk 2.0.0. 3 where we can observe as Linux version 2.6.30.4-uc0-AR-804"


            Regards,
            Pradeep

            Comment


            • #7
              Hi Pradeep

              I see your confusion, I was not the original poster for this thread, that was "elesueur" over 3 years ago and he was the one that posted a log showing the older version of the SDK. No one ever responded to the original post until I had a similar problem and I asked for help and again no one responded to me until figured out my own solution.

              So I can assure you that I am using linuxsdk version, 2.0.0.3 a boot log is posted below.

              As for what you discovered that is good news to hear that dBug will erase the entire MTD block when it is filled up but that is not the problem that I and the original poster reported. The problem is that at some point the kernel does not see changes to the kcl parameter made in dBUG, did you attempt to reproduce that problem? Did you look at the specific code that I pointed out in my solution post? Specifically at the order in which config_BSP() and m520x_probe() is called.

              Matt S.

              Here is boot log from my device:
              External Reset

              ColdFire MCF5208 on the XPort Pro
              Firmware v4d.1a.1E-svn708 (Built on Apr 19 2010 14:21:37)
              Copyright 2006 Freescale Semiconductor, Inc.
              Lantronix Inc. 2007-2010
              Enter 'help' for help.

              Accepting FW upgrades
              Press any key to stop autoboot
              Compressed image found. Uncompressing...
              Shutting down IO
              Linux version 2.6.30.4-uc0-AR-804 ([email protected]) (gcc version 4.4.1 (Sourcery G++ 3


              uClinux/COLDFIRE(m520x)
              COLDFIRE port done by Greg Ungerer, [email protected]
              Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
              XPort Pro and MatchPort AR support by Lantronix, Inc.
              Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064
              Kernel command line: rootfstype=romfs
              NR_IRQS:256
              PID hash table entries: 64 (order: 6, 256 bytes)
              Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
              Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
              Memory available: 11560k/16384k RAM, (1685k kernel code, 208k data)
              Calibrating delay loop... 109.36 BogoMIPS (lpj=546816)
              Mount-cache hash table entries: 512
              net_namespace: 492 bytes
              NET: Registered protocol family 16
              bio: create slab <bio-0> at 0
              NET: Registered protocol family 2
              IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
              TCP established hash table entries: 512 (order: 0, 4096 bytes)
              TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
              TCP: Hash tables configured (established 512 bind 1024)
              TCP reno registered
              NET: Registered protocol family 1
              Lantronix CPM Device Driver version 3.0
              JFFS2 version 2.2. (NAND) �? 2001-2006 Red Hat, Inc.
              ROMFS MTD (C) 2007 Red Hat, Inc.
              io scheduler noop registered
              io scheduler anticipatory registered
              io scheduler deadline registered
              io scheduler cfq registered (default)
              ColdFire internal UART serial driver
              ttyS0 at MMIO 0xfc060000 (irq = 90) is a ColdFire UART
              console [ttyS0] enabled
              FEC Ethernet Driver
              fec: PHY @ 0x0, ID 0x0143bc31 -- BCM5241
              eth0 (fec): not using net_device_ops yet
              Expected flash size: 16777216
              m520xevb flash probe(0x0,1000000,2): 1000000 at 0
              mpt: Found 1 x16 devices at 0x0 in 16-bit bank
              Amd/Fujitsu Extended Query Table at 0x0040
              mpt: CFI does not contain boot bank location. Assuming top.
              number of CFI chips: 1
              cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
              Found 0 partitions on the command line.
              Creating 5 MTD partitions on "mpt":
              0x000000000000-0x000000020000 : "LTRXbloader"
              0x000000020000-0x000000040000 : "LTRXconfig"
              0x000000040000-0x000000060000 : "dBug"
              0x000000060000-0x000000080000 : "dBugConfig"
              0x000000080000-0x000000400000 : "Kernel"
              Creating 4 MTD partitions on "mpt":
              0x000000400000-0x000000800000 : "UserSpace"
              0x000000080000-0x000000800000 : "WritableFlash"
              0x000000880000-0x000001000000 : "UserExtra"
              0x000000860000-0x000000880000 : "dBugConfBackup"
              m520xevb ram probe(0x401f9500,296000,4): 296000 at 401f9500
              Creating 1 MTD partitions on "RAM":
              0x000000000000-0x000000296000 : "Romfs"
              m520x_wdt: WDT driver for M520x initialized. timeout=30 sec (nowayout=0)
              TCP cubic registered
              NET: Registered protocol family 10
              IPv6 over IPv4 tunneling driver
              NET: Registered protocol family 17
              RPC: Registered udp transport module.
              RPC: Registered tcp transport module.
              VFS: Mounted root (romfs filesystem) readonly on device 31:9.
              Freeing unused kernel memory: 56k freed (0x401da000 - 0x401e7000)
              init started: BusyBox v1.13.3 (2013-12-23 09:16:13 PST)
              starting pid 17, tty '': '/etc/init.d/rcS'

              Comment


              • #8
                Hi Matt,

                I am able to reproduce this issue only when XPort Pro configured with dBUG R708 and Linux SDK 1.6.0.0 combination only.

                Even the customer log says same. But as per your information, your are able to reproduce in Linux SDK 2.0.0.3.

                Can you please conform once again that you reproduce this issue with dBUG R708 and Linux SDK 2.0.0.3 combination?


                Regards,
                Pradeep

                Comment


                • #9
                  Hi Pradeep,

                  I verified that I can repeat this bug with Linux SDK 2.0.0.3 and dBUG R708 and it's just as I described previously.

                  To help you reproduce here are the steps I took.

                  1. Use the DeviceInstaller application to completely erase the flash and install dBUG R708.
                  2. To make it easy to see where in the configuration block data is being written I modified the kernel to report where it found the dbugConfig block, to do this simply un-comment the kprint() statement on line 192 of linux/linux-2.6.x/drivers/mtd/maps/m520x.c.
                  3. Build the SDK and install it the image on the device.
                  4. Configure dBUG to not autoboot "dBUG> set autoboot none. Leave the device at the dBUG prompt.
                  5. Run the script below to interatively change the kcl parameter, boot to linux, reboot and repeat. All output from the device is written to a file output.txt. The script is setup to change the kcl parameter 120 times to quickly move the configuration block close to the point where the problem occurs (i.e. at offset 0x70000) Then it continues to change the kcl parameter another 20 times with reboots between each change so that you can see when the problem occurs at offset 0x70000 or configuration block change 128.
                  6. In a separate terminal window I monitored output.txt for changes to the kernel command line and the dBugConfig block in use with the command:
                  tail -f output.txt | egrep "Kernel command|m520x_get_dBugConfig|kcl:"

                  Around about the 127th change to kcl (depending on how many times you change the dBUG configuration block before starting the script) you will see the that the kernel command line string as reported by the kernel during boot (i.e. the line "Kernel command line: rootfstype=romfs foo=127") will stop changing. You will also notice that each time the kernel is booted the m520x_get_dBugConfig line is printed 3 times, once before the kernel command line is reported and two more times before the boot is completed. Starting around about the 127 iteration of my script the first print for m520x_get_dBugConfig will start to always report the configuration block to be at offset 0x6fe00 (i.e the line m520x_get_dBugConfig: 0x6fe00 / 0x60000 (127)" however the other reports (that occur after the kernel reports the command line) will continue to change and increment up beyond an offset of 0x70000.

                  Here is some output from running the script and monitoring output.txt as I've described.
                  kcl: rootfstype=romfs foo=117
                  kcl: rootfstype=romfs foo=118
                  kcl: rootfstype=romfs foo=119
                  kcl: rootfstype=romfs foo=120
                  kcl: rootfstype=romfs foo=121
                  m520x_get_dBugConfig: 0x6f200 / 0x60000 (121)
                  Kernel command line: rootfstype=romfs foo=121
                  m520x_get_dBugConfig: 0x6f200 / 0x60000 (121)
                  m520x_get_dBugConfig: 0x6f200 / 0x60000 (121)
                  kcl: rootfstype=romfs foo=122
                  m520x_get_dBugConfig: 0x6f400 / 0x60000 (122)
                  Kernel command line: rootfstype=romfs foo=122
                  m520x_get_dBugConfig: 0x6f400 / 0x60000 (122)
                  m520x_get_dBugConfig: 0x6f400 / 0x60000 (122)
                  kcl: rootfstype=romfs foo=123
                  m520x_get_dBugConfig: 0x6f600 / 0x60000 (123)
                  Kernel command line: rootfstype=romfs foo=123
                  m520x_get_dBugConfig: 0x6f600 / 0x60000 (123)
                  m520x_get_dBugConfig: 0x6f600 / 0x60000 (123)
                  kcl: rootfstype=romfs foo=124
                  m520x_get_dBugConfig: 0x6f800 / 0x60000 (124)
                  Kernel command line: rootfstype=romfs foo=124
                  m520x_get_dBugConfig: 0x6f800 / 0x60000 (124)
                  m520x_get_dBugConfig: 0x6f800 / 0x60000 (124)
                  kcl: rootfstype=romfs foo=125
                  m520x_get_dBugConfig: 0x6fa00 / 0x60000 (125)
                  Kernel command line: rootfstype=romfs foo=125
                  m520x_get_dBugConfig: 0x6fa00 / 0x60000 (125)
                  m520x_get_dBugConfig: 0x6fa00 / 0x60000 (125)
                  kcl: rootfstype=romfs foo=126
                  m520x_get_dBugConfig: 0x6fc00 / 0x60000 (126)
                  Kernel command line: rootfstype=romfs foo=126
                  m520x_get_dBugConfig: 0x6fc00 / 0x60000 (126)
                  m520x_get_dBugConfig: 0x6fc00 / 0x60000 (126)
                  kcl: rootfstype=romfs foo=127
                  m520x_get_dBugConfig: 0x6fe00 / 0x60000 (127)
                  Kernel command line: rootfstype=romfs foo=127
                  m520x_get_dBugConfig: 0x6fe00 / 0x60000 (127)
                  m520x_get_dBugConfig: 0x6fe00 / 0x60000 (127)
                  kcl: rootfstype=romfs foo=128
                  m520x_get_dBugConfig: 0x6fe00 / 0x60000 (127)
                  Kernel command line: rootfstype=romfs foo=127
                  m520x_get_dBugConfig: 0x70000 / 0x60000 (128)
                  m520x_get_dBugConfig: 0x70000 / 0x60000 (128)
                  kcl: rootfstype=romfs foo=129
                  m520x_get_dBugConfig: 0x6fe00 / 0x60000 (127)
                  Kernel command line: rootfstype=romfs foo=127
                  m520x_get_dBugConfig: 0x70200 / 0x60000 (129)
                  m520x_get_dBugConfig: 0x70200 / 0x60000 (129)
                  kcl: rootfstype=romfs foo=130
                  m520x_get_dBugConfig: 0x6fe00 / 0x60000 (127)
                  Kernel command line: rootfstype=romfs foo=127
                  m520x_get_dBugConfig: 0x70400 / 0x60000 (130)
                  m520x_get_dBugConfig: 0x70400 / 0x60000 (130)
                  kcl: rootfstype=romfs foo=131
                  m520x_get_dBugConfig: 0x6fe00 / 0x60000 (127)
                  Kernel command line: rootfstype=romfs foo=127
                  m520x_get_dBugConfig: 0x70600 / 0x60000 (131)
                  m520x_get_dBugConfig: 0x70600 / 0x60000 (131)

                  This bug is very repeatable, I've repeated it several times now with this script.


                  #!/bin/sh

                  # reboot.sh

                  # Usage:
                  # $ reboot.sh <device> <port speed>
                  # Example: connect.sh /dev/ttyUSB0 115200
                  #
                  # WARNING: if you kill this script prematurely with ctrl+c you will live an orphan
                  # cat process reading from the serial device, if you don't kill that orphan
                  # process subsiquent runs of this script will not capture the serial output
                  # properly.
                  #

                  # Set up device
                  stty -F $1 $2

                  # Let cat read the device $1 in the background
                  cat $1 > output.txt &

                  # Capture PID of background process so it is possible to terminate it when done
                  bgPid=$?

                  # Read commands from user, send them to device $1
                  #while read cmd
                  #do
                  # echo "$cmd"
                  #done > $1

                  for i in {0..120}
                  do
                  echo '************************'
                  echo "Test Run $i (just changing kcl)"
                  echo "set kcl rootfstype=romfs foo=$i" | tee $1
                  sleep 1
                  echo "show" | tee $1
                  sleep 1
                  done

                  for i in {121..150}
                  do
                  echo '************************'
                  echo "Test Run $i (rebooting)"
                  echo "set kcl rootfstype=romfs foo=$i" | tee $1
                  sleep 1
                  echo "show" | tee $1
                  sleep 1
                  echo "gfl" | tee $1
                  sleep 15
                  echo "reboot" | tee $1
                  sleep 10
                  done

                  # Terminate background read process
                  kill $bgPid

                  Comment


                  • #10
                    Hi Matt,

                    Thanks for your detailed information and script.

                    By fallowing your procedure and script, I am able to reproduce issue in Linux SDK 2.0.0.3.

                    This bug will be fixed and updates are available in next Linux SDK release.

                    Regards,
                    Pradeep

                    Comment

                    Working...
                    X