stefan, I have a patch to abuild.sh on the issue tracker. This patch works
as follows:
If there is a targets/vendor/mainboard/Config-abuild.lb
that will be used instead of the auto-generated one. See what you think.
See example
targets/digitallogic/msm586seg/Config-abuild.lb
This is how it looks.
~/src/LinuxBIOSv2/util/abuild/abuild.sh -t digitallogic/msm586seg
~/src/LinuxBIOSv2/
Processing mainboard/digitallogic/msm586seg (i386: ok)
Used existing test target
/home/rminnich/src/LinuxBIOSv2//targets/digitallogic/msm586seg/Config-
abuild.lb
Creating builddir...ok
Compiling image ..ok.
The msm586seg now builds correctly in abuild. if this patch is ok, I will
apply it or you can.
Also, note that abuild won't create linuxbios-builds if you specify -t ...
this is a bug.
ron
oh, wow, what a mess. There's a lot to fix still. We'll be looking at each
of these in turn, to try to get them to build. The last batch of patches
from people left the tree in a very unhealthy state.
We're going to have to watch this a lot more closely. If we can't improve
the situation somehow, the only thing I can think of to do is limit people
to sending in patches via the issue tracker, and shrinking the set of people
who can commit down to a very small circle. Based on what I'm seeing here,
the current setup is not working. I have not wanted to do this as we here at
LANL don't have tons of free time to monitor patches, but the current
situation can not continue.
I think the earlier suggestion, of requiring positive evidence that abuild
works after a patch, might be right. only problem -- abulid is making
mistakes. The digital logic msm586 bulid fails in abuild, and works fine
otherwise. oops.
thanks
ron
I have committed this. It was waiting too long. It caused no problems
for building arima/hdama once I corrected a few typos.
Signed-off-by: Ronald G. Minnich
let me know if there are troubles. Will the first person to test this on
real hardware please change status to resolved, instead of testing.
Stefan, can we have status items of 'builds ok'? It would help.
thanks
ron
stephan, oille,
Please check the memhole patch.
when the hole_startk == one node basek,
1. it will modify base reg instead of hole reg
2. or if K8_HW_MEM_HOLE_SIZE_AUTO =1, then hole_startk will be moved to pri
node mem middle....
this could solve the problem such as
1. two nodes, and first cpu have 2G installed, and memhole size is set to
2G, or mmio_basek is 2G, ( 2 IB installed).
2. four nodes. and every node has 1 G installed, and mmio will be 1G, and
memhole is 1G.....
New Mem hole behavoir will be
1. if K8_HW_MEM_HOLE_SIZEK == 0, then don't set mem_hole
2. if it is set, and it make hole_startk <= mmio_basek, will not reset mem
hole in northbridge.c
3. if it is set, and it make hole_startk > mmio_basek, memhole will be reset
in northbeidge.c
4. if hole_startk met with basek, it will use base reg instead of increase
the hole_sizek to make hole_startk to the middle of pri node.
YH
I sent you my latest tall last week.....for aruma, s2881/s2885. Only
miss the HW mem hole setting regarding hole_startk == basek....
Regarding apic id lifting
1. final solution will be
a. ENABLE_APIC_EXT_ID will decide if lifted apicid
b. APIC_ID_OFFSET will decide offset
c. LIFT_BSP_APIC_ID will decide if lift BSP's....
2. Need to put back sth back to cpu_scan_bus...
Giant patch? It is already into two patch....
1. it is in two patch.... one for microcode
2. One for acpi, Serengeti is just for referenc.e
I have lost the sync to the public tree....., later I will send my tar
ball to Stephan and you instead if needed...
YH
-----Original Message-----
From: linuxbios-bounces(a)openbios.org
[mailto:linuxbios-bounces@openbios.org] On Behalf Of Ronald G Minnich
Sent: Monday, November 21, 2005 4:28 PM
To: LinuxBIOS
Subject: [LinuxBIOS] issue 24
Yh Lu, could you please look at issue 24, and respond to stefan's
issues?
Yh Lu, I notice in issue 24, you set the idx to 0x10 in the amd k8
northbridge code, as opposed to the previous 10. Did you change this
back? What is the current favorite setting? Did we ever decide if this
was really ok? I've not been tracking all the 'lifting' discussions as I
should have been -- sorry.
At the least, please, can you review this patch and let's try to get it
in as a set of patches, not as one giant patch; and, please seperate out
the board-specific stuff (serengeti) from the global stuff that affects
everything (northbridge/amdk8).
What's the state of the ********** 16 *************** lnxi patches? did
someone apply them and not mark them, or do we really have to test them
all.
I'm going to look at issue 31 next ... maybe this one will be easy.
I was that close to applying Yh Lu's issue 24 patch, but it scared me.
ron
--
LinuxBIOS mailing list
LinuxBIOS(a)openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Yh Lu, could you please look at issue 24, and respond to stefan's issues?
Yh Lu, I notice in issue 24, you set the idx to 0x10 in the amd k8
northbridge code, as opposed to the previous 10. Did you change this
back? What is the current favorite setting? Did we ever decide if this
was really ok? I've not been tracking all the 'lifting' discussions as I
should have been -- sorry.
At the least, please, can you review this patch and let's try to get it
in as a set of patches, not as one giant patch; and, please seperate out
the board-specific stuff (serengeti) from the global stuff that affects
everything (northbridge/amdk8).
What's the state of the ********** 16 *************** lnxi patches? did
someone apply them and not mark them, or do we really have to test them
all.
I'm going to look at issue 31 next ... maybe this one will be easy.
I was that close to applying Yh Lu's issue 24 patch, but it scared me.
ron
applied. I don't like one or two things, but they appear harmless. Oh boy.
But this has waited way too long.
First, arch/i386/lib/cpu.c has an #ifdef CONFIG_SMP || CONFIG_IOPIC.
Somebody want to clean this up? IIRC this was needed due to silliness in
the VIA?
This has not broken targets AFAIK.
abuild.sh won't run for me -- HOWTO?
I put a HOWTO directory at the top level, I am hoping its appearance
there will inspire people.
ron
I've started cleaning up issue tracker stuff. I just finished my latest,
and am working epia-m now. I will sign them off. The test will be if
they at least build.
I will let you know as I do each one.
ron
Hi,
is there a reason that the LB checksum used on the intel/xe7501devkit
is completely different (and covers a really small space only)
default LB_CKS_RANGE_START=128
default LB_CKS_RANGE_END=130
default LB_CKS_LOC=131
compared to all the other supported boards:
default LB_CKS_RANGE_START=49
default LB_CKS_RANGE_END=122
default LB_CKS_LOC=123
Regards
Stefan
