Re: Resize a disk image from 32G to 4G or copy u-boot?
* On 2020 26 Mar 18:26 -0500, Nate Bargmann wrote: > This is now resolved thanks to the help of user Klaus on the Olimex > forum. The trick was to use dtrfstune to change the p2 UUID of the > 4G micro-SD to match that of the p@ UUID of the 32 GB card. s/dtrfstune/btrfstune/ s/p@/p2/ Sigh... - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Resize a disk image from 32G to 4G or copy u-boot?
If you say so, it wasn't aparent that was what the problem was. Lots of things can manipulate UUIDs. apropos uuid on this Pi says: dbus-uuidgen (1) - Utility to generate UUIDs FcDirCacheCreateUUID (3) - Create .uuid file at a directory FcDirCacheDeleteUUID (3) - Delete .uuid file findfs (8) - find a filesystem by label or UUID swaplabel (8)- print or change the label or UUID of a swap area uuid (1) - Universally Unique Identifier Command-Line Tool uuid (3) - DCE compatible Universally Unique Identifier library uuid_clear (3) - reset value of UUID variable to the NULL value uuid_compare (3) - compare whether two UUIDs are the same uuid_copy (3)- copy a UUID value uuid_generate (3)- create a new unique UUID value uuid_generate_random (3) - create a new unique UUID value uuid_generate_time (3) - create a new unique UUID value uuid_generate_time_safe (3) - create a new unique UUID value uuid_is_null (3) - compare the value of the UUID to the NULL value uuid_parse (3) - convert an input UUID string into binary representation uuid_time (3)- extract the time at which the UUID was created uuid_unparse (3) - convert a UUID from binary representation to a string I've got at least half a dozen 128 GB sds: https://www.bhphotovideo.com/c/product/1466563-REG/sandisk_sdsqqnr_128g_an6ia_high_endurance_microsd_128gb.html Haven't bought any bigger ones but you can get them up to 1 TB. On 3/26/20, Nate Bargmann wrote: > This is now resolved thanks to the help of user Klaus on the Olimex > forum. The trick was to use dtrfstune to change the p2 UUID of the > 4G micro-SD to match that of the p@ UUID of the 32 GB card. > > All is working well now. I now have the 32 GB card available to work > with the Raspberry Pi 4B that arrived today. :-) > > - Nate > > -- > > "The optimist proclaims that we live in the best of all > possible worlds. The pessimist fears this is true." > > Web: https://www.n0nb.us > Projects: https://github.com/N0NB > GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 > > -- - No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Cities are cages built to contain excess people and keep them from cluttering up nature. Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach
Re: Resize a disk image from 32G to 4G or copy u-boot?
This is now resolved thanks to the help of user Klaus on the Olimex forum. The trick was to use dtrfstune to change the p2 UUID of the 4G micro-SD to match that of the p@ UUID of the 32 GB card. All is working well now. I now have the 32 GB card available to work with the Raspberry Pi 4B that arrived today. :-) - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
On Thu, Mar 26, 2020 at 03:28:36PM +0100, Helmut Grohne wrote: > One part of the question here is "why do we need libatomic-ops?". The > answer to that is, because libgc uses it and libgc is used by e.g. gcc, > gnutls, guile, and make. Possibly, some of these could be built without > libgc, but this is how they are packaged for Debian at present. Package > dependencies currently say that we need libatomic-ops. > > The other part is "what is missing in libatomic-ops"? If you look at a > more recent implementation, such as riscv, you see that it basically > says "trust gcc". So I guess all you need here is an arc-specific > implementation that says "gcc knows what it is doing, use its > primitives". > > Given sufficient work, I guess libatomic-ops could be removed in favour > of using the gcc built-ins directly. Not sure whether that'd fly with > libgc upstream though. > > So no, this is not a stupid question. Thank you for asking. The way I read the details on libatomic is that it provides functions to implement the things a given architecture can't do with intrinsics in gcc directly. So on some architectures it does nothing and on others it implements missing bits for atomic operations. -- Len Sorensen
Re: Debain on a Buffalo TeraStation Live (HS-DHTGL/R5)
> On Thu, Mar 26, 2020 at 1:15 PM Gilles Risch wrote: > > Hello, > > During these days of isolation I reanimated my old TeraStation Live > (HS-DHTGL/R5), equipped it with some new disks and installed the latest > official firmware (2.14). This firmware is based on a quiet old Linux > kernel: > #uname -a > Linux TS-LIVE 2.6.16.16-arm1 #9 Fri Aug 31 13:42:57 JST 2007 armv5tejl > unknown > > So I decided to look for something newer. Is it possible to install and > run a recent version of Debian on this Marvell Orion based NAS? There is still minimal kernel support for this platform in the old board files (not in the .dts format), and the armel kernel enables support, but as far as I can tell, it only has 128MB of RAM, and the official minimum for a Debian installation is now 256MB, so this may be a rough ride. Using OpenWRT instead of Debian would better fit into the RAM, but they have removed support for all Marvell Orion5x based platforms a few months ago, making that also a bit hard, though depending on how motivated you are, you could add back OpenWRT support by creating a dts file for their "Kirkwood" port. Arnd
Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
Hi Alexey, On Thu, Mar 26, 2020 at 12:53:45PM +, Alexey Brodkin wrote: > Sorry for this stupid question but I'm not very familiar with use-cases for > libatomic-ops so would like to get some more clarification on what's needed > here. > > I know that GCC has quite a few built-ins for atomic ops and we do implement > them. > I'm adding our GCC maintainer (Claudiu) in the Cc so he may jump in if needed. One part of the question here is "why do we need libatomic-ops?". The answer to that is, because libgc uses it and libgc is used by e.g. gcc, gnutls, guile, and make. Possibly, some of these could be built without libgc, but this is how they are packaged for Debian at present. Package dependencies currently say that we need libatomic-ops. The other part is "what is missing in libatomic-ops"? If you look at a more recent implementation, such as riscv, you see that it basically says "trust gcc". So I guess all you need here is an arc-specific implementation that says "gcc knows what it is doing, use its primitives". Given sufficient work, I guess libatomic-ops could be removed in favour of using the gcc built-ins directly. Not sure whether that'd fly with libgc upstream though. So no, this is not a stupid question. Thank you for asking. Helmut
RE: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
Hi Helmut, > > 2. libgpg-error has ARC support since v1.33, see: > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.gnupg.org_cgi-2Dbin_gitweb.cgi-3Fp- > 3Dlibgpg-2Derror.git-3Ba-3Dcommit-3Bh- > 3D48c8f8ddfc80&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=_zJyx > Gdx_-O_dKHjFp6S-2ZXebEcmuHfmUsgpc4uEXA&s=myC306ViTlaxOV8nbOJR8pC74k2lsKmmB1hCGQR0PrE&e= > > This is only the native-support. For rebootstrap, we also need cross > build support, i.e. recording the generated lock-obj header (once glibc > is done). > > > And only for "libatomic-ops" & "guile" nothing has been done yet so if > > there's something > > that really needs to be done please let us know. > > I suggest that you focus on libatomic-ops then. And on glibc of course. > I guess that the other issues are easily solvable when they arise. Sorry for this stupid question but I'm not very familiar with use-cases for libatomic-ops so would like to get some more clarification on what's needed here. I know that GCC has quite a few built-ins for atomic ops and we do implement them. I'm adding our GCC maintainer (Claudiu) in the Cc so he may jump in if needed. -Alexey
Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
Hi Alexey, On Thu, Mar 26, 2020 at 11:51:44AM +, Alexey Brodkin wrote: > I guess almost all of the packages you mentioned already have > needed improvements for ARC. I didn't mean to imply that anything was missing. I just mentioned those that usually need work without having checked any. > 2. libgpg-error has ARC support since v1.33, see: > > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commit;h=48c8f8ddfc80 This is only the native-support. For rebootstrap, we also need cross build support, i.e. recording the generated lock-obj header (once glibc is done). > And only for "libatomic-ops" & "guile" nothing has been done yet so if > there's something > that really needs to be done please let us know. I suggest that you focus on libatomic-ops then. And on glibc of course. I guess that the other issues are easily solvable when they arise. Helmut
Debain on a Buffalo TeraStation Live (HS-DHTGL/R5)
Hello, During these days of isolation I reanimated my old TeraStation Live (HS-DHTGL/R5), equipped it with some new disks and installed the latest official firmware (2.14). This firmware is based on a quiet old Linux kernel: #uname -a Linux TS-LIVE 2.6.16.16-arm1 #9 Fri Aug 31 13:42:57 JST 2007 armv5tejl unknown So I decided to look for something newer. Is it possible to install and run a recent version of Debian on this Marvell Orion based NAS? Kind regards, Gilles signature.asc Description: OpenPGP digital signature
RE: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
Hi Helmut, > On Wed, Mar 25, 2020 at 05:25:58PM -0700, Vineet Gupta wrote: > > ARC glibc is still in works, but assuming that will happen in near future > > what > > other upstream prerequisites are needed. The obvious ones would be Linux > > kernel, > > gcc, binutils: all 3 of which are supported for ARC. From a quick glance at > > debian > > wiki pages, I presume *bootstrap is mostly done native, so needs qemu ? > > (full/user > > emulation ? And does qemu need to be upstream too ? > > Given that I ran into the glibc issue, I can tell that at least > rudimentary arc support support is already available in Debian unstable > for binutils, linux and gcc. (Otherwise, I would not have come as far as > glibc.) Once glibc is in place, work can proceed on the Debian side. > guile, libatomic-ops, libffi, libgpg-error and nspr ususally need a > little upstream support. dpkg, gmp, openssl, and perl usually need > Debian-specific changes. I'd recommend looking into libatomic-ops and > libffi early. The other packages are usually simple. I guess almost all of the packages you mentioned already have needed improvements for ARC. 1. libffi has ARC support since v3.1, see: https://github.com/libffi/libffi/commit/b082e15091961373c03d10ed0251f619ebb6ed76 2. libgpg-error has ARC support since v1.33, see: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commit;h=48c8f8ddfc80 3. nspr has ARC support since v4.1, see: https://hg.mozilla.org/projects/nspr/rev/cc73b6c7dab2e8053533e1f2c0c23dc721e10b76 And only for "libatomic-ops" & "guile" nothing has been done yet so if there's something that really needs to be done please let us know. -Alexey
