We link with libsa here, so this shouldn't be needed.

This shouldn't be needed because we link with libsa.

OK, this changes things.

USE_SMALL_CGBASE is there so that i386 will use smaller than 64-bit disk addresses to do some computations that shouldn't need 64-bit numbers. By doing this, you remove that optimization which has been required to stay small enough in the past.

You've also broken the ability to compile for only UFS1 or UFS2

I'd be tempted to put them into ufsread.h: (a) so that we don't get conflicting decls and (b) the impl matches the decl :)

This is likely not needed here. BERI boot2 isn't under the extreme size pressures and if it had it before, it was because it was blindly copied from i386.

These should be in ufsread.h... The other advantagae is that you aren't declaring forward references to globals just to avoid warnings. Solves the warning, but not the problem the warning is trying to prevent.

ufsread.c isn't built into libsa, the code just lives there. We could change this though.

Same as above.

If you check the Makefile I define this when I compile ufsread.c

Yep, I'd be fine with this.

I can take it out. I'll double-check with @rwatson and @brooks and co.

Yeah, makes sense. It just felt like that was the wrong place to put those. Maybe we need another boot.h or something.

Please do. It belongs there. It creates a whole crapton of problems to have files that are compiled N different ways in N different places, so if we can put it in libsa, it should go into libsa.

Oh, right, the whole reach over and compile it N different ways problem that I so dearly love.

beri's boot2 blindly copied way too much from boot2 on i386, and it's been a big hassle, so the few cargo-culted changed because it was like that on x86 we have here the better.

That's usually called 'stand.h' :)

But we have too many space constrained loaders, so maybe we need to think about the bigger picture.

But in this case, these are interfaces that are required to use ufsread.h. We either need to put them in there, or clearly articulate what every single include of ufsread.h should also include. Since that's a ticklish problem that might have lots of sprawl were we to implement it, I suspect you don't want to do that as part of this review.

Also boot.h is likely the wrong name since it conflicts, I believe, with other files of that name, possibly not located in /stand

This seems fine. We've got quite a bit of storage on the FPGA and we don't support 32-bit at all at this point so 64-bit math is fine (if I understand the comments above.)