Pi 4B problem

Nope. By design, ARM processors support both big-endian /and/ little- endian modes:

"ARM cores support both modes, but are most commonly used in, and typically default to little-endian mode."

Actually, there /is/ such a flag: "Cortex-A series processors provide support for systems of either endian configuration, controlled by the CPSR E bit that enables software to switch dynamically between viewing data as little or big-endian. Instructions in memory are always treated as little-endian."

ARM is little-endian by default, like x86 or AMD64 (or, going back further, the 6502 :-) ). Unlike those two, it can be kicked into big-endian mode if you need it, though I don't know of anything that uses that mode. The different flavors of Linux available for the Raspberry Pi are all little-endian.

Raspberry Pi OS is a fork of Debian, so look at Debian's instructions. For example this is the 'tasksel' tool that selects common bundles of packages to install:

In general the RPi folks tend to preconfigure things so you don't need to do major system changes like this, but the Debian documentation is there if you need it.

Theo

Re: Re: Pi 4B problem By: A. Dumas to Vincent Coen on Sat Feb 26 2022 08:27 am

AD> I think every Pi 4 user looking to try things out needs at least two SD AD> cards:

This is a great post. Thank you.

I'd also like to throw RetroPie into the ring. Worth having an SD card for all your retro gaming goodness, and RetroPie is a great way of doing that.

Tristan.

Hello All!

Looks like from at least one poster Ubuntu Desktop should be working on a Pi4 so need to retry it but this time only on a SD card - may be with the USB plug removed to stop it booting to the SSD drive.

I will need to find a USB driven SSD or HDD to use to speed the testing up if the first tests work as it could be an issue with the PiHut supplied SSD which is a WD 240 GB M.2 2280 (Sata interface I understand) as the interface card cannot use M.2 NVME which is a real shame.

One thing I have noticed with the M.2 SSD is that when running sudo fstrim -av it exits with the implied not finding a SSD so I have to guess that the WD M.2 SSD is not being treated as a SSD and that is a worry if there is no garbage collection taking place.

I may try contacting WD (assuning they have a tech support dept) and see if they can shed any light on this as PiHut does not seem to have that level of technical support in-house like wise Argon who do not respond to emails.

I am using a Argon One M.2 case which includes a board to install a M.2 SSD in that is liked to the Pi via a USB bridge double plug.

Anyone any experiences on these points ?

Thanks for every one's help on these issues,

Vincent

Hello A!

Saturday February 26 2022 15:32, you wrote to me:

Point made, currently I am running Ubuntu Desktop using a SD which is very slow and so far I have noticed two issues :

1. Running auto update via the gui tool is basically not working after a few seconds as the progress bar has only moved a little then has stopped but I see drive light does come on but the Time display has stopped.

1. Starting the Terminal program has locked up to the point of not being able to entry any thing from the keyboard.

I have to conclude that this build for the Pi has not been really tested against it so I will have to try one of the other distros that was mentioned from a poster over the last day or so and see if any of these are any better.

That said it has been pointed out on one of the Pi forums that using a WS

Of course there could well be clashing in the USB interface between HDD accesses and any other data bus processing.

After all the Pi is still a basic Arm system with a very basic data bus design as far as I can tell.

.. and no I was not expecting fast performance compared to my multi core system using Sata 3 drives and a SSD.

Will see if there is a difference using the other distro's as it is possible that Ubuntu only recompiled their system for it without modding the hardware drivers etc to take into account Pi architecture.

Mind you, that is another "Assumption".

The expression "Pay peanuts must expect monkey's", comes to mind :)

Vincent

Hello A!

Saturday February 26 2022 15:32, you wrote to me:

Running fstrim is a required process if you are running with a SSD at least in two primary Linux based systems that have it as a boot drive otherwise failing to do so will make the SSD run out of disk space when the only fault is that it has not run Garbage collection to clean up the unused clusters.

Only drawback to using SSD's under *nix. Windows does it automatically some how but for *nix you have to specify fstrim to run once every 24 hours for lightly used systems and 12 hourly for heavier load systems - it might need to be more often if using them in a busy server.

