OpenWrt Forum Archive

Topic: Questions about CFE

The content of this topic has been archived on 6 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi,

Can anyone explain something about CFE? I honestly think I've tried all the docs and done a lot of googling!

There seem to be two radically different implementations of CFE out there.

According to which platform, supported commands in CFE seem to vary drastically between a few one or two letter commands and a much more complete set with comands such as nvram, setenv and a way of passing parameters (such as root=) to the kernel.

It seems that bcm47xxs tend to have the complete set and bcm63xx the limited one.

Mine only has the f/h option to speciffy flassh or tftp source and it only allows you to specify a single file to tftp or run.

1) Is there a "backdoor" to gain the extended commands?
2) Is there a *reliable* way to build and install a new CFE (eg using the toolkit on the Broadcom site) - I have serial but no JTAG.
3) What I'm trying to achieve is mounting a usb device on root. So far I've explored various options, but the assumption that you *will* have a squashfs root on device node 31:0 is built right into the bcm specific stuff in linux/arch/mips.

Thanks in advance and Happy 2011.

bbigg wrote:

2) Is there a *reliable* way to build and install a new CFE (eg using the toolkit on the Broadcom site) - I have serial but no JTAG.

I wouldn't mess with CFE without JTAG. On the other hand, you almost always have JTAG. What's your hardware?

bbigg wrote:

3) What I'm trying to achieve is mounting a usb device on root. So far I've explored various options, but the assumption that you *will* have a squashfs root on device node 31:0 is built right into the bcm specific stuff in linux/arch/mips.

Why don't you change it there?

Hi bbigg,

I think you may be misinterpreting what CFE is.  It's the boot code that gets things started, has a few features, can be affected by nvram contents, can initialize nvram but is hardly ever changed and never a part of standard firmware images.  The CFE starts firmware - but not as a part of it.  Firmware images reside in their own place in flash memory, as does nvram.  CFE typically remains untouched.

All this, AFAIK, is a Broadcom structure adopted by many manufacturers.

Hope this helps,
Bill

Thanks for your answers

jal2

> you almost always have JTAG. What's your hardware?

Hardware is Actiontec Q1000 and yes, I do in all likelihood. Right next to the serial there's 2 lines of 6 solder pads. What I mean is that, if possible, I don't want to have to solder pins on and acquire JTAG interfacing hardware.
> Why don't you change it there?

Actually I just figured out a way by building busybox with pivot root and hacking the build kit template rcS file to remount root. Will share it when I figure out somewhere appropriate to put it/


Bill_MI

Doesn't this suggest that CFE, although it's role is only as a boot monitor/loader, *is* getting built into the images I build. See the following output from the build script:

        /opt/bcm963xx_router/hostTools/bcmImageBuilder --output bcm96368G1_cfe_fs_kernel --chip 6368 --board "96368VVW" --blocksize 64 --cfefile /opt/bcm963xx_router/targets/cfe/cfe6368.bin --roo
tfsfile rootfs.img --kernelfile vmlinux.lz --include-cfe; \

as well as:

createimg: Creating image with the following inputs:
        Board id                : 96368VVW
        Number of Mac Addresses : 11
        Base Mac Address:       : 02:10:18:01:00:01
        Main Thread Number:     : 0
        PSI Size:               : 24
        Input File Name         : bcm96368G1_cfe_fs_kernel
        Output File Name        : bcm96368G1_flash_image_96368VVW

        Image components offsets
        cfe offset              : 0xbfc00000    -- Length: 56856
        file tag offset         : 0xbfc10000    -- Length: 256
        rootfs offset           : 0xbfc10100    -- Length: 4141056
        kernel offset           : 0xc0003100    -- Length: 988308

What I was getting at is the way that. once you stop the bootloader, although you might get an identical CFE prompt, the command set you have seems to vary so drastically.

Interesting.  I'd like to hear what's going on with the Actiontec - is that some kind of extension of CFE?  My older stuff (Linksys) had a CFE taking up most of a 256k block and it doesn't behave much like a BIOS, which is what it sounds like you have there.

Two more interesting references about CFE and its (apparent) limitations on 963xx:
http://skaya.enix.org/wiki/CfeKernel

also http://www.neufbox4.org/wiki/index.php? … NB4-FXC-r1

has a discussion which points at:

shared/opensource/include/bcm963xx/bcm_hwdefs.h

which is off the root of the bcm963xx source trees.

Looking further through this directory, there's this rather worrying comment (for 6368 development) in 6368_map_part.h

