AW: AW: [Oberon] USB Boot

[Stauber Sven Philipp]

Hi,
 
>At that point I read through the source for the linker and boot loader, and I had the impression that the bootloader executed >in real mode, so it only had access to the legacy 640Kb memory limit, and so the linker limit was not so much an >unfortunately chosen constant as a hard engineering constraint. 
Yes, unfortunetely. I'm still working with an older release where the USB boot file is ~580K (which works). Some tests showed that the boot process will hang at "Oberon loading" if the boot file does not fit into 640K. I'll try to make the USB files somewhat smaller.
 
Things you can do for making it smaller by just re-linking it:
- Don't link AosATADisks into AosUSB.Bin - load it later via config string
- Don't link all USB host controller drivers into AosUSB.Bin (AosUsbOhci is required for OHCI HC's, AosUsbUhci for UHCI HC's and AosUsbEhci for high-speed transfers (EHCI HC's always have integrated UHCI or OHCI HC's to support low-/fullspeed transfers)).
-Set various Debug variables to FALSE

Cheers,
Sven Stauber



________________________________

Von: oberon-bounces at lists.inf.ethz.ch im Auftrag von Aubrey McIntosh
Gesendet: Di 17.01.2006 17:47
An: oberon at lists.inf.ethz.ch
Betreff: Re: AW: [Oberon] USB Boot





-- Aubrey McIntosh, Ph.D.
  

>>> kellerog at student.ethz.ch 1/17/2006 1:27 AM >>>
> On the linking, if I put the Dec. 19 Crazy fresh release on a CD, change the Ramdisk size to 140Mb, and change the Linker parameters to build the file onto RAM: and read the binaries from CD:, the system traps in Bblinker0.Relocate.  Has anyone built AosUSB.Bin from the distributed image?

can you tell us what value the constant HeapSize in BbLinker0 on your
machine has? it's possible, that you do have the version where the
linker-internal heap is 512KB at most, which usually leads to the trap
you described. to fix that, you can just multiply the value by 2,
compile, free and use again ...


--roger


Hi Roger,

The value in the release is 2 * 512 * 1024;

When I free & re-compile  (with PC.Compile :-) I get the same trap.  When I change the value to 4*512*1024, I get a trap at the same pc, but a different value of adr.

The ASSERT is failing on the third term in the expression.  I assume that it is easy for you to reproduce this, and there is no need to clutter the mailing list with dumps.

When I was working on AosFtpFS, I frequently had .Bin files that produced traps.  At that point I read through the source for the linker and boot loader, and I had the impression that the bootloader executed in real mode, so it only had access to the legacy 640Kb memory limit, and so the linker limit was not so much an unfortunately chosen constant as a hard engineering constraint. 

I ended up having to remove some functionality, I think XML configuration support, in order to obtain a working .Bin file. 



--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon