Flash map for 4MB and 8MB devices

[Jason]

What is the Flash map for the 4MB and 8MB Bifferboards?

Also,is the Bootloader physically optimised to be loaded into the
Bottom area of the flash chips (which is organised in smaller pages
than the upper areas), given the flash chip's 'B' marking?

Reason for asking, is that I'm thinking of implementing JFFS2 (or UFS)
file systems in the onboard flash for ease of access/update (using MTD
block drivers) under a custom kernel and want to ensure I'm mapping
the memory correctly, taking into account the Bifferboard bootloader.

My goal here is to retain the original BiffBoot loader as a 'rescue'
and master re-flash loader, and then have a small custom kernel I can
configure as a configurable kexec secondary boot loader to load
kernels/rootfs either from combinations of MTD, USB or MMC/SD. This
will enable one to try out various kernels without needing to re-flash
as such.

Once a config is stable I can then write the kernel and/or rootfs to a
mountable mtd partition, and update it fairly easily afterwards if
required. I'll probably configure the flash memory into five
sections - BiffBoot loader and supporting config, secondary boot
Kernel, operating Kernel and rootfs.

Regards
Jason

[bifferos]

On Aug 5, 1:49 pm, Jason <g...@solo-c.demon.co.uk> wrote:
> What is the Flash map for the 4MB and 8MB Bifferboards?

Check out this URL.
http://sites.google.com/site/bifferboard/Home/kernel-flashing-in-detail

It's the same for 4 and 8MB units, but just more sectors between
config block and bootloader.

> Also,is the Bootloader physically optimised to be loaded into the
> Bottom area of the flash chips (which is organised in smaller pages
> than the upper areas), given the flash chip's 'B' marking?

No, the bootloader cannot be bottom loaded if the board is to remain
x86 compatible. All x86 CPUs start executing at 0xfffffff0.

> Reason for asking, is that I'm thinking of implementing JFFS2 (or UFS)
> file systems in the onboard flash for ease of access/update (using MTD
> block drivers) under a custom kernel and want to ensure I'm mapping
> the memory correctly, taking into account the Bifferboard bootloader.

OK, we can tweak the bootloader layout if the current arrangement is
not satisfactory.

> My goal here is to retain the original BiffBoot loader as a 'rescue'
> and master re-flash loader, and then have a small custom kernel I can
> configure as a configurable kexec secondary boot loader to load
> kernels/rootfs either from combinations of MTD, USB or MMC/SD.    This
> will enable one to try out various kernels without needing to re-flash
> as such.

Are you aware that the latest versions of Biffboot have tftp? Anyhow,
you don't need a kernel/kexec to do this. You can use the flat binary
mode of the bootloader, and prepare yourself your own bootloader
extension to do this:

See:
http://sites.google.com/site/bifferboard/Home/howto/alternative-oses

> Once a config is stable I can then write the kernel and/or rootfs to a
> mountable mtd partition, and update it fairly easily afterwards if
> required.   I'll probably configure the flash memory into five
> sections - BiffBoot loader and supporting config, secondary boot
> Kernel, operating Kernel and rootfs.

Incidentally, if you want me to add something to Biffboot to make this
easier, I can certainly do that.

> Regards
> Jason

kind regards,
Biff.

[Jason]

Ta - I'd forgotten the X86 default to exec at a high position (mostly
use Arm and PPC devices these days), and being too reliant on the
likes of Grub on current Intel machines.

In terms of of the use of kexec style kernel based bootloaders, it's
just something I'm familiar with from playing around with OpenEmbedded/
Angstrom linux (e.g. on PDAs such as the Zaurus). I've guess I've
just got used to the flexibility this introduces in customising the
boot process - having never really got into the likes of uboot/
redboot.

In terms of the Bifferboard boot loader, UFS/JFFS2 support would be
useful with the ability to config flash partitions. However, I can
see this would be overkill in most applications, and could be seen to
waste space on a 1MB flash model.

Jason

On Aug 5, 2:40 pm, bifferos <biffe...@yahoo.co.uk> wrote:
> On Aug 5, 1:49 pm, Jason <g...@solo-c.demon.co.uk> wrote:
>
> > What is the Flash map for the 4MB and 8MB Bifferboards?
>

> Check out this URL.http://sites.google.com/site/bifferboard/Home/kernel-flashing-in-detail

[bifferos]

On Aug 5, 3:24 pm, Jason <g...@solo-c.demon.co.uk> wrote:
> In terms of the Bifferboard boot loader, UFS/JFFS2 support would be
> useful with the ability to config flash partitions.   However, I can

Presumably, we are talking about a bootloader which flashes into pre-
configured areas instead of flashing the payload always in the same
place. Then some kind of index needs to be flashed, which I presume
must be in its own sector. Next, at boot the bootloader reads the
index to find out where it'll load it's kernel + initrd from. I don't
see any reason why this shouldn't be applied even to the 1MB boards,
so long as:

a) It can be disabled with a bootloader option
b) The default configuration (config block missing) results in the old-
style of operation.

There are a few applications that would benefit from kernel loaded via
TFTP, followed by rootfs loaded from 1MB on-board flash. The kernel
could be generic for a bunch of boards