Now I have had a quick look at the SD card in use and it has Ubuntu Desktop

I will look in on the Debian website for their release notes for v11 and see what the procedure is to upgrade the distro to use KDE or failing that Gnome, however that does not mean they will work with a Pi in a reasonable manner - suck it and see, I guess.

Worse come to it then I will revert to server mode as it will be used un-attended mode once the special software is tested and installed.

Thanks for you help,

Vincent

I think every Pi 4 user looking to try things out needs at least two SD cards:

1. One card for "Raspberry Pi OS 32-bit (Bullseye) with desktop and recommended software". This is the tried & tested OS with all the Pi customisations from the people at Pi HQ. Can't get more compatible than this. Leave this card alone, except for updating with apt (same as Debian and all its flavours) and installing the tools you want. Don't go & switch desktops if you don't want trouble. The Pi people are OK at brewing their own distro but in my experience they don't check things for even 1 nanometre outside that realm and they often come up with their own solutions, so general Linux interoperability sometimes suffers.

1. One card for the other OS. Ones that I know work really well out of the box, that don't need any special treatment, and will install & work flawlessly, are:

Installing on SD card is the easiest/cheapest option for the short term. But if you found an OS or flavour you like, one that works, installing it on any USB drive (preferably a USB3 SSD for lots of extra speed) will also work out of the box. Really, the Pi 4 is primed to check both the SD card slot and USB devices for boot drives, and will just find them. No more need to keep the /boot partition on SD card and the rest of / on the external drive. See

The only major disadvantage of any(!) desktop OS alternative to RasPiOS is that there will be no video hardware acceleration in the browser, if you like that sort of thing. I never use that on a Pi so I don't care. LibreElec, the media player OS, reportedly does have it but I guess that's not in a browser? I don't know, haven't installed that in years.

Generally: A) use a good power supply with a good USB cord. But what is good? You may think that that old wall plug you had will just work but chances are it will not, or not well. Can't go wrong with the official RPi power adapter. Buy three. B) Avoid el cheapo SD cards at all cost. Sandisk Extreme are OK but probably more optimised for large block transfers. In my experience, Sandisk Extreme Pro (different from just "Extreme"!) are faster, *very* reliable and don't lose speed over time. But now I only use Lexar "High Performance 633x" which are better optimised for small read/writes and not as expensive as Sandisk Extreme Pro. No faults yet. C) Samsung Portable SSD T5 are not the cheapest ever but work well in my experience. Absolutely no advantage whatsoever going to T7 unless they happen to be cheaper. Apparently some USB SSD drives (or controllers) don't (or didn't) work well with the Pi or with RaspiOS but the T5 ones I have definitely do and always did.

Or even on RaspiOS, perhaps because they botched another update, like Bob just posted...

If PiHut sells that drive it will be fully compatible. They are a long standing & respected Pi shop. I'd say, stop trying custom things like manually fstrimming until you get a bog standard installation working. An installation of a recent desktop OS, not Ubuntu server 20.04!

Well yes, obviously. But *surely* the OP wasn't trying to run an Intel binary on an ARM CPU (or vice versa). The chances of that working are sqrt(bugger_all).

But I thought the person I replied to above was saying that Ubuntu was designed for Intel, implying that the same source code, compiled for a variety of computers with different CPUs, would run best (by some criterion) on Intel.

I didn't know that. Or at least, I knew that ARM didn't fabricate the chips, but I rather assumed that *all* ARM chips, as a fundamental part of the design, had a fixed endian-ness, in the same way that all x86-compatible chips (even if designed by AMD rather than Intel) are fixed endian-ness and all SPARC are the opposite to Intel.

If what you are saying were true, then how could binaries that were compiled for one manufacturer's ARM CPU be guaranteed to run on all other manufacturers' ARM CPUs?

As it happens, it seems that ARM chips are clever buggers and can run in either endian-ness according to a flag. Well aren't they little show-offs? ;-)

Silly question: is there any fundamental advantage of LE over BE or vice-versa, or is it a fairly arbitrary choice that once a given chip has been designed, needs to be adhered for in perpetuity so any future CPU of that type can run binaries compiled for an older version of the CPU.

