Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

- copyright header to local conventions
- fix a little white space
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

- Turn the copyright header to the local convention
- fix a little white space
- fix flash_sdb_check (must return error -- but it's unused)
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

The optimization is the removal of the retval variable in
bbspi_transfer() and using the val parameter as a "shift register"
that is returned at the end of the function.
Signed-off-by: Theodor Stana <t.stana@cern.ch>

How-to guide for the tool (together with flash-write tool) can be found in
sdbfs.README.
Signed-off-by: Theodor Stana <t.stana@cern.ch>

SQUASH remove flash-read binary: 598d cdf68
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

The issue was due to a bug in gpio_in, which was doing an AND with
the value of GPIO_SPI_MISO, which was set to the pin offset, instead
of what it was set in the include/syscon.h file.

When I copied the gpio functions from include/syscon.h, I overlooked
the fact that the pins for the gpio functions there are set using
wbgen macros that actually perform the shifting, and I simply copied
the functions and redefined the GPIO_SPI_MISO macros as offsets.

The issue has been fixed by redefining the gpio_in function as an
AND with the value (1 << PIN_NR). This fixes everything.
Signed-off-by: Theodor Stana <t.stana@cern.ch>

Signed-off-by: Theodor Stana <t.stana@cern.ch>

For this to work, I also had to add (in flash.c) setting the
entry-point to the right value (the one where the SDB magic is
detected).

The rest of the commit files are just toying around for testing
purposes.
Signed-off-by: Theodor Stana <t.stana@cern.ch>

There was somewhat of a bug in the spec_write_flash function of
flash-write. The memcpy function was not functioning 'as expected',
so I changed the fixed-size buffer for a pointer and malloc-ed it
to the size. This seems to fix the bug.

The issue about reading the flash status register has yet to be
fixed.
Signed-off-by: Theodor Stana <t.stana@cern.ch>

Signed-off-by: Theodor Stana <t.stana@cern.ch>

The flash-write tool is operational. The call to read status register
from flash-host is not working yet, and that is to be solved. In the
meantime, there are sleep functions inserted where we're supposed
to poll the status register.
Signed-off-by: Theodor Stana <t.stana@cern.ch>

wrc_main still in test-mode, currently doing a read of the first two
sectors (in the purpose of testing flash-write in tools -- see next
commit)

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

eeprom_present() returned a value nobody used. Rename to eeprom_init()
instead. Also, save the two parameters so that they are not needed
in other functions (see later commits).

Also, turn int8_t to int as function arguments (int is better for the
CPU).

This adds 20 bytes to the legacy case, and removes 4 to the sdb case.
The legacy size is reduced by later commits.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

This allows stuff like

  ./MAKEALL spec_legacy_defconfig spec_sdb_defconfig

to choose your relevant configuration files alone.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

This is the simpler thing: have vendor ID in the data structure.

We have 100 bytes more of data, but we save 50 bytes of code.  Total:
50 more but with simpler code (not bound to cern and gsi, thus
reusable).

Please maintainer choose and squash.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

[Note: this patch can be preserved or squashed into commit
  replace sdb.c with new library-based code
at the maintainer's best choice]

My initial code assumed the vendor is always VID_CERN, but this is
not true: some cells we use are VID_GSI.  This takes care of the thing.

To save a little space, instead of adding a 64-bit field to the data
structure describing a device, I add an integer field stating whether
the device is CERN or GSI.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

This adds almost 800 bytes to all configurations, but removes
200 bytes from the gsi_defconfig.  This is because sdb-eeprom
is already managed with this library, and thus the commit is removing
a duplication.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

It is not mandatory to actually register the tree, but it's
a good move for consistency.

Later we'll need to scan several devices, for example to look for a
mac address in carrier flash or eeprom. To do that we'll need to have
devices properly registered.

This costs 150 bytes of binary size in gsi_defconfig.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

This makes the binary size 500 bytes bigger for gsi_defconfig
(the configuration already using the library) and strangely a little
smaller for etherbone_defconfig.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

We agreed, long ago, to have 128k on the spec, like GSI is
already doing. This changes the default in Kconfig and removes
specific settings in configs/*
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

If the host wants a consistent view (*if* it wants it), it
can wait for the sequence number to be even, read the lot and
then check it did not change.

If it is odd, it means the structure is being modified. If it changed
after reading it means a new modification started.

Not my invention: it's old stuff, though smart. See sequential locks
in the kernel for example.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Conflicts:

	arch/lm32/ram-wrs.ld

"char valid" in a structure of integer makes alignment problems
(because we are accessing it from a different CPU we'd better not have
holes).

Also, there is no inherent consistency needed here, and this valid bit
is racy anyways. We could solve it with a sequence number, if any, but
let's avoid it altogether by now.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>