-
Notifications
You must be signed in to change notification settings - Fork 2
/
NOTES
1493 lines (1274 loc) · 66.3 KB
/
NOTES
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
================
APEX Boot Loader
NOTES
================
TODO:
o 2011.sep 16
o Pushed mx51 code to git hosts. It doesn't initialize properly
for USB, but there's no data to support further work at the
moment.
o 2011.sep.01
o === TODO
o Move MXC drivers to src/drivers-mxc/
o serial moved
o Add directory listing on fat.
x Write mapping command to allow addresses to be remapped from
the command line. It could be useful when loading a uboot
image where we cannot change the load address. May be
interesting in other cases. This also means we need to be
able to show the mappings, especially when they are not one to
one.
o Switch to protothreads for background service, e.g. ethernet.
x Support for high-capacity SD cards. Need this support to
mount the armhf card.
o 2011.aug.29
o imx51 boot successful. Boot to linux successful, but video
output broken probably caused by an incompatibility between
hardware and kernel. In fact, uboot booting doesn't make the
video work. Genesi is working on a solution.
o === TODO
x Support image load address change on loading images to allow
loading images with bogus or unusable for some reason. This
should only be necessary for uboot images but we never really
know.
x Fix environment set on mx51. Was a bug in the flash read.
x Move driver info calls to separate entry points s.t. version
only shows the most basic data.
x Implement a list or show command on regions that can be used
to show directory contents. Now, separate commands.
x Figure out if and why image show doesn't work when reading
directly from media. Seems to work OK.
x Move alias to 'set' and allow set alone to show environment as
well as set parameters.
o 2011.jul,1
o For the imx5x, we don't need to initialize SDRAM or test whether
or not we're running from SDRAM in most cases because the boot
ROM does this for us. In fact, we don't even need to be able to
relocate ourselves at all. We can eliminate the code that
detects whether we're already running in the right place if we
want.
o 2009.jan.4
o Handling extended partitions and large drives. The problems of
a couple of days ago are no longer present. Upgraded the
compiler and now there is no sign that the 64 bit support is
broken.
o THUMB. There is better support for thumb in that there are
functions to handle some of the cp15 calls that were always
inlined. For code that must inline, the macros are still
present.
o NOR flash scanner. It would be helpful to have a function to
scan nor flash and determine which blocks are in use. Also, it
would be handy to have a notation for flash that allows
specification of erase blocks or pages (NAND only). For example,
"nor:/N" where N is the block number, even when the blocks are
of differing sizes.
o 2009.jan.2
o Handling extended partitions and large drives. The extended
partition scanning code (in drv-ext2) properly reads each of the
extended partition descriptors. For the MV2120 platform, this
requires the CONFIG_DRIVER_LONG_LONG_SIZE option because the
seek function cannot otherwise distinguish between a large
positive offset or a negative one. However, there is a catch in
that the 64 bit length option appears to be unstable is some
cases. The program doesn't crash, but it does perform
improperly. A "du ata:0s+1s" doesn't end with a single sector.
The ext2_identify() function won't read any partitions.
One of the catches is that the starting offset for an extended
partition is the accumulation of the starting offsets for the
extended partition records plus the starting LBA for the
partition. This can be seen in the way that the sector_start is
adjusted for each extended partition record.
o 2008.dec.30
o Handling extended partitions. While adding features for the
MV2120 we found support for extended partitions in of itself is
reasonably simple to implement. However, the extended partition
is past a 2GiB offset. This offset is manageable, but we really
need to be able to handle extended partitions beyond 4GiBs. The
internals of the descriptor need to be extended to 48 or 64 bits
in order to handle this. Ay, carumba. I never thought that the
boot loader would have to be 64 bit filesystem compliant.
o 2008.dec.16
o The drv-ata driver needs to support multiple drives and the
absence of either or both. The orion5x controller ought to be
able to determine when a drive is present, so we should not have
to depend on a ready_wait timeout.
o 2008.nov.25
o Alias/environment variable references. Presently, variable
substitutions only traverse a single level. It is necessary to
support indefinite recursion. If kernelsrc refers to another
variable and it is used in the startup variable, we should be
able to dereference it.
o Startup that doesn't use copy. Originally, we only supported a
copy when loading data into memory. With aImages, there could
be an "im load" instead. How should this be integrated into
APEX?
o 2008.nov.18
o Thumb and GCC4.3. Support for thumb has been added back into
the build, but it doesn't appear to work. The failure has been
traced to the snprintf code being compiled for ARM. It may be
the first code executed in THUMB, so perhaps this is simply
something wrong with the thumb code in general.
o Exception vectors. It would be helpful to enable exception
vectors on the platform so that we can debug some conditions
that trap. This may require that we put those vectors into the
first portion of the APEX image and use the MMU to map them into
the proper place in RAM. Alternatively, we could put the
exception vectors (aligned) anywhere in the APEX image and map
those. The advantage of the first is that we *can* have
exception vectors without the MMU if NOR flash maps to 0.
o 2008.nov.9
o Detecting SATA. Absent SATA drives must not break the ATA
driver.
o dump command. The ASCII output doesn't change byte order with
the hex output data. So, in the case of a little-endian dump,
the ASCII ordering doesn't change when displaying words. This
may be incorrect. It should be compared with other kinds of hex
dumps.
o 2008.nov.2
o Feroceon. The ARM site claims that the 88F5182 is an ARMV5TE
which is true, sort of. It is really an ARM926EJS and is better
described by that reference when attempting to locate the
correct CP15 instructions to use.
o Revising the CP15 commands. It might be better to organize the
cp15 commands such that each ARM processor class has a header.
So, we'd have one each for the arm720, arm920, arm926, xscale,
feroceon, and so on. There seem to be some differences at this
level that aren't well categorized by the armv4, armv5, and so
on. The best thing would be to allow for stable implementations
of routines that *could* be the same, but could also change per
ARM implementation. If for no other reason than the Linux
kernel has organized the code that way.
The primary reason to look at it this way is to define
functions, as Linux does, to perform specific operations instead
of giving macros for every CP15 operation. In this way, we can
maintain the necessary balance between flexibility and accurate
implementation.
o 2008.nov.1
o mv2120
o Kernel wont' boot. Need to look at the booting code in uboot
to see what they're doing before the pass control to the kernel.
o Environment. Need to place an environment for APEX into flash
so that we can customize it once the system is running. We
can probably get away with a simple default, but I know we'll
want to be able to modify it once the system is running.
o MMU makes the IO much faster, but the cmd-reset doesn't work
any more. Not sure why since none of the peripherals would
work if the caching were broken...I thought.
o Timing with newly formatted ext3 partition. The second set of
numbers in parenthesis comes from enabling the MMU and cache
in APEX.
uboot ext2load apex copy apex im lo
uImage 35s 4s (2s) 8s (2s)
uImage-big 111s 9s (3s) 22s (3s)
o generic ata driver.
There are a lot of details to get right in order to let this
driver be sufficiently generic to be useful. The old CF driver
has a lot of LH7 specific hacks to deal with the peculiar
interface of the Logic brand dev boards.
We'll have to let the platform customize the accessor functions
adequately to enable alignment of the IO and to deal with the odd
cases such as device select.
There needs to be an is_present() function call that will
identify whether or not the drive is present. The read call may
need to be able to error out if the device is absent.
The region/path code needs to permit an extra indicator of the
channel and, god forbid, the controller. I don't want to get
too crazy with this, but it could be helpful.
The driver should support an info call so that report code can
say something about the underlying device support. This may be
too much to ask, however.
o 2008.sep.14
o Zero-length region. It may be useful to add state to the
descriptor_d that annotates a region that had no defined
length. The image handling code passes a flag to this effect
and some of the commands check for zero-length regions before
modifying the length to ...
o 2008.sep.11
o Images are working. There is an open issue dealing with a source
image that overlaps the target memory region. At the moment, we
don't handle this case at all. Relocating the source image is a
substantial task and may not very general purpose considering
that APEX doesn't attempt to grasp the overall memory map of the
system. Finally, APEX is designed to not require that images be
copied to RAM before being loaded. It much more efficient to
load/check images as they are being read from the source.
o 2008.aug.27
o The setenv command should be able to cope with a bad flash
environment region by letting the user set variables in the
memory copy. The user wouldn't be able to save, but variables
could be set. The trouble is that erasing the flash doesn't
clear the error in the environment being unwritable. Perhaps we
need a status which is unsaveable.
o 2008.aug.18
o Memtest would be nice to protect the user from testing invalid
memory. We could add a -f switch to force any address, but
normally protect the user from invalid RAM addresses.
o It would be handy if we could add a check to the build process
to make sure that a particular symbol is smaller than a known
value. This would make it possible to detect when the bootstrap
is too long, and therefore, unable to execute because it will
not be available in RAM when it needs to be.
o 2008.jul.9
o Fixed ext2 to use inode_size.
o BUG: found that the region ext2://3/file@100 doesn't work.
o 2008.aug.24
o We have added environment variables for the ramdisk, but there
is a redundancy. The length is represented in the source region
as well as the variable for the size. It would be ideal if the
source region simple referred to the size and it was expanded when
the region is referenced. We may live with the redundancy for a
while.
o It would be good to merge the environment and the aliases into a
single environment. Doing so requires that we allow the program
and user to distinguish between immediately saved environment
variables and the transient ones, like aliases. Moreover, it
should be possible to distinguish which variables cannot be
saved, e.g. the $apex or the $variation. Also, we should start
allowing the user to save to the environment even if there isn't
a environment variable struct.
o 2008.jun.27
o New Kbuild
o basic operation works
o Need packaging and _config target support
o Ian asked for a background task (service ()) invocation implementation
o Ian asked for peek/poke
- Need to fix ext2 driver bug (done)
o Should look into orion port to fix performance issue on boot
o Should add u-boot image support, probably as a driver
o 2008.mar.19
o Discovered that there is a bug in the ext2 driver. A filesystem
with deleted files and directories doesn't show up correctly.
o 2007.jul.23
o UBOOT annoyances
o flash info shows addresses; flash erase uses block numbers, WTF
o No type ahead, command line editing, or history
o units conversion is vague, hex numbers don't need 0x prefix
o No measurable progress long-running commands, just spinner
o help is vague. bootm, for example, claims that there could be
more than two arguments, but that isn't really the case.
o Allowing enter to redo a previous command is dangerous and
annoying since there is no ability to cancel a command while
it executes.
o Multiple code paths for common functions. e.g. booting linux
has more than one code path and the ARM path doesn't include a
ramdisk
o image format has data in it that doesn't belong there. The
load address for a ramdisk isn't really the purview of the
ramdisk creator but the boot loader. Moreover, since uboot
won't load a ramdisk as part of the bootm command, we have to
do it by hand. what is the point of the header?
o Rampant #ifdef's based on the targets. There is code in the
arm specific Linux command for several different targets to
copy the ramdisk to RAM. This makes for very poor
maintainability.
o 2007.jul.22
o Slug is having problems at 128MiB of RAM
o we could use a memory test command, just for grins. The code
is there but there is no command. This also requires us to
have a way to determine where APEX memory resides.
o Fix the memscan command to not be destructive.
o 2007.jun.5
o checksum verification.
o Use cases include copy to flash with checksum.
copy from xmodem to memory and then to flash.
Copy from running version to flash.
o What do we do if there is already a checksum? Can we detect
it? Should this be automatic in the copy? Probably a good
idea because we make sure there are no errors anywhere. Note
that we would need to leave space after the binary for this,
for APEX.
o One of the problems is that we need to have a checksum on the
checksum block if there is anything more than a simple
checksum and length there. We don't want data that cannot be
verified. For example, if there is a date, we want to know
that the date is correct.
o If a checksum is appended to APEX, it will be stored as part
of any load, xreceive or tftp, but it won't be included as
part of the $apex variable.
o If the block is aligned, we should make this alignment
relatively small.
| CRC-PAYLOAD | LENGTH-PAYLOAD | CRC-DATA | TIMESTAMP | DESCRIPTION |
o Seems like this block should be aligned to a 16 byte
boundary. The timestamp is a 32 bit UNIX date. CRC-DATA is
the same CRC algorithm run on the timestamp and description.
o What happens when we have a file with a checksum and we want
to verify it with cksum? We cannot verify an image if there
is our trailer already there. Perhaps not a problem.
o The above format gives 16 bytes for a description, not null
terminated.
o The version can be determined by the size of the block for
which the the CRC matches. Clumsy, but we don't waste bits on
something redundant.
o 2007.jun.3
o GCC 4.x and EABI. The missing function is __aeabi_uidivmod.
Check the kernel.
o Fixed. We can link with AEABI.
o 2007.jun.1
o It is possible to modify the environment s.t. the startup
commands prevent the system from booting. Very bad. We may
want a way out, e.g. ^C at startup (or another key) to disable
startup commands.
o 2007.may.26
o CRC revisited
o I've discovered why the CRC code is having problems.
o The apparently popular implementation isn't exactly compliant
with the standards. It does compute a CRC, but it doesn't do
it in the same manner as the cksum program.
o there is likely to be little reason to stick with their
implementation as it doesn't yield smaller or faster code.
o We need to decide if we want to
a) use a header for the CRC, or at a minimum, a header to
define that there is a CRC.
b) this header couple include room for a jump, 1 ARM instruction
c) or we can use a trailer. Trouble with a trailer is that
the cksum program cannot be used directly to append this.
d) use a magic number anywhere to cope with finding the
checksum.
e) trailer/header could be a 16 byte structure. Perhaps more.
f) could fall back on uboot header, but disinclined due to
excessive complexity.
o 2007.may.19
o Would be neato to support uImages. I don't *like* the idea, but
it could be kinda handy.
o Need to implement multiple checksum algorithms so that we can
compare easily. For example, the chksum algorithm, while
inappropriate for our stream checksum needs, is good for
comparing with an offline copy.
o Need to revise the CRC algorithm to comply with POSIX.2
standard. Here's the text from a web page describing the
algorithm. Note that the polynomial is the same as the CRC32
polynomial used by Ethernet. ... on second thought, I cannot use
this algorithm because it depends on the length of the message
and there is no way for me to compute this in a stream.
Perhaps, I'm better off using the exact algorithm in the Ethernet
standard.
The default CRC used is based on the polynomial used for CRC error
check-checking ing in the networking standard ISO/IEC
8802-3:1989. The CRC checksum encoding is defined by the
generating polynomial:
G(x) = x^32 + x^26 + x^23 + x^22 + x^16 + x^12 +
x^11 + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1
Mathematically, the CRC value corresponding to a given file is
defined by the following procedure:
The n bits to be evaluated are considered to be the
coefficients of a mod 2 polynomial M(x) of degree n-1.
These n bits are the bits from the file, with the most
significant bit being the most significant bit
of the first octet of the file and the last bit being the
least significant bit of the last octet, padded with zero
bits (if necessary) to achieve an integral number of
octets, followed by one or more octets representing the
length of the file as a binary value, least significant
octet first. The smallest number of octets capable of
representing this integer are used.
M(x) is multiplied by x^32 (i.e., shifted left 32 bits) and
divided by G(x) using mod 2 division, producing a remainder
R(x) of degree <= 31.
The coefficients of R(x) are considered to be a 32-bit
sequence.
The bit sequence is complemented and the result is the CRC.
o 2007.may.17
o NAND flash driver rectification
o Need to resolve how we determine page size and addressing when
we are relocating
o Need to determine how best to handle early relocation wrt page
size and addressing.
o The lookup table is nice, I suppose, but I'd rather work out
either a config method or a way to decode the size that is
uniform.
o CRC on copies
o It should be possible to compute the CRC of a block of data
s.t. we store the image followed by the CRC and we are safe to
copy until the crc goes to zero.
o This was confirmed by Abdul as he's done it.
o This would allow us to do something like
copy nand:0+* $bootaddr
where the * means copy until we find that the CRC has been
met.
o May need to revise the syntax so that we know the upper limit.
copy nand:0+2m* $bootaddr
This way we know to copy no more than 2m, but report an error
if we get to the end of the block and the CRC fails.
o 2007.may.13
o Need to regularize the configuration options. For example, the
VMA is an APEX parameters, not a platform parameter. We want
the configuration options to relfect the most logical placement
so that we don't have redundant entries.
o Thus, APEX_VMA, KERNEL_LMA, USE_RAMDISK...
o We want to support SRAM or other early RAM access. The most
logical way to do this is to have a region where this can
happen. Trouble is, it either needs to be required, or not.
Moreover, it could be SDRAM once SDRAM is initialized. Need to
think more about this. Perhaps the best way is to locate the
stack at the 'correct' location after SDRAM is available.
o We should move APEX up some in memory so that we can support
larger kernels, 4 MiB, at least.
o 2007.may.12
o We want to make it a requirement that there be a stack when we
call apex_relocate(). These functions are notoriously finicky
and we'd be well served to allow for a stack to accomodate
register spills and more complex code. It would also normalize
the MMC boot process where we needed to allocate a boot stack
for exactly that purpose. It could even be the case that this
is a configuration time parameter and that it is setup
automatically just before the relocation routine begins. In
this case, it may be desirable to explain to the user how this
stack is used and how it must be in a region of memory that
cannot be clobbered.
o APEX has gotten kinda large. Even when the small option is
selected, the loader seems to be swollen. It could be that this
is partially due to the explicitly large initialization code for
the mx31 target (which gave an APEX of 27k at the smallest). It
seems reasonable that an APEX, free of any drivers, be less than
16K. It may be the case that thumb support will be the only way
to get a truly small loader.
o It would be good to have a way to generate a BDI init code-let
so that we can initialize SDRAM (and such) for the user using
the BDI capability for running code directly on startup. In
fact, it may be possible to do this with a special build. Whoa.
o 2007.may.11
o Need to move *all* configurable parameters to the Kconfig.
o Need to move bootstrap into segments so that we can properly
initialize when we don't have access to a stack.
o Should allow the initialization code, after SDRAM init, to setup
an early stack. It could even be the _correct_ stack address
since we don't really care. This may make some portions of the
code *much* easier to handle.
o RedBoot and APEX
In debugging an update to APEX, I found that the startup copy
commands would tend to fail. The copy would have some garbage
in the middle of the destination: 0x632b0, 0x63f00, 0x638c0 when
copying the kernel to 0x8000.
Changing the kernel command line to *not* use variables for the
copy source and destination appeared to fix the problem, but that
wasn't a very satisfying solution. Looking at those memory
location from RedBoot revealed that the contents of memory at thos
locations appeared to come from the contents that were there when
RedBoot was running. It was easy to detect the error by
performing a checksum. Oddly, a second copy of the data was
always successful. I suspected the cache.
Revising the cache flush code to more closely match that which the
kernel implemented didn't seem to fix the problem. What did
seem to fix the problem was disconnecting the Ethernet cable from
the Slug while booting. Thus, I suspect that the problem is
caused by the NPE still thinking it can write to memory.
Really, this is probably never going to be a problem since RedBoot
ought to normally disable the MMU and caches before executing the
second stage boot loader (or kernel) and I suspect that this
oddity won't occur under normal use.
o Support for non-ARM
o The biggest hurdle to supporting non-ARM architectures will be
the implicit dependence on stack-free procedure calls.
o Some platforms, such as PowerPC, may have SRAM that can be used
for a stack until SDRAM is initialized.
o It may be feasible to rework the initialize_platform code to run
inline instead of using calls. Really, there isn't much that
must be done from the standpoint of execution.
o x86 is the real bear, but I don't think we really care about
that.
o *** Note that these considerations should be accomodated once we
change a) to a single code stream for the initialization (which
is nearly there in May 2007) and b) to add an early stack to the
configuration. Even x86 ought to work under these
circumstances.
o Enviroinment/alias variations. The default state is to use the
simply named version of each variable, aliases before environment
variables. If 'variation' is defined among the aliases, it is
appended to the variable name and that one is checked first. If
that one is found, it is used. Otherwise, the default is used.
For example, when variation is "-1", "boot-1" would be used to
boot the kernel.
This new feature requires support in two ways. First, we need
another standard environment variable to hold the boot preparation
commands, "setup". So, "startup" is called first. It may set
"variation". Then APEX calls "setup". Setting the variation will
can change *all* variable references including driver regions.
So, for example, the variation can be used to set the underlying
partition for booting simply by changing the base device. This
can also be used to change some other environment variable used as
a reference elsewhere.
Now, we need a command, platform specific, that determine the
variation and sets the appropriate alias. It would be put into
the startup command: "check-variation", "query-variation",
"select", "survey". On nslu2, for example, it would check whether
or not the reset button is pressed. If so, it would set variation
to '-alt'. Perhaps the suffix is part of the command. At this
point, the boot would proceeed normally.
o Very slow environment region means that an empty environment makes
the boot-time very slow. So, we should check it once and if it is
empty we can assume it is still empty when the first word is
0xffffffff.
o Add option to change the write throughput spinner for the NOR
driver. The lh7a404 is much faster that the lh7952x's and the
spinner should reflect this.
o Alignment trap handler would be a good thing.
o We could catch errors instead of failing completely.
o Not worth too much code.
o descriptor_d.width
o annotates a descriptor, telling the driver what width the caller
would like used.
o Force 1 byte width for CF interfaces.
o Force 2 byte width for 16 bit only access
o Force 4 byte width for unforgiving CPU registers, e.g. IXP
o This needs to propagate to dump and fill so that we can control
the access to some regions.
o We could annotate memory, for a given target, so that the memory
driver does the right thing.
o Need to fix the envmagic script because it it a significant
portion of the time it takes to build on the nslu2.
o Driver enhacements
o Query infrastructure. There presently isn't a way to ask a
driver anything. A query infrastructure could help, but it must
be very light weight.
o Query for the base address. This would be used to convert FIS
regions into nor: regions. At the moment, FIS regions are
mapped to mem: regions which means two things. First, it is
possible that the flash is not in READARRAY state. This turns
out not to be true, but it *could* be. Second, we cannot write
or erase the FIS partition which would be a convenience. Having
a way to query the start of flash would mean that we could
return a valid nor: region.
o Query for block size. This would allow us to detect erases
operations that don't request erasure of the whole block. This
would allow a safe environment erase function, or perhaps a flag
to the erase function to handle this case.
o Must implement safe flash region erase. Must must must. (see above)
o We've implemented alias/environment variables for the block
drivers for the filesystem and partition drivers. This may mean
that we need to move these drivers such that the init's follow the
environment initialization. At the moment, this isn't the case
since none of them do anything at init time.
o Implement uniform driver basis in environment. There is no reason
not to use an environment variable for the default driver for each
of the higher level drivers. This means we can, for now,
circumvent the need for layering drivers with regions. Also, this
will make it more obvious to the user how to change the underlying
driver for each of those systems. *And* we can then create a DOS
partition driver....maybe.
o Environment/alias part is done.
o Document that the initrd= command line option can be used to setup
the ramdisk location. Unfortunately, the parser may not handle
hexadecimal. Need to check on that. It's 'initrd=start,size'.
o SD/MMC driver doesn't have timer_fetch() function because it
hasn't been initialized and the functions aren't in .bootstrap.
It might be worthwhile making this work.
o Add a 'show' function so that we can 'show drivers' and 'show
services' and maybe other things.
o Support for arrow keys
o I believe that the only hitch is that we need to cope with the
multi-byte-ness of the codes.
o Perhaps a simple state machine will do.
ESC [ A
o The [ will be suppressed as will the next character.
o If the loader is small, the relocation code performs adequately.
I haven't measured the performance, but it seem to be reasonably
quick to start.
However, if the loader were substantially larger because, say, it
included a splash image, we would probably want to do something
about the relocation routine.
The easiest thing to do is to allow for the instruction cache to
be enabled early, before there are MMU tables. This is OK for the
ARM7/ARM9 AFAICT because it assumes linear memory mapping *and*
the relocate inner loop is a simple four (or so) instruction
fragment.
There is more, though. It may be desirable to enable the
instruction cache while uncompressing the kernel. I suspect that
the gzip decompression would be noticeably faster with the
instruction cache. However, we don't know if the kernel will
tolerate the presence of the I-cache once it boots.
o There is now code to do so, but it doesn't appear to make a
different on the ARM9.
o Copying from TFTP doesn't reliably finish. The transfer tends to
halt, either after no blocks, or one block. We need to diagnose
the nature of the failure and either implement a retry, or come up
with a method to restart the operation. For example, it could be
that we restart transparently so that we can see to the place
where we are attempting to read.
o The envmagic is weak. If a variable isn't defined for a given
configuration, but it exists elsewhere in the code, the magic
number will be the same when thay variable is added to the
configuration. So, either we insert the string into the
environment, or ... I don't have another plan except to ignore the
problem.
o arp_resolve returns a string. It should be able to return an
error condition. This means that a ^C will terminate the ARP, but
it won't tell the user that that is the reason.
o Command history.
o Should be easy to implement
o Ring buffer of strings.
o Say, 4k
o Each line is entered as a null terminated line of text followed
by a word aligned length.
o There is a pointer to the next available position in the buffer.
o Previous command is found by back tracing until the length of
the previous command is zero or the length bypasses the pointer
to the next available space in the buffer.
+ Implemented
o There is an error in the dump code. It doesn't dump the CLCD
registers correctly. This is not excusable.
o Improving network responsiveness
o Since there is a limited number of receive buffers, we may need
to change the structure of the network protocol drivers
o Need a flush function to flush receive buffers.
o RARP is a good example. The response from the server is nearly
immediate. If we don't clear the buffer, it may take a timeout
and retransmission to see the reply
o Still, need to inspect the network traffic to make sure this is
the reason for the delay on rarp.
o May need to wait for the link to come up before sending the
network configuration packets. Don't know, but we've added the
flush before sending the rarp packets and it still takes a while
for rarp to respond.
o Interrupt key
o There are places, especially in the network code, where console
activity will cancel the operation. Trouble is that we don't
want it to be overly sensitive. It would be good to have some
defined keystrokes for for break and cancel. ESC isn't a good
choice because we're like to be able to use arrows at some
point. ^C is better.
+ Implemented in the console code.
o We can probably get away with a Kconfig option and no UI to
change it.
o emac-lh79524
o Looks like there is a problem transmitting when packets are
received.
o Need to get a better picture of the network traffic. ethereal
shows that tftp is fine in a full-duplex switch situation.
o In half-duplex as I have, there are lots of problems
transmitting when there is traffic on the wire. Need to
instrument.
o BTW, the SMC91x has no problem with this. In fact, as far as I
can tell it always handles retransmits flawlessly.
o Actually, the problem appears to be that the emac is easily
overwhelmed by packets when in promiscuous mode. By eliminating
the CPYFRM bit, it seems to be stable with tftp receives.
o Network traffic, continued
o I've created an ethernet_service function with a user supplied
termination function.
o The user can let the receives continue until an arbtrary set of
conditions are met.
o The only pieces missing is a way to hook the receive so that the
user's function can gain access to inbound packets.
o Simplicity. Needs to work for internal features as well as
external ones. For example, rarp packats should not be in the
core since the user may never care about them.
o We can simplify by eliminating the interface, for now.
o register_ethernet_frame_receiver(receiver, priority) Either a
static array (which I like) of limited length, or a linked list.
Latter requires some sort of memory management, ew.
o int frame_receiver (frame), returns zero if the packet should
continue to be checked, non-zero if the packet has been
received and there is no reason to continue processing.
o There can be receivers for icmp, rarp, and arp built in. We can
hook dhcp.
o The receivers must agree to be efficient.
o We may want to engineer the drivers to be able to cache a couple
of packets.
o Here's what we need to do. Ethernet receive should do some
cursory checks, verify that the MAC address is interesting and
the IP address is relevent when there is an IP header. After
that, the receivers can be used to handle the rest of the
verification.
o We need a port allocator with a somewhat random initial value.
If that isn't possible, we should at least be able to count up.
o Note that none of this really helps with multiple consoles. We
still need to eliminate statics and there must be a want to
efficiently execute more than one thread. Remember that the
SSEM did this, but it has select. Perhaps we should do the
same. Hmm.
o Network traffic state machine
o We've been able to keep this application simple since there has
been only one thread of execution and one task
o Network changes all of that
o telnet sessions will also make it necessary to be more flexible
o Need to have threads of execution
o Network packets can be queued to a thread
o I think we can have a function that handles network traffic in a
polled fashion, dispatching ICMP and ARP, if we choose, and has
a couple of terminating conditions: receipt of a relevent packet
or a timeout.
o Trouble is that we may receive a packet and be busy elsewhere.
o We can service the network connection in some fashion while we
do other work, but we may need to queue packets for processing
since the network interface has limited capability for buffering.
o Perhaps this packet queue can be limited to the network, for
now.
o It would be good to think ahead here. Can we add logic to the
network layer so that we can queue packets intelligently and
process them when the time comes. For instance, we register
discriminator functions for each task that can deal with network
traffic. Discriminators perform the queuing themselves. There
comes a time, later, when the discriminator can do what it likes
with the packets. It may even be the case that we do the
network logic immediately. For example, the tftp driver
registers a discriminator that can receive data packets, but it
will automatically stop when its queue is filled. The core
routine that is using the data will call the service function
when it can. If the tftp_read call is entered and there is no
data available, it will block until there is some. Essentially,
it will enter a special form of the service loop that terminates
on a timer instead of returning immediately when there is
nothing to do.
o *** How can this be generalized to handle multiple console
streams? Can it be? Can we do a round-robin for console
streams such that the separate threads of execution each get a
chance to handle command, process input, and so on? This seems
like it may be overkill for a simple monitor, but we will need
something if we start to be able to handle telnet sessions as
well as a USB console.
o tftp write requires that we know if a descriptor is for reading or
for writing. There is nothing in the interfaces to support this at
the moment. Either we cache the file-open data, or we let it all
be lazy and perform the open when the first read or write call is
made.
+ Reading works fine at the moment.
o descriptors really need to allow drivers to define a
context. tftp is probably the most compelling case for
this...especially once we've opened the connection and we need to
keep track of the open file. Alternatively, we can continue to do
as we've pleased which is to use a driver global. Ho hum.
o The filesystem drivers don't say enough about where they get their
source devices. Perhaps it would be best to use aliases so that
we can control it at runtime.
o The adc test driver needs to be able to check for touch events.
o Do we want to be able to show all variables, env and aliases in
the same command?
o ipconf command
o ipconf rarp
o ipconf dhcp
o ipconf boot
o ipconf 192.168.8.203/24
o ipconf clear
This will make it clearer to users how to clobber the
configuration. Also, we may be able to enforce reconfiguration
this way.
* There are two copies of the adc driver, one in the 7952x directory
and another in the 7a40x directory. I'd like to reduce the
redundancy, but that would require moving the driver to be outside
of mach-*/. Either make a mach-lh/ or put them in drivers/. The
trouble is that I need a way to make sure that...Perhaps I should
have a drivers-lh/ for shared drivers specific to Sharp products.
That way, I can make it clear.
* Done and it's nice.
o We've added RARP which can configure the IP address. There is a
problem, tho. The user can get the IP address from the alias
list. If the user clobbers it, the host_ip_address isn't
clobbered. The user might think that erasing the alias removes
the IP address setting. We need to either detect the loss of the
alias, or we need to no store the IP address in an array.
o Need a default command line setting in the config file. It should
completely override the platform default, when present.
o Pipes should work for streaming between drivers. [g2] wants to be
able to specify a list of drivers/regions to try. This may mean
I'll have to combine the parse and the open methods so that the
open can continue until it succeeds.
E.g. nor:128k+1m|(ext2,vfat):/boot/zImage
Trouble ensues when the options are more complex, NxM.
* Aliases can be simple text substitutions.
alias flpart nor:128k+1m
alias kernel /boot/zImage
flpart|(ext2,vfat):kernel
* Done. Substitution is with $.
o The splashscreen should be able to be read from a filesystem
copy ext2:/boot/splash fb:
This will also require that we be able to store an image in the
loader and copy it out. Aliases make this possible
alias splashimage ...
+ We have a splash command that reads from a region but doesn't
write to one. In other words, we *could* do as suggested, but
there isn't much reason for it from the POV of simplicity.
o Aliases mean we can have references to
alias env nor:128k+32k
alias apex mem:...
aliases must match exactly. Always. I'd like to make the
environment alias be environment, but partial alias matches might be
too much of a strain. Perhaps near matches are OK if there are
no other near matches.
o It looks like there is a conflict with using the name ./config for
the configuration file and all of the config targets. I believe
this to be due to hidden dependencies within make. Bad make. So,
we're going to go back to the .config files for now. I'd use
conf, but that is the name of the configuration program. It may
take some time to sort this out and make it neat.
o There is a need to be able to control the access width in the
memory driver. Sometimes, for the purpose of debugging, it is
helpful to be able to read different widths. The memcpy command
is probably too coarse in some cases as is evidenced by the fact
that dumping from the CF flash region on the 79520 does the wrong
thing.
o I believe the problem really has to do with the chip select
issue. Without reads from system memory, the chip select
doesn't toggle and the CF fails to return a different memory
location. Thus the real problem is that the memcpy performs too
many transfers at one time.
o Finally, I don't know what the right solution to the problem
should be.
o Dump could be made to do the right thing with a switch to read
only one byte (or word) at a time. This is probably desirable
anyway since we could use a mode to display words or
half-words instead of just bytes.
o It might be helpful to make the envmagic script more repeatable.
Need to look into this. Seems like it changes when there are no
changes to the environment variables.
o An erase confirmation might be helpful, but it requires that the
driver participate. It would be helpful to tell the user exactly
what will be erased. Note that BDI doesn't, and I don't think
that other bootloaders do. Still, it would be helpful to let the
user know what the erase is going to do.
o Separate the string functions so that the linker can include only
those that are needed.
+ Done.
o I think that the partition logic needs to move to the CF driver
(and other block-level drivers) so that the filesystem code can be
cleaner. It allows us to read from unpartitioned devices as well
as any other random-access, byte stream.
o This change will require that the spec strings are filled out to
handle chaining. We would do fatfs->dospart->cf. Might seem
heavy-weight, but it means reasonable flexibility. It ought not
be much code and the calls can be handled with simple
pass-through in the case of read().
o Looks like the ADC test driver may interfere with the kernel
booting properly. First I've seen of it. It's OK, though, since
we don't need it.
o Might be good to have a paranoid setting that lets us require
confirmation before clobbering flash or eeproms or whatever. This
could be a list of important regions. The region list could be
bothersome since there is aliasing unless it is specific to the
driver that can clobber it. Then again, not. Since writing has
to go through the driver that understands the true addressing. It
means that we have to protect nor:#+# for flash and cannot depend
on mem:#+# to be recognized as being the same.
o Buried region strings must be revealed. The emac driver has one
for the MAC address EEPROM. The fatfs driver has one for the
underlying block device. The latter may be best revealed with an
environment variable...or not. Don't know about the emac one.
I intend thay the user specify the fatfs support driver via the
specification string. fatfs:cf: or something.
o Need to rectify the vpen_enable code in the flash drivers. It
ought to be something defined in the hardware file s.t. it is not
compiled unless needed. IIRC, it was smaller to put the vpen code
into functions than to put it inline. However, it is easier to
code if it can be inlined. Hmm.
o Would be nice if ^C could break into long-running functions.
Could be dangerous, though, e.g. writing to flash. More thought
needed.
+ Supported and implemented in several places.
o I am suspicious that the nor-cfi erase code isn't quite right.
When asked to erase nor:0+120k, I think it erased the block at
nor:120k.
o Checksum function doesn't appear to work over FAT read files. It