problem loading Biffboot onto MRT WANSER-R units

[Razvan Dragomirescu]

Hello everyone,

 

We're in the process of getting some WANSER-R units from the guys at MRT Communications to continue our Bifferboard-based product and we've asked MRT to load Biffboot onto the boards and assign them unique MAC addresses.

 

However, they emailed back saying that they were unable to load Biffboot (most probably the Community Edition) via JTAG and that they are also unable to assign unique MAC addresses to the boards (they apparently do have a tool for this but it's incompatible with Biffboot for some reason).

 

They also said that we were the first to order Biffboot-enabled units directly from them (which is a bit weird since I've seen at least 2 messages on the boards here saying they had contacted them and placed orders).

 

So, has anyone on this list managed to get WANSER-R units preloaded with Biffboot from the manufacturer? Any clues on how to do it / what to instruct them to do?

 

Thank you,

Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

[Andrew Scheller]

> So, has anyone on this list managed to get WANSER-R units preloaded with
> Biffboot from the manufacturer?

Not myself (I have no need for 500 bifferboards!).

> Any clues on how to do it / what to instruct
> them to do?

You need to write the MAC address into biffboot before flashing it...
https://sites.google.com/site/bifferboard/biffboot-community-editions
"Modification of the Bootloader binary is not permitted, excepting the 6-byte
MAC address found 8 bytes from the end of the 64k Bootloader binary."

You'll probably need to update the biffboot_versions list, but have a look at
http://www.andrewscheller.co.uk/biffboot_setmac.py
Let me know if you find it useful and I'll clean it up and stick it
onto sourceforge.

There's also http://bifferboard.svn.sourceforge.net/viewvc/bifferboard/biffboot/biffboot_info.py
As bifferboard unfortunately now seems like a 'dead' project (at least
from my hobbyist point-of-view), I never got round to doing much
testing with BiffBootCE.

Lurch

[biff...@yahoo.co.uk]

On Jan 3, 3:01 pm, Andrew Scheller <ya...@loowis.durge.org> wrote:
> You need to write the MAC address into biffboot before flashing it...https://sites.google.com/site/bifferboard/biffboot-community-editions

> "Modification of the Bootloader binary is not permitted, excepting the 6-byte
> MAC address found 8 bytes from the end of the 64k Bootloader binary."

I would do it like this:

1) Using a binary editor, write the address FF:FF:FF:FF:FF:FF into the
location 8 bytes from the end of the bootloader, so that it keeps the
flash 'unprogrammed' state.
2) Make up some 8MB firmware using dd or some other tool such that the
bootloader is right at the end of an 8MB file.
3) Tell MRT to program this 8MB firmware using their bulk programmer
before they put the chips on the board. You can also write the
bootloader by JTAG later, it just takes longer this way.
4) When the boards are being tested, at the factory (or you can do it
yourself), program the 6 byte MAC address using the Python JTAG
software. The JTAG software probably doesn't currently support this,
but it will be trivial to change that. Have a look at:
https://github.com/bifferos/bb/blob/master/tools/jtag/program.py

You can see that the first operation is an erase, and then the sector
is programmed. Don't do the erase, as that will erase the bootloader
You simply need to program the individual bits for the MAC area, which
will be all '1's starting at 0xfffffff8. EonProgram takes a short, so
for mac 00:01:02:03:04:05 you do something like:

r = rdc.RDC()
r.EonProgram(0xfffffff8, 0x0100)
r.EonProgram(0xfffffffa, 0x0302)
r.EonProgram(0xfffffffc, 0x0504)

I tested that python script before I released it, but take note it was
a relatively old computer I tested on, I think it could even have been
a 586, so if it doesn't work for you could perhaps try something
slower.

Hope this helps,
Biff.

[Razvan Dragomirescu]

Thanks for the update Biff,

They've managed to flash the bootloader to the units (the problem was that they were trying to flash the LZMA-compressed file instead of the uncompressed BIN file).

 

I still don't get the MAC address situation - don't the units already have a unique MAC address (from the factory)? We don't care what MAC address they come with, we are changing it from Linux (ifconfig eth0 hwaddr xx:yy:zz:aa:bb:cc) anyway as soon as the firmware boots up (but we use the original MAC for copy protection, so we would need it to be unique, not from a specific range, just unique).

 

