If you could move your stuff to V2 that would be wonderful. You'll have to
learn V2 structure but that's good. And you need to convert .s to .c but
that's good too.
ron
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/
I come bearing good news!
So it's all working now. I've got the kernel running
and userspace apps working. My unoptimized boottime
from power on to the point that /sbin/init runs the
first rc script looks to be around 6 seconds. Yay!
Thanks to all of you for all the hard work and help.
If any of y
also, you should try to make memtest86 a payload and see if it passes.
ron
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
are you building the kernel with ONLY serial console, and not vga console?
ron
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Ah, I had assumed that filo could only load an elf
image. Okay. Replaced that with a fresh bzImage with
early printk enabled. Looks to fail at the same point.
I noticed filo is now able to show the kernel version
and build date so I'd guess that this is getting
better. Here's the debug output. I'm
Before you do anything else, set your kernel up with CONFIG_EARLY_PRINTK
You'll get output you might not get otherwise.
> I
> think filo isn't able to read the version info out of
> the kernel for some reason.
I don't think that is it.
filo will work fine with a normal bzImage anyway, you don
hmm, that's a good point. i used the version of
mkelfImage that was part of the src tree. it reports
itself as 1.16.
# /usr/local/sbin/mkelfImage --version
/usr/local/sbin/mkelfImage 1.16
and it came from:
freebios/util/mkelfImage
now that i look, i see there is another mkelfimage in
the tree as
On Tue, Jan 25, 2005 at 11:31:10PM -0800, ramesh bios wrote:
> I converted my bzImage using mkelfImage like so:
>
> --kernel=./bzImage.in --output=bzImage.elf
> --command-line="root=/dev/hdc2 console=tty0
> console=ttyS0,38400 ro init=/sbin/init"
Which version of mkelfImage are you using? There h
Christer wrote:
> takes over. So check that the debug baudrate and
> that the baudrate
> for the rest of LinuxBIOS is the same.
>
Yup Christer, you were right. Thanks. It was because
baud rate in serialio.c was set to 115200. So I set it
back to 38400 all over and it gets to almost the final
ste
Adam Sulmicki wrote:
do you have to pledge your soul in order to register there?
Registration was relatively painless. There is a NDA though, so you
might want to think about what you want to do with the info.
AMD may let LinuxBIOS register settings or init sequences go public if
asked nicely.
ramesh bios <[EMAIL PROTECTED]> writes:
> So my current status is that I get as far as:
>
> Enable FLASH
> Set F0/0x52 to 0xee
> cs5530: Enabling Primary IDE Controller
> cs5530: Enabling Secondary IDE Controller
> Set F0/0x5b to |= 1 << 5(0x38)
> handle_superio start, nsuperio 1
> handle_superio
The docs are now all at:
http://wwwd.amd.com/amd/developer.nsf/
do you have to pledge your soul in order to register there?
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
to find a superio.
The superios can only live at one or two addresses in general. What you
can do is probe the superio by outb()'ing the sequence for enabling it and
reading the ID back (that's in the book). Only one of the addresses will
work.
ron
___
ramesh bios wrote:
somewhere on www.national.com, but since AMD took
over the Geode, all
that documentation has disappeared.
The docs are now all at:
http://wwwd.amd.com/amd/developer.nsf/
Sign up for your password and decoder ring.
-Bari
___
Linuxbios
> somewhere on www.national.com, but since AMD took
> over the Geode, all
> that documentation has disappeared.
Yup, the document that would help appears to be called
xpressrom_gx1_memsizing.pdf. The google cache of it is
still there but it's so horribly mangled that I didn't
try hard to underst
(Note the new mail address, I'm not sure if the hack.org address still
reaches me).
ramesh bios <[EMAIL PROTECTED]> writes:
> Christer, I'm having trouble with my gx1 board. The
> ramtest fails and I see an explicit difference in what
> the normal bios sets MC_BANK_CFG to and what the
> raminit a
On Tue, Jan 18, 2005 at 10:47:38PM -0800, ramesh bios wrote:
> I noticed you mentioned reading the nsc reference
> drivers to get further understanding. Are these
> available somewhere?
NSC offered the BLDT, BootLoader Development Toolkit, without an
agreement of exclusivity and without licensing
Oooh, I guess it's a chance for me to contribute in
some way. :-)
I'm not familiar with DIMM autosizing. But I believe
the problem is coming from the following block of code
that does the module bank detection. At least that's
the first sign of trouble since module bank detection
is done and then
I think you may have found a bug I never had time to fix. Certain DIMMs
never worked on my Geodes.
ron
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Yes, I do.
http://www.intworks.biz/ ramesh/geode_gx1.pdf
The register I've been examining is:
MC_BANK_CFG, on page 114
LinuxBIOS sets it up as:
Probing for DIMM0
Probing for DIMM1
Found DIMM1
Page Size: 1000
Component Banks: 4
Module Banks:2
DIMM size: 08
On Tue, 18 Jan 2005, ramesh bios wrote:
> Page 99 of the rev 4.1 GX1 spec shows the SDRAM Memory
do you have URL handy for this?
ron
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Page 99 of the rev 4.1 GX1 spec shows the SDRAM Memory
Controller control registers. That info corresponds
with the addresses that get written by
src/northbridge/nsc/gx1/raminit.inc (also the ones
that I think I'm dumping).
I matched the northbridge pci config space config (the
lspci -xxx -s 0:0.
This is the geode chipset, right?
Seems to me that
lspci -xxx -s 0:0.0 will give you all you need, or is there some other
place that dram config gets stored?
ron
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailm
You were right. There is a problem with the sdram
setup. It fails the ramtest.
I set about attempting to dump the memory controller
registers on linux running with phoenix bios (with the
intent of having something to compare with what
linuxbios sets these regs to). i'm not completely sure
if the f
On Thu, 13 Jan 2005, ramesh bios wrote:
> >
> > Also, what is the 8a00-000f0d66? that's a really
> > odd range to test. Do
> > you really have that much memory on your geode?
> > Something is not right.
>
> Yup, I had not set up the range at all. So ramtest
> took whatever was in eax, ebx
>
> Also, what is the 8a00-000f0d66? that's a really
> odd range to test. Do
> you really have that much memory on your geode?
> Something is not right.
Yup, I had not set up the range at all. So ramtest
took whatever was in eax, ebx as the range.
I'm gonna read the gx1 spec and the ramset
Ramesh, your config looks fine.
ron
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
On Wed, 12 Jan 2005, ramesh bios wrote:
>
> LinuxBIOS-1.0.0 Thu Jan 13 13:01:00 MYT 2005
> starting...
> Setting up default parameters for memory
> Sizing memory
> Probing for DIMM0
> Probing for DIMM1
> Found DIMM1
> Page Size: 1000
> Component Banks: 4
> Module Banks
Oh, how embarassing. I didn't set the sdram address
range for ramtest. I am going to read the spec and
find the memory map after lunch. Ignore the comments
where I made the assumption that sdram was good.
> Testing SDRAM : 8a00-000f0d66
> SDRAM fill:
> 8d71
__
hi richard,
yup, sounds pretty much like it. mine's a gx1/cs5530a
combo. i just posted about my latest status. i'm
starting to suspect that the ram setup might be fine.
it could be that i might have somehow misconfigured my
linuxbios build. i had sent an email where i detailed
what i think is bein
I used the phoenix bios to boot up and then dumped out
the northbridge. Then I called dumpnorth at
ram_setup_end, which is prior to "Copying LinuxBIOS to
ram." The diff of the two was as below:
linux:
< 40: 1e 12 00 c1 00 00 00 00 00 00 00 00 00 00 00 00
---
phoenix:
> 40: 00 10 00 47 00 00 00 00
I think the RAM is misprogrammed.
You need to dump the registers (lspci -xxx -s 0:0.0) for the northbridge,
then dump them BEFORE jumping to linuxbios -- there are assembly functions
that will let you do that.
ron
___
Linuxbios mailing list
Linuxbi
On Mon, 10 Jan 2005, ramesh bios wrote:
> Just wanted to report that your suggestion was
> excellent. I'm now getting serial output saying
> "Jumping to LinuxBIOS". It took only a few minutes to
> get this working so I was pleasantly surprised. :-)
> Thanks!
it did not get near as far as it sh
--- ramesh bios <[EMAIL PROTECTED]> wrote:
> Ok. So I took a look at the code to figure out why
> the
> last output that I see is "Jumping to LinuxBIOS".
I've got a gx1 reference platform on loan for a while.
Is that mostly the same hardware as what you have?
Perhaps I can help you fix this up
Ok. So I took a look at the code to figure out why the
last output that I see is "Jumping to LinuxBIOS".
My assembly is weak so I'd appreciate corrections to
my interpretation of the asm below.
decompr_end_n2b:
movb $0x12, %al ; outb %al, $0x80
movl %esp, %ebp
mov $str_pre
Hi Ron,
Just wanted to report that your suggestion was
excellent. I'm now getting serial output saying
"Jumping to LinuxBIOS". It took only a few minutes to
get this working so I was pleasantly surprised. :-)
Thanks!
Ok, I'm now going to read a bit more about x86 booting
and figure out what's ne
your plan is fine. use the advantech pcm5823 as a model board, and use
freebios, not freebios2.
Don't fit linux into the flash. Use filo and boot linux from a hard drive.
Keep me posted on how it goes and good luck.
ron
___
Linuxbios mailing list
Li
It is a typical embedded geode board and has two winbond W83977F superio chips, and realtek 8100BL ethernet. Currently, both boards have PhoenixBIOS on them. The flash chip that appears to be used to store the BIOS is an SST 39SF020A chip. The board has a CompactFlash slot on ide0 for the operating syst
On Tue, 2004-09-14 at 21:19, elife elife wrote:
> Hi,
> It seems flash_rom in freebios/util/flash_and_burn not support SST
> 49LF002A flash chip. Who can teach me how to add this feature?
>
It is easy. Download the datasheet from their web site. Find out the
read/write/erase/id
Hi,
It seems flash_rom in freebios/util/flash_and_burn not support SST
49LF002A flash chip. Who can teach me how to add this feature?
Thanks!
_
免费下载 MSN Explorer: http://explorer.msn.com/lccn
On 28 Oct 2003, Xavier Pegenaute wrote:
> SST 39SF020A (70-4C-NH)
I get many of my flash parts from Avnet.
ron
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
SST 39SF020A (70-4C-NH)
Although it is not an equivalent part, I use the Atmel AT49F002T in
place of the SST39SF020A and it works fine on the epia-800. I program
it with a Needhams programmer, though, not sure if you can program it on
the mobo. You for sure need Atmel programming software
other flash memory by the case of an error while i'm trying?
>
> The code is:
>
> SST 39SF020A (70-4C-NH)
>
> Thanks a lot.
> Xavi.
>
> ___
> Linuxbios mailing list
> [EMAIL PROTECTED]
Hi,
now i want to try LinuxBios with an epia-m, any one know where i can
find another flash memory by the case of an error while i'm trying?
The code is:
SST 39SF020A (70-4C-NH)
Thanks a lot.
Xavi.
___
Linuxbios mailing list
[EMAIL PROTECTED]
44 matches
Mail list logo
