@michalsc

Quote:

michalsc wrote: @Geri It does require uImage unfortunately (uImage contains the header which UBoot requires). ub2lb does support initrd images (again, with UBoot header), dunno whether the slb can handle them too.

AFAIK the SLB can't handle standalone ramdisk images, as it only accepts one argument as image name (it may be able to load a combined kernel/ramdisk image). But support for initrd images is a big step forward! IMHO another absolute requirement is a configurable load addess. The SLB always uses 0x00500000 as load address for uImages. That can be a problem for newer kernel images, which have their entry point at 0x00400000. On the other side it may not be a problem for the Sam440 board, but for the A1.

_________________
A1SE: G3@600MHz, 2GB, 1GBit network card
A1XE: G4@933MHz, 2GB, refitted AC'97 codec
microA1: G3@800MHz, 1GB

- A1 Linux support -

@Geri

Just make the entry point be where the bootloader loads it?

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@michalsc

Uhm, isn't this whole discussion flawed? Isn't it the first level bootloader that is looking on the CD for an slb?

The slb is located on the media itself, therefore you don't need to modify the slb to support reading initrd images from a CD, you just put ub2lb on the CD instead of slb and off you go?

Or am I missing something crucial?

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@olegil

Quote:

olegil wrote: @Geri Just make the entry point be where the bootloader loads it?