We would also like to avoid having to use JTAG (don't have a JTAG cable or programmer and have never done this before), is there a way for them to do this at the factory?

 

So do we have to program a MAC address into the last 6 bytes of flash at all or will Biffboot pick up the default MAC address and boot without problems?

 

Thanks again,

Razvan

 

 

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

--
To unsubscribe send email to bifferboard...@googlegroups.com

[biff...@yahoo.co.uk]

On Jan 7, 10:59 am, Razvan Dragomirescu
<razvan.dragomire...@gmail.com> wrote:
> I still don't get the MAC address situation - *don't the units already have
> a unique MAC address (from the factory)?* We don't care what MAC address

They will have whatever MAC address was programmed into the flash. I
think there is a general misconception here, there is no other place
where the MAC can be stored. If you buy a network card for your PC it
will have some flash memory to store the MAC - this is no different
from the Bifferboard, except the Bifferboard does not have that
'extra' flash memory, it would be a pointless extra expense. The MAC
isn't stored in the silicon of the NIC. It's just combined into the
main flash, and programmed into the NIC registers at boot time, by
Biffboot, so the operating system gets to see it. MAC addresses are
generally assigned to a batch of boards, but you cannot get to them
programmatically unless you have made some provision for this in your
firmware.

> We would also like to avoid having to use JTAG (don't have a JTAG cable or
> programmer and have never done this before), is there a way for them to do
> this at the factory?

Sure, but you'll have to provide them with a tool, and that may mean
developing it yourself, and in order to do that it'll be difficult
without a JTAG cable. I say 'developing' in the broadest sense. You
probably only need to test what I've shown above. I think it's a
little risky though, to attempt sale of the boards without the
capability to reprogram via JTAG. It means if the firmware becomes
corrupted somehow it has to go back to the factory. For the few euros
it costs to wire up/buy a JTAG adapter I can't understand why you'd
not want that security. The postage cost to China for one single
board is probably around the cost of a JTAG cable.

> So do we have to program a MAC address into the last 6 bytes of flash at
> all or will Biffboot pick up the default MAC address and boot without
> problems?

CE version of Bittboot comes with a default MAC, if you're happy with
that, no other action needed.

BTW, about this:

>They also said that we were the first to order Biffboot-enabled units
>directly from them (which is a bit weird since I've seen at least 2
>messages on the boards here saying they had contacted them and placed orders).

It's perfectly feasible that someone else is ordering the units
without Biffboot, and reprogramming them when they get them. The only
advantage of programming them at the factory is that they can be
tested there, so perhaps remove some faulty ones before shipment. I
suspect if MRT burns a NAS firmware they can use the test procedure
for that, it might be better this way, and cause less confusion all
round (but for large orders it makes more work for you, obviously).

regards,
Biff.

[Razvan Dragomirescu]

Thanks Biff! I'll get a JTAG adapter (any suggestions on what model we should get?), the problem with these units is that they're going directly to our client in the United States that expects to be able to flash our firmware via Ethernet and then send the units on their way to their users. I'm trying to avoid getting them to us in Romania first to just change a MAC address, then reship them to the United States.

 

Just to summarize: what you're saying is that the address programmed in the last 6 bytes of the flash memory will be the MAC address that the board will end up using. So if we flash the default CE Biffboot (or instruct MRT to do so), all our boards will have a MAC of 00:01:02:03:04:05. Correct?

 

And yes, you're right, I had misunderstood how the unique MAC addresses were assigned, I thought they were an attribute of the silicon (the Ethernet chip) and not something that actually sits in the main flash memory of the Bifferboards.

 

Thank you!

Razvan

 

 

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

Biff.

[biff...@yahoo.co.uk]

On Jan 7, 1:07 pm, Razvan Dragomirescu <razvan.dragomire...@gmail.com>
wrote:

> Thanks Biff! I'll get a JTAG adapter (any suggestions on what model we
> should get?), the problem with these units is that they're going directly

I think this has been discussed in the group before. I made a couple
of my own in the past, they are not very difficult and can be done on
stripboard.

> to our client in the United States that expects to be able to flash our
> firmware via Ethernet and then send the units on their way to their users.
> I'm trying to avoid getting them to us in Romania first to just change a
> MAC address, then reship them to the United States.
> Just to summarize: what you're saying is that the address programmed in the
> last 6 bytes of the flash memory will be the MAC address that the board

Almost, it's not quite the last 6 bytes, it's two bytes in.
0000ffb0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ|
0000ffc0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ|
0000ffd0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ|
0000ffe0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ|
0000fff0 e9 0a f1 ff ff ff ff ff 00 01 02 03 04 05 08 ff |
é.ñÿÿÿÿÿ.......ÿ|
00010000

> will end up using. So if we flash the default CE Biffboot (or instruct MRT
> to do so), all our boards will have a MAC of 00:01:02:03:04:05. Correct?

Yes.

regards,
Biff.

[Razvan Dragomirescu]

Would something like this work: http://www.digilentinc.com/Products/Detail.cfm?Prod=JTAG-HS2 ? As far as I could tell from reading the group + Wiki, I need a Xilinx-compatible cable (and the original Xilinx ones cost an arm and a leg). I also don't have a computer with a parallel port (and buying another computer just to get a parallel port is not something I plan to do - if I can even find one that still has a parallel port :) ).

 

The one I linked to above appears to be completely compatible with Xilinx software (and I'm assuming with Biff's software as well). Is there anyting in the open-source BiffJtag software that requires a physical parallel port? I may be asking stupid questions, I know :), so thank you for your patience.

 

Razvan

 

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

regards,
Biff.

[Ole Andre Rodlie]

Hi, I use "Xilinx Buffered Parallel Cable III PC3 DLC5 LPT JTAG
Programmer for CPLD XC2C64A", you can find it new on Ebay for ~ $10.

You can find a parallel port PCI card for ~ $5 if you don't have one
(yes, you need to use the parallel port).

Regards

Ole Andre

[Andrew Scheller]

> software (and I'm assuming with Biff's software as well). Is there anyting
> in the open-source BiffJtag software that requires a physical parallel port?

It was much *much* slower than using 'real' JTAG, but I once (with
much trial&error) managed to adapt Biff's open-source python jtag to
use a Bifferboard's GPIO pins, i.e. having GPIO on one bifferboard
talking to the JTAG on a second bifferboard :-)
Unfortunately I accidentally overwrote all my modifications though,
and it was so painfully slow (IIRC it took about quarter of an hour
just to read the 64k bootloader) I didn't bother to re-create it.

Lurch