Re: [PATCH] sparc: fix tftpboot.img build

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jun 19, 2009 at 13:46, David Miller<davem@xxxxxxxxxxxxx> wrote:
> From: Julian Calaby <julian.calaby@xxxxxxxxx>
> Date: Fri, 19 Jun 2009 12:18:50 +1000
>
>> Looking at the code of piggyback_32.c and piggyback_64.c, there aren't
>> that many differences - I think that these could easily be merged into
>> a single file.
>>
>> I'm at work at the moment, but I'll have a closer look tonight.
>
> Thanks for looking into this Julian.

Ok, the primary differences between the sparc64 and sparc32 piggyback tools are:
1. The sparc32 version has had some "endian fixes" applied to it back in 2000.
2. The sparc64 version performs an extra step and has some code work
in a slightly different way. (e.g. it goes straight to the HdrS
signature in the ELF header rather than searching for it like sparc32)
3. The (I assume) header is calculated slightly differently. (it uses
8191 for a constant in sparc64 and 4095 in sparc32)

I think that the bulk of the changes would fit under the umbrella of
"endian fixes", and would really like to get hold of the "endian fixes
for cross-compiles" patch from Pete Zaitcev <zaitcev@xxxxxxxxx> (CC'd)
which was applied to arch/sparc/boot/piggyback.c (as it was at the
time) some time in 2000. The problem is that none of the git trees I
can find go back any further back than 2002-02-05.

This patch would probably apply to the sparc64 version without many
changes, and would probably make them almost identical apart from the
constant and extra step mentioned above.

I'd also really like to look at the history of this file before it was
renamed to piggyback_32.c, however this doesn't seem to be available
in any convenient, readily available form. There have been no
significant changes to it apart from Sam's sparc32 / 64 merge work
since the limit of the history I can find.

I'm going to try to mangle piggyback_64.c to match how piggyback_32.c
works as it's mostly abstracting some of the fancier casts into
functions, however I'm not sure which one reliably works, (I'm
guessing the *_64.c) so this is pretty much a shot in the dark for the
moment.

After that, I'll try to organise build tests here, but I don't
actually have a fully working 32 bit sparc machine to run these on.
... However, it doesn't have to run, just boot over the network, which
I'm all set up to do, so arguably if the kernel loads, that's success
... I'll have to think a bit more about that.

Thanks,

-- 

Julian Calaby

Email: julian.calaby@xxxxxxxxx
.Plan: http://sites.google.com/site/juliancalaby/
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Kernel Development]     [DCCP]     [Linux ARM Development]     [Linux]     [Photo]     [Yosemite Help]     [Linux ARM Kernel]     [Linux SCSI]     [Linux x86_64]     [Linux Hams]

  Powered by Linux