| View previous topic :: View next topic |
| Author |
Message |
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1350
Location: Richmond Hill, Canada
|
 Posted: Sat Dec 18, 2021 12:26 am Post subject: |
 |
|
| manphiz wrote: | Thanks guys! So I figured out that to properly build qemu with USE="static-user static" I need to build all its dependencies with "static-libs". Now I have this
| Code: | gentoo-vm /usr/mips64el-unknown-linux-gnu # file /usr/mips64el-unknown-linux-gnu/usr/bin/qemu-mips*
/usr/mips64el-unknown-linux-gnu/usr/bin/qemu-mips64el: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, stripped
/usr/mips64el-unknown-linux-gnu/usr/bin/qemu-mipsn32el: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, stripped
gentoo-vm /usr/mips64el-unknown-linux-gnu # file /usr/mips64el-unknown-linux-gnu/bin/bash
/usr/mips64el-unknown-linux-gnu/bin/bash: ELF 32-bit LSB pie executable, MIPS, N32 MIPS-III version 1 (SYSV), dynamically linked, interpreter /lib32/ld.so.1, for GNU/Linux 3.2.0, stripped
gentoo-vm /usr/mips64el-unknown-linux-gnu # file /usr/mips64el-unknown-linux-gnu/lib32/ld.so.1
/usr/mips64el-unknown-linux-gnu/lib32/ld.so.1: ELF 32-bit LSB shared object, MIPS, N32 MIPS-III version 1 (SYSV), static-pie linked, not stripped
|
However I still cannot chroot due to the same issue:
| Code: | gentoo-vm /usr/mips64el-unknown-linux-gnu # chroot . /bin/bash --login
chroot: failed to run command ‘/bin/bash’: No such file or directory
|
I wonder whether I need to build bash to be static? However it doesn't seem to have a static USE flag. I'm still confused. |
Did you register for mipsn32el?
Your /usr/mips64el-unknown-linux-gnu/bin/bash is | Quote: | file /usr/mips64el-unknown-linux-gnu/bin/bash
/usr/mips64el-unknown-linux-gnu/bin/bash: ELF 32-bit LSB pie executable, MIPS, N32 MIPS-III version 1 (SYSV), dynamically linked, interpreter /lib32/ld.so.1, for GNU/Linux 3.2.0, stripped |
so it will want to use | Quote: | | /usr/mips64el-unknown-linux-gnu/usr/bin/qemu-mipsn32el |
-- edit --
another way to test is try run qemu-mipsn32el, for example | Code: | | chroot /usr/mips64el-unknown-linux-gnu /usr/bin/qemu-mips32el /bin/bash |
Please note above when working only give you one bash session. no other command will work within the bash session unless you prefix command with /usr/bin/qemu-mips32el |
|
| Back to top |
|
 |
