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 Point
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 processor
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 work,
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 featu
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 the
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 s
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.
Alternatively
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 and
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 "unsubscrib
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 conve
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
r
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 o
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 debia
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 mini-p
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 - j
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
>
>
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 scree
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 ins
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 o
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
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 beli
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?
D
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 investigati
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
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 (rep
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
Martin Michlmayr wrote:
Given that the LS Pro software doesn't need the 15M parameter (since
it's an initrd), the first choice might be best.
Is the nvram utility included is the LS Pro software environment or is
that only on the Kurobox Pro?
(and upgrades the firmware to a known-good versio
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 arg
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 ramdisk
Barry Tennison wrote:
Do you by any chance have an arm/lenny or arm/sid installation on
which you could do the above steps-to-reproduce, with genisoimage v
1.7.1-1 ? I know the maintainer(s) would be much more interested if
they know the bug is there in the sid version. And if it isn't, I
WI
Hi,
After much wailing and gnashing of teeth, I have a Lenny/armel
user-space with a stock-ish Debian kernel on a Buffalo Linkstation Pro v2:
~# grep ^Hardware /proc/cpuinfo && uname -a && cat /etc/debian_version
Hardware: Buffalo/Revogear Kurobox Pro
Linux linkstation 2.6.25-rc8-orion
34 matches
Mail list logo
