> In Raspbian Buster on my Pi 3B
> es2gears
[...]
> 718 frames in 5.0 seconds = 143.600 FPS
> root@upstairs:/usr# glxgears
[...]
> 838 frames in 5.0 seconds = 167.566 FPS
[...]
> Debian Stretch on my Pinebook Pro has the 60 hz limit in effect.
Not sure in which way these data points are relevant.
> The whole point of my rant is that the instant folks find out that 64 bit
> will run on whatever platform we are discusing, and armhf needs more
> attention paid to details like addressing beyond 3 gigs, PAE IOW, 6
> months later there are no armhf distros left.
FWIW, I'm finding hard to
> My opinion (professional in this case, even) is that i386 users want
> compatibility with their binaries from 1998.
I don't claim to be representative, but at least the above doesn't fit
my case: I use i386 on many of my machines and here are the reasons:
- 2 of those machines use processors
> * 32-bit ABIs/arches are more awkward. glibc will continue *by
>default* to use 32-bit time_t to keep compatibility with existing
>code. This will *not* be safe as we approach 2038.
>
> * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc
>upwards, but this will of
> The PINE A64+ is based on the Allwinner A64, the same images will *not*
> work.
But only the u-boot and the .dtb file need to be different, right?
Stefan
>>> Are there any other boards or chipsets I should be considering?
>> I'm also using A20-based boards for the same kind of use you describe
>> and for the same reasons, and while I haven't yet felt a need to replace
>> them, I've noticed the ESPRESSObin as a candidate for successor.
>> It's not
> Are there any other boards or chipsets I should be considering?
I'm also using A20-based boards for the same kind of use you describe
and for the same reasons, and while I haven't yet felt a need to replace
them, I've noticed the ESPRESSObin as a candidate for successor.
It's not very much more
> So http://www.digi.com, and the 37 page "U-Boot Reference Manual" that
> you can download and print from their site is all BS?
I don't know. I'd assume it's the doc that applies to a version of
U-Boot they distribute. Are you using Digi's U-Boot? I'm not.
I'm using the U-Boot from denx,
>> > The u-boot protocol assumes some of the files you see here:
>> [...]
>> > Are located at fixed offsets from the disks LSN0.
>> I don't were you got that idea.
^^^
know
> From Digi,
That's rather vague.
> who own the copyrights since they announced it in 2001.
> The u-boot protocol assumes some of the files you see here:
[...]
> Are located at fixed offsets from the disks LSN0.
I don't were you got that idea. Or maybe you're using a non-mainline U-Boot.
The mainline U-Boot I'm using on my Banana-Pis can find the files it
needs (including boot.scr) in
> So what tools do I use to build an installable kernel deb for a u-boot
> system?
I'm not sure what you mean.
My BananaPi here uses the stock Debian kernels without any trouble.
Both the vmlinuz and the dtb files are read as-is by U-Boot.
The only thing I need to do is to package the initrd
> Logout and login manually, or disable automatic logins.
Why not just switch to another user (and hence login a second time on
another virtual console)?
Stefan
> Debian almost certainly won't run.
For some definition of "won't run", but you can most likely get a plain
standard Debian to work using a non-Debian kernel.
Stefan
>> Thanks Joonas. It is going to run the C++ program on NXP i.MX-6ULZ
>> ARMv7, the application is running on about 5MB RAM, I think RAM
>> looks fine. The boost and other C++ system libraries about 6 MB, the
>> program self is not too large, about 2 MB libraries and 500 KB binary
>>
> The reality of the situation is that the market currently favors GLES
> over GL on ARM SBC's, delivered with proprietary blobs.
Not sure which market you're talking about, but this "reality" is
a problem for Debian.
> the best FOSS user experience that's possible with the proprietary drivers
>> Both Dmitry and I just learned that the RPI has the VC4 driver which enables
>> it to do hardware acceleration for Desktop OpenGL, we must admit that this is
>> a game changer in many ways, even if we are talking on just one board (but
>> quite an ubiquitous one).
> I expect this also applies
> Yeah - it depends exactly on your background. There's a small (but
> growing) set of arm64 desktop users,
Apparently none of them are here, tho.
> and it would be unfortunate to cut them off.
But would it? IIUC this proposed change only impacts Qt applications,
and it's not clear whether it
> In fact I don't know anybody is using Debian's mips32eb port.
IIUC this `mips32eb` port is the one called just "mips".
I'm using it on my BT HomeHub 5
https://openwrt.org/toh/bt/homehub_v5a?s[]=homehub
It's one of the very few devices which satisfy:
- includes a DSL modem
- includes a
> What I need is an arm64 board, like this one, that does not suffer from
> the fact that the pi uses a usb-2 internal hub to talk to everything but
I don't have any actual experience with it, but the ESPRESSObin board
looks promising in this area.
Stefan
> rock64@rock64:~$ sudo dpkg-reconfigure locales
> [sudo] password for rock64:
> locales-all installed, skipping locales generation
It says right there: the command didn't do anything because
"locales-all" is installed.
> Regardless of what I select.
> Sigh. I wish I had never heard of this
> Similarly for wifi cards like those Intel ones like iwlwifi (which is
> the one that I have in this Core 2 Duo here)...
I can answer this part: yes, you can definitely put an Intel wifi card
in the mini-pcie slot of an ARM box.
Stefan
> Spit. I do see a driver listed on vger?, but haven't downloaded it yet.
> Should I?
No idea, my sunxi boxes are (mostly) headless anyway (tho I'm thinking
of converting one of them into a video player once the VPU support is in
mainline).
Stefan
> Do they not understand that the market for their hardware would expand
> considerably if they'd supply the info and encourage our FSF aligned
> people to write the drivers,?
>
> Look at the nouveau situtation.
AFAIK Nvidia doesn't understand much more than ARM does: they get as
much in the way,
> This still looks like a 1 man part time effort. And it will likely remain
> so until there is arm64 support in debian. But likely next generation
> after stretch now.
Mali support is unrelated to Debian. The main issue is that ARM (the
company behind the Mali GPUs) works hard to undermine
> I would like to find a substitute to my KuroBox Pro, which is an armel-based
> NAS. Here is its summary:
> * An Orion processor running at 400MHz
> * 128MB of RAM
> * a slot for one 3.5" SATA HDD
> * gigabit ethernet
> * 2 USB 2.0 ports
You might like to check
> I was under the impression that that's not the case:
> https://lwn.net/Articles/314561/
Aha! Using the same trick that was used in the Mach microkernel.
Stefan
> In principle this would work fine. But if it worked then debian armel
> would already be built this way (we didn't _want_ to drop strongARM
> support). The problem is that the compiler, when outputting code for
> EABI (armel), does not support armv4, (due to boring stuff about thumb
>
>> I guess all I'm still missing is some community of tweakers adding
>> facilities to set global compilation flags to use for all those
>> recompiled packages and things like that, so you don't have to do it by
>> hand for each and every package you want to recompile with your
>> own compilation
>> Reminds me that I wish there was some kind of "Debian from Source"
>> effort which would make it easy to install specific packages by
>> compiling them locally. So you'd get a slightly Gentoo-ish flavor
>> of Debian.
> Are you talking about something like this?
>
>> > I have an old Jornada 720 handheld PC with SA-1110 (StrongARM) CPU. I
>> > have a kernel compiled for armv4l architecture (not by me) and a
>> > userland that I don't want to use.
>> The last Debian release using StrongARM was 5.0 "Lenny" - using the
>> original 'arm' port.
>>
> the reason i ask that is, i'm not seeing any real difference: you
> still have to download the linux kernel source (to submit dtsi
> patches), the linux git repo is still the central location for dtsi
> management... unless you're happy to set up an alternative parallel
> repository (and
> the only big advantage of dtb files (binary compiled) is *IF* the
> decision is made to respect dtb files and treat them as inviolate
> and supported forever without needing recompiles, you stand a
> chance of being able to upgrade linux kernels *without* replacing
> the dtb file.
That
> physically). What you often gain going to a 64 bit CPU is the ability
> to do 64 bit arithmetic in one instruction, and store the variables
[...]
> 32 bit calculations, then it doesn't matter, so in many cases it isn't an
> issue, but when it matters it can really make a difference in
> How many can be upgraded to Debian and operated with 100% free software,
> no binary firmware blobs at all? Is there any comparison table that is
> useful for people buying these things with the intention of running free
> software?
My understanding is that if you're really interested in
> If you ignore proprietaryness, I expect iOS devices are more secure
> than Debian, given their secure enclave stuff. Debian doesn't yet have
> support for Secure Boot.
SecureBoot has very little to do with security.
More specifically, it's mostly useful to provide "security against the
end
>> I start screen to BananaPi (not Pro, but I think their serial console
>> settings are same) serial console with next parameters:
AFAIK the actual SoC and board doesn't setup anything on the serial
console side. It's setup by the later boot loader (the one loaded from
Sd card or from nand),
Debian support on mainline kernel does not support
all Cubietruck features.
Such as what?
NAND,
DMA,
Audio,
USB gadgets,
Video output,
GPU (which is basically separate from the video output itself),
VPU,
Encryption accelerator,
cpufreq
This list is probably not exhaustive. There are existing
so the point is: if anyone wishes me to propose to allwinner that
they convert over to devicetree, or any other proposal which involves
significant low-level changes to their working practices that could
potentially have a massive knock-on effect onto their
multi-million-dollar clients, it
38 matches
Mail list logo
