| Age | Commit message (Collapse) | Author |
|---|
|
Dumpimage (it invoked with "-T rkspi" or "-T rksd") would not work due
to check_params failing. These changes ensure that we can both be called
with an empty imagename.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
This change set adds documentation to the header0 initialisation and
improves readability for the calculations of various offsets/lengths.
As the U-Boot SPL stage doesn't use any payload beyond what is covered
by init_size, we no longer add RK_MAX_BOOT_SIZE to init_boot_size.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
While not required for correctness, we pad the SD/MMC images to a full
blocksize (i.e. 512 bytes). This is to keep things consistent with all
operations being performed on blocksize units.
Note that a case could be made to choose a 2K alignment (as init_size
needs to be a multiple of 4 blocks) and to keep even closer to rkspi,
but the 512 byte choice felt more natural as it's also the natural
blocksize of SD/MMC devices.
Series-changes: 2
- added missing commit message (with a bit of background to the
in-line comment in the code).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
The calculation of the variable header size in rkcommon_vrec_header
had been updated twice in the earlier series (introducing boot0-style
images to deal with the alignment of the first instruction in 64bit
binaries). Unfortunately, I didn't update the comment twice (so it
remained out-of-date).
This change brings the comment back in-sync with what the code is
doing.
Series-changes: 2
- fixed typo in commit message (been update -> been updated)
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
In (first) breaking and (then) fixing the rkspi tool, I realised that
the calculation of the required padding (for the header-size and the
2K-in-every-4K SPI layout) was not as self-explainatory as it could
have been. This change rewrites the code (using new, common functions
in rkcommon.c) and adds verbose in-line comments to ensure that we
won't fall into the same pit in the future...
Tested on the RK3399 (with has a boot0-style payload) with SD/MMC and SPI.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Our earlier change broke the generation of SPI images, by excluding the
2K used for header0 from the size-calculation.
This commit makes sure that these are included before calculating the
required total size (including the padding from the 2K-from-every-4K
conversion).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
When OF control is enabled for the SPL stage, nodes are removed from
the DTB to reduce its size. While /chosen is kept, /config is removed.
There's no reason why /chosen should be kept over /config (and as we
would like to put properties into /config that control the SPL stage),
we add '/config' to the list of nodes to be retained for the SPL stage.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
This adds documentation on the u-boot,spl-payload-offset property
(which overrides CONFIG_SYS_SPI_U_BOOT_OFFS during the SPI loading in
the SPL stage, if present).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
For the RK3399-Q7, we need some flexibility (depending on the feature
set we include in the SPL stage and how large our SPI flash is) in
positioning the SPL payload (i.e. the FIT image containing U-Boot, ATF
and the M0 payload) in our SPI flash.
To avoid having to deal with this through different U-Boot images, we
introduce a the '/config/u-boot,spl-payload-offset' property node
allow it to override the default setting.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Series-cc: Simon Glass <sjg@chromium.org>
Series-cc: Klaus Goger <klaus.goger@theobroma-systems.com>
Series-cc: Kever Yang <kever.yang@rock-chips.com>
|
|
|
|
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
On the RK3399-Q7, the on-module USB3 hub is held in reset at boot-up
to save power and needs to be woken up using GPIO4A3.
Note that this is not a negated reset-signal (due to a level shifter
being needed for this signal anyway), but a negated enable-signal:
to enable, we need to output LOW (i.e. 0)... so we mark this as an
ACTIVE_LOW signal.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
CMD_USB_MASS_STORAGE
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
|
|
The dwc3 controller is using 8 bit UTMI+ interface for USB2.0 PHY,
add one variable in dwc3/dwc3_device struct to support 16 bit
UTMI+ interface on some SoCs like Rockchip rk3399.
Change-Id: Ic5db5e9ee845b5f9d2848bb44fbf07c094b3b5a7
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
|
|
|
|
This patch adds board_usb_init() and interrupt callback
for dwc3 gadget.
Change-Id: I1ea19c0ec7d3fd14904e7fcc97c6d19221206762
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
|
|
To include the ability to load from an SPI flash in SPL, it's not
sufficient to define SPL_SPI_SUPPORT and SPL_SPI_FLASH_SUPPORT via
Kconfig... so we conditionally define SPL_SPI_LOAD if SPI support
is already enabled for SPL via Kconfig.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
Series-to: u-boot@lists.denx.de
Series-cc: Klaus Goger <klaus.goger@theobroma-systems.com>
Series-changes: 4
- changed rk3399_common.h to allow a per-board SPI config through
defconfig (previously a stand-along patch, now part of the series)
|
|
The existing Rockchip SPI (rk_spi.c) driver also matches the hardware
block found in the RK3399. This has been confirmed both with SPI NOR
flashes and general SPI transfers on the RK3399-Q7 for SPI1 and SPI5.
This change adds the 'rockchip,rk3399-spi' string to its compatible
list to allow reuse of the existing driver.
X-AffectedPlatforms: RK3399-Q7
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
This commit adds support for the pin-configuration of the SPI5
controller of the RK3399 through the following changes:
* grf_rk3399.h: adds definition for configuring the SPI5 pins
in the GPIO2C group
* periph.h: defines PERIPH_ID_SPI3 through PERIPH_ID_SPI5
* pinctrl_rk3399.c: adds the reverse-mapping from the IRQ# to
PERIPH_ID_SPI5; dispatches PERIPH_ID_SPI3
through SPI5 to the appropriate pin-config
function; implements the pin-configuration
for PERIPH_ID_SPI5 using the GPIO2C group
X-AffectedPlatforms: RK3399-Q7
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
The baudrate in rkspi was calculated by using an integer division
(which implicitly discarded any fractional result), then rounding to
an even number and finally clamping to 0xfffe using a bitwise AND
operator. This introduced two issues:
1) for very small baudrates (overflowing the 0xfffe range), the
bitwise-AND generates rather random-looking (wildly varying)
actual output bitrates
2) for higher baudrates, the calculation tends to 'err towards a
higher baudrate' with the actual error increasing as the dividers
become very small. E.g., with a 99MHz input clock, a request
for a 20MBit baudrate (99/20 = 4.95), a 24.75 MBit would be use
(which amounts to a 23.75% error)... for a 34 MBit request this
would be an actual outbout of 49.5 Mbit (i.e. a 45% error).
This change rewrites the divider selection (i.e. baudrate calculation)
by making sure that
a) for the normal case: the largest representable baudrate below the
requested rate will be chosen;
b) for the denormal case (i.e. when the divider can no longer be
represented), the lowest representable baudrate is chosen.
Even though the denormal case (b) may be of little concern in real
world applications (even with a 198MHz input clock, this will only
happen at below approx. 3kHz/3kBit), our board-verification team kept
complaining.
Series-changes: 4
- added in v4 after receiving complaints from the board-verification
team
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
|
|
The original clock/bitrate selection code for the rk_spi driver was a
bit limited, as it always selected a 99MHz input clock rate (which
would allow for a maximum bitrate of 49.5MBit/s), but returned -EINVAL
if a bitrate higher than 48MHz was requested.
To give us better control over the bitrate (i.e. add more operating
points, especially at "higher" bitrate---such as above 9MBit/s), we
try to choose 4x the maximum frequency (clamped to 50MBit) from the
DTS instead of 99MHz... for most use-cases this will yield a frequency
of 198MHz, but is flexible to go beyond this in future configurations.
This also rewrites the check to allow frequencies of up to half the
SPI module rate as bitrates and then clamps to whatever the DTS allows
as a maximum (board-specific) frequency and does away with the -EINVAL
when trying to select a bitrate (for cases that exceeded the hard
limit) and instead consistently clamps to the lower of the hard limit,
the soft limit for the SPI bus (from the DTS) or the soft limit for
the SPI slave device.
This replaces
"rockchip: spi: rk_spi: select 198MHz input to the SPI module for the RK3399"
"rockchip: spi: rk_spi: improve clocking code for the RK3399"
from earlier versions of this series.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Series-changes: 4
- rewrite to not introduce a chip-specific define, add a dynamic
module input rate selection and unify the bitrate handling for hard
and soft limits.
(replaces 2 earlier commits mentioned in the commit message)
|
|
i2c/spi_set_rate
For the RK3399, i2c_set_rate (and by extension: our spi_set_rate,
which had been mindlessly following the template of the i2c_set_rate
implementation) miscalculates the rate returned due to a off-by-one
error resulting from the following sequence of events:
1. calculates 'src_div := src_freq / target_freq'
2. stores 'src_div - 1' into the register (the actual divider applied
in hardware is biased by adding 1)
3. returns the result of the DIV_RATE(src_freq, src_div) macro, which
expects the (decremented) divider from the hardware-register and
implictly adds 1 (i.e. 'DIV_RATE(freq, div) := freq / (div + 1)')
This can be observed with the SPI driver, which sets a rate of 99MHz
based on the GPLL frequency of 594MHz: the hardware generates a clock
of 99MHz (src_div is 6, the bitfield in the register correctly reads 5),
but reports a frequency of 84MHz (594 / 7) on return.
To fix, we have two options:
* either we bias (i.e. "DIV_RATE(GPLL, src_div - 1)"), which doesn't
make for a particularily nice read
* we simply call the i2c/spi_get_rate function (introducing additional
overhead for the additional register-read), which reads the divider
from the register and then passes it through the DIV_RATE macro
Given that this code is not time-critical, the more readable solution
(i.e. calling the appropriate get_rate function) is implemented in this
change.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
Series-changes: 2
- fixes an off-by-one for the RK3399 that cause the SPI module input
clock to be misstated as 84MHz (even though it was running at 99MHz)
|
|
This change adds support for configuring the module clocks for SPI1 and
SPI5 from the 594MHz GPLL.
Note that the driver (rk_spi.c) always sets this to 99MHz, but the
implemented functionality is more general and will also support
different clock configurations.
X-AffectedPlatforms: RK3399-Q7
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com>
Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
Cover-letter:
rockchip: spi: rk3399: add SPI support for the RK3399
This series adds SPI support for the RK3399 (SPI1 and SPI5). This
consists of the following individual changes:
- clock support for the SPI blocks clocked from GRF (i.e. SPI1, SPI2,
SPI 4 and SPI5)
- pinctrl for SPI1 and SPI5
- changes the SPI module input clock to 198MHz (instead of 99MHz) for
the RK3399 to improve the available bitrates at higher frequencies
(e.g. adding the 39MBit and 28MBit operating points)
- modifies the calculation of the top frequency permissible (as the
49.5MBit operating point had not been permissible due to a hard
limit at 48MBit)
In addition to these changes, the divider calculation for the baudrate
is changed to
- try hard not to exceed the requested rate (i.e. err towards a
lower rate)
- not to overflow the divider field (which may result in a very large
actual baudrate for very small requested baudrates)
To make it easier to track this change set (and avoid me sending patch
series with broken cover letters), this now also includes the change
to have a per-board SPI config:
rockchip: spl: rk3399: prepare to have SPI config per-board
To support SPI flashes (via the device model) and enable loading of
later-stage images from SPI in SPL, we need a few adjustments to the
common configuration header for the RK3399:
- enable SPL_SPI_LOAD if SPI is enabled for SPL (in rk3399_common)
- move CONFIG_SPI and CONFIG_SPI_FLASH (from rk3399_common) to defconfig
END
Series-version: 4
Series-changes: 3
- replaced macro-pasting with a lookup table to improve readability
(as requested by Simon)
Series-changes: 2
- fixes a wrong macro usage, which caused the SPI module input clock
frequency to be significantly higher than intended
- frequencies have now been validated using an oscilloscope (keep in mind
that all frequencies are derived from a 99MHz module input clock) at the
following measurement points (assuming the other fix for the usage of
DIV_RATE from the series):
* 1 MHz ... 0.99 MHz
* 5 MHz ... 4.95 MHz
* 10 MHz ... 9.9 MHz
* 30 MHz ... 33 MHz
* 50 MHz ... 49.5 MHz
|
|
|
|
To run U-Boot with full DM support on the RK3399, we need to implement
clk_get_rate for the UART0 (default console on the RK3399-Q7) and UART2
(default console on the RK3399-EVB) in a minimal way: as there's no
code to change the clock source to anything but the 24M oscillator yet,
we simply return a rate of 24MHz.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
This change migrate the following configuration options for Kconfig:
* PHY_GIGE, indicates that a controller (with an appropriate PHY) is
Gigabit capable and enables extra support in the miiutil for
parsing the status of Gigabit PHYs
* adds configuration options for Micrel KSZ9021 and KSZ9031 GbE PHYs,
which previously had to enabled through a board-specific config file
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Series-to: u-boot@lists.denx.de
Series-cc: Klaus Goger <klaus.goger@theobroma-systems.com>
Series-cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Series-cc: Joe Hershberger <joe.hershberger@gmail.com>
Series-version: 3
Series-changes: 3
- add a label to the PHY_GIGE option to make it selectable via menuconf
- automatically select PHY_GIGE when a KSZ9021 or KSZ9031 is selected
- fix indentations (convert spaces to tabs)
- adds help text for PHY_MICREL
Series-changes: 2
- migrate PHY_GIGE to Kconfig
|
|
Some platforms require more complex U-Boot images than we can easily
generate via the mkimage command line, for instance to load additional
image files.
Introduce a CONFIG_SPL_FIT_SOURCE and CONFIG_SPL_FIT_GENERATOR symbol,
which can either hold an .its source file describing the image layout,
or, in the second case, a generator tool (script) to create such
a source file. This script gets passed the list of device tree files
from the CONFIG_OF_LIST variable.
A platform or board can define either of those in their defconfig file
to allow an easy building of such an image.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
|
|
The sunxi SPL was holding the detected RAM size in some local variable
only, so it wasn't accessible for other functions.
Store the value in gd->ram_size instead, so it can be used later on.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
|
|
The generic ARMv8 assembly code contains routines for setting up
a CCN interconnect, though the Freescale SoCs are the only user.
Link this code only for Freescale targets, this saves some precious
bytes in the chronically tight SPL.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
|
|
Not every SoC needs to set up the GIC interrupt controller, so link
think code only when the respective config option is set.
This shaves off some bytes from the SPL code size.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
|
|
So far we were not using the FIT image format to its full potential:
The SPL FIT loader was just loading the first image from the /images
node plus one of the listed DTBs.
Now with the refactored loader code it's easy to load an arbitrary
number of images in addition to the two mentioned above.
As described in the FIT image source file format description, iterate
over all images listed at the "loadables" property in the configuration
node and load every image at its desired location.
This allows to load any kind of images:
- firmware images to execute before U-Boot proper (for instance
ARM Trusted Firmware (ATF))
- firmware images for management processors (SCP, arisc, ...)
- firmware images for devices like WiFi controllers
- bit files for FPGAs
- additional configuration data
- kernels and/or ramdisks
The actual usage of this feature would be platform and/or board specific.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
|
|
At the moment we load two images from a FIT image: the actual U-Boot
image and the DTB. Both times we have very similar code to deal with
alignment requirement the media we load from imposes upon us.
Factor out this code into a new function, which we just call twice.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
|
|
Currently the SPL FIT loader always looks only for the first image in
the /images node a FIT tree, which it loads and later executes.
Generalize this by looking for a "firmware" property in the matched
configuration subnode, or, if that does not exist, for the first string
in the "loadables" property. Then using the string in that property,
load the image of that name from the /images node.
This still loads only one image at the moment, but refactors the code to
allow extending this in a following patch.
To simplify later re-usage, we also generalize the spl_fit_select_index()
function to not return the image location, but just the node offset.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
|
|
Currently the SPL FIT loader uses the spl_fit_select_fdt() function to
find the offset to the right DTB within the FIT image.
For this it iterates over all subnodes of the /configuration node in
the FIT tree and compares all "description" strings therein using a
board specific matching function.
If that finds a match, it uses the string in the "fdt" property of that
subnode to locate the matching subnode in the /images node, which points
to the DTB data.
Now this works very well, but is quite specific to cover this particular
use case. To open up the door for a more generic usage, let's split this
function into:
1) a function that just returns the node offset for the matching
configuration node (spl_fit_find_config_node())
2) a function that returns the image data any given property in a given
configuration node points to, additionally using a given index into
a possbile list of strings (spl_fit_select_index())
This allows us to replace the specific function above by asking for the
image the _first string of the "fdt" property_ in the matching
configuration subnode points to.
This patch introduces no functional changes, it just refactors the code
to allow reusing it later.
(diff is overly clever here and produces a hard-to-read patch, so I
recommend to throw a look at the result instead).
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
|
|
Revise the loop watching for a timeout on obtaining a DRAM PHY lock to
clearly state a timeout in milliseconds and use get_timer (based on
the ARMv8 architected timer) to detect a timeout.
|
|
ARM64 is using 64bit address which address cell is 2 instead of 1,
update to support it when of-platdata enabled.
Change-Id: Ieca9734b6b3f5808a16c7fa38105dd021ead728d
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Andrew F. Davis's below patch will make malloc_base, limit, ptr not initualized
in spl_init when we call spl_init in board_init_f. Add spl_early_init which can
be called in board_init_f to fix this issue.
commit b3d2861eb20a795b99292b823c923935df26dfc6
Author: Andrew F. Davis <afd@ti.com>
Date: Fri Jan 27 10:39:19 2017 -0600
spl: Remove overwrite of relocated malloc limit
Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
|
|
ATF(ARM Trust Firmware) is used by ARM arch64 SoCs, find more infomation
about ATF at:
SPL is consider as BL2 in ATF, it needs to load other part of ATF binary
like BL31, BL32, SCP-BL30, and BL33(U-Boot). And needs to prepare the
parameter for BL31 which including entry and image information for all
other images. Then the SPL handle PC to BL31 with the parameter, the
BL31 will do the rest of work and at last get into U-Boot(BL33).
Cover-letter:
arm64: rk3399: enable SPL with ATF support
RK3399 SPL is not enable bacause of the lack of ATF support in SPL,
after port some source code from ATF, I manage to enable the support for
ATF in SPL. This patch set depends on some patch for SPL support multi
binary in FIT which is from Andre.
The patch of sdram controller is still not clean, because I want to get
comments from upstream.I port this driver from coreboot, and I don't
want to make much change on it. The rk3399 dram controller has many registers
to config, I want to make them directly used by driver instead of parse
and copy them one by one from dts.
Another part of comment is welcome for the implementation of spl_atf.c
and the entry in spl.c
END
Series-prefix: RFC
Series-cc: andre.przywara@arm.com
Change-Id: I1609951af76399ba0699c1ad13a31e072b0d567f
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Conflicts:
common/spl/spl.c
|
|
package the U-Boot and ATF in a FIT file for SPL.
use command:
tools/mkimage -f rk3399_atf.its -E rk3399_atf.itb
Change-Id: Idf2418157819341e7e218168a970430975e33a3d
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
The logical expression to check the dtb is incorrect in
load_devicetree.
The problem was indicated by cppcheck.
The inconsistent variable name dtppart is changed to dtbpart.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Hannes Schmelzer <oe5hpm@oevsv.at>
Acked-by: Hannes Schmelzer <oe5hpm@oevsv.at>
|
|
The evaluation of option -c is incorrect:
According to the C99 standard endptr in the first strtol is always
set as &endptr is not NULL.
So the first part of the or condition is always true.
If all digits in optarg are valid endptr will point to the closing \0
and the second strtol will read beyond the end of the string optarg
points to.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
|
|
va_start must always be matched by va_end.
The problem was indicated by cppcheck.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
We should not first dereference p and afterwards assert that is
was not NULL. Instead do the assert first.
The problem was indicated by cppcheck.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
In dram_init_banksize there seems to be a typo concerning
a plausibility check of the fdt.
Testing sc > 2 twice does not make any sense.
The problem was indicated by cppcheck.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
A feature rich Linux kernel needs more than 8 MiB.
Hence enlarge CONFIG_SYS_BOOTM_LEN to 64 MiB for the GXBB systems.
As all known GXBB systems have at least 512 MiB of RAM this poses no problem.
Cc: Andreas Färber <afaerber@suse.de>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
