@Spectre660

Are you teasimg us here or dropping hints?

Last edited by Hypex on 09-Jan-2015 at 10:22 AM.

@Hypex

Quote:

Hypex wrote: @Geri Three resons come to mind: 1.) It doesn't support FFS2 and that would have to be added in. 2.) I kinda hacked some things in there for the installer so would need to clean it up or split ot off into a different build. 3.) I don't like the idea of replacing a persons SLB. Seems to far just to install Linux and I have seen a friends OS4 system break because of this. Or because of number 1.

Sure, it should be the user's decision, whether he wants to use a different second level bootloader or not. I was thinking more about detecting which bootloader is installed in the RDB and installing the right bootloader scipts under Linux so that boot entries are still created correctly. This would give the user the freedom to install his preferred bootloader beforehand. At least he could choose between a separate boot partition with the slb_v2 or no boot partition using Parthenope.

Quote:

Quote: U-Boot settings in general aren't changed a lot, so that shouldn't hurt. No but I have thought of doing it. Infact I could probably automate it to do it from the SLB. If it doesn't break the boot.

I think I got a little bit confused with this. So actually your modified bootloader would have to do two things:
1. set the programming interface register for booting the installer and
2. modifying the bootcmd variable to include the pci write commands for subsequent boots from the HD.

I wish I had the time and knowledge to work on a new U-Boot firmware to render such workarounds unncessary.

Quote:

Quote: Where there any specific objections raised? Yes, but more a question that objection. For example, "/boot" is setup in installer menu for boot volume, why can't that be used?

The concept is borrowed from PCs with UEFI firmware. For the native UEFI boot mechanism a FAT formatted partition is mounted under /boot/efi, which contains the UEFI compatible GRUB bootloader. This partition also needs to be set up during installation (if not already there).

Quote:

People can also wonder about this extra "a1boot" folder and why it is there. Or not there in testing.

This folder is more or less the equivalent of the "efi" (/boot/efi) folder on UEFI PCs. Actually on the A1 the user should not setup a boot partition mounted under /boot, but a spare partition (similar to the FAT formatted partition above) that is later on mounted under /boot/a1boot/ and which serves as emulation layer for the slb_v2 second level bootloader.

This emulation layer resp. spare partition is necessary, because:

- the slb_v2 can only read EXT2/3 partitions with an inode size of 128 bytes and
- the slb_v2 expects the a1boot.conf file in the /boot folder of a Linux root partition! So strictly speaking it's the slb_v2 that doesn't know about boot(-only) partitions!

On the other side this spare partition has the following advantages:

- the Linux root file system can use an optimized inode size or even a more advanced filesystem like ext4 or even the next generation Linux file system (btrfs).
- it supports multiple Linux installtions in a non-conflicting manner: they can use the same or different Linux kernel versions, boot arguments, initramfs images...whatever.
- it cleanly separates the files needed for the slb_v2 from the installed Linux system: all in all it just depends on the perceptions of the installed Linux system and the slb_v2. For the installed Linux system the /boot folder looks like on any other PC Linux installation (with the kernel and initramfs images, the System.map file and the kernel config file). For the slb_v2 the spare partition only contains the actual boot images, which are automatically updated on every kernel package installation and thus kept in sync with the images in /boot/.

Quote:

I'm used to it now. Even if "/boot/a1boot" isn't at "/boot".

Right, /boot/a1boot/boot/ is /boot for the slb_v2, because it sees the spare partition as a root file system on its own. For the installed Linux system the normal /boot folder on the root partition is... well... /boot.

Maybe you can point users to this post for now, until there isn't a better explanation.