Was there any reason that all CPUs designed after the very first one didn't

Were any of the CPUs used in early domestic computers (eg Z80, 6809, 68000) BE, or were the all LE like the 6502? Was SPARC in the minority in being BE? What about CPUs in early mainframes - were they all the same byte-ordering?

Well-written software doesn't care, anyway. A good example is the SQLite library, where you can write a database file on LE and read on BE and vice versa.

The Wikipedia article on Endianness claims to answer those questions:

On Sat, 26 Feb 2022 22:04:22 -0000, "NY" snipped-for-privacy@privacy.invalid declaimed the following:

Early computers were NOT BYTE ORIENTED. They used "words" of whatever the native size on the machine happened to be. Common mainframes used

2. When looking at an integer value, it was common to see bits numbered

with the more significant bits on the "left". This is no problem on a word addressable computer (on the Xerox Sigma-6, used by my college in the late

LB,9 word, ix

locates the 32-bit word at address "word", then takes the value of the index register to select which byte in that word... and as I recall index 0 was bits 31..24 [so effectively big end]).

Big/Little only became a matter when accessing byte-addressable memory. Does the processor write

Memory Bits

or does it write

On the other hand, Intel processors, DEC Alphas and at least some programs that run on them are little-endian.

There are also mixed forms of endianness. For example, VAX floating point uses mixed-endian, also referred to as middle-endian. The ordering of bytes in a 16-bit word differs from the ordering of 16-bit words within a 32-bit word. """

Remember that Intel's first processors were just 4-bit! ... and grew to

Hello The!

Sunday February 27 2022 13:32, you wrote to me:

The purpose of the SSD garbage collection process for want of a better name is to find all clusters no longer in use and make them available in the - yes available lists/index.

Failure to do this process whether within the SSD's controller or by application s/w on the platform will result in no free clusters available to create, add, extend replace a file or file record.

A case in point my media system which uses a Samsung SSD was over loaded a year or so ago when I loaded up around 1 Tb of video despite saving them on a HDD as clearly the system was first saving all data to the boot (SSD) drive.

This process took up many time more than the total video content being transferred and the facility stopped because there was no more clusters available until I ran fstrim -av and left it some minutes. At which point I could continue with the load.

I have now changed the cron process to run it 2 times per day and before when ever I have a large video load up to do as a safeguard.

Windows does this process using it's own version of a similar process to fstrim but thats as far as I know or can guess as I have never bothered to look closely into it.

I am sure you can research this in more detail than outlined above if required.

Using fstrim has absolutely nothing to do with extending the life of a SSD and possibly could decrease it slightly but it is a needed function unless the SSD controller does it automatically and for the SSD's designed for server use they do so but you have to pay the extra cost for those devices - a lot more. The cost increase is not justified for a desktop type system unless you need the faster write speeds they tend to have but the closest to which is a M.2 NVME or similar device set.

Vincent

In brief:

Big endian is useful because the most significant part comes first. For example, when comparing two decimal numbers aaa and bbb you start with the hundreds digit, and if the hundred digit from a is greater than the hundreds digit from b, then you have your answer and can skip the rest. This is useful in eg network routing, eg if you want to pattern match 192.168.x.x you only need wait for the 192.168 bytes to arrive on the wire before you can route the packet.

Little endian is useful because the address of an object does not depend on its type. In other words:

uint32_t x = 5; uint8_t *y = &x; printf("%d\n", *y);

will still print '5'. On a big endian machine it would print '0' (being the most significant byte of x). You have to know that the object is 32 bits to offset the calculation for the LSB:

uint32_t x = 5; uint8_t *y = &x; printf("%d\n", y[3]);

but that would need to be adjusted to y[1] if x was a 16 bit type.

A reason for LE's rise and BE's decline is that the memory conversion between different types has become more important, but the sorting thing is less important - you're now doing comparisons on 32 or 64 bit chunks, or in networking hardware, where the byte-by-byte comparison doesn't matter.

Theo