We already have a pointer for barebox_boarddata, so use it to
request the corresponding SDRAM region instead of calculating
it again.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
barebox_boarddata should stay the original boarddata and not
be modified. Keep a local pointer in barebox_arm_boot_dtb()
instead.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Fixes: 65071bd arm: Clarify memory layout calculation
arm_mem_barebox_image() shall return the beginning of the barebox
image (and thus the end of the malloc region). For relocatable
images we can return a suitable location, but for non relocatable
images we do not have a choice: We must return TEXT_BASE. If TEXT_BASE
happens to be outside the memory region between membase and endmem
we can return the base of the ramoops area.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Markus Pargmann <mpa@pengutronix.de>
This patch handles the ip env to "" if no ip env is given. Otherwise
we get a NULL pointer derefence.
Signed-off-by: Alexander Aring <aar@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Nowadays we have AR9331 devicetree from linux v4.7-rc2
in the file dts/src/mips/qca/ar9331.dtsi.
Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Also sync black-swift.dts with tplink-mr3020.dts.
And also see this linux kernel commit:
commit 2c3694d2e6ead3964aafb31e4e529de219ced92b
Author: Antony Pavlov <antonynpavlov@gmail.com>
Date: Thu Mar 17 06:34:19 2016 +0300
MIPS: ath79: add initial support for TP-LINK MR3020
Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Commit da89ee8f2e ("Center FLP timing at 16ms") breaks
genphy_restart_aneg() for Micrel's ksz9031. According to the
datasheet, the ksz9031 requires a wait of 1ms after clearing
the PDOWN bit and before read/write access to any PHY registers.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Fixes:
fs/squashfs/inode.c: warning: format '%d' expects argument
of type 'int', but argument 3 has type 'long long int'
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The SD and eMMC version numbers are a pain to print and sort, since
they are inconsistent in if a two digit minor version shdoulde be
treated as a single number or as minor and micro version numbers.
This allows version 1.10 and 4.5 and 4.41, where 41 is less than 5.
Signed-off-by: Trent Piepho <tpiepho@kymetacorp.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Add code needed to expose iNVM memory on the chip as a cdev. The
driver also registers a dummy "invm" device that exposes "locked"
property which is used to implement iNMV line locking feature.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
As per datasheet (section 4.6 p. 147) accessing EEPROM on i210
requires software to hold a corresponding lock bit in SW_FW_SYNC
register.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
As described in the datasheet Software/Firmware synchronisation bits
are expected to be released by the software after it is done using
it. Add a porper subroutine to do that instead of relying on the
Firmware clearing those bits due to timeout.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Refactor Flash/EEPROM reading code to use vtable with pointers to
small, specialized functions based on the flash class instead of big
monolithic funtions whose behaviour is driven by a number of flags and
variables.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
We always call e1000_init_eeprom_params() as a part of probing, so
there's no need check if it needs to be called in e1000_read_eeprom().
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
There are several reasons why that code in e1000_probe had to be
changed:
- It reads from chip variant specific register (present only on
i210) in a chip variant agnostic codepath
- It makes no sense to check for FLUPD bit to make a decision weither
to validate EEPROM or not since its function per datasheet is:
" ... Flash Update.
Writing 1b to this bit causes the content of the internal 4 KB
shadow RAM to be written into one of the first two 4 KB sectors
of the Flash device (Sector 0 or Sector 1). The bit is
self-cleared immediately... "
and it is only through sheer serendipity the defined value for
bitmask for FLUPD is equivalent to bitmask for FLASH_DETECTED bit
which is the bit we actually care about and need to test against
(FLUPD for i210 has a different bitmask)
Fix those problems by replacing the i210 specific check inside of
e1000_validate_eeprom_checksum() with a chip agnostic one and using
correct bitmask.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
All of the chips that bitbang Microwire to access EEPROM appear to be
configured in the same way, so move common code into a separate
function and make use of it.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
All of the chips that bitbang SPI to access EEPROM appear to be
configured in the same way, so move common code into a separate
function and make use of it.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Sascha Hauer
Alexander Aring
Antony Pavlov
grodriguez
Lucas Stach
Trent Piepho
Andrey Smirnov