entire output?
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
be going wrong and
where to start looking.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Marc Jones wrote:
Myles Watson wrote:
Here's my attempt at fixing abuild for serengeti_cheetah_fam10.
It's pretty trivial, since I'm just using the ROM_IMAGE_SIZE in
Config.lb and putting it in Config-abuild.lb. When I reduce this size
(past what it is in Config-abuild.lb), it gives me
Marc Jones wrote:
ron minnich wrote:
Marc, here are the register dumps.
As a reminder, we seem to have no memory above 1M.
It looks like stage2 has problems. The MSRs are not setup beyond what
stage1 did to allow stage2 to run.
Specificly, geodelx_pci_domain_phase2() is not running
Peter Stuge wrote:
On Tue, Jan 08, 2008 at 04:54:29PM -0700, Marc Jones wrote:
How about this?
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
Add hlt() back into the die() function and update
in
r3038 to v2. Since the patch is identical, I'm tempted to steal Marc's
ack from r3038.
Acked-by: Marc Jones [EMAIL PROTECTED]
Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED]
Acked-by: Marc Jones [EMAIL PROTECTED]
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
generated
code is equivalent, so it should be a no-brainer.
Add a copyright header to the code, the header is derived from the one
found in the same piece of code in v3.
Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED]
This looks good. Thanks for the iterations.
Acked-by: Marc Jones
for Family 10h
* paranoid checks for CAR size
* clear abstractions
Not tested, as I lack hardware working with v2.
Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED]
Much better than it was. Thanks!
Acked-by: Marc Jones [EMAIL PROTECTED]
--
Marc Jones
Senior Firmware Engineer
(970) 226
ron minnich wrote:
On Jan 7, 2008 3:57 PM, Marc Jones [EMAIL PROTECTED] wrote:
The hlt is really the right thing to do and I would rather it be in
there. Correctly behaving jtag should be able to handle it. I understand
clearing the fifo so do it before the hlt.
OK. How about we do a bunch
. In your payload can
you do a push/pop test?
As for 1MB and above, it sounds like GLIUInit() isn't running correctly.
Can you dump RCONF and GLIU MSRs? Something like v2 print_conf() in the
norwich\mainboard.c.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL
it is finished. As for
the build side I think this might be where buildrom comes in and does
the wget etc.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http
.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
ron minnich wrote:
On Jan 7, 2008 2:18 PM, Marc Jones [EMAIL PROTECTED] wrote:
I don't like taking the hlt() out of die(). Can you describe when you
where having issues?
In the early days of LinuxBIOS, using an American Arium JTAG debugger,
I found that I could not examine memory
. Building on
that the macro could fill in ecx as well.
What do you think?
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo
would be very interested in seeing some profiling of LB and
if there are any places where we could optimize for speed. Please post
any specific questions or results.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
any idea why it is stuck waiting but you should get some
insight by instrumenting init_cpus(), wait_cpu_state() and
wait_ap_started();
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
of cheetah_fam_10.conf, so it's easy
to see what it is.
Myles
Myles,
I agree using the same serengeti_cheetah.conf is better so here is my
attempt..
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
[BUILDROM] Add
Myles Watson wrote:
On Dec 20, 2007 12:15 PM, Marc Jones [EMAIL PROTECTED] wrote:
Myles Watson wrote:
Hey all - following on Marc's awesome Barcelona patches, here is the
code to add the fam10 target to buildrom.
It works for me, but since you used the generic.mk instead
Myles Watson wrote:
Myles Watson wrote:
On Dec 20, 2007 12:15 PM, Marc Jones [EMAIL PROTECTED] wrote:
Ah! missed the LAB stuff, sorry. I will make those changes.
Is the serengeti_cheetah_fam10-payload.patch really needed? It cleans up
the config.lb a little but I don't see
with access to the build server
or a similar setup is probably the best candidate to fix this (I've done
my share ;-) )
-Corey
Corey,
I looked at the output and I don't see anything obvious. It doesn't fail
for me either. I'll work with Stefan when he is able to look at it.
Marc
--
Marc
src/mainboard/*/Options.lb (trivial)
Signed-off-by: Corey Osgood [EMAIL PROTECTED]
Acked-by: Corey Osgood [EMAIL PROTECTED]
Thanks Corey.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios
Corey Osgood wrote:
Marc Jones wrote:
[EMAIL PROTECTED] wrote:
Author: cozzie
Date: 2007-12-19 09:07:37 +0100 (Wed, 19 Dec 2007)
New Revision: 3018
Modified:
trunk/LinuxBIOSv2/targets/amd/serengeti_cheetah_fam10/Config.lb
Log:
Small fix to make the abuild happy, add ROM_SIZE
Corey Osgood wrote:
Marc Jones wrote:
Corey Osgood wrote:
Marc Jones wrote:
[EMAIL PROTECTED] wrote:
`/home/corey/LinuxBIOSv2/util/abuild/linuxbios-builds/amd_serengeti_cheetah_fam10/normal'
make: *** [normal/linuxbios.rom] Error 1
It looks like abuild tries to do a failover
would be required for
SMBIOS. Maybe a payload or a custom driver would be the way to go.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org
/fallback/normal images.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Can someone with an dual cpu or dual core Intel system try this patch?
Thanks,
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
---BeginMessage---
Changes to core lapic.h. This file is used by Intel multiprocessor
Peter Stuge wrote:
I think amd/norwich, pcengines/alix1c or maybe amd/db800 would be
good starting points. (What about amd/rumba?)
The db800 should be closest since it has an example of SIO support.
Rumba is a GX not a LX mainboard.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226
Carl-Daniel Hailfinger wrote:
On 10.12.2007 21:56, Marc Jones wrote:
A devices needs to be listed in the config.lb if it requires more setup
than standard PCI initialization (resource allocation). Usually that
means the CPU, northbridge, southbridge, and SIO. Those devices are
usually
of the base code (except for adding some POST
codes).
Thanks for separating the patches, it made it a lot easier to see the
changes.
Myles
Acked-by: Myles Watson [EMAIL PROTECTED]
Thanks,
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http
/src/no
rthbridge/amd/amdfam10/raminit_sysinfo_in_ram.c:45: error: previous
implicit declaration of 'udelay' was here
fixed raminit_sysinfo_in_ram.c. Changed the call to udelay_tsc().
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com
ron minnich wrote:
On Dec 12, 2007 9:49 PM, Marc Jones [EMAIL PROTECTED] wrote:
I don't think that moving the stack should be a problem. All access
should be push/pop or ss/esp/ebp relative. I also don't think you need
to copy the stack back (like K8) and I would only copy the amount
in the mainboard code. The stuff below it should
be a stage1_done() or start_stage2() in stage1.c that gets called from
disable_car() as you proposed. I think that would work and isn't too
complicated. Everything stays together... In fact, I think I like it.
Marc
--
Marc Jones
Senior Firmware Engineer
.
I also didn't understand why the type change from uint32_t to u32 was
important.
Myles
Just trying to follow the LB guidelines. Maybe I should have left it alone.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
yhlu wrote:
On Dec 13, 2007 9:01 AM, Marc Jones [EMAIL PROTECTED] wrote:
part 3 is trimmed too.
Get all four parts here:
http://linuxbios.org/~mjones/barc121207.tar.gz
1. it seems that you keep native ram init code raminit_ddr2.c and
raminit_ddr2_dqs.c
2. northbridge.c and etc still
sb generated
cycle. Anyway this can wait and it is totally lowprio, but still I'm curios ;)
I have the same BKDG that you should have and I don't see any additional
documents that might have more information. I will let you know if I
come across anything.
Marc
--
Marc Jones
Senior
it die if a a device isn't found? Seems like that would be a
warning. I can imagine some cases where a device might or might not be
installed on a mainboard that could be supported by a single ROM image.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Carl-Daniel Hailfinger wrote:
You mean, the stack is moved? Or why do we need to adjust the
pointers? Won't that leave pointers to variables on stack dangling?
I meant that ss, esp, ebp are adjusted to point at the new stack. The
contents of the stack don't change.
--
Marc Jones
Senior
. Once copied
the pointers are adjusted and then the function returns.
That about sums it up
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http
to be moved you would want
to do it before the wbinvd so you were copying from cache to memory.
Much faster than memory to memory.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios
Carl-Daniel Hailfinger wrote:
On 13.12.2007 02:29, Marc Jones wrote:
Carl-Daniel Hailfinger wrote:
You mean, the stack is moved? Or why do we need to adjust the
pointers? Won't that leave pointers to variables on stack dangling?
I meant that ss, esp, ebp are adjusted to point at the new
Marc Jones wrote:
Carl-Daniel Hailfinger wrote:
Dumb question: We know the location of the stack when we enter
disable_car(). We also know that all memory belongs to us. Can we copy
CAR stack contents to some safe location and restore them after wbinvd()?
This shouldn't be needed
ron minnich wrote:
On Dec 12, 2007 6:00 PM, Marc Jones [EMAIL PROTECTED] wrote:
There are a couple ways to address this.
1. copy the stack to a new location.
2. Set the tags dirty with by writing the way MSRs.
3. enable the cache and copy the stack back on it's self to dirty the tags.
I
AMD 8111 southbridge adjustments for Barcelona.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
Additional early AMD8111 southbridge support for Barcelona platforms.
Check that the SMBus controller is found and stop
Changes to core lapic.h. This file is used by Intel multiprocessor CPUs
as well as AMDs. Could someone with Intel APIC experience take a close
look at this and try it?
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com
more testing with it.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
(pci_domain) as well
as do any system specific initialization on those devices.
During the LinuxBIOS PCI/system scan process, if a device in config.lb
is found, the functions to do customized initialization are called via
the device_operations and the chip_operations structs.
Marc
--
Marc Jones
Senior
registers are located in Function 2 if you
decide to dump and compare them.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman
Uwe Hermann wrote:
See patch.
That file is a duplicate (it was slightly different at some point, but
identical in its current form) of coherent_ht.c, so drop it.
Uwe.
Signed-off-by: Uwe Hermann [EMAIL PROTECTED]
Acked-by: Marc Jones [EMAIL PROTECTED]
--
Marc Jones
Senior
- 2 CPUs
CONFIG_LOGICAL_CPUS : 1 - build multi core support in.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo
Steve Isaacs wrote:
Thanks.
On Tue, 2007-12-04 at 10:18 -0700, Marc Jones wrote:
CONFIG_MAX_CPUS : Saves space in the ACPI tables and additional stack
space for maximum possible number of cores in the system. Might be
better named as CONFIG_MAX_CPUs_CORES (AMD only
that
could be adjusted by a mainboard override.
Family 10h need more tricks.
These changes are coming soon.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
Marc Jones wrote:
yhlu wrote:
my own tree have
#if CacheSize 0x8000
/* enable caching for 16K/8K/4K using fixed mtrr */
movl$0x269, %ecx /* fix4k_cc000*/
#if CacheSize == 0x4000
movl$0x06060606, %edx /* WB IO type */
#endif
#if CacheSize
();
console_init();
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
is zeroed, %edx keeps its
value ($0x06060606 in case of CacheSize=32k). wrmsr is issued. Is there
any reason to assume that this will not disable CAR again between 16k
and 32k? And no, that code is not protected by an #ifdef.
Ah! You are right. This is a bad bug.
Marc
--
Marc Jones
Senior
Carl-Daniel Hailfinger wrote:
On 29.11.2007 23:58, Marc Jones wrote:
Carl-Daniel Hailfinger wrote:
Everything is set up correctly until now.
/* enable caching for 16K/8K/4K using fixed mtrr */
movl$0x269, %ecx /* fix4k_cc000*/
#if CacheSize == 0x4000
movl
if the size isn't power of 2 between 4K and 64K? If you
wanted to support non power of 2 you should round up otherwise you might
write off the end.
Note that Geode platforms don't use the same car file as K8 and has a
max cache size of 32K. See arch\x86\geodelx\stage0.S
Marc
--
Marc Jones
Senior
Carl-Daniel Hailfinger wrote:
On 28.11.2007 23:52, Marc Jones wrote:
Carl-Daniel Hailfinger wrote:
Marc?
This has been sitting in my tree for a while now.
On 16.11.2007 16:00, Carl-Daniel Hailfinger wrote:
Hi,
v2 and v3 have almost identical CAR setup code with identical bugs for
CAR
ron minnich wrote:
add one debug print, move all smbus_read_byte to spd_read_byte.
attached.
ron
Acked-by: Marc Jones [EMAIL PROTECTED]
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing
is in
there. Also, in my experience it is ok to have overlapping post codes as
long as there are key post codes that are not duplicated to indicate the
areas that you are in.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
- there are indeed some good reasons why you want the
power button wired to ground. Carry on.
Jordan
Yes, there are some no power button (instant on) implementations that
are interesting for Geode systems. Peter's patch will be a good addition.
Marc
--
Marc Jones
Senior Firmware Engineer
(970
.
The artecgroup mainboard is incomplete.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
ron minnich wrote:
Well, I hope this is it. My alix1c now works very well. I think the
IRQs are right.
Thanks again to Marc Jones for clearing me up on IRQ tables.
Attached.
ron
-default IRQ_SLOT_COUNT=9
+default IRQ_SLOT_COUNT=7
This should be IRQ_SLOT_COUNT=5
Otherwise it looks
in stepan's neck until the issue is fixed.
If this issue is not fixed within 24h the revision should
be backed out.
Best regards,
LinuxBIOS automatic build system
All platforms building without errors.
Stefan ++
Good job,
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226
:/
new boot log with log level = 8?
Ok will do that in the evening. Now I'm away from that computer.
Rudolf
Rudolf,
Check CONFIG_LOGICAL_CPUS=1 is set. I think that is the flag for
intializing aditional cores on each CPU.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
ron minnich wrote:
Try 2.
Marc, it is actually reading the first two SPD values before it hangs.
ron
This sounds like the the spd_read is wbroken or GLSpeed is not
compatible with the memory. See sdram_set_spd_registers and then
checkDDRMax in amd\lx\raminit.
Marc
--
Marc Jones
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
[EMAIL PROTECTED] wrote:
Quoting Marc Jones [EMAIL PROTECTED]:
[EMAIL PROTECTED] wrote:
Ok I am a little confused on how to tell what devices are what in
irc_tablec.c
How do I tell?? Also where does the value for the bitmap come from?
Thanks for your help - Joe
/* bus, dev|fn
/whdc/archive/pciirq.mspx
Your bus/dv/fun should match the devices found when you do an lspci. The
value for the bitmap is what IRQs are available on that INT#. Theses are
typically 10 and/or 11 but could be any shareable IRQ.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
this for the
LX/5536 platforms too. What do you think?
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
could be getting the four
second ACPI soft-off if the power button signal was tied to on.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org
the problems you find as you transition to LinuxBIOS.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
it failed.
limit |= ((resource-base + (resource-size - 1)) 8) 0xff00;
I think Rudolf's use of resource_end() is better than the inline math.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios
somewhere inside stage2 or in the jump to it.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Carl-Daniel Hailfinger wrote:
On 08.10.2007 19:01, Marc Jones wrote:
Tom Sylla wrote:
The next question is where would be a good place for the Counter 1
init? It seems like it should be done generically in LB for any SB
with a PIT.
I agree with Tom. The PIT should be setup by linuxbios
/8254.
Interestingly, I found hardwaremain() contains a call to timer_init().
timer_init() doesn't really init the timer completely. I will look at
this more closely.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
at 0x-ROMsize.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
.
http://linuxbios.org/index.php/Buildrom
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
with a PIT.
I agree with Tom. The PIT should be setup by linuxbios for x86 systems.
I can't think of an x86 that doesn't have a PIT. I don't see a good
generic place to put this. PIT init should go in early init so that it
can be used for timing loops.
Thoughts?
Marc
--
Marc Jones
Senior
/index.php/Development_Guidelines#How_to_contribute
I would expect three patches: northbridge, southbridge, and mainboard.
Thanks for the contribution!
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios
the linux kernel reprogram the PIT (maybe not
if it is using ACPI timer or HPET)?
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org
.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
ron minnich wrote:
On 9/25/07, Marc Jones [EMAIL PROTECTED] wrote:
All this seems like a good reason to let the driver and/or system level
software enable PERR# and SERR# and for LinuxBIOS to leave them alone.
you're right. I don't even remember when those started getting set,
and had
Note that other LX platform owners should update the buildrom platform
linuxbios tags to pick up the PERR#/SERR# fix.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
Update AMD GeodeLX platfroms to get latest
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
ron minnich wrote:
On 9/26/07, Marc Jones [EMAIL PROTECTED] wrote:
Ron,
I have tested it. :)
I have not used flashrom since I use a rom emulator. I will look into it.
I fixed my msm800sev problem. The part is an FWH part. We have a
problem in flashrom in that parts can be FWH or LPC
i/o based PCI config
accesses. It indicates that it is a config access and not just a normal
PCI i/o access.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
]:][slot][.[func]]
| -d [vendor]:[device]
device expects -s 0:d.0
Sorry, it requires the -s option as Stefan has pointed out.
setpci -s 00:0d.0 COMMAND=7
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com
Marc Jones wrote:
Marc Jones wrote:
Steffen D. wrote:
About the ethernet problem:
OK. I think is see the problem. Bus Master Enable and Memory Enable
aren't enabled in the command register. I am not sure why the Memory
Enable isn't set. LinuxBIOS should set that and this seems
Steffen D. wrote:
Marc Jones schrieb
#define PIRQB 11
to
#define PIRQB 5
This will move audio and eth0 to 5 while USB will be on 10 and 11.
Marc
I changed this and nothing happens - i have put lspci ouput and irq
source in the attachment...
00:0d.0 Ethernet controller: Realtek
Marc Jones wrote:
Marc Jones wrote:
Marc Jones wrote:
Steffen D. wrote:
About the ethernet problem:
OK. I think is see the problem. Bus Master Enable and Memory Enable
aren't enabled in the command register. I am not sure why the Memory
Enable isn't set. LinuxBIOS should set
(chipset_irq_map, 0xCFC)
is basically the same as
pci_write_config8(pdev, 0x5c, 0xab);
pci_write_config8(pdev, 0x5d, 0x09);
CFC/CF8 is the PCI config space.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios
boards and it is happening the same on each board.
Do you mean this line of code?:
#define M_PIRQB (1 PIRQB)/* Bitmap of supported IRQs */
regards,
steffen
#define PIRQB 11
to
#define PIRQB 5
This will move audio and eth0 to 5 while USB will be on 10 and 11.
Marc
--
Marc
---
this also seems very strange sharing irq11 with... can the problem be
right here?
That shouldn't be the issue. I recall now that PIRQB is shared with the
audio device. d.0 is the eth0 and f.3 is audio.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http
Marc Jones wrote:
Steffen D. wrote:
About the ethernet problem:
---
meshnode:~# modprobe r8169
r8169 Gigabit Ethernet driver 2.2LK loaded
PCI: Guessed IRQ 11 for device :00:0d.0
PCI: Sharing IRQ 11 with :00:0f.3
eth0: RTL8169sb/8110sb at 0xd0016000, 00:08:ee:00:ee:1c, IRQ
could try is changing the IRQ mapping to isolate the IRQs.
In the mainboard diirectory change irq_tables.c PIRQB to something else
like 5 to isolate it.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
says r8169: eth0:
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
be adapted to the CS5530. Is it pretty much understood that setting
the IRQ steering registers within that function is the right place?
-Jonathan
Sounds like the right place to me.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com
there are additional problems in the pci scan code.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
1 - 100 of 197 matches
Mail list logo
