>
> Well they are different options. But the setup is odd.
> STD_FLASH tells ipl.S not to bootstrap from the DOC millenium. This I
> think is a little odd that we are still even using ipl.S in this case
> but it isn't a big problem.
>
> USE_GENERIC_ROM is used to specify which of the fill_inbuf routines
> you get. Normally you will want to read your kernel or whatever out
> of flash, and that flash is probably pretty straight forward when you
> don't have a DOC millenium, but it can be replaced by something that
> reads a kernel from disk or reads, or over the network
> (i.e. etherboot).
>
> So while I agree that we have a confusing setup in config options, I
> don't think we have any real bugs in there.
>
> Eric
>
Well, alright. I'm using both right now as I'm trying to get any kind of
elf image to boot from the standard 256k part on sis630s. I don't think
I'm the only one trying to get this right now, so let me try to get an
open discussion going here on what needs to be done in this case...
Please, if anyone cares to jump in, or correct me, it'd be more than
welcome. I make no claim to actually knowing what I'm doing here. The
following procedure is definitly WRONG. Please don't follow it expecting
good results.
I start with a config file like this one:
# ------------ Winfast 6300 with 256k flash & elf support config
# standard options follow, none of which in dispute..
arch i386
target ~/256kelf
mainboard leadtek/winfast6300
option SERIAL_CONSOLE
option UPDATE_MICROCODE
option CONFIGURE_L2_CACHE
#option HAVE_FRAMEBUFFER
# options that may be wrong..
#option USE_DOC_MIL
option USE_GENERIC_ROM=1 # use the correct fill_inbuf() for normal flash
# set ipl.S to skip the DoC junk. Do we still need ipl.S
# because of SiS630 peculiarities? NOTE: this makes docipl
# 64k large...?... I suppose this is due to a relaxation of
# the constraints imposed apon by the DoC (must set up DoC is 512 bytes?)
option STD_FLASH
option USE_ELF_BOOT=1 #use Eric's elf boot loader
# point to a valid elf image
makedefine BOOT_IMAGE=~/256kelf/netboot.ebi
# ln -s ~/256kelf/netboot.ebi ~/256kelf/vmlinux
linux ~/256kelf/
#----------------------------- end winfast.config
run NLBConfig on the config file, should work fine..
Then, I'll need to edit my ldscript.ld to change the _ROMBASE
< _ROMBASE = 0x80000; /* 512k */
> _ROMBASE = 0x40000; /* 256k */
Now, when I run make i'm going to end up with a docipl of size 65536 (64k)
I'll also have a linuxbios.rom of size 65536 (64k)
and a vmlinux.bin.gz.block of 458752 (448k).
Grand total: 589824 (576k)
That is of course, wrong, and the default in all the other standard prom
cases because the boards not based on sis chipsets don't require a docipl
(-64k) and support chips 256k larger than the SiS boards (-256k).
So, it's 320k too large.
I believe the correct place to trip this image down is the size of
vmlinux.bin.gz.block .
So in the Makefile
< dd conv=sync bs=448k if=vmlinux.bin.gz of=vmlinux.bin.gz.block
> dd conv=sync bs=128k if=vmlinux.bin.gz of=vmlinux.bin.gz.block
okay, now
docipl (64k)
linuxbios.block (64k)
vmlinux.bin.gz.block (128k)
Now to make a romimage..
cat docipl vmlinux.bin.gz.block linuxbios.block > romimage
vmlinux.bin.gz.block and linuxbios.block are in the opposite order of what
seems logical because we buffered out vmlinux.bin.gz.block to put
linuxbios.block in a specific place on the flash (0x30000) and by doing so
we guarantee that while in the linuxbios code, we have the entirety of the
flash.
Now, what I think I'm missing is telling the docipl to find linuxbios at
0x30000, then telling linuxbios to find the elf image at 0x10000.
I'm probably missing more, someone please elaborate on what exactly.
I don't believe there are any post codes in the docipl section (is it
simply not possible to use post codes there perhaps? Sure would be useful,
but i'm not comfortable tinkering with it yet.) But I *think* the docipl
is ran because the post does go to 0x00. When I put complete junk in the
flash, it stays at 0xFF :) But it's definitly not finding the linuxbios
part.
P.S. If anyone needs drivers for the flash parts sst28sf040 or pm29f002t
(they seem to ship with the Winfast and Matsonic respectivly) let me know.
I'm using a while loop with a volatile int to slow down the writting
process (much faster than usleep, but slower than needed) to these flash
chips so I consider it a horrible hack and haven't submitted patches for
Ollie's sis flash tool.