/* TBD.  Taken from 6358_map.h.  Need to verify for BCM6368. */
typedef struct SpiControl {
maybe explaining Scratch pad errors I get.

Anyway, back to CFE: It appears that it is what it is, there's no way of extending the command set and I've been reasonably successful using pivotroot
and external usb. My problem now seems to be the amount of pre compiled binaries making up a large part of the system (smd, ssk, sshd, telnetd, etc). Even sshd comes with a source tree but no config.log to indicate how it was built! Is this a possible GPL violation? (probably time for an new thread)

Thanks for your contributions anyway.

bbigg wrote:

Doesn't this suggest that CFE, although its role is only as a boot monitor/loader, *is* getting built into the images I build. See the following output from the build script:

/opt/bcm963xx_router/hostTools/bcmImageBuilder \
--output bcm96368G1_cfe_fs_kernel \
--chip 6368 --board "96368VVW" --blocksize 64 \
--cfefile /opt/bcm963xx_router/targets/cfe/cfe6368.bin \
--rootfsfile rootfs.img \
--kernelfile vmlinux.lz \
--include-cfe

as well as:

createimg: Creating image with the following inputs:
        Board id                : 96368VVW
        Number of Mac Addresses : 11
        Base Mac Address:       : 02:10:18:01:00:01
        Main Thread Number:     : 0
        PSI Size:               : 24
        Input File Name         : bcm96368G1_cfe_fs_kernel
        Output File Name        : bcm96368G1_flash_image_96368VVW

        Image components offsets
        cfe offset              : 0xbfc00000    -- Length: 56856
        file tag offset         : 0xbfc10000    -- Length: 256
        rootfs offset           : 0xbfc10100    -- Length: 4141056
        kernel offset           : 0xc0003100    -- Length: 988308

I disassembled bcmImageBuilder to discover why it requires a --cfefile. The contents of the CFE are irrelevant to bcmImageBuilder. However, the file size of the CFE is used in the calculation of the offsets of the rootfs and the kernel images.

For example, if the CFE is found to be 58200 bytes and the flash IC uses an erase block size of 65536 bytes, then the tag header will start at $FLASH_BASE+0x10000, and the rootfs will start at $FLASH_BASE+0x10100, and the kernel will follow the end of the rootfs.

The CFE isn't always under 65536 bytes.   For example, the CFE bootloader image in the bloaty firmware of the Zyxel P-2812HNU-51c, takes up nearly two 64KB flash blocks.[1]

The bcmImageBuilder tool requires a copy of the CFE bootloader to establish its file size, and to make those calculations of the rootfs and the kernel image offsets. The open source alternatives to the bcmImageBuilder tool typically allow the firmware hacker to specify his own offsets, but that increases the likelihood of errors.

Incidentally, using imagetag as a base, I developed a 100% compatible open source alternative to bcmImageBuilder. [2] It has identical command-line options to bcmImageBuilder (bIM), support for little-endian images, and it correctly calculates the image CRC where the image contains the CFE as well as the rootfs and kernel images. In coding that tool, I discovered a few oddities about bIM. For example, it's possible to use the tool to create a Broadcom flash image that contains ONLY the CFE bootloader.

cheers,
asbokid

[1] http://www.jstic.com/Newsgroup/Zyxel/P- … _infos.txt
[2] https://docs.google.com/leaf?id=0B6wW18 … p;hl=en_US

(Last edited by asbokid on 23 Jul 2011, 04:40)

Hello guys,

thanks for the info shared in this post, but I couldn't get any "CFE>" pronpt from my P-2812HNU-51c once powered up and boot stopped. I use Zyxel TTL-serial adpter cable and have the serial port set-up as 115200-None-1-None. I have no cause of framing error (I changed the TTL adapter/converter, the USP-Serial adapter and the serial cable)
I had it frozen few months ago when I upgraded it.
The power led goes RED and some rubbish prints on the screen and then nothing, something like this:

Ÿ™‹y“‹s‹ŸŸëå*DÒ¶¿{!=79!%¿{ye=7“¿Ÿ›£¿Q-5'5¿y!#!''5¿•£Ÿ£•£Ÿ£95—£—Ÿ›£ëå71=‹¿)5Y
[51-5w
-#1q=o=#7'5‹¿'Ÿ¿51-557¿ëåWõõ»m-5‹¿wY_¿-#-¿;ëå]¤Ójº‹¿5#7!-#A-#-¿5#
ëå*]¤Ójº‹¿5#7!-#A-#-¿yae_guWuwëå*ôŸ›=1‹¿Ÿ›=1A-#-¿5#
ëågcey=IOK¤Ú‹ªº-7¿…¿åë¯e-¿u#5¿;!m#-¿åë;!W-%5m#-åëu#5¿;!}m#-¿åëu-¿;!}m#-¿åë{aY‹¿u-¿;!m#-¿åë}[51-5Y-1#='§¿%%¿-7¿…¿›ŸåëF£Ñԍ-££££5¿…¿Ÿåëu#5¿W=)y5=5¿åëW=)y5=5¿¥¿=#¿#5¿=)¿åëu-

I wonder what went wrong with it.

Thanks for any fix or workaround you can suggest

The discussion might have continued from here.