Rebasing a 2009 branch on current master (VX900 anyone?)

[Alex G.]

Hi,

I am that guy that never seems to get VX900 working properly. I've
recently received some code[1] for the VX900 from VIA. It is based on a
coreboot fork from about 2009.

Rather than try to continue my own VX900 effort, I think it is better to
use the code provided by VIA, and clean that one up.

I don't have the SVN history for the code, but Cristi was able to trace
it back to somewhere around hash a9c5ea08d07d343d32d4c083a232107bd84d8064

VIA has no interest in maintaining or rebasing the code, so we're on our
own here. The good news is that using this code will reduce the time
needed to complete the VX900 port significantly.

I therefore ask the gurus, "What is the best way to go about this?"

Let's hope we can get this code working with our current master. If we
manage to rebase it, I can clean it up, and optimize it a bit.

Alex

[1] http://g-tech.no-ip.org/~mrnuke/coreboot_vx900_vt8595a.tgz

Rebasing a 2009 branch on current master (VX900 anyone?)

[Peter Stuge]

Alex G. wrote:
> Rather than try to continue my own VX900 effort, I think it is
> better to use the code provided by VIA, and clean that one up.

I agree.
> I don't have the SVN history for the code, but Cristi was able to trace
> it back to somewhere around hash a9c5ea08d07d343d32d4c083a232107bd84d8064

Commit 22b44ba9c3672115bfe90ff9b218553959743b6e seems to be the first
commit which includes all unrelated changes in the tarball.
> I therefore ask the gurus, "What is the best way to go about this?"
>
> Let's hope we can get this code working with our current master. If
> we manage to rebase it, I can clean it up, and optimize it a bit.

Step 1: Work with tarball code until you can build a working ROM.
(Check if all files are included in the tarball. Consider option ROM
licensing.. Etc.)

Step 2:
$ git clone http://review.coreboot.org/coreboot coreboot && \
  cd coreboot && \
  git checkout -b vx900 22b44ba9c3672115bfe90ff9b218553959743b6e && \
  cp -a ../coreboot_vx900_vt8595a/* . && \
  find . -name vssver2.scc -o -name '*.o' -delete && \
  rm src/G* && \
  git checkout \
    src/arch/i386/boot/acpi.c src/arch/i386/init/ldscript_fallback_cbfs.lb \
    src/arch/ppc/include/ppc74xx.h src/arch/ppc/include/ppc750.h \
    src/config/LinuxBIOSDoc.config src/config/doxyscript.base \
    src/cpu/ppc/ppc4xx/pci_bridge.c src/cpu/x86/mtrr/mtrr.c \
    src/cpu/x86/tsc/delay_tsc.c src/lib/malloc.c targets/buildtarget \
    util/mptable/mptable.c $(git status|awk '/util.vgabios/ {print $3}')

Step 3: Start making commits..
One commit per obvious logical change in existing code and I'd
suggest one commit each for cpu/model_c7, northbridge/vx900 and
mainboard/vt8595a+target/vt8595a additions.

Obviously study src/cpu/via/car/cache_as_ram.inc changes carefully,
as with all other changes to existing code.

Step 4: Consider rebasing. Let's think about that later.

//Peter

Rebasing a 2009 branch on current master (VX900 anyone?)

[Cristian Măgherușan-Stanciu]

Wow, I can't believe I was so close to the commit before the fork ;-D​

I also think this is a good strategy, please keep us posted on any progress.

Cheers,
Cristi