_________________
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: @Spectre660 Are you teasimg us here or dropping hints? ;-(

Looks like teasing! We don't have Debian Jessie yet!

Well, it's just a matter of time...

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

- A1 Linux support -

@Geri

This is teasing
http://forum.hyperion-entertainment.biz/viewtopic.php?f=52&t=2238&start=20#p30706

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

@Spectre660

Quote:

Spectre660 wrote: @Geri This is teasing http://forum.hyperion-entertainment.biz/viewtopic.php?f=52&t=2238&start=20#p30706

True!

Years ago I also tested lots of Linux installations on my A1XE. Unfortunately I don't have so much spare time anymore...

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

- A1 Linux support -

@Geri

I like to see what works.
We even managed a working Lubuntu 14.10 installer for Sams
even though there was no Powerpc release for 14.10.
The Interesting thing has been that the graphics performance has been improving
with the newer versions even thought there is no DRI .

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

@Spectre660

Quote:

Spectre660 wrote: @Geri The Interesting thing has been that the graphics performance has been improving with the newer versions even thought there is no DRI .

That's good to hear. Does DRI work on the Sam440 boards now too or still only on the Sam460?

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

- A1 Linux support -

@Geri

No DRI on either the Sam440 nor Sam460 with my kernels.
For some reason there if a failure in the ring buffer test.
So software rendering only .

Quote:

Geri wrote: @Spectre660 Quote: Spectre660 wrote: @Geri The Interesting thing has been that the graphics performance has been improving with the newer versions even thought there is no DRI . That's good to hear. Does DRI work on the Sam440 boards now too or still only on the Sam460?

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

@Geri

Quote:

At least he could choose between a separate boot partition with the slb_v2 or no boot partition using Parthenope.

Okay, good idea, didn't think of that. Of course as it stands the A1 has only one bootloader.

It would need extra code to install it into the RDB.

Quote:

So actually your modified bootloader would have to do two things:

Yes. A script could be created that does the pci write so as not to obfuscate the bootcmd. Then something like "run disable_a1ide" could be inserted that's easy enough to understand.

Quote:

For the native UEFI boot mechanism a FAT formatted partition is mounted under /boot/efi, which contains the UEFI compatible GRUB bootloader

Okay I see now. That reminds me, I did install Linux to on an Intel Mac, which uses UEFI or EFI. But I forget if it needed boot volume.

Quote:

Actually on the A1 the user should [b]not setup a boot partition mounted under /boot[\b]

I always thought that /boot was strange. That is there is a boot volume mounted at /boot which so far looks normal. But then /boot has other files in it and if it has a boot folder then /boot/boot/ occurs which looks repetitive. Or recursive since this is Linux. Be okay perhaps if it could point to boot folder of boot volume. Can a mountpoint specify a folder off a device?

Of course /boot/a1boot/ gets equally strange when it turns into /boot/a1boot/boot/...

Being able to change the "/boot" when mounting boot volume would be good as well in the installer menu. I may have mentioned that earlier before.

Quote:

- the Linux root file system can use an optimized inode size or even a more advanced filesystem like ext4 or even the next generation Linux file system (btrfs).

Are they replacing ExtX? Just when it was getting good. Well we could use btrfs too I suppose if it's in the kernel.

Quote:

Maybe you can point users to this post for now, until there isn't a better explanation.

When we have users who can install normally without having to stop the installer and mod around.

@Hypex

Quote:

Hypex wrote: @Geri Okay, good idea, didn't think of that. Of course as it stands the A1 has only one bootloader. It would need extra code to install it into the RDB.

We could leave that up to the user, as he has to know what to do in this case (because it would also affect booting of OS4). You know: make the common case fast (or easy in our case) and the rare case correct (or don't mess it up in our case).

Quote:

Quote: So actually your modified bootloader would have to do two things: Yes. A script could be created that does the pci write so as not to obfuscate the bootcmd. Then something like "run disable_a1ide" could be inserted that's easy enough to understand.

True, a script is much better in this case.

Quote:

Quote: For the native UEFI boot mechanism a FAT formatted partition is mounted under /boot/efi, which contains the UEFI compatible GRUB bootloader Okay I see now. That reminds me, I did install Linux to on an Intel Mac, which uses UEFI or EFI. But I forget if it needed boot volume.

Hmm, I guess it already existed. But Apple usually does it's own thing and makes things different...

Quote:

Quote: Actually on the A1 the user should [b]not setup a boot partition mounted under /boot[\b] I always thought that /boot was strange. That is there is a boot volume mounted at /boot which so far looks normal. But then /boot has other files in it and if it has a boot folder then /boot/boot/ occurs which looks repetitive. Or recursive since this is Linux. Be okay perhaps if it could point to boot folder of boot volume. Can a mountpoint specify a folder off a device?

Well, strictly speaking you can setup a boot partition mounted under /boot, but it could not be used in the same way as the partition mounted at /boot/a1boot/. Thus it's basically useless.
I'm not sure what you mean with a mountpoint off a device, but a mountpoint always has to be within the scope of the root file system.

Quote:

Of course /boot/a1boot/ gets equally strange when it turns into /boot/a1boot/boot/...

/boot and /boot/a1boot/[boot] are simply two different things. The first is for the Linux installation. The second is just for the bootloader and only needs to be mounted in the Linux installation's root file system for kernel updates and to edit the boot entries. Otherwise it would not be interesting for the Linux installation.

Quote:

Being able to change the "/boot" when mounting boot volume would be good as well in the installer menu. I may have mentioned that earlier before.

What would this be needed for?

Quote:

Quote: - the Linux root file system can use an optimized inode size or even a more advanced filesystem like ext4 or even the next generation Linux file system (btrfs). Are they replacing ExtX? Just when it was getting good. Well we could use btrfs too I suppose if it's in the kernel.

I don't think they're going to replace Ext with it. btrfs is what zfs is for BSD, a next generation filesystem that can do most things out of the box: e.g. using two harddisks as a RAID without having to setup a RAID device first. This gives the filesystem more information for e.g. error recovery.

Quote:

Quote: Maybe you can point users to this post for now, until there isn't a better explanation. When we have users who can install normally without having to stop the installer and mod around.

That's the plan!

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

- A1 Linux support -

@Geri

Quote:

Geri wrote: @Hypex Quote: Hypex wrote: @Geri U-Boot settings in general aren't changed a lot, so that shouldn't hurt. No but I have thought of doing it. Infact I could probably automate it to do it from the SLB. If it doesn't break the boot.

I think I got a little bit confused with this. So actually your modified bootloader would have to do two things:
1. set the programming interface register for booting the installer and
2. modifying the bootcmd variable to include the pci write commands for subsequent boots from the HD.

I wish I had the time and knowledge to work on a new U-Boot firmware to render such workarounds unncessary.
[/quote]

I actually dabble in UBoot for money, occasionally. Sort of UProstitution, or possibly even "Senior Development Engineer"-ing. Do we have the exact sources used to compile the one you're using now? There's also the missing SATA booting that people are practically begging for

_________________
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: I actually dabble in UBoot for money, occasionally. Sort of UProstitution, or possibly even "Senior Development Engineer"-ing. Do we have the exact sources used to compile the one you're using now? There's also the missing SATA booting that people are practically begging for

There's the uboot-amigaone project on sourceforge.net, where I uploaded the sources for two U-Boot versions a long time ago as GIT repositories (I think 1.1.0 and 1.1.4). Unfortunately Sourceforge.net changed they project web interface again so I can't find the link to the sources at the moment, but I should have them on a harddisk somewhere as well.

There are also newer U-Boot images floating around. For example I'm using v1.1.4 to boot from a SATA harddrive.

The best would naturally be to develop/build a new U-Boot firmware (to fix the remaining shortcomings of the current U-Boot firmware) based on the current U-Boot sources, given that U-Boot's code structure has improved a lot in the last time (Kconfig system, FDT support, common driver model, etc..). Unfortunately support for the 6xx PowerPC CPUs (as used by the A1) was just dropped these days. Not to speak of the AmigaOne platform code, which was dropped some years(?) ago.

BTW: could you give me an introduction to U-Boot programming?

Last edited by Geri on 16-Jan-2015 at 08:17 PM.

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

- A1 Linux support -

@Geri

well, MOST updates to UBoot are simply new boards being supported, which would give absolutely zero benefit to us (since our got dropped ). But obviously, SOME updates might add useful drivers.

This SATA boot you're talking of, why don't more people use that? Would it load AOS?

_________________
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 well, MOST updates to UBoot are simply new boards being supported, which would give absolutely zero benefit to us (since our got dropped ). But obviously, SOME updates might add useful drivers.

I remember that Freescale submitted a full driver for the Silicon Image SATA controllers. The current one only supports booting from two ports and IIRC doesn't rescan devices on a ide reset command.

Quote:

This SATA boot you're talking of, why don't more people use that? Would it load AOS?

Yes, it can boot OS4. This U-Boot version was never officially released by Hyperion for some reason. I guess that's the reason why it isn't in widespread use.

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

- A1 Linux support -

@Geri

Eh, UBoot still supports 7xx and 74xx, which in my naive little head includes the 750CXe, 750FX and all the 74XX variants used by all A1s I ever heard of.

But the platform code is gone, yes. There's still a bios emulator, so it shouldn't be that hard to put the AmigaOne code back in.

The hard part is doing this without jtag. Allthough UBoot can load UBoot, but of course some things would already be set up so it's difficult to know that all is correct. A flash burner seems useful here. Technically I don't have a working A1 any more, though.

_________________
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 Eh, UBoot still supports 7xx and 74xx, which in my naive little head includes the 750CXe, 750FX and all the 74XX variants used by all A1s I ever heard of.

The patch to remove all remaining 74xx_7xx boards was just merged today. So the next U-Boot release will come without support for these CPUs, as far as I can tell.

https://patchwork.ozlabs.org/patch/429447/

Quote:

But the platform code is gone, yes. There's still a bios emulator, so it shouldn't be that hard to put the AmigaOne code back in.

True, the BIOS emulator is still there and I think even used by other boards.

Quote:

The hard part is doing this without jtag. Allthough UBoot can load UBoot, but of course some things would already be set up so it's difficult to know that all is correct. A flash burner seems useful here. Technically I don't have a working A1 any more, though.

Yes, it will be a hard job without a debugger (at least before any serial console is up and running). We (Bill Toner and I) planned to flash a testing U-Boot version directly by using the AmigaOne itself. That's why I made a simple DualUBootA1 PCB that can hold two flash ROMs and allows to boot from one of the two firmwares.

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

- A1 Linux support -

@Geri

As for UBoot programming, I suggest starting with one of the application notes by Freescale on the subject matter, my first board took about half an hour for rudimentary support

I used http://cache.freescale.com/files/32bit/doc/app_note/AN3765.pdf at the time, as I was making an MPC5121e board. However, that was way back before all these new things, so ymmv.

_________________
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.

@Geri

(re deletion of 7xx_74xx):
Which again is not much of a problem given that you can just use todays git, which still has it. You seem to think that running the latest release is beneficial by default, but this just isn't so. This is not Linux, it's just a bootloader. Does your old PC require an up-to-date EFI boot the latest Linux?

_________________
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 As for UBoot programming, I suggest starting with one of the application notes by Freescale on the subject matter, my first board took about half an hour for rudimentary support I used http://cache.freescale.com/files/32bit/doc/app_note/AN3765.pdf at the time, as I was making an MPC5121e board. However, that was way back before all these new things, so ymmv.

Yes, this looks really outdated. I'm afraid even the makefile system has changed in the meantime.

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

- A1 Linux support -

@olegil

Quote:

olegil wrote: @Geri (re deletion of 7xx_74xx): Which again is not much of a problem given that you can just use todays git, which still has it. You seem to think that running the latest release is beneficial by default, but this just isn't so.

I know that it is still in an older git version and that I can make a branch of that version to develop the AmigaOne support. But the work on the A1 Linux kernel support has taught me that development is easier, if you can submit your code ealier to upstream. And the missing 74xx_7xx support definitely makes that harder. I don't think they allow a simple revert of the commit without a huge code rework (it was not only removed, because the boards we're not in use anymore).

Quote:

This is not Linux, it's just a bootloader. Does your old PC require an up-to-date EFI boot the latest Linux?

Surely not. Although EFI firmwares could see more frequent updates, given that they had severe security holes in the not so distant past.

Last edited by Geri on 17-Jan-2015 at 12:30 PM.

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

- A1 Linux support -