The SLB just loads the image and hands over to U-boot then. Since U-boot still has to decompress the kernel image, it would overwrite the image it has to decompress (because the load address overlaps the entry point - correct me, if I'm wrong).
AFAIK a standard PPC Linux kernel always starts from address 0. A huge kernel image would again overwrite its own uImage during decompression. The simplest solution here would be a U-boot environment variable that the SLB can read and uses as load address for a uImage (bootm already accepts a load address as argument).

_________________
A1SE: G3@600MHz, 2GB, 1GBit network card
A1XE: G4@933MHz, 2GB, refitted AC'97 codec
microA1: G3@800MHz, 1GB

- A1 Linux support -

@olegil

Quote:

hm, isn't this whole discussion flawed? Isn't it the first level bootloader that is looking on the CD for an slb?

Yes, it is. The first level bootloader has also another name: boota. It scans the boot media (three of them in user defined order) after the slb and executes it. What happen next is up to the slb itself.

Quote:

therefore you don't need to modify the slb to support reading initrd images from a CD, you just put ub2lb on the CD instead of slb and off you go?

Yes, kind of. Just keep in mind ub2lb uses different it's own format of menu.lst file (the menu file which defines what entries/boot options/modules/kernel parameters/initrd images are to be used)

But, going back toward UBoot bugs.
- Some parts of boota command do allocate memory bud never free it back (they assume boota command completes with success).
- boota command uses getenv function to read some environment variables from nvram. Since it does not copy the envs but uses only a pointer to them, it fails in some cases (the tftp boot provided by uboot sets some environment variables by itself. After that, the pointers returned previously by getenv calls are invalid but still used by UBoot).

@olegil

Quote:

El Torito, what and what?

El Torito (pdf spec) modes "Floppy Booting", "Hard Disk Booting" and "No Emulation Booting" (see page 16), three completely separate methods, any of which, in 2001, a BIOS was not unlikely to not support correctly.

In 2001, the most widely supported one was floppy booting.

@olegil

Quote:

endlessly for about 30 seconds?

Yes it is. I timed it tonight. I'd have to eject the CD to get out of it.

@olegil

Quote:

So you think that not being more advanced than a PC bios is a bug? Seriously, there is one way to make an auto-bootable CD on the AmigaOne, much the same way there's one way to make an auto-bootable CD on a PC.

When did I say I wanted UBoot more advanced than a PC BIOS? When the FLB gets stuck on CD because it thinks it's an Amiga one that is a bug.

So you are saying that the only way to get a CD to boot on the AmigaOne is make an OS4 one that could also boot Linux? How would that be done.

Quote:

Would be smarter to make Linux boot the same way. UBoot has never before supported autodetection of boot devices, the Amiga extensions are improvements, not bugs. So instead of whining about UBoot, fix Linux so it'll create boot CDs that are compatible with the mechanisms used.

Linux can't be fixed for that. Booting a CD is seperate to Linux. Anyway the AmigaOne bootable Linux CDs use the El Torito booting method which has been suppoted since day 1 in UBoot. It is it's native method. It is called MSDOS booting in MakeCD and infact is what an OS4 bootable CD is also built on.

UBoot is the one that doesn't support standard PPC booting methods. We can't boot a Debian Linux Cd directly because UBoot isn't officially supported. Debian supports the OpenFirmware standard. So UBoot would need an OF emulator to boot standard CDs. What's more, the situation isn't good, as a Debian CD will even boot directly on a Pegasos. That makes Linux on the A1 suck even more.

@michalsc

Quote:

Amiga bootable CD for UBoot conforms the El Torito standard. Here, the slb is embed on CD.

In that case, "if it's an Amiga El Torito bootable CD then boot it, if it's a Linux El Torito CD then boot it..."

@Hypex

Is it endless or does it end after 30 seconds?

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@Hypex

Quote:

Hypex wrote: @olegil UBoot is the one that doesn't support standard PPC booting methods. We can't boot a Debian Linux Cd directly because UBoot isn't officially supported. Debian supports the OpenFirmware standard. So UBoot would need an OF emulator to boot standard CDs. What's more, the situation isn't good, as a Debian CD will even boot directly on a Pegasos. That makes Linux on the A1 suck even more.

Booting a Debian CD on the A1 can and should be fixed in Debian. For example there is a file called yaboot on the install CD that is used as bootloader on PowerMacs. Thus Debian should either add direct support for Uboot image files or we include a second level bootloader on the CD.

_________________
A1SE: G3@600MHz, 2GB, 1GBit network card
A1XE: G4@933MHz, 2GB, refitted AC'97 codec
microA1: G3@800MHz, 1GB

- A1 Linux support -

@Hypex

Quote:

I'm not saying to rid of CD booting all together, I am saying that it needs to be improved so it works as it should. Right now you can only boot from a Linux or AmigaOS CD. And if you have a Linux CD in the drive the OS booter will search it endlessly for an Amiga boot block for about 30 seconds until it gives up. It does this for each CD.

I can't say that I've noticed this. If that is the case, then it is something that needs to be improved.

Quote:

Amiga bootable CD's have an ID like "AMIGA BOOT" on them. If that isn't on the CD it should stop looking and boot the HD.

What about Linux boot CDs?

Quote:

Quote: I agree that UBoot isn't the greatest, but, I'd rather that they focus on the OS instead. The OS has been focused on. But UBoot has been left for years. It's time for an update!

But there's so much still to be done on the OS. To be honest, working on the BIOS is supposed to be done by the motherboard manufacturer, not by the OS developers. Unfortunately, the Amigaone manufacturer isn't involved in the Amiga scene any more.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Geri

Quote:

The SLB always uses 0x00500000 as load address for uImages. That can be a problem for newer kernel images, which have their entry point at 0x00400000

What! You mean that there is only 0x100000 bytes left for the kernel? 1 MB!

What about using something higher than 500000 in the diskboot line?

Quote:

On the other side it may not be a problem for the Sam440 board, but for the A1.

Because they have a newer UBoot?

@olegil

Quote:

Is it endless or does it end after 30 seconds?

It gives up after 30 seconds. With two discs it delays the booting by a minute.

@Geri

Quote:

Booting a Debian CD on the A1 can and should be fixed in Debian. For example there is a file called yaboot on the install CD that is used as bootloader on PowerMacs. Thus Debian should either add direct support for Uboot image files or we include a second level bootloader on the CD.

Good point. I find it hard to beleive that UBoot would be used in commercial embedded boards if it isn't supported by a major Linxu distro. Is UBoot actually used in the commercial market anywhere or is it a poor mans bootloader?

I do wonder if mkisofs can directly modify ISO images so that a UBoot image can be grafted on and El Torito type set?

I suppose a vmlinux image can't be directly loaded anyway on the A1.

Otherwise I am struggling myself just to find a kernel I can turn into an image.

Last edited by Hypex on 18-Jul-2008 at 09:45 AM.

@Hans

Quote:

I can't say that I've noticed this. If that is the case, then it is something that needs to be improved.

Thankyou!

Quote:

What about Linux boot CDs?

Depends on the booter. It seems to mostly get stuck on El Torito CDs.

Quote:

But there's so much still to be done on the OS. To be honest, working on the BIOS is supposed to be done by the motherboard manufacturer, not by the OS developers. Unfortunately, the Amigaone manufacturer isn't involved in the Amiga scene any more.

I know, but I am asking for only small changes. Mainly bugfixes. I know MAI used UBoot, bit I don't think they wrote it! Yes we are without a motherboard manufacturer.

But is was HJF and co. that put work into UBoot for the A1 and also the OS4 booting ability.

@Hypex

Quote:

Hypex wrote: @Geri Quote: The SLB always uses 0x00500000 as load address for uImages. That can be a problem for newer kernel images, which have their entry point at 0x00400000 What! You mean that there is only 0x100000 bytes left for the kernel? 1 MB!

Yes.

Quote:

What about using something higher than 500000 in the diskboot line?

Sure, you can use a higher address with diskboot and tftpboot. But you can't change the load address that is used by the SLB.

Quote:

Quote: On the other side it may not be a problem for the Sam440 board, but for the A1. Because they have a newer UBoot?

Yeah, AFAIK their U-boot firmware supports device trees. Thus the Sam440 can boot newer kernels in uImage format which still have their entry point at 0x0.

_________________
A1SE: G3@600MHz, 2GB, 1GBit network card
A1XE: G4@933MHz, 2GB, refitted AC'97 codec
microA1: G3@800MHz, 1GB

- A1 Linux support -

@Hypex

Quote:

Hypex wrote: @Geri Good point. I find it hard to beleive that UBoot would be used in commercial embedded boards if it isn't supported by a major Linxu distro. Is UBoot actually used in the commercial market anywhere or is it a poor mans bootloader?

Oh, it's used a lot in commercial embedded boards. However these board normally don't run full-featured distributions like Debian (usually something like ELDK, Montavista Linux or OpenWRT).

Quote:

I do wonder if mkisofs can directly modify ISO images so that a UBoot image can be grafted on and El Torito type set?

That would be worth to try out.

Quote:

I suppose a vmlinux image can't be directly loaded anyway on the A1.

It can be, if you write your own SLB that loads and starts the kernel by itself. For now we have to live with U-boot.

Quote:

Otherwise I am struggling myself just to find a kernel I can turn into an image.

The standard U-boot way of booting should always work. I only see a problem, if you want to boot both Linux and OS4 with the SLB. It works fine, but there are some things that could be improved.

_________________
A1SE: G3@600MHz, 2GB, 1GBit network card
A1XE: G4@933MHz, 2GB, refitted AC'97 codec
microA1: G3@800MHz, 1GB

- A1 Linux support -

@Geri

Quote:

Yes.

So does it compress to 0x400000 or to 0 and copies it?

How does an old 1.4MB 2.4 kernel fit even?

Quote:

Sure, you can use a higher address with diskboot and tftpboot. But you can't change the load address that is used by the SLB.

Okay, so this wouldn't matter if it loaded it high and then unpacked it low?

What about uncompressed, would that be better?

Quote:

Yeah, AFAIK their U-boot firmware supports device trees. Thus the Sam440 can boot newer kernels in uImage format which still have their entry point at 0x0.

Lucky for them. Can things start at 0? Does UBoot have to relocate the code or is it PC-relative?

Quote:

Oh, it's used a lot in commercial embedded boards. However these board normally don't run full-featured distributions like Debian (usually something like ELDK, Montavista Linux or OpenWRT).

Okay, so is there a live CD of one of these we could try out? I suppose the kernel would break. Or they use newer UBoots!

Quote:

That would be worth to try out.

Guess I would need to read up on it and what it can do. I've suggested a complicated thing like that before!

Quote:

It can be, if you write your own SLB that loads and starts the kernel by itself. For now we have to live with U-boot.

Hmmm, okay. But any vmlinuz would crash it right? We'd need an A1 specific kernel still?

Quote:

The standard U-boot way of booting should always work. I only see a problem, if you want to boot both Linux and OS4 with the SLB. It works fine, but there are some things that could be improved.

Yes, of course.

Last edited by Hypex on 23-Jul-2008 at 06:58 AM.

@Hypex

Quote:

Hypex wrote: @Geri So does it compress to 0x40000 or to 0 and copies it?

The kernel image is decompressed to 0x00400000 and a simple bootloader is started at this address, which initializes the device tree and hands it over to the kernel.

Quote:

How does an old 1.4MB 2.4 kernel fit even?

The correct number is 0x00400000. You missed a 0.

Quote:

Okay, so this wouldn't matter if it loaded it high and then unpacked it low?

Yes, at least I think so. (Slowly but surely I get confused with all this addresses! )

Quote:

What about uncompressed, would that be better?

I'm not sure, if U-boot supports that. But even in that case you would have to modify the SLB.

Quote:

Lucky for them. Can things start at 0? Does UBoot have to relocate the code or is it PC-relative?

If I understand it correctly the kernel is not relocatable, but don't nail me down to that.

Quote:

Okay, so is there a live CD of one of these we could try out? I suppose the kernel would break. Or they use newer UBoots!

Embedded boards rarely have a CDROM drive. They usually boot from a FLASH ROM.

Quote:

Hmmm, okay. But any vmlinuz would crash it right? We'd need an A1 specific kernel still?

Yes, you always need a A1 specific kernel as long as U-boot doesn't provide a device tree on its own (currently a minimal device tree is build into the kernel image and that is A1 specific).

_________________
A1SE: G3@600MHz, 2GB, 1GBit network card
A1XE: G4@933MHz, 2GB, refitted AC'97 codec
microA1: G3@800MHz, 1GB

- A1 Linux support -