Re: [f-cpu] more about f-romfs

[nico <nicolas@seul.org>]

All this kind of thing are really to simillar to the x86 !

Todays, boot rom does one thing : jump to the good piece of code. It
must be really small. When need juste something to boot from somewhere
and that's all ! 

Driver and stuff like that are in memory with the kernel.

Yann Guidon a écrit :
> 
> here are some more thoughts and contextual stuff.
> it's preliminary and moving, there's no code yet.
> 
> however i think it is a good answer to the people
> who want a "BIOS" for F-CPU. First it is impossible
> to do that on a platform where there is only a CPU
> and then i understand that in the past years, the
> PC BIOSes have increased in complexity to a point
> where it's unmanageable. Having a small boot routine
> with a romfs-like support is a cool solution.
> 
> i have to sleep now, after i read the comments that
> i just got.
> 
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
>   ------------------------------------------------------------------------
> f-romfs.txt
> created mer mar 13 03:30:43 GMT 2002 by whygee@f-cpu.org
> 
> A discussion about a "file format", the associated algorithm
> and the context of using a romfs-like system.
> 
> --------------------------------------------------------
> 
> BIOS/Monitor/extensions :
> 
> The F-CPU processor is designed to boot at address 0
> after reset. It will fetch its instructions from a
> non-volatile memory or an image of this data if the
> system is simulated in VHDL or C. The boot code will detect and
> initialize all the fundamental devices such as the memory
> controllers. For example, the refresh rate will be tuned,
> the bank size will be adjusted and the base address of the
> private memory range will be set to an unused range
> (if the system is comprised of several CPU with their own
> private address ranges, but they must not overlap).
> 
> The boot memory also contains very low-level and primitive
> routines for doing basic stuff, such as sending error
> messages (to a virtual console that is mapped somewhere
> in the CPU, probably the SR). When done, we have to

Yet an other way to get out of the cpu : beark !!! there only the
vci/wishbone/amba interface connected to the outside world nothing else
or it will be a lot of pain in the as !

> initialise a lot of other things which are independent
> from the F-CPU project and we don't have the means
> to work on the HDD controller, the keyboard driver,
> the video framebuffer... You'll understand that we don't
> want to mess with it, a single CPU is already complex enough.
> 
> We would like to let the user configure his system
> and install only the necessary drivers, or customize it with
> his driver for his prototype peripheral, etc.
> But we don't have access to a file system because
> the HDD is not yet setup ! this would bloat the code
> or make it too complex. OTOH we would like to let the
> user interact with the HW.
> 
> The solution is to use something that looks like
> romfs : we have access to user-provided data and
> code modules and we have to provide a few functions
> that allow the modules to interact in a read-only way :
>  - locate : return the physical address of the requested block
>  - open   : returns a handle to the specified block
>  - close  : close handle
>  - read   : get a word
>  - seek   : goto a specified offset in the "file"
>  - exec   : specify a file and run it
> 
> since the additional modules are meant to
> provide development or debug tools, it is useful
> to use "directories" and "symbolic links".
> This is done with the help of "flags", just like
> a normal FS. we can add other flags : executable
> (so a user won't attempt to execute raw data),
> and compressed (in case we have some room for
> the decompression tables and code, when the
> Flash will be completely filled with tux
> pictures etc...)
> 
> The Flash image will be built with a simple
>   $ cp bareboot.bin newimage.bin
>   $ cat modules.romfs >> newimage.bin
>   $ installflash newimage.bin
> (science fictious)
> 
> The bareboot.bin file is built from an assembly
> langage source containing :
>  - the startup code
>  - RAM initialisation code
>  - the minimum libraries : decompression, romfs utilities
>    and some additional stuff as needed
> 
> The modules in modules.romfs are built from
> an utility (kind of mkromfs) with a set of specified
> files which are also assembled, using symbols extracted
> from the startup/library code. The modules' code must
> be position-independently coded because when executed,
> the code (which can be decompacted) will be copied
> and aligned in private/fast memory.
> 
> When all the minimal setup is performed (RAM and IRQ,
> for example) then the boot code uses the romfs functions
> to access the romfs part of the Flash, seeking a "startup"
> binary which will then initialise the rest, using
> internal scripts or facilities that the user can customize
> at will. The file could be named "runfirst" for example.
> If no romfs is found (starting at the end
> of the boot block) or if the startup file is absent,
> the CPU sends an error code to the virtual console
> and enters an infinite loop or in shutdown state.
> 
> Granularity : F-CPU is a byte-addressing machine
> but the architecture does not like unaligned instructions
> or data access.
> * Concerning the instructions, the code
> blocks should be copied to the main memory and
> the starting address must be aligned to the 256
> bit boundary imposed by the cache lines. In fact,
> code that is optimized for F-CPU aligns loop entries
> to 32 byte boundaries and it would not be wise
> to break this. Furthermore, the Flash memory is
> a rather slow device and is likely to be uncacheable

??? Why put it uncacheable ?

> (though its contents doesn't change, but you get
> the idea...). The SDRAM memory has much more bandwidth

??? It depend on the memory (for reading not writing of course)


For me, all of the following are much too early. This is system designer
problem not ours.

nicO
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/