Incidentally, if the config block itself is re-organised it might
double up as both Biffboot config *and* flash map index thus wasting
no space.

cheers,
Biff.

[oPless]

On Aug 5, 2:40 pm, bifferos <biffe...@yahoo.co.uk> wrote:

> On Aug 5, 1:49 pm, Jason <g...@solo-c.demon.co.uk> wrote:
>
> > What is the Flash map for the 4MB and 8MB Bifferboards?
>

> Check out this URL.http://sites.google.com/site/bifferboard/Home/kernel-flashing-in-detail

>
> It's the same for 4 and 8MB units, but just more sectors between
> config block and bootloader.
>
> > Also,is the Bootloader physically optimised to be loaded into the
> > Bottom area of the flash chips (which is organised in smaller pages
> > than the upper areas), given the flash chip's 'B' marking?
>
> No, the bootloader cannot be bottom loaded if the board is to remain
> x86 compatible.  All x86 CPUs start executing at 0xfffffff0.
>
> > Reason for asking, is that I'm thinking of implementing JFFS2 (or UFS)
> > file systems in the onboard flash for ease of access/update (using MTD
> > block drivers) under a custom kernel and want to ensure I'm mapping
> > the memory correctly, taking into account the Bifferboard bootloader.
>
> OK, we can tweak the bootloader layout if the current arrangement is
> not satisfactory.
>
> > My goal here is to retain the original BiffBoot loader as a 'rescue'
> > and master re-flash loader, and then have a small custom kernel I can
> > configure as a configurable kexec secondary boot loader to load
> > kernels/rootfs either from combinations of MTD, USB or MMC/SD.    This
> > will enable one to try out various kernels without needing to re-flash
> > as such.
>
> Are you aware that the latest versions of Biffboot have tftp?  Anyhow,
> you don't need a kernel/kexec to do this.  You can use the flat binary
> mode of the bootloader, and prepare yourself your own bootloader
> extension to do this:
>
> See:http://sites.google.com/site/bifferboard/Home/howto/alternative-oses
>

How does one initiate tftp loading?

[Jason]

Yep - something along those lines - makes sense to re-use the config
sector for the flash memory index as well (as it is likely to be small
table). The bootloader can use this index to define the mtd parts
for the Kernel.

I was also considering the size of the bootloader itself, as this
could grow if filesystem capabilities (e.g. JFFS2 or UFS) are added.
Alternatively the bootloader could be agnostic to the content of the
flash partitions, with a requirement that the kernel be written/read
'raw' rather than implemented as a file system. Once loaded the
kernel then takes on the responsibility of processing the flash
filesystem where the rootfs is stored (i.e. kernels compiled with
JFFS2/UFS support).

This would offer the advantage of being able to simply mount the flash
rootfs as rw to update it dynamically (without the need for bootloader
reflashing), and could also be used to upgrade the kernel as well via
Linux using the mtdwrite module (and the dd command).

In theory the config sector could also be accessed if declared as a
mtd part to the kernel to make the system fully configurable under
Linux, although a front end tool for editing the config might be
desirable.

Regards
Jason

[bifferos]

On Aug 5, 5:24 pm, oPless <opl...@gmail.com> wrote:
> How does one initiate tftp loading?

It's available only from Biffboot v2.2 onwards. More info here:
http://sites.google.com/site/bifferboard/Home/biffboot-v2-2

Ignore the bit about it being experimental, it's been the default for
all boards shipped since last week.

thanks,
Biff.

[Simon Waite]

Ach .... just missed the update mine are all 2.0 :)

--
Earth. What a planet. On Earth, you enjoy eating a tasty clam. On my
planet, clams enjoy eating a tasty you.
-Dr ZoidBerg

[bifferos]

On Aug 5, 5:47 pm, Jason <g...@solo-c.demon.co.uk> wrote:
> I was also considering the size of the bootloader itself, as this
> could grow if filesystem capabilities (e.g. JFFS2 or UFS) are added.

I can pretty safely say that JFFS2 will never be added to Biffboot
unless someone releases a non-GPL version, but so long as the
locations of the various kernel parts are obtainable, then the kernel
can be booted from such a system.

> Alternatively the bootloader could be agnostic to the content of the
> flash partitions, with a requirement that the kernel be written/read
> 'raw' rather than implemented as a file system.   Once loaded the
> kernel then takes on the responsibility of processing the flash
> filesystem where the rootfs is stored (i.e. kernels compiled with
> JFFS2/UFS support).

I think this is how other RDC devices do it.

> This would offer the advantage of being able to simply mount the flash
> rootfs as rw to update it dynamically (without the need for bootloader
> reflashing),  and could also be used to upgrade the kernel as well via
> Linux using the mtdwrite module (and the dd command).

OK, sounds good.

> In theory the config sector could also be accessed if declared as a
> mtd part to the kernel to make the system fully configurable under
> Linux, although a front end tool for editing the config might be
> desirable.

Just as an aside, the config structure is only documented indirectly
here:
http://sites.google.com/site/bifferboard/Home/howto/qemu
(in add_kernel_to_loader.py)

regards,
Biff