Sascha:
> In order to get an idea of how routing is supposed to work I had to look
> around in the code. It's really a pain to see and I really don't want to
> have to debug it. The combination of two spaces indentation and a huge
> #ifdef density makes it really hard to read.
Indentation is affor
>> This hasn't
>> seen development activity in 5 years.
>
> Please see https://github.com/virtualsquare/picotcp
But the TCP/IPV4 standard didn't change, either.
>> lwIP on the other hand still sees active development.
>
> I agree with you. It looks like lwIP is more popular than picotcp.
Sure.
> Not sure if I'd say it would be "complex", but time consuming for
> sure.
Yes.
> but AFAIK, while ARM9 CPU emulation is availible, there's no AT91 SoC
> specific IP blocks emulation that it supports.
I think the fastest way to work out this setup is building barebox for
versatile and using "qe
Hello.
> emulate a spacial boot configuration of the CERN White Rabbit switch
> (http://white-rabbit.web.cern.ch/).
The White Rabbit switch is AT91SAM9G45 (I have one on my desk).
Unless your own WR switch is a new design running on cortex-a57, you
shoul cross-compile for arm32 and use a correspo
> Subject: [PATCH] at91sam9x5: for ROM base address (bugfix for nand ECC)
Argh! After a lot of editing, the subject line is wrong.
fix ROM base address (bugfix for nand ECC)
Anyways, let me add this detail. The current code considers the
case where dev_request_mem_region() fails.
ho
From: Edoardo Scaglia
The ROM base address in the 9x5 processors lives at 1M, not 4M,
where SMD is, as defined later in the same file.
The ROM includes some tables that are used to build error-correction data
for NAND memory. By using the wrong address, we get wrong data and
the result is undet
> static variables are initialized to 0 (for pointers: NULL) by the
> compiler.
Well, not really. The compiler just places them in the .bss area. It
is barebox, it is run-time initialization, that zeroes bss.
So it is barebox, not the compiler.
Uwe, I know you know this, but I'd better make it
> The most notable is lwIP (http://savannah.nongnu.org/projects/lwip/).
I'm not happy at all about this code base, it looks quite ugly and
old-fashioned. It's not the barebox kind of quality. I'd stay with the
current code rather than lwip, despite the number of users.
If any, I'd evaluate picotc
ot;thos").
> are you the same Alessandro Rubini who wrote "Linux Device Drivers"?
Not completely. Many years passed, and I'm now less positive about the
future. But next time please ask offlist, or search the net.
Now, netiquette-wise, is it worse talking about oneself or
Great news Sascha.
>> I therefore decided that it's no longer necessary to have the overhead
>> of Linux at all. The project will be renamed to barebOS in the next few
I believed it, until the "rename" bit.
Actually, adding a scheduler and making it an RT OS has been in my
intentions for quite a
I wrote:
> Since uncompressed environent areas are not supported any more, what is
> the preferred method to change the default environment variables?
Actually, by removing compressing code the environment is uncompressed
itself, but it looks like I have other problems that are not yet
completely
Hello.
I'm using barebox on a machine where I wasnt to change the mac address
at flashing time (i.e., not at build time: I'd better not relink
barebox every time I flash a new machine).
I did it lazily with a sed script when the environment was not
compressed, but now a mate updated to a newer ve
12 matches
Mail list logo