manphiz
n00b
Joined: 01 Dec 2021
Posts: 26
|
| Posted: Mon Dec 20, 2021 10:48 pm Post subject: |
|
|
Thanks pingtoo. I did register for mipsn32el:
| Code: | # ls /proc/sys/fs/binfmt_misc/
mips mipsel mipsn32el register status |
I tried your last command but it fails to find libreadline.so.8
| Code: | # chroot /usr/mips64el-unknown-linux-gnu /usr/bin/qemu-mipsn32el /bin/bash
/bin/bash: error while loading shared libraries: libreadline.so.8: cannot open shared object file: No such file or directory |
However there is one:
| Code: | # find /usr/mips64el-unknown-linux-gnu/ -name "libreadline*"
/usr/mips64el-unknown-linux-gnu/usr/lib/libreadline.so
/usr/mips64el-unknown-linux-gnu/usr/lib/libreadline.so.8.1
/usr/mips64el-unknown-linux-gnu/usr/lib/libreadline.so.8 |
Looks like something is still messed up. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9850
Location: almost Mile High in the USA
|
| Posted: Mon Dec 20, 2021 11:20 pm Post subject: |
|
|
libreadline should be in /lib or (/lib64 for 64-bit?) of the chroot normally?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1350
Location: Richmond Hill, Canada
|
| Posted: Tue Dec 21, 2021 3:50 pm Post subject: |
|
|
We are progressing 
| manphiz wrote: | I tried your last command but it fails to find libreadline.so.8
| Code: | # chroot /usr/mips64el-unknown-linux-gnu /usr/bin/qemu-mipsn32el /bin/bash
/bin/bash: error while loading shared libraries: libreadline.so.8: cannot open shared object file: No such file or directory |
However there is one:
| Code: | # find /usr/mips64el-unknown-linux-gnu/ -name "libreadline*"
/usr/mips64el-unknown-linux-gnu/usr/lib/libreadline.so
/usr/mips64el-unknown-linux-gnu/usr/lib/libreadline.so.8.1
/usr/mips64el-unknown-linux-gnu/usr/lib/libreadline.so.8 |
Looks like something is still messed up. |
It is likely your chroot environment during build it miss USE=split-user (or the other way around, I never learn which way is right). But we can try to fix this one by set correct LD load path. you can check /usr/mips64el-unknown-linux-gnu/etc/ld.so.conf. if line /usr/lib not exist please add a /usr/lib line into the file.
either way after "/usr/lib" fix use command | Code: | | /usr/mips64el-unknown-linux-gnu/sbin/ldconfig |
to update LD cache.
Now try chroot bash again.
-- example on my machine --
Here is my bash linkage | Code: | lddtree /bin/bash
bash => /bin/bash (interpreter => /lib/ld-linux-aarch64.so.1)
libreadline.so.8 => /lib64/libreadline.so.8
libtinfow.so.6 => /lib64/libtinfow.so.6
libtinfo.so.6 => /lib64/libtinfo.so.6
libc.so.6 => /lib64/libc.so.6
ld-linux-aarch64.so.1 => /lib/ld-linux-aarch64.so.1 |
And this is my /etc/ld.so.conf | Code: | # ld.so.conf autogenerated by env-update; make all changes to
# contents of /etc/env.d directory
include ld.so.conf.d/*.conf
/lib64
/usr/lib64
/usr/local/lib64
/lib
/usr/lib
/usr/local/lib
/usr/lib/rust/lib
/usr/lib/llvm/12/lib64
/usr/lib/llvm/11/lib64 |
|
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54651
Location: 56N 3W
|
| Posted: Tue Dec 21, 2021 4:12 pm Post subject: |
|
|
manphiz,
What profile are you using in your target root?
| Code: | | mips64el-unknown-linux-gnu-emerge --info |
would be good to see.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
manphiz
n00b
Joined: 01 Dec 2021
Posts: 26
|
| Posted: Wed Dec 22, 2021 7:23 pm Post subject: |
|
|
Re eccerr0r and pingtoo:
So it looks like it's trying to find the shared libraries under usr/lib32 instead of usr/lib, probably because I'm using qemu-mipsn32el. I tried to update etc/ld.so.conf with the new path, but I cannot run sbin/ldconfig as I cannot chroot to it yet. So as a quick hack I just added some symlinks of the missing libraries under usr/lib32. And now I'm hit with this new error:
| Code: | gentoo-vm /usr/mips64el-unknown-linux-gnu # chroot /usr/mips64el-unknown-linux-gnu /usr/bin/qemu-mipsn32el /bin/bash
/bin/bash: error while loading shared libraries: /lib32/libc.so.6: cannot read file data
gentoo-vm /usr/mips64el-unknown-linux-gnu # ls -l lib32/libc.so.6
-rwxr-xr-x 1 root root 2337548 Dec 12 09:06 lib32/libc.so.6
gentoo-vm /usr/mips64el-unknown-linux-gnu # file lib32/libc.so.6
lib32/libc.so.6: ELF 32-bit LSB shared object, MIPS, N32 MIPS-III version 1 (SYSV), dynamically linked, interpreter /lib32/ld.so.1, for GNU/Linux 3.2.0, with debug_info, not stripped |
Not sure why I cannot read the file data in /lib32/libc.so.6 as it's just there and supposedly in the correct mips N32 format.
Re NeddySeagoon:
The output of the command:
| Code: | Portage 3.0.28 (python 3.9.9-final-0, embedded, gcc-11.2.1, glibc-2.34-r3, 5.10.78-gentoo-dist x86_64)
=================================================================
System uname: Linux-5.10.78-gentoo-dist-x86_64-Intel-R-_Core-TM-_i7-4558U_CPU_@_2.80GHz-with-glibc2.33
KiB Mem: 2032296 total, 1637628 free
KiB Swap: 10485756 total, 10485756 free
Timestamp of repository gentoo: Thu, 16 Dec 2021 00:45:01 +0000
Head commit of repository gentoo: 49389332b09ccfd40b6a0a8f9b1ddf697cd7b394
sh bash 5.1_p8
ld GNU ld (Gentoo 2.37_p1 p1) 2.37
app-misc/pax-utils: 1.3.3::gentoo
app-shells/bash: 5.1_p12::gentoo
dev-lang/perl: 5.34.0-r5::gentoo
sys-apps/baselayout: 2.8::gentoo
sys-apps/sandbox: 2.29::gentoo
sys-devel/autoconf: 2.71-r1::gentoo
sys-devel/automake: 1.16.5::gentoo
sys-devel/binutils: 2.37_p1-r1::gentoo
sys-devel/binutils-config: 5.4::gentoo
sys-devel/gcc: 11.2.1_p20211127::gentoo
sys-devel/gcc-config: 2.5-r1::gentoo
sys-devel/libtool: 2.4.6-r6::gentoo
sys-devel/make: 4.3::gentoo
sys-kernel/linux-headers: 5.15-r1::gentoo (virtual/os-headers)
sys-libs/glibc: 2.34-r3::gentoo
Repositories:
gentoo
location: /var/db/repos/gentoo
sync-type: rsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000
sync-rsync-verify-jobs: 1
sync-rsync-verify-max-age: 24
sync-rsync-verify-metamanifest: yes
sync-rsync-extra-opts:
ACCEPT_KEYWORDS="mips ~mips"
ACCEPT_LICENSE="@FREE"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=loongson2f -Wa,-mfix-loongson2f-nop -O2 -pipe"
CHOST="mips64el-unknown-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=loongson2f -Wa,-mfix-loongson2f-nop -O2 -pipe"
DISTDIR="/var/cache/distfiles"
FCFLAGS="-Os -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildpkg config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news nodoc noinfo noman parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-Os -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="en_US.UTF-8"
LDFLAGS=""
LINGUAS="en"
PKGDIR="/usr/mips64el-unknown-linux-gnu/packages/"
PORTAGE_CONFIGROOT="/usr/mips64el-unknown-linux-gnu/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/usr/mips64el-unknown-linux-gnu/tmp/"
SHELL="/bin/bash"
USE="kdrive minimal mips multicall zlib" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" PYTHON_TARGETS="python3_9" USERLAND="GNU" VIDEO_CARDS="fbdev"
Unset: ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CONFIG_SHELL, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EMERGE_DEFAULT_OPTS, ENV_UNSET, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, L10N, LC_ALL, LD, LEX, LFLAGS, LIBTOOL, MAKE, MAKEFLAGS, MAKEOPTS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, RANLIB, READELF, RUSTFLAGS, SIZE, STRINGS, STRIP, YACC, YFLAGS
|
|
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54651
Location: 56N 3W
|
| Posted: Wed Dec 22, 2021 8:24 pm Post subject: |
|
|
manphiz,
| Code: | | Portage 3.0.28 (python 3.9.9-final-0, embedded, gcc-11.2.1, glibc-2.34-r3, 5.10.78-gentoo-dist x86_64) |
That says that you have the embedded profile set. That's mostly not useful. It certainly won't be the profile set in in stage3 you may have downloaded.
If there was a current download for your Loongson somewhere in the Gentoo mips selection, which one would it be?
Why would you select that download?
We have tried building something from the front going forward. I can make statically linked code work but that's all.
My idea now is to unpick something that used to work, no matter how old and
a) unpick it to learn about where we need to get to
b) chroot into it it see if we can.
I have the desktop-loongson2f-hardened-20140630 install. It uses the | Code: | | hardened/linux/mips/mipsel/multilib/n32 |
profile.
Attempting to chroot in fails and I've added all of the qemu static-user mips emulators, so the system can take its pick.
That old tarball also sets | Code: | | CFLAGS="-O2 -march=loongson2f -Wa,-mfix-loongson2f-nop -pipe" |
for the compiler options, which may or may not be a good thing for QEMU and cross compiling.
Does QEMU implement the complete loongson2f instruction set, or not?
The loongson2f is a 64 bit CPU too. The existence of /multilib/ profiles suggests that the on disk layout keeps 32 bit and 64 bit versions of the same thing separate.
That matters when we try to put things together with a cross compiler.
Its also passible that its a 32 bit userland on top of a 64 bit kernel, like SPARC.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1350
Location: Richmond Hill, Canada
|
| Posted: Thu Dec 23, 2021 9:28 am Post subject: |
|
|
manphiz,
This is going down the rabbit hole 
I think at this point I would follow NeddySeagoon suggestion, Start fresh get a existing mips32 tarball or rebuild using correct 32bits arch flags to new crossdev again.
As NeddySeagoon point out 64 bits kernel on MIPS 64 bits CPU is capable run 32 bits userland. So if your application must stay in 32 bits userland you can start a target mips32el-unknown-linux-gnu cross build. Otherwise I suggest move everything to mips64el for better support.
On the other hand I am being curious, what is output of | Code: |
chroot /usr/mips64el-unknown-linux-gnu /usr/bin/qemu-mipsn32el /lib32/ld.so.1 /lib32/libc.so.6 |
?
And did you actually got an error when using ldconfig? on my machine ldconfig is a static linked executable does not require anything special | Code: |
chroot /usr/mips64el-unknown-linux-gnu /usr/bin/qemu-mipsn32el /sbin/ldconfig |
should just work. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54651
Location: 56N 3W
|
| Posted: Thu Dec 23, 2021 11:08 am Post subject: |
|
|
pingtoo,
I don't think its that simple either. I have a /no-multilib/install here and my mips64el-unknown-linux-gnu cross toolchain cannot build things tor the | Code: | | hardened/linux/mips/mipsel/multilib/n32 |
glibc fails amongst others.
I don't know if that's because my native install is /no-multillib/ or not.
I did think of downloading the old image chrooting in and updating it but that gives me illegal instruction errors in the target, which suggests that either qemu does nof gully support the loongson2f or I'm doing it wrong.
The image is bootable so might actually boot in qemu-system but I've always used libvirt to manage vitual machines and it doesn't support mips.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1350
Location: Richmond Hill, Canada
|
| Posted: Thu Dec 23, 2021 4:53 pm Post subject: |
|
|
| NeddySeagoon wrote: | pingtoo,
I don't think its that simple either. I have a /no-multilib/install here and my mips64el-unknown-linux-gnu cross toolchain cannot build things tor the | Code: | | hardened/linux/mips/mipsel/multilib/n32 |
glibc fails amongst others.
I don't know if that's because my native install is /no-multillib/ or not.
I did think of downloading the old image chrooting in and updating it but that gives me illegal instruction errors in the target, which suggests that either qemu does nof gully support the loongson2f or I'm doing it wrong.
The image is bootable so might actually boot in qemu-system but I've always used libvirt to manage vitual machines and it doesn't support mips. |
Understood, but I wonder is this have to do with trying to use 64 bits setup for 32 bits build. what if the tool chain is native to 32 bits, will it be better?
@manphiz, what is your end goal?- Create a modern stage3?
- Learn better cross build?
- target a specific app for loongson2f?
- something not in this list?
I doubt the libc "cannot read file data" error is a configuration/setup issue. It could be much deeper issue need to resolve at build time or even something kind of porting effort, so before further into the wonderland I like to know how much we need to put in to get it there. |
|
| Back to top |
|
|
manphiz
n00b
Joined: 01 Dec 2021
Posts: 26
|
| Posted: Fri Dec 24, 2021 1:40 am Post subject: |
|
|
| NeddySeagoon wrote: | manphiz,
| Code: | | Portage 3.0.28 (python 3.9.9-final-0, embedded, gcc-11.2.1, glibc-2.34-r3, 5.10.78-gentoo-dist x86_64) |
That says that you have the embedded profile set. That's mostly not useful. It certainly won't be the profile set in in stage3 you may have downloaded.
|
Ah so it looks like I'm using the default embedded profile while I should have picked one of the mips* profiles.
| NeddySeagoon wrote: | If there was a current download for your Loongson somewhere in the Gentoo mips selection, which one would it be?
Why would you select that download?
We have tried building something from the front going forward. I can make statically linked code work but that's all.
My idea now is to unpick something that used to work, no matter how old and
a) unpick it to learn about where we need to get to
b) chroot into it it see if we can.
I have the desktop-loongson2f-hardened-20140630 install. It uses the | Code: | | hardened/linux/mips/mipsel/multilib/n32 |
profile.
Attempting to chroot in fails and I've added all of the qemu static-user mips emulators, so the system can take its pick.
That old tarball also sets | Code: | | CFLAGS="-O2 -march=loongson2f -Wa,-mfix-loongson2f-nop -pipe" |
for the compiler options, which may or may not be a good thing for QEMU and cross compiling.
Does QEMU implement the complete loongson2f instruction set, or not?
The loongson2f is a 64 bit CPU too. The existence of /multilib/ profiles suggests that the on disk layout keeps 32 bit and 64 bit versions of the same thing separate.
That matters when we try to put things together with a cross compiler.
Its also passible that its a 32 bit userland on top of a 64 bit kernel, like SPARC. |
I think the special compiler options should be fine as it's just to work around a Loongson2f CPU bug that may causes the system to hang, while the instructions are MIPS-III compatible. Ideally it shouldn't affect it being able to run under qemu-mips, but I haven't succeeded either.
Also the previous stage3 is using n32 which is a 64-bit ABI but uses 32-bit pointers to save memory usage, given that the box only has 1GB of memory. I was running OpenBSD on n64 and some programs (like mu4e) would just eat up all the memory and crash.
Anyway I'll take a look at the previous stage3 and see how they handled this. Hopefully the library layout has not changed too dramatically. |
|
| Back to top |
|
|
manphiz
n00b
Joined: 01 Dec 2021
Posts: 26
|
| Posted: Fri Dec 24, 2021 1:48 am Post subject: |
|
|
| pingtoo wrote: | manphiz,
This is going down the rabbit hole
I think at this point I would follow NeddySeagoon suggestion, Start fresh get a existing mips32 tarball or rebuild using correct 32bits arch flags to new crossdev again.
As NeddySeagoon point out 64 bits kernel on MIPS 64 bits CPU is capable run 32 bits userland. So if your application must stay in 32 bits userland you can start a target mips32el-unknown-linux-gnu cross build. Otherwise I suggest move everything to mips64el for better support.
On the other hand I am being curious, what is output of | Code: |
chroot /usr/mips64el-unknown-linux-gnu /usr/bin/qemu-mipsn32el /lib32/ld.so.1 /lib32/libc.so.6 |
?
And did you actually got an error when using ldconfig? on my machine ldconfig is a static linked executable does not require anything special | Code: |
chroot /usr/mips64el-unknown-linux-gnu /usr/bin/qemu-mipsn32el /sbin/ldconfig |
should just work. |
The output of the commands:
| Code: | # chroot /usr/mips64el-unknown-linux-gnu /usr/bin/qemu-mipsn32el /lib32/ld.so.1 /lib32/libc.so.6
/lib32/libc.so.6: error while loading shared libraries: /lib32/libc.so.6: cannot read file data
# chroot /usr/mips64el-unknown-linux-gnu /usr/bin/qemu-mipsn32el /sbin/ldconfig
Illegal instruction (core dumped)
|
Maybe I should have chosen the correct profile otherwise the instruction set is mixed up? Anyway let me try restart with the correct profile and report back.
| pingtoo wrote: | @manphiz, what is your end goal?
Create a modern stage3?
Learn better cross build?
target a specific app for loongson2f?
something not in this list?
I doubt the libc "cannot read file data" error is a configuration/setup issue. It could be much deeper issue need to resolve at build time or even something kind of porting effort, so before further into the wonderland I like to know how much we need to put in to get it there.
|
Hopefully to get the first 2 of your list. But yeah if this becomes a porting effort it's so far beyond my knowledge, but hopefully it's not harder than creating a cross linux from scratch which may still be doable. Will see.
Anyway, thanks guys for all the helps. Happy holidays! |
|
| Back to top |
|
|
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1350
Location: Richmond Hill, Canada
|
| Posted: Fri Dec 24, 2021 12:38 pm Post subject: |
|
|
| manphiz wrote: | The output of the commands:
| Code: | # chroot /usr/mips64el-unknown-linux-gnu /usr/bin/qemu-mipsn32el /lib32/ld.so.1 /lib32/libc.so.6
/lib32/libc.so.6: error while loading shared libraries: /lib32/libc.so.6: cannot read file data
# chroot /usr/mips64el-unknown-linux-gnu /usr/bin/qemu-mipsn32el /sbin/ldconfig
Illegal instruction (core dumped)
|
|
| Quote: | # chroot /usr/mips64el-unknown-linux-gnu /usr/bin/qemu-mipsn32el /sbin/ldconfig
Illegal instruction (core dumped) |
Almost certain that your previous build compiler option(s) may be incompatible with qemu
So, you plan to have 32 bits cross build? or still need the multilib concept?
I suggest use 32 bits to start with simple compiler option(s) to get a working setup and from the working setup to perform optimization. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54651
Location: 56N 3W
|
| Posted: Fri Dec 24, 2021 1:01 pm Post subject: |
|
|
Team,
I thought I would try something mips64el that is reported to work. So the Debian Stretch installer boots.
The kernel and initrd file names have changed since that gist was written but if you adjust that, it boots.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
manphiz
n00b
Joined: 01 Dec 2021
Posts: 26
|
| Posted: Tue Dec 28, 2021 1:22 pm Post subject: |
|
|
Hi guys,
Just wanted to report back that I have retried bootstrapping with the correct profile (/var/db/repos/gentoo/profiles/default/linux/mips/17.0/mipsel/n32), and it ended up with the same "illegal instruction" error. I then checked the qemu documents[1] and found that it seemed that Loongson 2F system was only supported on MIPS64 hosts. So probably this is not gonna work anyway.
So I guess the next step is to try to bootstrap a new stage3 using the 2014 images. I'm gonna read more documents regarding stage 1 and stage 2. Any pointers are welcome.
Thanks guys for the help, and I'll probably need more next  Happy holidays!
[1] https://qemu-project.gitlab.io/qemu/system/target-mips.html#supported-cpu-models-for-mips64-hosts |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54651
Location: 56N 3W
|
| Posted: Tue Dec 28, 2021 1:59 pm Post subject: |
|
|
manphiz,
The Gentoo Handbook used to say
| Gentoo Handbook wrote: | | So, should you choose to start from a stage1, stage2, or stage3 tarball? Starting from a stage1 allows you to have total control over the optimization settings and optional build-time functionality that is initially enabled on your system. This makes stage1 installs good for power users who know what they are doing. Stage2 installs allow you to skip the bootstrap process, and doing this is fine if you are happy with the optimization settings that we chose for your particular stage2 tarball. Choosing to go with a stage3 allows for the fastest install of Gentoo Linux, but also means that your base system will have the optimization settings that we chose for you. Since major releases of Gentoo Linux have stage3's specifically optimized for various popular processors, this may be sufficient for you. If you're installing Gentoo Linux for the first time, consider using a stage3 tarball for installation. |
What it doesn't say is that your configuration changes will be applied in the course of routine updates, with the exception of tuning CHOST, which almost nobody needs any more.
The few users that think they do, hands up it you are installing on an i586 system, will never save the time that CHOST changing takes up rebuilding the toolchain in the right order.
That was useful when i386 and onwards was supported, maybe.
stage1 and stage2 tarballs are no longer distributed. The are still produced as intermediate steps to generate the stage3.
If you really want a stage1 or a stage2, you will need to get to grips with the catalyst build tool.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
manphiz
n00b
Joined: 01 Dec 2021
Posts: 26
|
| Posted: Tue Dec 28, 2021 3:26 pm Post subject: |
|
|
| Thanks for the pointer Neddy! I'll take a look at catalyst and hopefully they can still be correctly setup in the old system. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo on Alternative Architectures
