Ethernet in a cold climate / SMDK6410
andy at warmcat.com
Tue Dec 29 07:50:52 EST 2009
On 12/29/09 12:33, Somebody in the thread at some point said:
>> Like I say it sets up a magic nCS signal in the bootloader init, it
>> talks about it as CS8900A but elsewhere they talk about "ethernet",
>> so it may simply use this nCS to get to both ethernet chips, I
>> didn't look at the schematic yet.
> I'd assume so given that the board has a physical switch selecting between
> the two ethernet controllers.
Yeah I found that thismorning, CFG6. I added a comment about that and
the (discovered by trial and error) requirement that it's nCS1
specifically needed to drive it to work with the 0x18000000 magic number.
I found that the nCS1 bus width defaults to 8-bit in the CPU, otherwise
it's now addressable. So I am adding some constants for s3c64xx SROM
unit in the platform stuff and will set it up in mach-smdk6410.c.
>>> Qi would be a massive step back for me in terms of usability
>>> unfortunately - having to transfer things to an SD card to boot them
>>> would add a lot to my edit, compile run cycle compared to netboot.
>> You seem pretty sure about that, so much so I guess you never tried
>> this workflow.
> Really, I've tried this and similar workflows. Network boot beats
> everything else I've tried.
>> 1) you screwed your kernel and it blows chunks on boot. In that
>> case, you either have to make arrangements in the bootloader to
>> check a button and use a backup kernel if pressed (Qi supports this
>> generically), or pop the SD card and write the kernel on the host.
>> In the button case, you just reset with that button down and use a
>> host build script to ssh / rsync over your next kernel try without
>> touching the SD Card.
> Either physically swapping the SD card or having to dance with the
> bootloader to revert to a known good configuration then refresh are very
> involved relative to flipping the power switch and booting, partly
> because they do actually take a relatively long time and partly because
> they aren't the same routine normally used to boot and so require more
> attention and thought (not much, but enough).
Yeah. All I can say is that constant testing of kernels that fail to
boot is a somewhat specialized case. You would be into pressing a
button or popping the card.
>> 2) you are working on a driver that can be done modular while
>> there's risk of it blowing chunks. In this case your build script
>> can build the kernel on the host and update the module over ssh /
>> rsync. You then modprobe -r / modprobe it without touching the SD
>> Card or even resetting.
> This is what I'm actually doing - things that can be built modular
> generally are, but there's always things that won't allow that.
Sure. In the ones you build modular, there's no cost to the SD flow.
>> I don't see those workflows as any "massive step back"; compared to
>> raw NAND being able to pop and rewrite the SD card in an emergency
>> is certainly a massive step forward.
> Compared to NAND removable media can be a win, yes, though with fast
> JTAG having to rewrite the flash needn't be any slower so it's not quite
> that clear cut.
Right, but if you can eliminate JTAG in the flow, especially at the
factory, that is a major simplification.
SD + Qi has the advantage it eliminates completely "board bringup" at
the factory. Qi has no state stored on the board that changes boot
flow. So you can give a virgin board an SD and it brings itself up with
no special gear or processing steps.
>> There's another reason to not act special towards the device with
>> stuff that does not represent what will ship, as the developer
>> you're the first user of it and if you're not hammering on,
>> experiencing and optimizing the boot flow that ships, nobody else
> With what I do it is relatively rare for me to work directly on
> production systems - the majority of the systems I'm using for driver
> development involve lots of flying wires and never see the light of
> anything except my desk, the end result being either core kernel changes
> or chip-specific drivers. Where I am working on production systems
> generally either it's not possible to do anything except JTAG onto the
> flash or the only thing changed by netboot is where the kernel image is
> loaded from.
Again all I can say is it's specialized case. For normal dev work SD is
either painless or hugely advantageous.
More information about the linux-arm-kernel