Skip to content
Snippets Groups Projects
Select Git revision
  • add-tplink-eap225-outdoor-v3-support protected
  • master default
  • v21.02.2
3 results
Search by author
  • Any Author
  • Linus Lüssing Linus Lüssing tux
  • Paul Paul paul
  • Philipp Rothmann Philipp Rothmann yksflip
  • Till Till eex
4 authors
  1. Aug 18, 2021
    • Adrian Schmutzler's avatar
      ath79: convert remaining mtd-mac-address cases to nvmem · e826b642
      Adrian Schmutzler authored 
      
Since the nvmem-based approach for retrieving MAC addresses
appears to depend on the addresses being set up after the
partitions, it is no longer possible to keep the MAC address
setup in shared DTSI files while the partitions itself are
set up in DTS files for the individual devices.

In ath79 the firmware partition is typically located somewhere
"in the middle" of the partition table. Thus, it's not trivial
to share the partitions containing MAC address information in
a common DTSI (like we did in some cases on ramips).

In this commit, MAC address setup is thus moved to the relevant
partitions, and in most cases needs to be duplicated. While
the duplication is not really nice, it eventually provides a
cleaner and more tidy setup, making the DTS(I) file
fragmentation a bit more logical. This should also help
with adding new devices, as information is distributed across
less locations.

For consistency, this commit also moves the mtd-cal-data property
"down" together with the MAC address setup, so it's not based
on a partition before the latter is defined either. (This is
only done for those files touched due to nvmem conversion.)

Signed-off-by: default avatarAdrian Schmutzler <freifunk@adrianschmutzler.de>
      e826b642
    • Adrian Schmutzler's avatar
      ramips: convert most mtd-mac-address cases in DTSI to nvmem · ba3d92c5
      Adrian Schmutzler authored 
      
Convert most of the cases from mtd-mac-address to nvmem where
MAC addresses are set in the DTSI, but the partitions are only
located in the device DTS. This posed some problems earlier, since
in these cases we are using partitions before they are defined,
and the nvmem system did not seem to like that.

There have been a few different resolution approaches, based on
the different tradeoffs of deduplication vs. maintainability:

 1. In many cases, the partition tables were identical except for
    the firmware partition size, and the firmware partition was
    the last in the table.
    In these cases, the partition table has been moved to the
    DTSI, and only the firmware partition's "reg" property has
    been kept in the DTS files. So, the updated nvmem definition
    could stay in the DTSI files as well.

 2. For all other cases, splitting up the partition table would
    have introduced additional complexity. Thus, the nodes to be
    converted to nvmem have been moved to the DTS files where the
    partitioning was defined.

 3. For Netgear EX2700 and WN3000RP v3, the remaining DTSI file
    was completely dissolved, as it was quite small and the name
    was not really nice either.

 4. The D-Link DIR-853 A3 was converted to nvmem as well, though
    it is just a plain DTS file not taken care of in the first
    wave.

In addition, some minor rearrangements have been made for tidyness.

Not covered (yet) by this patch are:

 * Various unielec devices
 * The D-Link DIR-8xx family

Signed-off-by: default avatarAdrian Schmutzler <freifunk@adrianschmutzler.de>
      ba3d92c5
    • Stijn Tintel's avatar
      ipq40xx: fix Edgecore ECW5211 boot · a43da1be
      Stijn Tintel authored 
      
The bootloader will look for a configuration section named ap.dk01.1-c2
in the FIT image. If this doesn't exist, the device won't boot.

Signed-off-by: default avatarStijn Tintel <stijn@linux-ipv6.be>
      a43da1be
  3. Aug 17, 2021
    • David Yang's avatar
      ramips: add WPS button for newifi d1 · efca6798
      David Yang authored 
      
This device has a WPS button under WiFi antenna cover, add it to dts.

Signed-off-by: default avatarDavid Yang <mmyangfl@gmail.com>
      efca6798
    • Adrian Schmutzler's avatar
      ramips: mt7628: move mtd-eeprom out of root DTSI · ad6b0770
      Adrian Schmutzler authored 
      
The mt76x8 subtarget is the only one in ramips that stores the
mediatek,mtd-eeprom property directly in the "root" mt7628an.dtsi.

This is not optimal for a few different reasons:

 * If you don't really know it or are used to other (sub)targets,
   the property will be set somewhat magically.
 * The property is set based on &factory partition before (if at all)
   this partition is defined.
 * There are several devices that have different offset or even
   different partitions to read from, which will then be overwritten
   in the DTS files. Thus, definitions are scattered between root
   DTSI and individual files.

Based on these circumstances, the "root" definition is removed and
the property is added to the device-based DTS(I) files where needed
and applicable. This should be easier to grasp for unexperienced
developers and will move the property closer to the partition
definitions.

Signed-off-by: default avatarAdrian Schmutzler <freifunk@adrianschmutzler.de>
      ad6b0770
  5. Aug 16, 2021
    • Rui Salvaterra's avatar
      kernel: bump 5.10 to 5.10.59 · 9704d25d
      Rui Salvaterra authored 
      
No deleted or manually refreshed patches.

Signed-off-by: default avatarRui Salvaterra <rsalvaterra@gmail.com>
      9704d25d
    • Daniel Golle's avatar
      base-files: rename 'sdcard' to 'legacy-sdcard' · 98bccdaf
      Daniel Golle authored 
      
While an image layout based on MBR and 'bootfs' partition may be easy
to understand for users who are very used to the IBM PC and always have
the option to access the SD card outside of the device (and hence don't
really depend on other recovery methods or dual-boot), in my opinion
it's a dead end for many desirable features on embedded systems,
especially when managed remotely (and hence without an easy option to
access the SD card using another device in case things go wrong, for
example).

Let me explain:

* using a MSDOS/VFAT filesystem to store kernel(s) is problematic, as a
  single corruption of the bootfs can render the system into a state
  that it no longer boots at all. This makes dual-boot useless, or at
  least very tedious to setup with then 2 independent boot partitions
  to avoid the single point of failure on a "hot" block (the FAT index
  of the boot partition, written every time a file is changed in
  bootfs). And well: most targets even store the bootloader environment
  in a file in that very same FAT filesystem, hence it cannot be used
  to script a reliable dual-boot method (as loading the environment
  itself will already fail if the filesystem is corrupted).

* loading the kernel uImage from bootfs and using rootfs inside an
  additional partition means the bootloader can only validate the
  kernel -- if rootfs is broken or corrupted, this can lead to a reboot
  loop, which is often a quite costly thing to happen in terms of
  hardware lifetime.

* imitating MBR-boot behavior with a FAT-formatted bootfs partition
  (like IBM PC in the 80s and 90s) is just one of many choices on
  embedded targets. There are much better options with modern U-Boot
  (which is what we use and build from source for all targets booting
  off SD cards), see examples in mediatek/mt7622 and mediatek/mt7623.

Hence rename the 'sdcard' feature to 'legacy-sdcard', and prefix
functions with 'legacy_sdcard_' instead of 'sdcard_'.

Tested-by: default avatarStijn Tintel <stijn@linux-ipv6.be>
Signed-off-by: default avatarDaniel Golle <daniel@makrotopia.org>
      Unverified
      98bccdaf
  7. Aug 14, 2021
  9. Aug 12, 2021
  11. Aug 11, 2021
  13. Aug 10, 2021
  15. Aug 08, 2021

Hosted with love by Chaotikum e.V. Support us if you can