If you're using the built-in wifi on the 3B, then I'm pretty sure it's
2.4GHz only. You'll need to use an add-on USB wifi adapter if you want
5GHz (maybe SDIO is also possible).
Tim.
On 17/11/2023 15:53, basti wrote:
Hello,
i have a Raspi 3B+ and try to connect to WIFI 5G.
The Access
I could be wrong, but I also thought that processor errata
fixes/workarounds for 64 bit capable ARM processors are only
(consistently) applied to the 64 bit kernel.
i.e. if you run a 64-bit-capable ARM processor such as the A53 with a
32-bit Linux kernel, then you might hit unpatched
Hi Christian,
In additional to what's already been said...
If there isn't already (complete) upstream support for a particular
board, then you may want to look at the state of support for the
particular board in Armbian and/or OpenWRT.
Some of the Armbian or OpenWRT devs upstream their
Hello,
Sorry, not sure if debian-arm is a good place to discuss this, please
feel free to redirect me if not.
I'd be curious to know if this is a common problem, and if-so what other
solutions or alterations might be useful?
In the past I've had some hassle maintaining user-space software which
On 14/01/2020 12:35, David Pottage wrote:
> Can the RK3399 CPU and Debian kernel run 32 binaries? (Similar to how
> you can run old 32bit x86 on a modern 64bit intel CPU)
Yes, I run 32 bit containers on a RK3399.
n.b. some other 64 bit ARM CPUs won't execute 32 bit code (it's an
optional
On 07/04/16 16:02, Andrew McGlashan wrote:
> outdated
> Android is what I have to settle for unless I spring for a Google sold
> device and prices / availability in AU aren't as good as they are in the US.
You have a reasonable choice of devices with Cyanogenmod and/or AOSP
etc. - updates are
On 25/08/14 20:12, Luke Kenneth Casson Leighton wrote:
grab yourself something like an FTDI USB dongle off
of farnell and you should be set. something like this:
http://uk.farnell.com/ftdi/um232r/dev-module-usb-to-serial-uart/dp/1146036?Ntt=FT232+USB+UART
As an alternative, you could hack
I think you'll need to use wireshark to figure out what's different (if
anything) about the two sets of dhcp requests.
You might want to run wireshark on another box with two NICs bridged
(cubox into one, router into the other) to ensure you see unicast as
well as broadcast traffic.
On 01/04/13 21:01, Lennart Sorensen wrote:
Many HDMI outputs are limited to 1920x1080 after all (with a few capable of
1920x1200)
When necessary (e.g. long cable runs, or dot-clock limited DVI outputs),
I've always been able to get the dotclock down far enough by reducing
the refresh rate
On 09/03/13 11:02, Oliver Grawert wrote:
get a few chromebooks
... buy up a few with broken screens from ebay etc. ?
http://www.ebay.co.uk/itm/New-Samsung-Chromebook-with-BROKEN-SCREEN-/271166903320
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of
On 18/08/12 13:35, Matt Palmer wrote:
The fight isn't *quite* over, but by gum you've got a good start. In my
experience, all of these sorts of devices have 3.3V TTL serial ports, rather
than the RS232 standard of 12V. That's fairly easy to get around -- there's
no shortage of level
On 17/08/11 15:00, Gordan Bobic wrote:
Marvell is pretty good. Whether that is through Marvell's contribution
or not I don't know, but in terms of what the end user gets to work
with, it's seldom matched and hard to beat.
They are definitely better than some, but OTOH, they don't appear to
On 09/08/11 16:46, Luke Kenneth Casson Leighton wrote:
single-lane PCI-e is still only gigabit
AFAIK, single-lane 1st generation PCIe is 2.5 gigabit, and 2nd
generation is 5 gigabit. Also significant is the max-payload-size
capabilities of either end of the link (lspci -vv). A lot of
On 14/07/11 13:02, Luke Kenneth Casson Leighton wrote:
Well, I found tinyCC
Code performance will probably be slow. If you don't mind this it might
be OK.
which *seems* promising for the moment.
In any case, can you tell me what was the build process for gcc on android
used by debian
On 11/04/11 00:02, Phil Endecott wrote:
I run mythtv on amd64, but haven't tried it on arm. It's a bit
idiosyncratic, and fiddly to set up, but does a lot once you have it
running. I use packages from here:
http://debian-multimedia.org/
Tegra devices are a bit stronger as
they have
If price is a large consideration, then you're really looking at
mass-market / consumer devices.
. Linux-based NAS devices (remove and sell the hard disk, and replace
with SSD/ decent SD etc.). I've used the Buffalo linkstations. The
newer models have quickish CPUs but may be a bit short of RAM
On 24/03/11 17:49, chris wilkinson wrote:
The end result I'm trying to achieve is a NAS functioning as normal but also
with Debian so I can add further functions such as Apache.
Your options are probably:
0. Do all the NAS Stuff from within Debian - i.e. set up Samba etc.
yourself - just
On 15/02/11 18:03, Rick Thomas wrote:
Does there exist an inexpensive self-contained armhf box that folks
can use for development and experimentation? Something like the
Sheeva Plug for armel?
If your main criteria is inexpensive, then perhaps something like a ZTE
Blade with a damaged screen
On 16/02/11 10:32, Wookey wrote:
armhf needs v7, thumb2, VFP3
Ah OK. My reading of
http://wiki.debian.org/ArmHardFloatPort#PartialreferenceofSoCandsupportedISAs
seemed to imply that VFP2 was sufficient, as this was in the list:
Freescale
iMX3x
armv6
VFPv2
Martin Michlmayr wrote:
It seems the way you'd install Debian would be to:
- update the firmware to 1.10
- run a script provided by Debian that removes the initrd= parameter
from the u-boot config, and then puts the debian-installer kernel
and ramdisk on disk.
- reboot, run the
Martin Michlmayr wrote:
Oh, I thought you said the current firmware version had the press
reset, do TFTP feature. Bugger.
I was told it did by people on #linkstationwiki - I thought I had broken
this feature on my box by changing the default nvram settings, but after
further
Martin Michlmayr wrote:
Tim, can please install flash-kernel from unstable, attach the patch
below, run 'flash-kernel' and see if your machine still boots?
Yep, that works - that patch should be OK to commit, I think...
BTW, what about the Terastation Pro II/Live and Linkstation Pro Duo?
Martin Michlmayr wrote:
Does the LS use dhcp in this case to
obtain an IP address and the IP of the server, or will it always use
the hardcoded value (192.168.11.1)?
The Buffalo uboot uses a hard-coded IP address of 192.168.11.150, with a
hard-coded tftp server IP of 192.168.11.1 . I
Martin Michlmayr wrote:
* Tim Small [EMAIL PROTECTED] [2008-08-10 12:34]:
- Run a script supplied by Debian that will use nvram to change
bootargs_root
Pretty much, but I think the best approach is to supply an initrd which
does this automatically
I'm not sure we can do
Martin Michlmayr wrote:
For some reason, nic-modules doesn't depend on nic-shared-modules (which
contains mii) on arm whereas it does on armel. Fortunately, nobody is
supposed to use arm anymore but I'll look into fixing it anyway.
Hmm, yes, my bad, I accidentally clicked the arm, instead
Per Andersson wrote:
Do you think the current debian installer code and method
for installing Debian on the Kurobox Pro would work for
Linkstation Pro/Live as well? The method goes something
like this:
1) Create a ext2 filesystem on the first partition on the
attached harddrive. (Has to be ext2
Hello,
I presume (but I'm not sure) that the only method for installing Debian
on the kuropro, and lspro will be to start the installer via TFTP.. I
suppose it might also be possible to write an installer image to the HD
of the linkstation (by connecting the drive directly to another machine
Per Andersson wrote:
Can EM be used similarly on the lspro?
The Buffalo software does indeed include an emergency mode, but this
is entered as a special case from their kernel/initrd pair, both of
which are stored on the hard-disk. Once you install the Debian kernel
and initramfs
Martin Michlmayr wrote:
* Tim Small [EMAIL PROTECTED] [2008-07-27 15:01]:
. Patch the mainline initramfs code in a nice way, so that it'll
work with any lspro firmware version - and hope the kernel
maintainers accept the patch (which they might, as the current code
is arguably a bit broken
Ryan Tandy wrote:
You may remember that a while back I tried to use your kernel package,
but that my u-boot (from the original lspro firmware) didn't load the
initrd properly when I removed the initrd= boot parameter. Today I
updated the bootloader to 1.10 using the Buffalo updater, installed a
Martin Michlmayr wrote:
.. Remove the initrd=0x00800040,15M parameter (check that your env look like
those below), and verify
The reason is probably that it tells the kernel that the ramdisk is
15M long, but the Debian ramdisk will be much smaller. You could try
padding the Debian
31 matches
Mail list logo
